「天下武功，唯快不破」，这句话用在互联网世界里格外适合。互联网产品模式讲求快速迭代、小步快跑，业务和协同团队的快速变化是常态。
然而，要想真正在一个研发周期内每个需求执行不失控、成本和风险能控制、项目质量有保障，除了产品写需求文档、开发写代码改 BUG、测试写用例和 BUG 汇报验证外，通常还有很多非常重要而细碎的事情要做，比如：项目经理创建需求沟通群、组织站会、产品经理编写上线周知通知运营和客服人员等，其中有些工作是重复的，需求相关的信息也比较多，通常散落在各个地方后期难以查找。
对于 PMO 和开发组长而言，则需要在多需求并行的情况下快速地发现某些高风险需求并重点关注和推进。如何提升需求执行效率和降低并行需求管理成本呢?本文将分享马蜂窝交酒 PMO 团队是如何通过用自研 的 PMO 系统驱动过程管理的方式，来降低项目管理的人力成本。
Part.1 背景介绍
马蜂窝大交通和酒店研发团队采用双周 PK 和双周迭代模式。为了助力高效、透明的研发流程，团队成立初期就确立了使用工具来进行研发项目全周期管理的方式。通过对比后最终选择了 TAPD 作为产研流程的管理工具，主要是因为 TAPD 具有配置和操作简便、支持移动办公、项目间隔离性强等优势。
1.1 需求状态和分类
需求分为三类：日常、项目和线上问题。目前主要使用 TAPD 的「需求」功能管理需求，「迭代」功能管理迭代，日常类需求的迭代周期为 2 周，项目类需求的迭代周期为 4 周。
日常和项目需求的状态均有以下九种：
图 1：需求状态
1.2 PMO 的日常
1. 组织项目实施
线下的研发流程其实是个很庞大的矩阵图，横轴为需求的 9 种阶段，纵轴为 5 种不同角色——项目经理(PM)、产品经理、开发、测试、PMO，矩阵图明确地规定了对于一个需求而言不同角色在不同阶段应该做的事情。在需求处于不同状态时，5 种不同角色都有很多细碎的事情要做，比如：
- 准备阶段：「待实施」状态时，PM 需要为需求相关人员组建企业微信群，实现信息及时互通。
- 开发阶段：进入到「开发中」后，PM 需要每天组织站会并发送站会纪要到需求的企业微信群。
- 测试阶段：到「测试中」以后，测试需要每天发送测试日报到企业微信群。
- 上线后：需求状态转为「已上线」后，产品经理需要发送上线周知邮件;转到「线上效果跟进」，产品经理需要发送线上效果跟进邮件。
这些事情中有很多是重复性很强的工作，比如拉微信群等。上述这些不同的信息也会因产生的时间不同、同步的方式不同而非常分散，有的通过邮件，有的是微信群，后期查找起来非常困难。
2. 项目质量控制
对于 PMO、开发经理和开发总监而言，同时需要管控多个并行需求的实施质量，就需要能快速地获取到项目执行中的风险，比如：
- 每天有哪些项目未通过站会沟通，需要逐个在企业微信群查找并与 TAPD 中的需求做对比。
- 有哪些需求发生延期提测或者延期上线，需要逐个在 TAPD 中查找项目的提测和上线状态，非常繁琐而且容易遗漏。
除了需求的落地和多个需求并行管控外，每周产品经理们都需要向上级汇报本周的需求上线情况，每周每个业务线都有需求上线。多业务线和多负责人使得周报收集和汇总的工作量非常大，有时候难免会有些内容遗漏，也不能保证在固定时间发送。
1.3 PMO 系统设计目标
基于上述在需求管理、风险控制和日常工作中存在的一些问题，交酒 PMO 团队规划并实现了 PMO 系统，以期高效实现需求从实施到上线的全过程管理。PMO 系统的主要目标和定位如下：
- 信息全部需求相关信息统一在 TAPD 中录入和管理，包括站会纪要、测试日报、上线周知等。
- 支持多业务线，不同业务线的迭代开始时间和迭代周期、不同业务线对应的邮件组、企业微信群均可配置。
- 流程提效，包括自动创建企业微信群，从 TAPD 中查询站会纪要、测试日报等信息并发送到企业微信群，从 TAPD 中查询上线周知信息并自动发送邮件等。
- 并行需求管理和风险管控。
- 知识沉淀和管理，包括流程文档、PM 知识分享等。
- 向上汇报，多业务线的产品经理们在 TAPD 填写了不同需求的上线周知后，系统自动汇总本周全部上线的需求和上线周知，定时向业务总负责人发送周报。
Part.2 主要功能及实现
2.1 整体设计
PMO 系统将过程管理与 PMO 理论相结合，基于 TAPD 的 API 和企业微信 API 获取远端数据进行项目的数据扩展，可以同时支持多业务线的项目过程管理。
PMO 系统的核心就是进行关键信息的收集和高效的处理。具体来说，每个业务线在项目实施的不同阶段，都会通过创建企业微信群的方式实现实时的沟通和管理。通常来说分为如下几类：
- 短期群——需求企业微信群：该需求变为「待实施」后创建，需求上线一定时间后群可以解散;群成员包括该需求的产品经理和产品组长、开发人员和开发组长、测试人员和组长、研发总监;后面简称为「需求群」。
- 长期群——双周 PK 企业微信群：该业务线参加 PK 会议的全部开发组长和全部产品;后面简称为「双周 PK 群」。
另外，我们将每个业务线的邮件组分为研发组和产品组两个大组。
所有需求相关信息都由需求相关人员录入到 TAPD 中，PMO 系统自动从 TAPD 中拉取信息并做处理。
PMO 系统主要分为数据收集和数据处理两个部分，整体流程图如下：
图 2：PMO 系统流程图
2.2 主要功能实现
PMO 系统实现的功能主要包括：
1.对实施过程进行管理和风险控制，实现迭代管理和需求管理
2.向上管理，拉取一定周期内多业务线上线的需求，并定时给业务负责人发送周报
3.数据支持，按项目、迭代、季度、人的维度进行工时统计
4.知识沉淀和管理，包括流程文档、PM 知识分享等
下面我们来看具体的实现方式。
2.2.1 实施过程管理
对实施过程的管理主要分为迭代管理和需求管理。迭代管理主要是帮助 PMO 和管理人员进行并行需求管理和风险控制，需求管理则聚焦对需求实施流程进行提效。
1. 迭代管理
(1) 需求 PK 前后信息汇总
刚刚实行 PK 会议的时候，有些参与 PK 的需求录入到 TAPD 的时间很晚，与会人员对参加 PK 的需求不是很了解，产品人员花费了很多时间在 PK 会议中讲需求，最长的一次 PK 会议甚至开了 3 个小时。
为了解决这个问题，PMO 系统采用开启数据收集定时任务的方式，通过 TAPD API 统一获取待 PK 类型的需求，并在 PK 前一天下午固定时间发送到「待 PK」需求列表，帮助参与 PK 会议的开发、测试人员尽早了解这些需求，提升 PK 会议的效率。并且规定超过固定时间未录入到 TAPD 的需求不参加 PK 会议，侧面促进产品人员早日明确自己的需求。
图 3:「待 PK」需求消息发送流程图
图 4: 发送「待 PK」需求列表消息示例
PK 会议召开完毕后，当晚 8 点 PMO 系统会获取最新日常和项目迭代的待实施需求信息，并发送「待实施」需求汇总消息到「双周 PK 群」，发送格式为「需求名称|产品经理姓名|优先级」。
两次 PK 会议之间除了待实施需求、偶发性的特殊需求和线上问题修复之外，不接受其他需求。
图 5:「待实施」需求消息发送流程图
图 6:发送「待 PK」需求列表消息示例
(2) 进行中迭代需求进度汇总
之前当并行需求较多时，想了解整体执行情况需要挨个查看 TAPD 中的需求和任务执行情况并与计划时间做对比，这个过程比较耗时。因此每周五晚 6 点 PMO 系统针对不同业务线的进行中迭代的需求进度、延期情况发送邮件到该业务线的研发组&产品组，并发送消息到该业务线的「双周 PK 群」。协助 PMO 和管理人员快速识别风险并进行重点推进。
图 7:需求进度汇总流程图
图 8:每周需求进度汇总消息
图 9:每周需求进度汇总邮件
2. 需求管理
主要有以下三类功能：
- 自动创建企业微信群
- 自动同步消息和邮件
- 自动提示项目进度
下面详细介绍。
(1) 自动创建企业微信群
双周 PK 通过后，PMO 系统调用企业微信 API， 自动为每个待实施的需求创建企业微信群，更改群名称为需求名称-PM XX-PD YY，节约 PM 创建微信群和邀请人员加入的时间;需求状态转为「开发中」后，自动更改群名称，增加预计提测时间和预计上线时间。
图 10: 微信群示意
(2) 自动发送消息和邮件
PMO 系统可以通过定时扫描需求的评论和识别评论中的关键字自动发送站会纪要消息、延期风险邮件、上线周知邮件、测试日报和测试报告消息等。
为了让需求相关的信息全部都统一放置在 TAPD 中方便后期查询，并对一些操作进行自动化处理，PMO 系统定义了一些需求评论的模版，相关人员把所有需求相关的信息均按模版填写评论，PMO 系统的数据收集定时任务每隔 15 分钟扫描一次需求评论，识别模版中的关键字后，执行各类消息和邮件的发送。目前共处理 6 类关键字：站会纪要(项目经理录入)、测试日报(测试人员录入)、测试总结(测试人员录入)、延期风险(项目经理录入)、上线周知(产品经理录入)和线上效果跟进(产品经理录入)。
需求状态转为「开发中」之后，由项目经理填写站会纪要到需求评论中，PMO 系统每天上午自动发送站会纪要消息;需求状态转为「测试中」后，由测试人员填写测试日报，每晚自动发送「测试日报」;需求状态在「开发中」和「测试中」时，如果项目经理填写了「延期风险」，自动发送延期风险邮件;需求状态转为「已上线」后，由产品经理填写上线周知到需求评论中，PMO 系统自动发送上线周知邮件。
图 11: 信息的收集和处理
(3) 自动提示项目进度
一个需求评审结束的技术方案设计完毕后，开发和测试需要在 Wiki 文档和 TAPD 中利用任务功能进行排期，之后 PM 需要把排期表格拷贝到邮件中，给相关人员发送邮件。拷贝的过程是重复且耗时的。基于这些问题，PMO 系统通过 TAPD 中需求的状态流转实现了自动发送 Kick Off 邮件、提测邮件、超时控制消息等。这类需求的流程图如下图所示：
图 12: 需求状态变更和风险控制
当需求转为「开发中」，PMO 系统自动拉取该需求的各任务排期并发送 Kick Off 邮件，如果排期超迭代周期了，则需要走专门的审核流程。需求转到「测试中」，PMO 系统会自动发送提测邮件。
图 13: kick off 邮件示例
当需求未按时提测或者未按时上线时，PMO 系统会发送延期提测和延期上线消息到需求群和双周 PK 群;当任务未按时完成时，PMO 系统会发送超时未完成消息到需求群和双周 PK 群，方便 PM 和 TL 进行风险控制和有针对性的处理。如果需求上线 2 周后未填写「线上效果跟进」，PMO 系统会发送超时未跟进线上效果消息到需求群和双周 PK 群，提醒产品经理跟进线上效果。
图 14: 超时提醒
2.2.2 向上管理
为了节约产品经理在周末再次汇总和编辑本周上线内容，以及协调不同业务线产品经理编写周报时间的工作，PMO 系统每周五晚 6 点拉取本周上线的不同业务线的全部需求和每个需求的上线周知内容，给业务负责人发邮件汇报本周的需求进度和每个需求上线的效果。
图 15：上线汇总
2.2.3 数据统计
有人经常会问 PK 会议时一个迭代究竟接多少需求合适?研发 TL 在制定 KPI 目标时也经常会关注从需求实施效率角度看，当前需要几人日能完成一个项目类需求，日后目标是减少为多少人日完成一个同等规模的项目类需求?PMO 系统支持项目类需求按迭代、季度进行统计，给总监级别人员做决策时提供数据支撑。
图 16: 数据统计
2.2.4 知识沉淀和管理
团队里经常会有新鲜血液加入，PMO 对全员进行流程宣讲的频率还是比较低的，因此 PMO 系统里加入了一些项目流程的基本知识，方便新人熟悉流程和加速流程落地。
图 17: 知识沉淀
2.3 实现效果
PMO 系统分为 3 期，已全部上线。总结来看，截至目前实现的主要效果有：
- 信息统一汇总到 TAPD 后，所有人员可以方便地在 TAPD 查询需求相关的一切信息，包括评论、站会纪要、测试日报、测试报告、上线周知、线上效果等。
- PMO 系统提炼了全部需求的风险并发送到微信群，辅助 PMO 和管理人员重点关注某些高风险需求。
- 自动发送 Kick Off 邮件、提测邮件、站会纪要，并汇总和提示需求、任务延期风险，可以节约 PM 大量的时间。
- 自动汇总本周所有上线的所有需求和上线周知并发送周报给总业务负责人，节约了产品经理大量的编写周报时间。
- 帮助开发人员自动发送提测邮件，帮助测试人员自动发送测试日报和测试报告。
- 知识沉淀功能帮助 PM 和新人尽快的熟悉流程和相互学习。
Part.3 未来规划
通过 PMO 系统的应用，高效实现了需求从实施到上线全过程管理，盘活资源，实现项目增效。伴随着 PMO 系统的运行和推广，我们也在收集用户反馈并进行系统优化。与此同时，DevOps 系统也已经开发完毕并在交通业务落地。DevOps 系统覆盖了需求的从开发中到已上线的 4 个状态：
目前，对于延期提测或延期上线风险预警的依据主要来自对「实际时间」和「预测时间」之间的对比，其中「实际提测时间」、「实际上线时间」等信息是通过 PM 手动维护 TAPD 状态变更之后填写。后续 DevOps 系统将和 TAPD 打通，例如开发在 DevOps 系统中流转为「已提测」或者「已上线」后，该需求在 TAPD 中自动变为「已提测」和「已上线」，减少人为填写的不确定因素，PMO 系统统计延期提测和延期上线的需求时就会更加精准。
我们相信，未来随着 PMO 系统 与 DevOps 的打通，以及与 TAPD 等外部工具更加深度的连接，我们的项目管理将越来越高效，研发流程将越来越敏捷。
