高效的研发流程:1、项目信息集中管理工具 2、整合研发工具链 3、信息流动起来（研发流）
出处：https://mp.weixin.qq.com/s/IHtVVtrCbXcrJ6DZUeIpeg
案例背景
去哪儿网作为国内领先的在线旅游平台，在2013年之后，随着业务迅速发展，研发团队的规模也快速扩张。随之而来的如何降低项目管理成本、提升研发人员工作效率、保证项目交付质量等问题变得日益重要。
我所在的qunar研发支持团队，尝试对“需求-开发-发布”整个链条中的各种流程、工具、数据进行打通及自动化处理，以此减少研发过程中的各种浪费，提升整个研发体系的效率。
存在的问题
问题1：沟通写作成本高
配合开发的几个团队目前有什么进展？什么时候能联调？在当时，作为项目经理想准确获得自己项目的这些相关信息只能选择当面沟通、打电话、聊天群、邮件等“人肉”方式询问。
这样的结果是：不但沟通效率低，还导致开发人员的工作经常被打断。
问题2：信息不一致
由于各团队的项目信息管理方式、信息存放载体各不相同，同一个需求，不同时候问不同的人，得到的信息可能是大相径庭甚至互相矛盾，如果想校准信息，又是一波“人肉”确认环节……
问题2：缺少工具支撑
当时公司有一套老的项目管理系统，但大家都觉得不好用，所以实际上还是各自采用“Excel+邮件”的方式来管理自己团队的项目，导致在系统中记录的项目数据跟实际进行的情况差异很大。
具体原因如下。
-
老系统对研发生命周期的管理没有打通。使用时，在开发过程（需求-计划-开发-测试）的每个阶段要分别填写类似“申请单”的表格进行记录，而这些表单中很多字段是需要重复填写的，这对开发人员来说简直就是“反人类”的设定。
-
老系统各阶段表单，字段非常复杂。以提测环节为例，整个表单要填写几十个字段和确认项。我们曾经做过实验，仅填写提测申请单，平均每次需要花费30多分钟。
问题4：需求变更
当时去哪儿网每天并行开发的需求有上百个，一旦出现紧急需求插队或某个需求变更的情况，对后面需求的计划调整、影响关系人识别、影响周知，都是一场灾难……
解决方案
为了解决这些沟通协作问题，我们设计并实施了去哪儿网的项目管理平台（基于JIRA开发，同时结合研发过程改进、组织结构优化等实践一并实施）。
在解决项目管理相关问题之后，我们又进一步将项目管理系统同公司原有的工程类系统（GIT、Jenkins、CI等）打通，从打通“项目管理信息”，提升为打通“产品研发全过程信息”，帮助研发工程师一站式完成项目全过程的各种操作和相关信息查询。这一解决方案不止提升研发效率，还有效减少了信息传递不一致导致的人为出错。
整个解决方案分两个阶段实施。
第一阶段：打通项目全过程信息
这个阶段主要围绕降低项目管理成本展开，关键目标及实施的主要特性如下。
目标1：减少沟通协作成本
特性a：为各部门划分单独的项目池。
去哪儿网的组织结构是BU制，我们按照部门/团队的维度来划分项目池（如图8-1所示）。
图8-1 项目池划分
这样划分有以下好处。
（1）易于理解，在录入项目信息时，只需要在自己所属部门的项目池内录入就可以，不用做过多区分；
（2）体现了组织结构的概念，不同团队在操作权限、团队管理上的差异性需求，可以很方便的基于项目池做功能开关；
（3）团队的变化相对稳定，项目池调整维护的工作量比较小，不像按项目划分，需要经常为新项目增加JIRA项目池。
特性b：集中管理全部类型的团队事务。
在每个项目池下划分了不同的事务类型，包括：
-
产品业务需求；
-
技术优化需求；
-
线上问题处理；
-
日常任务；
-
测试阶段bug。
这样就把研发团队要做的所有类型的事情在一个系统内集中管理起来，这样做有以下几个好处。
（1）统一“语言和工具”。不像之前，要在不同系统和工具中记录项目信息，导致不同团队间沟通项目信息时因需要各种“翻译”而产生浪费。
（2）统一入口。对研发人员来说，可以一站式管理自己所有类型的任务，统一入口。
（3）统一数据。后续做开发计划制订、开发进度跟踪等项目管理相关活动时，直接基于一个系统生成报表和统计视图，不会出现跨多个系统做统计时数据不一致的问题。
目标2：消除信息搬运的浪费和信息不一致
在以前的研发过程中，不同角色在研发流程中的各个环节使用不同工具管理自己的任务信息，如图8-2所示。
图8-2 任务管理
这样导致的结果是：对一个需求来说，需要到多个系统中重复录入信息，而且由于系统是多个，还会经常出现各系统中信息不一致的情况。
我们的做法是：在项目管理系统的工作流中打通研发流程，一个需求（也就是一次业务发布）用一条系统记录跟踪到底。
如图8-3所示，对一条需求的记录加入了工作流和状态的概念，同时所有环节的信息都在这一条系统记录里。从需求创建开始，产品先录入需求，然后流转给开发记录开发计划，设计方案，开发完成后流转给测试……随着项目向后进行，不同角色在工作流中录入相应环节的项目信息。
图8-3 全链条需求管理
这样就确保了不同角色对这个需求的信息获取是一致的，而且不用像以前那样在多个系统重复录入。
此外，工作流的概念实际上等于是把公司的研发流程沉淀在工具中。只要大家适应工具，也就是习惯了公司的开发流程，这样流程的实施成本就会大幅降低（之前需要定期进行研发流程培训以及定期检查，要耗费项目管理人员大量的时间）。
目标3：简单易用
有个很实际的问题：很多公司都做了一套“线上项目管理系统”，但实际上大家还是习惯使用Excel，不喜欢用官方的项目管理工具，因为觉得麻烦。时间长了，官方的项目管理工具就成了“摆设”。
造成这种结果的原因何在？我们认为，除了工具的场景设计（工作流、视图）同实际情况不匹配，还有一个很主要的原因就是工具的易用性不好。因此，我们在细节上，对易用性方面做了许多改进。
-
尽量简化字段和工作流，控制研发人员使用项目管理工具的时间。首先，工作流中只保留研发流程的关键环节（需求-需求评审-计划-开发-测试-发布），尽量减少员工走流程的操作次数。其次，尽量精简每个环节填写的字段数量。不要为了项目管理人员的需要，在系统中增加大量的统计分类字段让大家填写。{1[最早我们设计的工作流，最长流程一共要走21个状态，经过反复讨论后认为过于复杂，最终核心状态精简到7步。]}
-
从用户角度出发，提供面向用户的“自适应”视图—看板、日历、面板。如图8-4至图8-6所示，除了为管理者提供各种统计视图外，还设计了各种根据当前用户姓名自适应显示的各类视图，以便于用户无需进行复杂的查询操作，就可以查看与自己相关的任务信息。
图像说明文字
图8-4 例1：团队看板中点击“我的项目”，即可自适应过滤当前用户的任务信息
图8-5 例2：自适应显示与当前用户相关的开发项目日历
-
在线Excel。在线项目管理系统另外一个比较让人诟病的地方是：批量修改任务数据时，需要一条条分别编辑和保存，不如Excel操作方便。因此，这里提供了类似Excel的在线表格编辑功能（如图8-7所示），支持Crtl+C插入行，Ctrl+V删除行、拖动排序等常见的Excel操作，同时可以在编辑后批量提交和保存，大大提高了信息录入的效率。
图8-6 例3：自适应显示与当前用户相关的开发中项目、过去7天内发布项目等
图8-7 在线表格编辑功能展示
-
批量同步物理看板上的卡片状态到系统中。很多敏捷团队都用“物理白板+卡片”的方式来管理团队内部的任务，但这样就产生了新问题：大家习惯更新物理看板的卡片状态，但线上系统中的任务信息却经常忘了更新。
这里使用一个JIRA插件“Agilecard”解决了这个问题，这个插件可以很方便地批量打印卡片。每天站会后（站会沟通时会更新卡片状态）对物理白板拍照，然后在JIRA中上传照片，这样就可以批量更新卡片状态，使之跟物理看板保持一致。本质上来说，相当于提供了一种低成本的方式保证物理看板和电子系统中信息一致。
第二阶段：整合研发工具链，提高研发效率
在实现了项目信息的集中管理后，接下来仍然从消除浪费、简单易用两个角度去进行尝试，把改进范围扩大到整个研发工具链（数据展示+操作入口），通过把项目信息和工程类系统之间的数据打通，以及对研发过程中的工具链进行操作入口整合，来提升工程师的工作效率。
我们发现，工程师在项目开发过程中，以及同各种工程系统打交道的过程中，依然面临着系统间信息不一致、信息搬运和操作复杂等问题，如图8-8所示。
图8-8 项目开发场景
在项目过程中，工程师需要完成以下操作步骤。
（1）到项目管理系统创建一条需求记录。
（2）到Git去拉分支，开始写代码。
（3）每次提交代码都要到CI平台下面不同系统中（Sonar、UT、自动化测试、代码评审等）输入分支名称，查看检查结果。
（4）开发完成，开发自测的时候，到发布平台把相关的工程、分支名称、各种发布参数填到发布平台，发完开发环境。
（5）再回到CI平台里，不同系统查看代码评审、自动化测试、数据库慢查询报警、SQL审核结果。
（6）提交测试，QA人员手工把相关的工程、分支名称、各种发布参数填到发布平台，再去CI里查看各种质量检查结果。
（7）在整个过程中，开发和QA人员还要记住定时去项目管理平台更新项目状态。
总结来看，问题在本质上跟第一阶段很类似。
-
项目各种信息分散，获取困难。
-
操作入口多，麻烦，易出错。
-
影响工作效率，容易导致流程跳步。
解决方案如图8-9所示，当开发拉出开发分支的时候，相应需求的项目管理信息会和相关的工程信息整合，统一在一个页面中展示。
-
自定义上线步骤。
-
汇总工程、分支等工程信息。
-
点击超链接可直接跳转到各工程系统。
-
代码质量结果实时预警。
-
点击按钮执行发布操作。
图8-9 机票项目管理系统界面
如果质量检查结果有问题，右侧“！”图标，会变成红色，然后用户可点击红色按钮，直接切换到质量详情页面，如图8-10所示。
图8-10 质量详情页跳转
新旧系统的对比如表8-1所示。
表8-1 新旧系统的对比
| 旧系统 | 新系统 |
|
各种信息，如工程/分支名称、需求JIRA号、标签信息等，需要在各系统中重复复制和粘贴，而且容易手误粘贴错误信息，导致操作失败 |
信息打通，无需在各系统中重复填写 |
|
要在各系统间来回切换，经常要开多个浏览器窗口 |
一站式完成研发相关操作（项目管理+工程类） |
|
每次代码提交，需要“人肉”到各CI子系统中查询执行结果 |
按需求维度，聚合并实时反馈软件质量信息；提交代码后，刷新JIRA需求页面就可以看到检查结果 |
|
— |
数据打通后，数据完整度和准确度都会有大幅提升，可以为后续数据统计度量打好基础 |
实现方式1：数据间对应关系
实现上文中提到的效果，最关键的一步是要把研发各系统间的数据打通。而在打通数据的环节中，最重要的是建立需求和代码间的映射关系。这两个概念属于两个维度，它们之间不具备天然的映射关系。
首先规定分支命名规范。要求所有开发分支的名称中必须包含对应需求的JIRA编号。{2[因为去哪儿网主要的分支策略是分支开发和主干发布，所以对我们来说，大多数情况下，一个开 发分支会对应一个需求。因此，我们的分支命名规范是基于这个前提制订的。]}
然后在后台增加监控程序。当一个新分支拉出时，自动解析分支名称中的需求JIRA编号，并把它们之间的映射关系记录在数据库中。
如图8-11所示，这样需求同各类工程类信息之间的映射关系就完整建立起来了。
图8-11 映射关系
实现方式2：系统结构介绍
数据打通之后，剩下的工作主要是把各系统的操作界面进行统一，以及用脚本来串联各系统间的调用逻辑。针对这一点我们做了以下几个方面的工作（如图8-12所示）。
-
各工程系统前后端分离、提供API，供互相调用。
-
用户交互的部分重新设计交互和前端，并统一到项目管理系统界面中。
-
专门开发一个消息中心（IC），用于各系统间通信（类似事件广播的方式进行通信），任何一个系统发生变化时，都会“广播”发出一条事件，其他系统监听到这条事件后，会根据自身逻辑做相应处理。
-
专门做了一个数据中心（DC），把各系统数据汇总到一个库里提供一站式查询，这样各系统需要读取其他系统数据时，可以直接到数据中心获取完整的数据，而不用到各系统中分别调取。
-
持续集成相关系统，为了满足快速检查代码质量、实时反馈的需求，要持续对速度做优化，正常情况下各检查点要做到分钟级反馈质量检查结果。
图8-12 系统结构
总结与思考
（1）项目管理平台首先应该满足“把项目管好”的需求。对一线研发人员来说，系统简单、易用永远是第一位的，其次才是管理层的各种“统计度量”需求。如果为了给老板做各种报表，要求员工花时间在系统中填写很多分类字段，这样反而是本末倒置。
（2）系统的设计，要结合公司的实际情况，匹配大家日常执行的研发过程。比如，文中的项目池划分、工作流状态、系统字段，都是根据去哪儿网的特点重新定义的，这样员工使用项目管理系统时才不会有陌生感，系统才能起到承载公司研发流程的作用。
（3）当团队规模变大后，管理层需要从系统中获取数据来实现对团队各方面状态的报表可视化。这种管理需求是正常的，但不能只考虑管理需求，应同时考虑是否会导致团队的项目管理成本上升（比如各种字段的填写、检查和确认等），所以用自动化手段获取所需的统计数据是最好的选择。
（4）无论是项目管理系统，还是工程类系统，都应该遵循一个原则：让用户少花时间做低层次操作（如各种复制和粘贴，各种“人肉”切换和查询），消除各种人为等待。这样才能让研发人员把更多精力放到设计和编码这类高层次的脑力活动上，进而提升研发效率。
（5）好的研发工具只是建设团队的一方面，实施过程中还需要配合组织结构、流程、文化建设等。多方面齐头并进才能有效建设和改进团队。比如，在实施项目管理平台过程中，还要并行开展全功能团队建设、需求拆分等其他方面实践。