第15讲 | 定制高效研发流程

May 9, 2018

第15讲 | 定制高效研发流程-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

第15讲 | 定制高效研发流程

2018-05-09 特赞CTO、TGO会员黄勇来自北京

《技术领导力实战笔记》

课程介绍



讲述：黄洲君

时长09:50大小9.00M



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

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

赞 14

提建议

第14讲 | 从零开始搭建轻量级研发团队

第16讲 | 培养中层团队的管理认知

 写留言

精选留言(15)

self-discipline
2018-05-10
请教:我们公司的产品经理呢，产品原型出来后，我们也评估了，开始开发，开发中，要上线了，产品经理不断改逻辑，加逻辑，小版本迭代变成大版本迭代，我是个中层吧，一直想在评估后开发前，做封版处理的，但是一直有上层的压力，封不了版本，求教如何处理呢，快两年了，心力憔悴
共 4 条评论
19
Eric
2018-05-26
我对特赞币的做法的理解应该是需求方和执行方在责任心、沟通、反馈上面增强的手段，但是手段之下如果对货币的价值定义不清晰，会有适得其反的效果
6
黄勇
2018-05-09
回答：易永健项目启动阶段第一条需求确定，如果放到项目计划阶段，那么项目估计可能更准一些，计划可能更合理些回答：考虑到项目计划阶段可能会结合实际情况对需求范围做一定调整，因此将需求确定放在了项目启动环节，也是为了给团队一个信号，只要项目启动了，需求就能随意变化了。对于领域已经划分好的迭代增量需求，文中提到的研发流程比较合适，但如果要做一个新领域需求，那么可能要有一个独立的领域建模子阶段，可以放在产品需求定稿前执行，形成通用语言和服务边界划分，运用ddd的思路方法回答：认同！全新的领域，可采用更加适合的方法。
展开
5
muzili
2018-05-12
能再详细解释一下，功能团队，效率团队和创新团队的区分和功能吗，规模比例是怎么样的？
3
一_FVision
2019-03-01
业务研发相互信任是关键，好的业务方，产品对每次的需求都要有明确的方向和目标，好的研发不光是埋头实现功能的代码机器，更需要注重业务收益，需求上线后的反馈，才能让自己的劳动与公司发展保持一致，拥有使命感
2
wenhao
2018-08-01
特赞币的做法确实挺好，不过这个虚拟货币没有一定的价值，各角色又为什么要去获取它。价值又是怎么定义的了？
共 2 条评论
2
黄勇
2018-05-09
回答 nopsky 项目上线以后，产品一般都会持续向研发反馈优化和bug，或者新功能，一般不会出现得不到反馈吧，您说的反馈内容是指项目好坏的使用数据和用户的评价吗？回答：反馈主要包括用户使用行为上的反馈，以及数据表现上的反馈。前者比较主观，需要通过调查来完成；后者比较客观，需要通过事实来说话。业务人员跟研发人员反馈的内容是什么？研发人员是不是也有获取币的方式？解决需求获取币吗？回答：业务人员主要反馈的是用户使用行为上的反馈，研发人员可以通过数据来反馈。研发人员也可以获得币，比如提出了一个很好的脑洞，被产品委员会采纳了。研发人员得到币以后，也能提自己的痛点，比如为了完成运营工单，希望产品如何提供功能上的满足。
展开
2
易永健
2018-05-09
项目启动阶段第一条需求确定，如果放到项目计划阶段，那么项目估计可能更准一些，计划可能更合理些对于领域已经划分好的迭代增量需求，文中提到的研发流程比较合适，但如果要做一个新领域需求，那么可能要有一个独立的领域建模子阶段，可以放在产品需求定稿前执行，形成通用语言和服务边界划分，运用ddd的思路方法
展开
2
一池浮萍
2020-10-10
请教您一个问题我们目前迭代是固定的一周一迭代，包括了需求评审、开发、测试、上线回归、发版，当然还包括很多杂项。如果遇到大项目，需要单独抽出人力进行测试，迭代任务也是需要兼顾，否则容易堆积。作为测试来说，压力很大，只要出了线上问题，测试就得承担责任，大家压力都很大。您觉得一周一迭代合理吗？
展开
1
七七默默
2018-10-30
特赞币很好
1
nopsky
2018-05-09
项目上线以后，产品一般都会持续向研发反馈优化和bug，或者新功能，一般不会出现得不到反馈吧，您说的反馈内容是指项目好坏的使用数据和用户的评价吗？
1
nopsky
2018-05-09
业务人员跟研发人员反馈的内容是什么？研发人员是不是也有获取币的方式？解决需求获取币吗？
1
小菜鸟
2022-06-26
大公司中的创新业务应该采用什么流程呢
刘二宝
2022-01-27
特赞币的思想感觉很新奇奥，我觉得这个想法的落地，是不是应该依靠于与需求管理平台的工具集成，使用工具串联流程，让想法更好的落地。
陈狄
2020-12-04
特赞币学习了，使用市场化的方法来协调研发和业务团队，就能把资源利用最大化。

