杨帆，CODE.FUN 创始人 & CEO，前腾讯 QQ 团队高级工程师、Win8QQ Team Leader，TGO 鲲鹏会成员，是一个技术爱好狂热者。2017 年正式开始创业，希望通过 AI 、编译器等相关技术，在跨平台、代码生成器、低代码等多种解决方案的融合下，打造下一代软件工程解决方案。
经过近两年的技术打磨和算法改进，推出产品 CodeFun，通过 UI 设计稿一键智能生成源代码，可让研发效率至少提升 500% 以上。在声网开发者创业讲堂 • 第 5 期中，杨帆以「拆解研发流程 做好探索型项目的过程管理」为主题进行了分享。
* 本文基于演讲内容整理，为方便阅读略有删改。关注「声网开发者」公众号回复关键词「JT0924」，即可领取完整版 PPT。
CODE.FUN 其实是一个 UI 设计稿转代码的工具，我们在做 App、小程序时都需要先做一个 UI 设计稿，那么将其上传到我们的平台之后，就会全自动生成微信小程序、VUE、 React 源码等，有很多种平台都可以选择。
这说起来可能很容易，但实际上要真正做一个让程序员可以为之买单的代码，要尽可能地模仿人手写的代码，并且尽可能相对优雅，在这一系列要求加持下，我们发现这是一个非常大的坑，因此这几年我们基本上都在经历一种匍匐前进的过程。梳理下来，整个过程如图 1 所示。
■图 1
我们是在 2019 年 9 月份启动了项目，直到 2020 年的 6 月份才发布了第一个版本来进行内测。在内测了一段时间之后，我们发现用户并不认可我们的产品，虽然一开始大家都对我们的产品很感兴趣，但是体验后发现并不能达到其预想的效果。后来陆续进行了大量的用户调研和访谈，我们决定放弃内测，回炉重造。
就这样又过去了一年，产品终于在去年 7 月份正式上线，这距离我们写下第一行代码整整过去了两年时间，而且中间还经历了离职潮，我们的团队从原来的十多个人到最少的时候只有 6 个人了，这真的是一些非常痛苦的变化。如今，我们又对算法进行了全新的重大升级，并且在 8 月份的时候正式启动商业化。
1）技术路线
在这三年中，我们碰到了很多问题，针对这些问题我们的技术路线也经历了多次的变更，具体如下。
“瘦” Plugin
“富” 预处理
智能分组预测
Flex 弹性预测
CSS 压缩
输出代码
因为最早写代码的时候，不可能设想得很完美。因此，在经历这一系列的变动以后，我们的团队现在提倡拒绝面向未来编程，一切都可以重构，一切都可以再优化，不要一味强调大而全。
2）用户画像
对于我们的产品到底卖给谁这个问题，我们也经历过一些变化。最初我们的目标用户是工程师，后来转变为设计师，再后来又变为产品经理。可见，在不同的周期对于用户的定位也会产生一些不一样的想法。
1、面临的挑战
当面对这么多未知问题的时候，我们的项目管理其实面临了巨大的挑战。总结下来，第一个挑战就是项目周期未知。因为我们根本不知道需要多久才能完成项目。一般我们做系统，可能只需要将页面、接口等整合到一起，然后做好运维工作就可以上线了，之后的工作交给运营跟销售来处理即可，前面的产品研发就只需要考虑人天的问题。但对于我们来说，项目周期则是完全未知的。
第二个挑战就是技术难度未知。在最开始做项目的时候，我们其实是想做低代码，比如拖拽。我们从 2018 年开始，花一年时间做了一个拖拽的低代码系统，那时业界还没有低代码声音。当时，在项目做出来之后，客户并不认可，当然这涉及到客户的理解、易用性以及整个行业周期等问题。但同时客户也提出，他还有大量设计稿的 UI 没有做完，我们能否把 UI 变成代码。原本我们设想这个工作只需要两三个月的时间，但结果我们一做就做了三年时间。这中间我们当然也想过放弃，怀疑过技术路线是否有问题，可见，技术难度是很难精准评估的。
第三个挑战就是否能够生存未知。当系统项目启动的时候，对于自己能不能生存下来都是一些未知数。
这几个方面叠加起来，如何管理好项目、如何使团队内想法保持一致、如何在这么长的周期中帮助团队成员保持信心都是巨大的挑战。
2、主流研发模式
说起主流的研发模式，大家基本上都会想到敏捷开发。关于敏捷开发，我在网上找到了图 2，它展示了一些非常经典的敏捷流程，包括迭代、周期、每日例会等。
■图 2
举一些大家最常用的经典的环节跟流程，比如从产品策划到需求宣讲，到需求开发再到开发测试、体验上线，这就是我称之为非常经典的流程，只要按照这个流程走就肯定不会错。这是一个标准的流程，在这个标准流程中我们为了信息的通畅，还需要一些非常重要的沟通机制，包括需求评审会、需求宣讲会、架构评审会、迭代总结会等。这些就是我们最常见的一些敏捷开发的环节。我自己对这个流程做了一个总结，我觉得用一句话来说就叫作 “数着迭代过日子”。
在经历需求研发的过程中会遇到各种各样的问题，这里我列举了一些老生常谈的问题，大家可以看一看自己是否也遇到过。
当团队规模扩⼤后，需求的沟通、⽬标理解，各⽅⾯开始出现偏差
为了解决这些偏差，开始上系统、定规则
交付延期，全天下的通病
关键是做出来的东⻄也不⼀定是⾃⼰想要的
在团队最早开始创业的时候，可能只有两三个人，此时没有什么沟通成本，但当团队扩大之后，不同能力级别的同事一定对需求的沟通以及目标的理解是存在偏差的，在团队内部定一些规则后，虽然增加了保障并提高了效率，但是在未知的情况下交付延期是必然的。我觉得延期不是最关键的，最关键的是当你在做一些探索性的时候，如果得到的结果不是你想要的，该怎么办？我对这个事情做了一个总结，就是当我们把一个人变成了写代码的机器的时候，他只会为自己的事情负责，如果用这种方式去做探索性的需求，那么一定是要完蛋的。在这种情况下，我们就要想办法在漫长的周期中寻找新的方式走向成功。
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。
并不是全世界所有的目标都能转成共识，一定存在一些目标是不可量化的，那么在这种情况下，该怎么达成共识呢？此时就需要建立一个新的共识模型。
对于建立共识模型，我们内部用的最多的是反馈，因为它代表了现象、场景、用户的声音，其中包含着很多信息可以提供指引，沿着这些反馈处理优先级，就一定能找到一个良性的发展路径。下面列出了四种获取反馈的方式，我称之为反馈生成公式。
在内部建立需求 “兜售” 制度
“随时随地” 启动产品内测
开设 “廉价” 的用户反馈渠道
建立 “有效” 数据指标
这里要注意，这个公式是每个角色、每个团队自己去寻找的，我这里列出的公式是在不同的时间周期、不同的团队规模下所运用过的一些方法，并且我们一直在对它进行调整跟优化。所以这些公式只适合于当时的我们，并不一定适合于现在以及未来的团队，并且它大概率是不适合于你。这个分享的目的是希望帮助大家找到一种建立自己公司的思考方式，而不是生搬硬套我们的公式。因为我们做的是 SaaS 产品，它有比较大的用户量，在这个层面上我们获取反馈是相对比较容易的。如果你是一个纯 B 端或者纯商业化的解决方案型的产品，可能就不能完全来照搬我们这样的链路。
1）在内部建立需求 “兜售” 制度
兜售其实就是销售，我们要建立需求销售制度。那么什么叫需求销售呢？我们认为每一个研发做的功能都投入了成本，包括时间、金钱等。在投入了成本之后，他创造了这个需求，那么就要负责在内部进行销售，看有没有人为这个需求买单。我们传统的做法是一边提测一边体验，对产品经理提出的反馈进行处理后测试上线。此时产品经理体验的完善度依赖于他个人的能力，这样很难得到非常公正的评价。所以我们就要把传统的非常依赖于某一个单点产品经理的体验机制扩散到整个团队中，使人人都成为产品经理，我们当时做了这样一种模式，就是要求每个开发在做完需求后，先在团队内寻求两到三个人进行用户反馈，这就是需求兜售制度。
2）“随时随地” 启动产品内测
这里有两个关键词，一个叫随时随地，一个叫内测。随时随地就是说，当任何人在做任何功能的时候，一旦出现不确定的问题，就可以立即开启一个内测。虽然考虑到所在团队的规模、架构不同，其可发挥的空间不一样，但我们还是希望尽可能做到随时随地，不要因为团队的制度而受到限制。另外，也不要因为技术而受到限制。产品一般分为现网、测试环境和开发环境，在这些环境下也要能够随时随地拉起一个全新的产品部署环境供别人体验，同时又不跟现网发生冲突。内测就要求速度快，要省略烦琐的步骤。总结来说两个很重要的点，第一个是内部系统的 CI/CD 的 DevOps 系统一定要足够的完善，让任何人都能快速拉起一套自己的体验环境进行分发。第二个就是在团队内部不要做太多限制。第三个就是要有一个分发的渠道，可以随时随地获得信息。
3）开设 “廉价” 的用户反馈渠道
廉价是指沟通成本很低，不能阻碍用户找到你。比如现在很多云厂商都喜欢工单机制，在这样的情况下，我们就需要开设一个廉价的用户反馈渠道，让别人能够通过网站页面的小气泡、微信群或者论坛方式快速得到沟通的渠道。除了得到沟通渠道，更重要的是要对用户进行解答和安抚，这样用户才更愿意跟你交流。这也是对前面随时随地启动产品内测的补充。如果没有一个廉价的渠道，就无法招募人员进行内测。
4）建立 “有效” 数据指标
前三点都是人在做，相对来成本较高，最后这一点则是通过数据进行分析。如果仅仅只是查看活跃度，那这一点其实没有什么任何意义，因为我们是要通过数据指标反过来进行产品的改进。比如用户在体验你的产品时，是否按照预先设立的关键路径操作、为什么没有继续操作等，这些可能在整个数据上报系统中都是相对比较完善的。根据这些信息，就可以进行产品的改进，从而引导用户更好地走下去。
再次强调一遍，这个公式不一定适合你，你一定要找到适合自己团队、自己产品的反馈公式，有了这些反馈之后你才能够构建你的共识。
有了初步的共识之后，就可以尽可能地通过可以持续更新的方式进行产品的开发。我们团队用过三种模式，在不同的阶段都得到了不同的效果。
1）组队模式
组队模式就是把整个团队打散分成若干小组，小组成立之后成员领取反馈或者目标任务，并分别依据目标工作。我们在成立这些小组的时候，就让成员首先推举项目经理，然后给这些小组分配项目经费，并要求小组一定要在项目执行工周期中把钱花出去，如果不花就没收。在这种情况下，各小组中的成员是互相成就的，这种互相帮助的氛围非常浓厚，他们会自发分析问题、研究问题、解决问题。
2）任务挑战模式
我们团队也不是全年一直保持组队模式，经常随着不同的任务周期产生一些新的玩法。在这个比较长期的过程中，经常会有一些来不及做但是又非常重要的任务，我们将其称为挑战任务。我们对挑战任务会有一些悬赏机制，鼓励大家来完成这些挑战。在完成挑战之后，根据任务的大小进行积分，最终可以换成 switch、xbox 等奖品发放给大家。
3）Owner 模式
我们把传统由产品经理负责的方式变成人人都可以做负责人的形式，不管是产品，还是测试，只要认为自己有能力负责，就可以由其来带领团队。在成为任务的 owner 之后，就可以根据任务的反馈、数据指标等信息来推进需求的管理。它其实跟组队模式有点像，但是组队模式更像是一种短期的激励挑战，而在 owner 模式下，可能就不只是产品经理来负责，也会有其他人可以做负责人。
我们在 CODE.FUN 研发的这三年周期中碰到了很多奇奇怪怪的问题，我们根据这些问题对团队做了一些调整，我今天梳理了之前的经验分享给大家，但大家一定要寻找自己的研发管理公式，不能照搬，创新没有捷径，努力控制变量才能让成功的概率最大化，所以我们也一直在调整，寻找自己的管理公式。
首先是挑选人才的问题，为了挑选人才，我们一直在不断地变化我们的面试试题，这些试题其实也是一种公式，你可以认为是我们的招聘公式。今年更新了整个招聘方式之后，我们寻找的人才其实还不错。其中有一个毕业生，他只花了一天就证明了自己的实力，也没有经过任何的培训，就能够自主的完成分析任务，并且进行报告的输出工作。这其实就是在人才招聘端能够做的一些优化。另外，就是不要挑战人性。如果说在招聘侧，不管是招聘的结构，还是薪酬结构方面都没有特别的变化，那么尽可能通过激励方式去做一些优化也不错。比如前面说的组队模式、任务挑战模式和 owner 模式，组队模式是我们试过最成功的一个玩法。当时我是把一个刚毕业一年的设计师、一个前端研发跟一个测试组在一起，让他们去制定自己的测试指标，他们为了这个测试指标还开发了一个测试工具，并且在团队内部进行需求的兜售。他们在这个过程中得到了很多的反馈，又反过来继续优化。优化这个功能真的帮我们团队开发出了非常多的内部工具，内部指标也都还不错。这是我们用过的一些小花招。
这其实就是优先级的问题了。最近我们把整个团队从市场、售前到产品研发拉通之后，每周都会开优先级排序的会议。我们之前是产品排优先级，现在每次开会就是先让市场同学发言，先说他心中的优先级，然后我们再跟其他优先级比较，这其中最主要的就是找到一把尺子，这把尺子用来衡量你的优先级。这把尺子其实就是反馈，这个反馈可以是用户的反馈，也可以是内部的反馈。当收集到足够多的反馈的时候，即使没有非常多的数据，但是你心中其实会有感觉，比如很多人提到这个问题，那么这个问题就是亟需解决的问题。所以我们靠自己心中的经验去评判其实是不够的。在产品总监层级或许可以做到准确判断，但当你做不到这种判断的时候就尽可能依赖于别人。其实有很多方式可以获取优先级。
（正文完）
