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