团队过程管理演进之路

我们的团队分为职能团队和跨职能团队。

组织架构上通过职能进行组织：

• 业务团队，包括品牌、供应链、营销、生产、运营等部门

• 产品团队，按照产品线划分，也可能是产品线的聚合，比如C端、B端

• 开发团队，往往按照技术栈划分，同时考虑领域的划分，比如大前端包括前端、移动端，后端又根据领域划分各个小组

• 测试团队，通常是跟开发团队分开的，隶属质量保障部门，保持独立性

在日常工作过程中，需要产研配合，在产品线上进行产品迭代开发。因此形成了跨职能的产线团队，跨职能团队由产品经理、开发、测试共同组成。

我们从职能团队按照产品线重组了虚拟的跨职能产线团队，那么团队形成后从哪里开始呢？我们需要有一个基本的管理过程框架，让团队RUN起来，我们采用的是Scrum的框架。

Scrum框架的要素总结起来叫3-3-5-5：

在引入框架初期，我们更多使用物理看板引导团队进行各项活动，因为物理看板有更强的交互感、代入感、仪式感，对于过程活动习惯养成很有利。

比如利用迭代看板进行每日站会：

• 看板上每一列代表任务的状态

• 列中的每个卡片代表一个任务，任务对应到一个人

• 行首的每个卡片代表一个需求

• 看板右边是迭代燃尽图，用以指示进度风险

团队每日站会之后，我们会有一个SOS的站会，利用SOS（Scrum of Scrum)看板解决跨团队、跨部门的风险预警、障碍解决：

• 每个卡片代表一个问题记录

• 行和列是部门及团队

经过一段时间的运行，就逐步形成了稳定的工作流，定义出从需求提出到上线运营的过程，在这些过程之上有一些规范。

特别是在角色间进行工作转换的卡点上，为了保证过程质量和效率，规范更为重要：

• 业务提出需求给产品

• 产品和研发进行需求评审

• 产研做迭代规划向业务运营给出版本承诺

• 开发提测需求由开发阶段进入测试阶段

• 开发、测试将需求交付产品进行验收

这些卡点上的流程规范保证团队在一定的规则下运转，团队有了很多共识，减少冲突、提高沟通效率和质量。

同时，我们在双周迭代过程中也形成了一定的工作节奏：

• 周四进行版本发布，既要关闭上个迭代，又要启动新迭代
  

• 迭代启动之前的周一，产品经理将待评审的需求列表给到研发团队，启动需求评审、设计
  

• 迭代启动后的2-3天进行用例评审
  

• 为保证迭代内版本按时交付，规定周4是最晚的提测时间
  

• 测试启动后2-3天进行UED验收
  

• 测试完成定时启动产品验收
  

这样团队对于工作节奏有了一个共识，跨团队、跨部门也工作在相同的节奏中，对于协同效率非常有利。

至此，我们团队运转得应该就比较良好了，也会暴露一些问题，比较典型的跨团队大粒度的事情怎么组织。

组织或部门中往往有一些比较大粒度的需求，需要在一定时间内完成（有deadline）；这些事情往往是比较重要的，比如新产品特性攻坚、双11大促支撑等。因为重要，所以需要特别重视和对待，我们称这些事情为专项。

我们把专项相关的人聚集在一起，形成一个虚拟的专项团队，方便把专项的过程、活动显示出来。

实际运作过程中，通过一定的措施，让专项需求实际在迭代团队中交付：

• 专项需求拆分至迭代团队

• 专项里程碑划分与迭代及版本周期对齐（双周）

• 迭代站会之后设立专项每日站会进行专项相关跨团队的沟通

• 专项定期会议（比如周会）进行沟通

通过专项虚拟团队，我们既将专项过程好价值特别呈现，又将专项落地融入到迭代开发中，降低了管理成本。

过程导入初期，PMO的同学到部门中引入过程框架，通过迭代活动，对团队进行辅导，形成了稳定的过程规范和工作节奏。

伴随团队的逐渐成熟、团队对于人才培养的需要、成员自身发展的需要，我们首先引入技术PM的角色。

技术PM从团队中来，通常是研发同学担任，主要承担Scrum Master的职责，推动过程活动流畅进行，对迭代过程结果负责。在选择的时候，通常跟职能部门leader共同商议，选择有潜力的同学，作为部门人才储备。

技术PM在技术和管理方面都要有良好表现，在管理方面我们建立了技术PM的成长路径、能力模型、评价反馈机制和长期培训赋能计划。

在团队过程不断成熟、发展的同时，不少同学后面顺利成为了团队Leader。

除了技术PM，我们还明确了几种类型的Owner：

这样就形成在不同层次上事情都有人负责，分担了管理压力，提高管理的精细化水平和效率。在提升团队主人翁意识的同时，提升了团队自组织能力。

作为部门或者团队的leader，经常会问这样的问题：

• 我的团队在干什么？

• 我有多少人？需要多久完成一个新需求？

• 我的团队干的如何？质量、效率怎么样？

想得到相对确切、量化的答案，我们需要数据支撑，而数据来自于团队日常活动。

前面我们说在过程导入初期，使用物理看板，提升代入感、参与感，但过程数据除非人工记录，就会丢失掉。

电子看板就很容易解决这个问题，我们来看看电子看板的优势：

• 通过电子大屏的方式，我们可以模拟物理看板的仪式感、代入感

• 电子看板数据自动记录，不会丢失
  

• 不受区域的限制，使得信息传播更容易，信息更透明

• 信息切换容易，能展现更丰富的信息，比如需求列表、bug列表、燃尽图

• 跨团队的需求依赖关系、跨团队项目需求聚合跟进等，展现了更大范围的信息

• 不受地域限制，像哈啰这样在上海和杭州都有研发中心的公司，使用电子看板开每日站会或迭代规划会就很方便

• 通过与其他的系统的连接，打通、获取更多功能和信息

我们对电子看板进行了一些扩充的应用，Jira是主要使用的电子看板。

有了电子看板的加持，我们就很容易回答部门leader的几个问题了：

• 通过既往人力分布，回答干了什么的问题

• 通过进行中人力分布，回答正在干什么的问题

• 通过对需求池情况的分析，回答还有多少事情要干的问题

• 通过迭代报告，回答在时间维度上干得怎么样的问题

• 通过专项报告，回答在重要事情上干得怎么样的问题

刚才我们聊的是从团队、部门leader的角度对于团队情况的分析、评价，这只是研发效能的一个场景视角。

研发效能整体上是为了我们的过程能够持续高效率、高质量交付有价值的需求。

我们在讲效能的时候，更多时候在说效率、质量、工程能力，对于价值方面的关注往往被忽略，特别是研发团队。

那么我们来看看研发过程对于价值交付的关注是怎么样的。

可以看到我们的研发活动与价值交付在每个阶段都息息相关。

之前我们讲T型人才观，更多是对于跨技术栈能力培养，现在也包含了产品业务思维等软实力的扩充，我们需要在团队中树立这样的人才观念。

价值交付牵涉到端到端的协同，研发团队需要与产品、业务团队一起进行目标对齐、过程协同、价值评价。我们采用产研月会的形式，拉通双方。

产研月会的主要内容有：

产研月会是阶段性的拉通会议，可以在更长周期OKR目标制定拉通、指引下进行，形成自顶向下、不断检视、适时调整的良好循环。

我们从导入基本的Scrum框架开始，让团队在稳定的过程规范以及节奏下工作，提升了团队内部以及跨团队的协作；
引入电子看板，使得信息更透明、数据能记录、对过程有更客观的评价；
通过引入技术PM、领域Owner、故事Owner、项目Owner在各个层次上发挥作用，提升了过程效率同时，提升团队自组织能力、主人翁意识，也丰富了团队的人才储备；
通过产研月会，拉通产研的目标、过程、价值，延伸了过程端到端的协作；
通过丰富的效能指标、场景应用，客观评价过程、发现问题、持续改进过程；
在这样的管理框架下，我们的团队能够持续改进和进化。

The End

如果你觉得这篇内容对你挺有启发，请你轻轻点下小手指，帮我两个小忙呗：