015 定制高效研发流程

当我们的研发团队组织架构搭建完毕后,接下来需要思考的是,如何让这个架构跑起来、跑得快、跑得稳。此时,我们需要定义出一个高效的研发流程,还要尽可能降低研发过程中所遇到的风险,确保在流程的每个环节中都不能出错。

在定义具体的研发流程之前,我们需要从整体入手,先把研发流程体系架构定义清楚,便于让团队从全局上把控整个过程。接下来需要从局部入手,将研发流程中所涉及的操作步骤罗列出来,便于指导团队完成具体的工作。

现在我们就从整体开始,对研发流程的体系架构进行探讨。

研发流程体系架构

高效的研发过程应该具备“多线程”的特性,仿佛多条并行流淌的河流,上游是业务,中游的是产品,下游是技术,流量取决于业务,流速取决于产品和技术。

需要说明的是,这里的“业务”其实包括两类人:一是公司内部使用产品的业务同事,二是公司外部使用产品的最终用户。为了便于描述,下文统一将他们称为“业务需求方”或“业务方”,简称“业务”。

根据我的上篇文章可知,整个研发工作流程体系架构是职能团队与项目团队的有机结合,团队职责清晰且协作高效(如图 1 所示)。

img 图 1:研发流程框架图

在职能团队中,产品委员会的产品专家们将业务需求统一记录到“需求池”中。需求池中的每一个需求都要描述业务的当前现状,还要包括业务对产品的未来期望。每隔一段时间(一般是 1~2 周),产品委员会将根据需求池中所记录的需求细节加以讨论,并将优先级较高的需求进行立项和排期,项目团队可知晓近期需要实现的业务需求是什么,整个团队的方向感也更加清晰了。

需求池中一个典型的需求可包括以下字段:

需求名称:用一个关键词描述,最多15个字。

需求来源:该需求来自于哪里?包括业务、运营、财务、法务、市场、其他。

业务痛点:为何要实现该需求?即业务当前的现状。

需求描述:该需求具体是什么?即业务将来的诉求。

渴望程度:期待何时可以上线?包括:本周、本月、下月、本季度、下季度、未来、或具体截止日期。

需求类型:包括:新功能(从 0 到 1)、优化(从 1 到 100)。

需求规模:包括:大(两周以上)、中(一至两周)、小(一周以内)、未知。

备注:可写下对该需求的补充或疑问,以便深入交流。

附件:可通过相关文档对需求进行补充描述。

创建人:该需求被谁创建?

处理状态:包括:未处理(默认)、处理中、已处理、关闭。

优先级:包括:A(重要&紧急)、B(重要&不紧急)、C(不重要&紧急)、D(不重要&不紧急)、X(待定)。

负责人:该需求由谁跟进?

简单情况下,可使用电子表格的方式来维护需求池,比如:Numbers、Excel 等,当然也可通过在线方式来管理,比如:石墨文档、金数据等。

需要注意的是,需求池对公司全员共享,由产品委员会管理并维护,其他人员只能阅读但无法编辑。产品专家们首先需要和业务需求方进行有效沟通,深刻理解他们的业务痛点与未来期望后,才能将这些需求入池。

从需求池中挑出的高优先级需求将分别“流入”对应的项目团队中,在项目的执行过程中难免会遇到技术上的遗留问题,然而团队不希望因为这些问题而导致项目工期受到影响。因此,这些技术遗留问题将被列为“技术债”,技术委员会中的技术专家们将对这些技术债加以管理和跟踪,在后期会有针对性地解决这些技术问题,偿还这些技术债。

了解了研发流程体系架构后,下面我们进入具体的研发流程操作步骤。

研发流程操作步骤

将需求转化为项目,是一个复杂的过程,如果只是一个体系架构,恐怕也只是空中楼阁,因此我们有必要对整个研发流程体系架构进行细化,为其设计具体的操作步骤,以便让整个流程可以顺利落地。

我们可定义了以下 10 个操作步骤,将需求转化为产品,将产品转换为项目,将项目顺利上线(如图 2 所示)。

img 图 2:研发流程操作图

以上 10 个阶段,涉及到不同角色的人员,每个阶段需要包含当前所需完成的任务,也涉及到相关例行会议。我们可将这份操作步骤打印下来,发给每一位研发人员,并贴在会议室的墙壁上,每日站立会的时候,团队都能看得见它。我们会慢慢发现,每个项目团队都有相同的工作习惯,大家还可不断优化这份操作步骤以及其中的相关细节。

需要注意的是,产品经理在需求调研阶段,必须了解业务的当前现状,搞清楚业务痛点是什么?我们不妨这样做业务调研:如果没有这项功能,业务同事需要花多长时间、多少人力来完成自己的工作?当前的获客成本是多少?订单转化率是多少?产品经理需要将这些信息和数据记录下来,并丰富到需求池中。此外,在每次启动项目之前,需要得知该执行项目的目标是什么?如何来验证这个目标?

我们需定期对已上线项目进行复盘,可通过“复盘四步法”来完成:

审视目标:当初设定的目标是什么?目前达成的现状是什么?差异是什么?

回顾过程:回顾整个过程是如何进行的?大致分为几个阶段?每个阶段发生了什么?

分析得失:哪些方面做得好?哪些方面做得不好?为什么?

总结规律:再次做同类事情应该怎么做?对未来工作有何指导?有何规律、原则、方法论?

使用以上项目流程与复盘方法,可确保以正确的方法将事情做正确。但是,只能解决研发内部的闭环问题,似乎无法解决研发和业务之间的外部闭环问题,也就是说,研发和业务之间的高效协作问题还需进一步探讨。

研发与业务如何协作?

这个问题也许在许多企业中会存在,毕竟业务和研发的工作性质不同,关注点也不同,因此考虑问题的方式也会不同。

业务心中可能会这样认为:为何我们提出的需求,研发总是迟迟不解决?

研发心中可能会这样认为:为何我们上线的功能,业务总是迟迟不反馈?

我们似乎遇到了一个“死锁”问题,彼此都在等待对方。业务提出需求,得不到及时响应;当研发响应后,却得不到反馈。久而久之,业务和研发之间会失去信任,从而严重影响企业的可持续发展。

这里我向大家介绍一种新玩法,它能让业务和研发得到更好的闭环,而且让双方的协作过程变得更加顺畅。我们称这个方案为“特赞之声”(如图 3 所示)。

img 图 3:特赞之声

在公司内部,我们制作了一种叫做“特赞币”的虚拟货币,其实它只是普通的磁铁,币上贴了一个自制的图案而已。我们给业务部门发放固定数量的特赞币,为了避免“通货膨胀”现象,我们一次性不会发太多币,后期可根据实际情况适当增发。

当业务部门遇到痛点时,可在痛点卡片上手动填写具体痛点,并用特赞币将卡片固定在白板上。此时需要消耗一个或多个特赞币,如果一次性使用多个币,表示优先级更高。项目上线后,当业务部门提供使用反馈后,将得到一个特赞币,提出的反馈包括对已有功能的称赞或吐槽。

也就是说,提需求要“花钱”,提反馈可“赚钱”,这样可确保业务所提需求都是最大痛点,由于币数是固定的,因此需要通过提反馈来获取新币,这样研发和业务自然就建立了有效循环。

除了痛点和反馈以外,公司全员也可以提出脑洞,也就是对产品的奇思妙想,脑洞被产品委员会采纳后,可赠送一定数量的特赞币。痛点会使用特赞币将其吸附在白板上,反馈和脑洞可使用普通磁铁来固定。

使用特赞之声,我们得到了以下收益:

业务人员:业务痛点得到更好的重视,得以更快速地解决。

研发人员:产品价值得到更好的体现,产生更高的成就感。

彼此双方:业务与研发不再孤立,从而形成了完美的闭环。

写在最后

没有人愿意在一个复杂的流程上投入自己更多的时间,流程是帮助我们更规范地做事情,目的是避免犯错误。因此,在流程的定义上,我们可以先简单后精细,简单才便于操作,精细才易于管理。

以上我们提到的研发流程十步骤,对于大家而言只是一个参考模型,大家需要根据自身实际情况,作出合理调整,流程才能发挥出最大的作用。否则,它可能会变成一种负担,反而约束了我们前进的速度。

研发流程是团队的行动规范,是大家共同智慧的沉淀,流程高效,产出才能高效。

作者简介

黄勇,现任特赞科技(tezign.com)CTO,图书《架构探险》作者,Smart 开源项目作者,TGO鲲鹏会上海分会董事会成员,QCon 讲师。十年以上互联网软件架构与技术管理经验,擅长敏捷开发,推崇“轻量级”架构思想。喜欢阅读,热爱交流,乐于分享。