共计 7373 个字符，预计需要花费 19 分钟才能阅读完成。
前言
杨帆，CODE.FUN 创始人 & CEO，前腾讯 QQ 团队高级工程师、Win8QQ Team Leader，TGO 鲲鹏会成员，是一个技术喜好狂热者。2017 年正式开始守业，心愿通过 AI、编译器等相干技术，在跨平台、代码生成器、低代码等多种解决方案的交融下，打造下一代软件工程解决方案。
通过近两年的技术打磨和算法改良，推出产品 CodeFun，通过 UI 设计稿一键智能生成源代码，可让研发效率至多晋升 500% 以上。在声网开发者守业讲堂 • 第 5 期中，杨帆以「 拆解研发流程 做好摸索型我的项目的过程治理 」为主题进行了分享。
本文基于演讲内容整顿，为不便浏览略有删改。
01 我的项目背景与起源
1、倒退历程
CODE.FUN 其实是一个 UI 设计稿转代码的工具，咱们在做 App、小程序时都须要先做一个 UI 设计稿，那么将其上传到咱们的平台之后，就会全自动生成微信小程序、VUE、React 源码等，有很多种平台都能够抉择。
这说起来可能很容易，但实际上要真正做一个让程序员能够为之买单的代码，要尽可能地模拟人手写的代码，并且尽可能绝对优雅，在这一系列要求加持下，咱们发现这是一个十分大的坑，因而这几年咱们基本上都在经验一种匍匐前进的过程。梳理下来，整个过程如图 1 所示。
■图 1
咱们是在 2019 年 9 月份启动了我的项目，直到 2020 年的 6 月份才公布了第一个版本来进行内测。在内测了一段时间之后，咱们发现用户并不认可咱们的产品，尽管一开始大家都对咱们的产品很感兴趣，然而体验后发现并不能达到其料想的成果。起初陆续进行了大量的用户调研和访谈，咱们决定放弃内测，回炉重造。
就这样又过来了一年，产品终于在去年 7 月份正式上线，这间隔咱们写下第一行代码整整过来了两年工夫，而且两头还经验了到职潮，咱们的团队从原来的十多个人到起码的时候只有 6 集体了，这真的是一些十分苦楚的变动。现在，咱们又对算法进行了全新的重大降级，并且在 8 月份的时候正式启动商业化。
2、技术路线与用户画像的屡次变迁
1）技术路线
在这三年中，咱们碰到了很多问题，针对这些问题咱们的技术路线也经验了屡次的变更，具体如下。
- “瘦”Plugin
- “富”预处理
- 智能分组预测
- Flex 弹性预测
- CSS 压缩
- 输入代码
因为最早写代码的时候，不可能构想得很完满。因而，在经验这一系列的变动当前，咱们的团队当初提倡回绝面向未来编程，所有都能够重构，所有都能够再优化，不要一味强调大而全。
2）用户画像
对于咱们的产品到底卖给谁这个问题，咱们也经验过一些变动。最后咱们的指标用户是工程师，起初转变为设计师，再起初又变为产品经理。可见，在不同的周期对于用户的定位也会产生一些不一样的想法。
02 翻新路上，项目管理的微小挑战
1、面临的挑战
当面对这么多未知问题的时候，咱们的项目管理其实面临了微小的挑战。总结下来，第一个挑战就是我的项目周期未知。因为咱们基本不晓得须要多久能力实现我的项目。个别咱们做零碎，可能只须要将页面、接口等整合到一起，而后做好运维工作就能够上线了，之后的工作交给经营跟销售来解决即可，后面的产品研发就只须要思考人天的问题。但对于咱们来说，我的项目周期则是齐全未知的。
第二个挑战就是技术难度未知。在最开始做我的项目的时候，咱们其实是想做低代码，比方拖拽。咱们从 2018 年开始，花一年工夫做了一个拖拽的低代码零碎，那时业界还没有低代码声音。过后，在我的项目做进去之后，客户并不认可，当然这波及到客户的了解、易用性以及整个行业周期等问题。但同时客户也提出，他还有大量设计稿的 UI 没有做完，咱们是否把 UI 变成代码。本来咱们构想这个工作只须要两三个月的工夫，但后果咱们一做就做了三年工夫。这两头咱们当然也想过放弃，狐疑过技术路线是否有问题，可见，技术难度是很难精准评估的。
第三个挑战就是否可能生存未知。当零碎我的项目启动的时候，对于本人能不能生存下来都是一些未知数。
这几个方面叠加起来，如何治理好我的项目、如何使团队内想法保持一致、如何在这么长的周期中帮忙团队成员放弃信念都是微小的挑战。
2、支流研发模式
说起支流的研发模式，大家基本上都会想到麻利开发。对于麻利开发，我在网上找到了图 2，它展现了一些十分经典的麻利流程，包含迭代、周期、每日例会等。
■图 2
举一些大家最罕用的经典的环节跟流程，比方从产品策划到需要宣讲，到需要开发再到开发测试、体验上线，这就是我称之为十分经典的流程，只有依照这个流程走就必定不会错。这是一个规范的流程，在这个规范流程中咱们为了信息的通顺，还须要一些十分重要的沟通机制，包含需要评审会、需要宣讲会、架构评审会、迭代总结会等。这些就是咱们最常见的一些麻利开发的环节。我本人对这个流程做了一个总结，我感觉用一句话来说就叫作“数着迭代过日子”。
3、⽼⽣常谈的痛点
在经验需要研发的过程中会遇到各种各样的问题，这里我列举了一些陈词滥调的问题，大家能够看一看本人是否也遇到过。
- 当团队规模扩⼤后，需要的沟通、⽬标了解，各⽅⾯开始呈现偏差
- 为了解决这些偏差，开始上零碎、定规定
- 交付延期，全天下的通病
- 要害是做进去的东⻄也不⼀定是⾃⼰想要的
在团队最早开始守业的时候，可能只有两三个人，此时没有什么沟通老本，但当团队扩充之后，不同能力级别的共事肯定对需要的沟通以及指标的了解是存在偏差的，在团队外部定一些规定后，尽管减少了保障并进步了效率，然而在未知的状况下交付延期是必然的。我感觉延期不是最要害的，最要害的是当你在做一些探索性的时候，如果失去的后果不是你想要的，该怎么办？我对这个事件做了一个总结，就是当咱们把一个人变成了写代码的机器的时候，他只会为本人的事件负责，如果用这种形式去做探索性的需要，那么肯定是要完蛋的。在这种状况下，咱们就要想方法在漫长的周期中寻找新的形式走向胜利。
03 突破迭代，寻找新的共识机制
1、什么是共识？
我认为，要解决后面提到的问题，就应该突破迭代，寻找一种全新的共识机制。什么是共识机制？举一个简略的例子，比方两个人吃饭，一个想吃火锅，一个想吃烧烤，在这种状况下大家呈现了意见的一致，而要想达成共识，无非就是有人退让，大家达成统一。然而在研发中，我认为共识其实是对所要摸索的指标的一种认可。
以 UI 设计稿转代码为例，咱们把将产品做到一种好用的状态作为指标，那么什么叫好用呢？这个好用是针对产品经理还是针对开发？又或者是针对代码冗余度、代码品质？对此，咱们很容易产生分歧，特地是在团队壮大之后，通过肯定的信息传递，共识是肯定会存在偏差的。
所以咱们能够将指标看作一头大象，当在做翻新的时候，更像是在做盲人摸象的过程，咱们并不知道将来的路是怎么的。此时，如果只是十分简地提口号和指标，那么大家摸到的部位大概率是不一样的。所谓的共识，我认为就是要让整个团队中不同的角色、不同的岗位所看、所想和最终实现的东⻄尽可能⼀致。
2、如何建设共识
既然翻新是未知的，那么咱们该怎么建设共识呢？这里我提出了一个观点，就是共识是要可量化的。如何对一个共识进行量化呢？具体如下。
1）OKR 思考法
目前 IT 行业中始终在提从 KPI 过渡到 OKR 的一种模式，并且很多公司也曾经开始践行。咱们明天不介绍 OKR 自身，也不波及 OKR 到底怎么用。我这里所说的 OKR 更多是一种工作办法或者是一种思考问题的形式。
我集体认为万事皆可 OKR，它是一种可量化的思维形式。我先疾速介绍一下 OKR，绝对于传统的 KPI 这种绩效指标形式，OKR 其实是把它分成了指标和要害后果两局部。比方咱们的指标是让 CODE.FUN 成为全中国最厉害的前端产品，其实有一些关键性的后果能够辅助证实这个指标是否达到，要害后果 KR 和指标之间其实是有一个证据关系或者是一个撑持关系，它自身是能够被量化的。比方第一个要害后果是用户冲破 100 万，第二个就是说全社会每天都看到有一线的技术媒体在报道咱们，这两个后果合起来就能证实 CODE.FUN 成为全中国最厉害的前端品牌的指标达到了，这就是一个 O 和 KR 的关系。
2）OKR 思考法量化共识
如何使用 OKR 量化团队的共识呢？这里我列举了几个因素，第一个是场景和景象，第二个是定义问题，第三个是指标，第四个是 KR，第五个是 todo。
假如有用户反馈在上传设计稿后，它的元素从红色变成了绿色，又或者用户反馈页面上传后与原始设计稿不一样。这些用户反馈的还原度品质问题就是景象，或者说它也是一种场景。有了这些景象跟场景之后，咱们就要从新来定义问题，举例中的问题是要做还原度监测，那么定义问题就是咱们心愿产品或者零碎的还原度可能达到十分高的品质水准，甚至是 100% 的还原率；也能够是心愿用户的满意度更高或者是用户的留存率更高。如果咱们将指标定位在解决留存率的问题，让整个零碎的还原率达到 95% 或者 98%。那么要达到这个指标，实际上 todo 必定是做一个监测零碎，然而即便做了监测零碎，也不肯定可能晋升还原率，其中还波及批改 bug 或者进行新的算法等问题。
因而，咱们会发现两头少了一层，这就是你的要害后果。咱们能够构想一下这里的要害后果，首先是要计算出零碎以后的还原率，有了还原率之后就能够梳理出各种场景的问题，有了这这些问题之后，咱们能力想方法进行解决。
咱们在定义问题的时候抉择了晋升留存率，但在晋升留存率的过程中，指标也会发生变化，因为晋升留存率有很多种解决办法，不肯定是晋升设计稿还原品质，可能有另外一个问题显得更紧急或者解决另外一个问题收益会更大。所以咱们在围绕这五个点对立思考的状况下，其实能够转换最上面的 todo 甚至是指标，因为真正最外围的是定义问题。定义问题就会波及疗效，定义问题后，咱们最终还要思考到底要达到怎么的疗效。其实咱们在 todo 的时候常常会犯一个十分大的谬误，就是忘了背地的初衷，只是很机械地做需要而不去思考。这就是我本人总结的一个叫 OKR 思考法，这里的 OKR 非彼 OKR。
04 翻新总有意外 当共识不可量化时
并不是全世界所有的指标都能转成共识，肯定存在一些指标是不可量化的，那么在这种状况下，该怎么达成共识呢？此时就须要建设一个新的共识模型。
1、建设新的“共识”模型，反馈生成公式
对于建设共识模型，咱们外部用的最多的是反馈，因为它代表了景象、场景、用户的声音，其中蕴含着很多信息能够提供指引，沿着这些反馈解决优先级，就肯定能找到一个良性的倒退门路。上面列出了四种获取反馈的形式，我称之为反馈生成公式。
- 在外部建设需要“抛售”制度
- “随时随地”启动产品内测
- 开设“便宜”的用户反馈渠道
- 建设“无效”数据指标
这里要留神，这个公式是每个角色、每个团队本人去寻找的，我这里列出的公式是在不同的工夫周期、不同的团队规模下所使用过的一些办法，并且咱们始终在对它进行调整跟优化。所以这些公式只适宜于过后的咱们，并不一定适宜于当初以及将来的团队，并且它大概率是不适宜于你。这个分享的目标是心愿帮忙大家找到一种建设本人公司的思考形式，而不是生吞活剥咱们的公式。因为咱们做的是 SaaS 产品，它有比拟大的用户量，在这个层面上咱们获取反馈是绝对比拟容易的。如果你是一个纯 B 端或者纯商业化的解决方案型的产品，可能就不能齐全来照搬咱们这样的链路。
1）在外部建设需要“抛售”制度
抛售其实就是销售，咱们要建设需要销售制度。那么什么叫需要销售呢？咱们认为每一个研发做的性能都投入了老本，包含工夫、金钱等。在投入了老本之后，他发明了这个需要，那么就要负责在外部进行销售，看有没有人为这个需要买单。咱们传统的做法是一边提测一边体验，对产品经理提出的反馈进行解决后测试上线。此时产品经理体验的欠缺度依赖于他集体的能力，这样很难失去十分公正的评估。所以咱们就要把传统的十分依赖于某一个单点产品经理的体验机制扩散到整个团队中，使人人都成为产品经理，咱们过后做了这样一种模式，就是要求每个开发在做完需要后，先在团队内寻求两到三个人进行用户反馈，这就是需要抛售制度。
2）“随时随地”启动产品内测
这里有两个关键词，一个叫随时随地，一个叫内测。随时随地就是说，当任何人在做任何性能的时候，一旦呈现不确定的问题，就能够立刻开启一个内测。尽管思考到所在团队的规模、架构不同，其可施展的空间不一样，但咱们还是心愿尽可能做到随时随地，不要因为团队的制度而受到限制。另外，也不要因为技术而受到限制。产品个别分为现网、测试环境和开发环境，在这些环境下也要可能随时随地拉起一个全新的产品部署环境供他人体验，同时又不跟现网发生冲突。内测就要求速度快，要省略繁缛的步骤。总结来说两个很重要的点，第一个是外部零碎的 CI/CD 的 DevOps 零碎肯定要足够的欠缺，让任何人都能疾速拉起一套本人的体验环境进行散发。第二个就是在团队外部不要做太多限度。第三个就是要有一个散发的渠道，能够随时随地取得信息。
3）开设“便宜”的用户反馈渠道
便宜是指沟通老本很低，不能妨碍用户找到你。比方当初很多云厂商都喜爱工单机制，在这样的状况下，咱们就须要开设一个便宜的用户反馈渠道，让他人可能通过网站页面的小气泡、微信群或者论坛形式疾速失去沟通的渠道。除了失去沟通渠道，更重要的是要对用户进行解答和安抚，这样用户才更违心跟你交换。这也是对后面随时随地启动产品内测的补充。如果没有一个便宜的渠道，就无奈招募人员进行内测。
4）建设“无效”数据指标
前三点都是人在做，绝对来老本较高，最初这一点则是通过数据进行剖析。如果仅仅只是查看活跃度，那这一点其实没有什么任何意义，因为咱们是要通过数据指标反过来进行产品的改良。比方用户在体验你的产品时，是否依照预先设立的要害门路操作、为什么没有持续操作等，这些可能在整个数据上报零碎中都是绝对比较完善的。依据这些信息，就能够进行产品的改良，从而疏导用户更好地走上来。
再次强调一遍，这个公式不肯定适宜你，你肯定要找到适宜本人团队、本人产品的反馈公式，有了这些反馈之后你才可能构建你的共识。
2、突破传统研发架构，激发谋求卓越的欲望
有了初步的共识之后，就能够尽可能地通过能够继续更新的形式进行产品的开发。咱们团队用过三种模式，在不同的阶段都失去了不同的成果。
1）组队模式
组队模式就是把整个团队打散分成若干小组，小组成立之后成员支付反馈或者指标工作，并别离根据指标工作。咱们在成立这些小组的时候，就让成员首先推举项目经理，而后给这些小组调配我的项目经费，并要求小组肯定要在我的项目执行工周期中把钱花进来，如果不花就没收。在这种状况下，各小组中的成员是相互成就的，这种互相帮助的气氛十分浓重，他们会自发剖析问题、钻研问题、解决问题。
2）工作挑战模式
咱们团队也不是全年始终放弃组队模式，常常随着不同的工作周期产生一些新的玩法。在这个比拟长期的过程中，常常会有一些来不及做然而又十分重要的工作，咱们将其称为挑战工作。咱们对挑战工作会有一些悬赏机制，激励大家来实现这些挑战。在实现挑战之后，依据工作的大小进行积分，最终能够换成 switch、xbox 等奖品发放给大家。
3）Owner 模式
咱们把传统由产品经理负责的形式变成人人都能够做负责人的模式，不论是产品，还是测试，只有认为本人有能力负责，就能够由其来率领团队。在成为工作的 owner 之后，就能够依据工作的反馈、数据指标等信息来推动需要的治理。它其实跟组队模式有点像，然而组队模式更像是一种短期的激励挑战，而在 owner 模式下，可能就不只是产品经理来负责，也会有其他人能够做负责人。
05 结束语
咱们在 CODE.FUN 研发的这三年周期中碰到了很多奇奇怪怪的问题，咱们依据这些问题对团队做了一些调整，我明天梳理了之前的教训分享给大家，但大家肯定要寻找本人的研发治理公式，不能照搬，翻新没有捷径，致力控制变量能力让胜利的概率最大化，所以咱们也始终在调整，寻找本人的治理公式。
06 问答环节
1、如何晋升研发人员的主观能动性？
首先是筛选人才的问题，为了筛选人才，咱们始终在一直地变动咱们的面试试题，这些试题其实也是一种公式，你能够认为是咱们的招聘公式。往年更新了整个招聘形式之后，咱们寻找的人才其实还不错。其中有一个毕业生，他只花了一天就证实了本人的实力，也没有通过任何的培训，就可能自主的实现剖析工作，并且进行报告的输入工作。这其实就是在人才招聘端可能做的一些优化。另外，就是不要挑战兽性。如果说在招聘侧，不论是招聘的构造，还是薪酬构造方面都没有特地的变动，那么尽可能通过激励形式去做一些优化也不错。比方后面说的组队模式、工作挑战模式和 owner 模式，组队模式是咱们试过最胜利的一个玩法。过后我是把一个刚毕业一年的设计师、一个前端研发跟一个测试组在一起，让他们去制订本人的测试指标，他们为了这个测试指标还开发了一个测试工具，并且在团队外部进行需要的抛售。他们在这个过程中失去了很多的反馈，又反过来持续优化。优化这个性能真的帮咱们团队开发出了十分多的外部工具，外部指标也都还不错。这是咱们用过的一些小花招。
2、在多个探索性我的项目需要下，如果商业效益都不是很显著，如何决策先做哪一个需要呢？
这其实就是优先级的问题了。最近咱们把整个团队从市场、售前到产品研发拉通之后，每周都会开优先级排序的会议。咱们之前是产品排优先级，当初每次散会就是先让市场同学发言，先说他心中的优先级，而后咱们再跟其余优先级比拟，这其中最次要的就是找到一把尺子，这把尺子用来掂量你的优先级。这把尺子其实就是反馈，这个反馈能够是用户的反馈，也能够是外部的反馈。当收集到足够多的反馈的时候，即便没有十分多的数据，然而你心中其实会有感觉，比方很多人提到这个问题，那么这个问题就是亟需解决的问题。所以咱们靠本人心中的教训去评判其实是不够的。在产品总监层级或者能够做到精确判断，但当你做不到这种判断的时候就尽可能依赖于他人。其实有很多形式能够获取优先级。
更多资源
1）理解更多对于声网 SDK 和其余应用案例，请看这里的开发者指南：
https://www.agora.io/cn/community/blog?categoryId=119&offset=0
2）理解咱们的更多 Demo 和案例：
https://www.agora.io/cn/community/demo
3）还能够退出声网 RTE 开发者社区和咱们一起探讨交换：
https://www.agora.io/cn/community/
