技术领导力实战笔记_19_第15讲_|_定制高效研发流程
当我们的研发团队、组织架构搭建完毕后，接下来需要思考的是，如何让这个架构跑起来跑得快、跑得稳。
此时，我们需要定义出一个高效的研发流程，还要尽可能降低研发过程中所遇到的风险，确保在流程的每个环节中都不能出错。
在定义具体的研发流程之前，我们需要从整体入手，先把研发流程体系、架构定义清楚，便于让团队从全局上把控整个过程。
接下来需要从局部入手，将研发流程中所涉及的操作步骤罗列出来，便于指导团队完成具体的工作。
现在，我们就从整体开始，对研发流程的体系架构进行探讨，高效的研发过程应该具备多线程的特征，仿佛多条并行流淌的河流。
上游是业务，中游是产品，下游是技术，流量取决于业务流速，取决于产品和技术。
需要。
说明的是，这里的业务其实包括两类人，一是公司内部使用产品的业务同事，二是公司外部使用产品的最终用户。
为了便于描述，厦文统一将他们称为业务，需求方或业务方，简称业务。
根据我的上一篇文章可知，整个研发工作流程体系架构是职能团队与项目团队的有机结合，团队职责清晰且协作高效。
我制作了一张研发流程框架图，感兴趣的朋友呢可以看一看。
在职能团队中，产品委员会的产品专家们将业务需求统一记录到需求池中。
需求池中的每一个需求都要描述业务的当前现状，还要包括业务对产品的未来期望。
每隔一段时间呢，产品委员会将根据需求池中所记录的需求细节加以讨论，并将优先级较高的需求进行立项和排期。
项目团队可知晓，近期需要实现的业务需求是什么，整个团队的方向感也更加清晰了。
需求池中一个典型的需求可包括以下字段，一、需求名称用一个关键词描述，最多十五个字。
二、需求来源，该需求来自于哪里？包括业务、运营、财务、法务、市场和其他。
三、业务痛点为何要实现？该需求及业务当前的现状。
四、需求描述该需求具体是什么及业务将来的诉求。
五、渴望程度期待何时可以上线，包括本周本月下月，本季度下季度、未来或具体截止日期。
六、需求类型包括新功能优化。
七、需求规模包括两周以上，一至两周、一周以内和未知。
八、备注可写下对该需求的补充或疑问，以便深入交流。
九、附件可通过相关文档对需求进行补充描述。
十、创建人该需求被谁创建？十一、处理状态，包括未处理处理中已处理和关闭。
十二、优先级包括ABCDX十三负责人，该需求由谁跟进？简单情况下，可以使用电子表格的方式来维护需求池，比如numbers、 excel等。
当然也可以通过在线方式来管理，比如实目文档进数据等。
需要注意的是，需求池对公司全员共享，由产品委员会管理并维护，其他人员只能阅读，但无法编辑产品。
专家们首先需要和业务需求方进行有效沟通，深刻理解他们的业务痛点与未来期望后，才能将这些需求入职。
从需求池中挑出的高优先级需求将分别流入对应的项目团队中，在项目的执行过程中，难免会遇到技术上的遗留问题。
然而，团队不希望因为这些问题而导致项目工期受到影响。
因此这些技术遗留问题将被列为技术债。
技术委员会中的技术专家们将对这些技术债加以管理和跟踪，在后期会有针对性的解决这些技术问题。
偿还这些技术债，了解了研发流程体系架构后，下面我们进入具体的研发流程。
操作步骤将需求转化为项目，是一个复杂的过程。
如果只是一个体系架构，恐怕也只是空中楼阁。
因此，我们有必要对整个研发流程体系架构进行细化，为其设计具体的操作步骤，以便让整个流程可以顺利落地。
我们可定义了。
以下十个操作步骤，将需求转化为产品，将产品转换为项目，将项目顺利上线。
这十个阶段呢涉及到不同角色的人员，每个阶段需要包含当前所需完成的任务，也涉及到相关例行会议。
我们可将这份操作步骤打印下来发给每一位研发人员，并贴在会议室的墙上。
每日战例会的时候，团队都能看得见他。
我们会慢慢发现，每个项目团队都有相同的工作习惯，大家还可不断优化这份操作步骤以及其中的相关细节。
需要注意的是，产品经理在需求调研阶段，必须了解业务的当前现状，搞清楚业务痛点是什么。
我们不妨这样做业务调研，如果没有这项功能，业务同事需要花多长时间，多少人力来完成自己的工作。
当前的获客成本是多少？订单转化率是多少？产品经理需要将这些信息和数据记录下来，并丰富到需求池中。
此外，在每次项目启动之前，需要得知该执行项目的目标是什么，如何来验证这个目标？我们需定期对以上线项目进行复盘，可通过复盘四步法来完成。
第一步是审视目标。
当初设定的目标是什么？目前达成的现状是什么？差异是什么？第二步是回顾过程，回顾整个过程是如何进行的，大致分为几个阶段，哪个阶段发生了什么？第三步是分析得失哪些方面做得好，哪些方面做的不好，为什么？第四步是分结规律，再次做同类。
事情应该怎么做对？未来工作有何指导，有何规律原则？方法论使用以上项目流程与复盘方法呢，可确保以正确的方法将事情做正确，但是只能解决研发内部的闭环问题，似乎无法解决研发和业务之间的外部闭环问题，也就是说，研发和业务之间的高效协作问题还需进一步探讨。
那研发与业务应该如何协作呢？这个问题也许在许多企业中会存在，毕竟业务和研发的工作性质不同，关注点也不同，因此考虑问题的方式也会不同。
业务中心可能会这样认为，为何我们提出的需求研发总是迟迟不解决？研发中心可能会这样认为，为何我们上线的功能业务总是迟迟不反馈？我们似乎遇到了一个死锁问题，彼此都在等待对方。
业务提出需求得不到及时响应，当研发响应后却得不到反馈，久而久之，业务和研发之间会失去信任，从而严重影响企业的可持续发展。
这里呢我向大家介绍一种新玩法，它能让业务和研发得到更好的闭环，而且让双方的协作过程变得更加顺畅。
我们称这个方案为特赞之声。
在公司内部，我们制作了一种叫特赞币的虚拟货币，其实它只是普通的磁铁币上贴了一个自制的图案而已。
我们给业务部门发放固定数量的特赞币。
为了避免通货膨胀现象，我们一次性不会发太多币，后期呢可根据实际情况适当增发。
当业务部门遇到痛点时，可在痛点卡片上手动填写具体痛点，并用，特赞币将卡片固定在白板上，此时需要消耗一个或多个特赞币，如果一次性使用多个币，表示优先级更高。
除了上线后，当业务部门提供使用，反馈后将得到一个特赞币提出的反馈，包括对已有功能的称赞或吐槽。
也就是说，提需求要花钱，提反馈可赚钱，这样可确保业务所提需求都是最大痛点。
由于币数呢是固定币，因此需要通过提反馈来获取新币，这样一来，研发和业务自然就建立了有效循环。
除了痛点和反馈外，公司全员也可以提出脑洞，也就是对产品的奇思妙想。
脑洞被产品委员会采纳后，可赠送一定数量的特赞币痛点，会使用特赞币，将其吸附在白板币反馈和脑洞呢可使用普通磁铁来固定使用特赞之声，我们得到了以下收益。
第一个是业务痛点，得到更好的重视，得以更快速的解决。
第二个是产品价值得到更好的体现，产生更高的成就感。
第三个是业务与研发不再孤立，从而形成了完美的闭环。
最后总结一下，没有人愿意在一个复杂的流程上投入自己更多的时间。
流程是帮助我们更规范的做事情，目的是避免犯错误。
因此在流程的定义上，我们可以先简单后精细，简单才便于操作，精细才易于管理。
以上我们提到的研发流程十步骤呢，对于大家而言只是一个参考模型，大家需要根据自身实际情况做出合理调整流程，才能发挥出最大的作用，否则它可能会变成一种负担。
反而约束了我们前进的速度。
研发流程是团队的行动，规范，是大家共同智慧的沉淀，流程，高效产出才能高效。
作者简介，黄勇，现任特赞科技CTO图书架构，探险作者，smart开源项目作者，TGO鲲鹏会上海分会会员，q控讲师，十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇轻量级系统架构，喜欢阅读、热爱交流，乐于分享。