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