百度 APP 大规模敏捷研发项目管理

在夯实移动基础、决战 AI 时代的百度战略下，百度 APP 承担着夯实移动基础的重任。2018 年起，工程效能部以交付加改进小分队的形式进入百度 APP，联合 PM、UE、RD、QA 承担百度 APP 版本、重点 Topic 交付加改进的工作。

一、百度 APP 介绍

百度APP是一款历史悠久，深受用户欢迎的搜索和资讯客户端，自2011年由“掌上百度”发展到2014年“手机百度”，于2018年正式更名为”百度APP“。现在百度APP作为以内容为主的容器，帮助用户完成内容消费和服务体验的全流程，建立起在移动时代连接人与内容及服务的入口；未来，百度APP将从连接信息到连接万物，蜕变为人与世界沟通的入口！面对承担如此重要的历史使命，百度APP团队将面对怎样巨大的挑战？背后涉及到的多体系、多部门、多角色，项目管理又是如何在其中扮演何种角色？和小型项目相比，大规模的项目管理是如何运作的？下面我们将以项目管理的视角切入如此大的项目中。

二、 准备期-理解特点与挑战

为了更好的理解百度APP，进入前期，就进行了从业务、架构、组织、流程各个方面的梳理，从而从整体认识了百度APP的特点，以及面临的挑战。

1、梳理组织架构

团队涉及百度内多个体系，生态内外多个部门，六个角色累积人员规模千人+。

注：Topic：百度 APP 独立具体业务，比如小程序就是一个单独的 Topic，类似的 Topic 还有 Feed、小游戏、社区等等；

2、了解业务架构

整体划分为：以基础建设的底层容器、百家号与小程序的承载形式、信息流和搜索与社区的分发模式、图文视频为内容的垂类细分业务。

3、理解特点与挑战

从组织架构上来看， 近千人规模的跨体系、跨部门、人员角色复杂，沟通成本和协同作战压力山大。从业务上来看，Topic较多且有耦合，更有跨Topic需求，全流程涉及多系统含10+个环节。

三、规划期-建立整体管理方案

1、确定目标

结合百度APP特点&挑战，建立规模化敏捷管理框架，实现整体闭环管理；提升研发效率，降低各个角色之间Handover成本，加速业务价值交付。

2、解决方案

1）整体思路

由于整体规模较大，且有区分 Topic，所以整体进行了分层管理；为了持续迭代产品，优化流程，在分层管理的同时实施闭环管理；

分层管理

确定项目组合层、Topic 层、团队层，明确各层角色、流程，落实到 iCafe，实现工具固化

•项目组合层：解决跨 Topic 的需求优先级问题，以及确定版本重点需求的问题

•Topic 项目群层：拉通 Topic 各个角色、各团队，实现跨组织、跨团队的面向 Topic 业务价值的管理

•团队层：实现组件团队的管理

闭环管理

•需求收益闭环：需求上线有收益回顾

•版本闭环：版本上线有回顾总结

2）建立规模化敏捷管理框架

每层分别对应不同流程，最后形成三类发布火车：

例行随版版本需求，每三周发版

对于需要配合运营活动、重大事件，增加三周中间小版本

针对非随版需求实施流式发布

3）管理方案

建立整体管理策略，实现整合管理，我们从如下几个方面介绍整体的管理策略：

整合管理：明确各级角色，建立各级流程、DOD(Definition of Done) 标准与度量；实现需求闭环与版本闭环；建立面向 Topic 的需求管理解决方案；

时间管理：建立三周发版节奏，建立整体发版心跳，使得各项工作有预期；

范围管理：根据需求插入时间，明确不同原则，使得需求变更有序进行，降低整体风险；

质量管理：升级质量标准，明确各项工作准入和准出，内建质量；

干系人管理：建立整体沟通地图，降低跨部门沟通成本；

沟通管理：建立整体沟通机制，实现团队内、Topic 内、跨 Topic 整体协同；

风险管理：分级风险管理；

人力资源管理：建设交付团队，落地管理机制；

四、落地期-具体管理策略与落地

下面对整合管理、时间管理、范围管理、干系人管理、沟通管理，几个具体管理策略进行一下介绍；

1、整合管理

1）版本闭环：实现版本整体业务、技术需求闭环管理

定义项目组合层-版本层的：

主要角色与职责，解决跨 Topic 需求优先级问题，实现整体版本的闭环管理

版本级别各个流程与准入准出的要求，内建质量

主要度量，实现量化管理，驱动持续改进

2）Topic 闭环：明确 Topic 项目群层的主要角色、职责、流程与度量，实现各 Topic 业务、技术需求闭环管理

3）团队闭环：明确团队层流程与度量，实现团队需求闭环管理

4）面向 Topic 的需求管理：落地与固化整体流程方案，解决 Topic 依赖管理与 Topic 内多端管理

主要思路：

空间设置：统一百度 APP 各个 Topic 整体空间，每个 Topic 一个子空间，每个子空间建立随版与非随版不同计划，再建版本计划

固化流程：通过 Feature 卡片固化 Topic 流程；通过 Story 卡片固化团队流程

卡片层级：Epic 为业务规划，Feature 为端到端需求，按照团队拆分 Story，RD 拆分 task 细化工作

团队视角：通过不同层级查询，支持团队视角

2、时间管理：建立三周发版节奏，实现整体可预期

3 周固定发版

需求前置，实现上个版本灰度期间下个版本视觉发布结束

3、范围管理：不同阶段不同插入需求策略，使得需求变更有序、高效进行

•插入节点 1（开发启动前）：需求正常走 LR 流程后，按优先级 Topic 开发排期。

•插入节点 2（需求开发测试阶段）：

Follow Topic 内部需求插入流程。原则是排定优先级，研发、测试角色评估，如果超出容量，置换低优需求；

•插入节点 3（上车截止，封版之后）：

需要发送插入邮件申请，并之前与涉及研发、测试角色评估此需求对版本影响，给出初步结论；

4、干系人管理 ：建立整体沟通地图，实现凡事 有接口人可联系

梳理 Topic，梳理主要角色

各角色/各 Topic 分别反馈对应的负责人

定期例行更新

5、 沟通管理-重要事件：建立整体闭环，实现整体管理可视化，加速问题解决与风险暴漏

确定各个层次主要事件，实现整体闭环管理

五、整体效果

通过建立整体的项目管理框架，实现了千人团队的协同，实现了版本初期优先级决策时间的有效降低，实现了整体的闭环管理。对发版周期、频率及时间成本进行了有效提升。

至此关于百度 APP 这样一个大规模的研发项目管理方案便整体展现出来。

本文转载自百度 App 技术。

原文链接：

https://mp.weixin.qq.com/s/HZMvTqMM02QTn--KhuiICg