哈啰:团队过程管理演进之路

职能团队依据业务领域需要划分为跨职能团队,怎么让团队运转起来?怎么组织跨团队的事情?怎么提升团队的自组织能力?怎么了解团队的效能情况?怎么拉通价值流上的角色?本文为你阐述团队管理的进化、精细化之路。本文主要分享哈啰技术团队的文章。@pdai

团队是什么样的?

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

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

  • 业务团队,包括品牌、供应链、营销、生产、运营等部门
  • 产品团队,按照产品线划分,也可能是产品线的聚合,比如C端、B端
  • 开发团队,往往按照技术栈划分,同时考虑领域的划分,比如大前端包括前端、移动端,后端又根据领域划分各个小组
  • 测试团队,通常是跟开发团队分开的,隶属质量保障部门,保持独立性

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

我们从哪里开始?

过程导入

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

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

  • 3个角色

    • 产品经理(PO);
    • Scrum Master;
    • 团队(开发+测试)。
  • 3种交付物

    • 产品需求池;
    • 迭代需求池;
    • 版本交付。
  • 5个活动

    • PO将需求提在产品需求池中,经过评审、设计、迭代规划(KO),进入迭代需求池;
    • 采用双周迭代的形式,交付版本,迭代周期和版本周期一致,都是两周;
    • 迭代中的每一天都有站会,以同步状态、发现风险、解决障碍;
    • 版本交付后有针对交付成果的评审会;
    • 有针对迭代过程的回顾会。
  • 5大价值观

    • 承诺;
    • 专注;
    • 开放;
    • 尊重;
    • 勇气。

过程导入中的物理看板

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

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

  • 看板上每一列代表任务的状态
  • 列中的每个卡片代表一个任务,任务对应到一个人
  • 行首的每个卡片代表一个需求
  • 看板右边是迭代燃尽图,用以指示进度风险

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

  • 每个卡片代表一个问题记录
  • 行和列是部门及团队

标准化流程规范

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

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

  • 业务提出需求给产品
  • 产品和研发进行需求评审
  • 产研做迭代规划向业务运营给出版本承诺
  • 开发提测需求由开发阶段进入测试阶段
  • 开发、测试将需求交付产品进行验收

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

其它

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

  • 周四进行版本发布,既要关闭上个迭代,又要启动新迭代
  • 迭代启动之前的周一,产品经理将待评审的需求列表给到研发团队,启动需求评审、设计
  • 迭代启动后的2-3天进行用例评审
  • 为保证迭代内版本按时交付,规定周4是最晚的提测时间
  • 测试启动后2-3天进行UED验收
  • 测试完成定时启动产品验收

这样团队对于工作节奏有了一个共识,跨团队、跨部门也工作在相同的节奏中,对于协同效率非常有利。至此,我们团队运转得应该就比较良好了,也会暴露一些问题,比较典型的跨团队大粒度的事情怎么组织。

怎么组织跨团队的大粒度事情?

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

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

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

  • 专项需求拆分至迭代团队
  • 专项里程碑划分与迭代及版本周期对齐(双周)
  • 迭代站会之后设立专项每日站会进行专项相关跨团队的沟通
  • 专项定期会议(比如周会)进行沟通

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

如何提升团队自组织能力?

技术PM

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

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

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

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

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

Owner机制

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

  • 领域Owner

    • 参与长周期、大粒度项目规划;
    • 价值分析、系统分析、架构设计;
    • 对齐产品架构与技术架构。
  • 项目Owner

    • 专项立项、项目团队建立;
    • 专项实施过程监控、协调、沟通;
    • 项目结项评价、价值达成评价。
  • 故事Owner

    • 需求评审、规划、设计;
    • 需求落地过程跟进;
    • 需求价值达成评价。

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

怎么了解团队的效能情况?

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

  • 我的团队在干什么?
  • 我有多少人?需要多久完成一个新需求?
  • 我的团队干的如何?质量、效率怎么样?

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

电子看板的引入

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

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

  • 通过电子大屏的方式,我们可以模拟物理看板的仪式感、代入感
  • 电子看板数据自动记录,不会丢失
  • 不受区域的限制,使得信息传播更容易,信息更透明;
  • 信息切换容易,能展现更丰富的信息,比如需求列表、bug列表、燃尽图
  • 跨团队的需求依赖关系、跨团队项目需求聚合跟进等,展现了更大范围的信息
  • 不受地域限制,像哈啰这样在上海和杭州都有研发中心的公司,使用电子看板开每日站会或迭代规划会就很方便
  • 通过与其他的系统的连接,打通、获取更多功能和信息

扩展电子看板应用

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

  • 利用Jira插件为Jira本身进行了扩展

    • 利用BigPicture进行项目规划;
    • 利用ScriptRunner进行数据搜索扩展;
    • 利用EasyBI进行报表数据统计;
    • 利用WebHook与钉钉等第三方系统连接。
  • 与其他系统结合

    • 与项目管理平台结合,生成数据报表;
    • 与质量管理平台结合,将用例、测试过程与需求绑定;
    • 与CI/CD系统连接,将代码分支创建与需求绑定,打通价值流与CI/CD PipeLine。

团队视角的数据报告

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

  • 通过既往人力分布,回答干了什么的问题
  • 通过进行中人力分布,回答正在干什么的问题
  • 通过对需求池情况的分析,回答还有多少事情要干的问题
  • 通过迭代报告,回答在时间维度上干得怎么样的问题
  • 通过专项报告,回答在重要事情上干得怎么样的问题

研发效能

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

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

  • 通常通过多种类型的指标进行评价

质量;效率;能力。

  • 可以从多种维度和场景进行评价
    • 团队组织层级:组织、部门、团队各层级;
    • 时间维度:迭代、月度等;
    • 需求层次:专项、需求;
    • 角色:根据角色特点呈现相关信息,比如技术PM对于过程的把控程度。

研发团队是怎么关注价值交付的?

研发过程与价值交付

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

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

  • 需求设计阶段

    • 直接参与价值达成预估;
    • 系统可实现性、人力成本预估,作为成本体现在ROI分析中;
    • 通过业务流程分析,映射到产品、技术架构,相互对齐;
    • 对于系统失败的损失进行风险预估。
  • 研发落地阶段

    • 通过对质量、效率的关注,加速价值交付;
    • 通过技术沉淀、技术创新加速业务孵化、筑建业务壁垒;
    • 通过大数据、算法、数据埋点等技术形式进行价值分析。
  • 线上运营阶段

    • 数据采集、分析,评价价值达成情况;
    • 数据协助产品/业务改进、决策;
    • 保持稳定性、进行业务监控,保障业务价值持续、稳定输出。

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

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

拉通产研—目标、过程、价值

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

产研月会的主要内容有:

  • 对齐目标

    • 确定新项目的优先级和等级;
    • 对齐阶段性目标;
    • 指导细粒度优先级;
    • 指导迭代规划。
  • 同步进程

    • 进行中项目完成状态、风险;
    • 阶段总结项目过程及投入分布;
    • 跟踪改进措施。
  • 关注价值

    • 量化分析项目达成情况;
    • 分析成功或失败的原因;
    • 产生新的需求或改建措施;
    • 产生产品,业务决策。

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

我们得到了一个什么样的管理框架?

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

在这样的管理框架下,我们的团队能够持续改进和进化。

文章涞源

转载说明

  • 作者:张晓辉
  • 版权声明:本文为哈啰技术团队的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
  • 原文链接:https://tech.meituan.com/2019/02/21/rd-team-resource-cost-optimization-practice.html

联系我

添加@pdai微信

PS:添加时请备注Java全栈,谢谢!