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