PMO 是干什么的？不就是个拉会的嘛？

　　这种根深蒂固的误解，就像，你说你是学计算机的，别人以为你是修电脑的。如果你是这么想的，那这篇文章应该会重新认识项目管理，以及PMO这个角色。

　　我们之所以写这篇文章，一是觉得国外传到中国来的PMO守则、指导方针等，存在水土不服的问题，我们现在遇到的问题甚至可能都比国外还要复杂。二是，我们在得物飞速发展的过程中结合理论与实战积累了一些经验，希望可以跟相关从业者探讨和交流。

　　文章从得物技术团队的发展不同阶段遇到的挑战出发，PMO在不同阶段的工作方向重心，实践沉淀，能力建设演进等。

　　一 技术团队的发展

　　近几年来，得物的业务百倍增长，得物技术团队作为业务快速扩张的重要支撑，团队规模在2年多时间内也发生了指数级的变化，以20倍+的速度快速增长，在此过程中，得物项目管理团队-PMO和技术er协同摸索、实践总结出了一套得物技术千人量级的规模化敏捷实践。　　

　　与单个敏捷团队通常选择Scrum或者Scrumban的模式相比，得物PMO认为需要在此基础上选择适合自己的大规模敏捷框架，同时需要根据团队发展的不同阶段及时调整框架，而不能照搬业界熟知的框架，需要进行自创和优化。

　　本文将从得物技术部的敏捷迭代在落地过程中的实践出发，对比敏捷行业敏捷实践的共性及差异性，以大规模团队的实践做为切入点，以点带面带大家了解千人规模的敏捷迭代在得物的落地实践。

　　二 千人敏捷迭代的挑战与解题思路

　　电商业务本身属于长流程业务，从产品上架到用户下单再到履约，涉及到商品管理、订单处理、支付结算、物流配送等多个方面。长流程的业务存在较重的上下游依赖情况，业务模式的复杂度叠加组织快速发展：新人快速进场、多地协同，端到端交付的协作复杂度呈指数级上升。

　　先来看看这个过程中遇到哪些挑战：

　　团队规模快速增长，敏捷团队如何划分才能够更好的保障业务需求的可持续交付？

　　业务和产品既要还要，心里对需求吞吐没有预期？

　　需求、项目太多研发和测试的资源缺口如何提前识别并解决？

　　跨业务线的需求优先级总会出现不一致，需如何保障团队之间的协作？

　　跨团队的需求交付时间不一致？

　　如何确保大规模团队的研发效率？

　　这些问题在不同行业、不同团队规模、不同团队成熟段阶段都可能会遇到，大家都会有不同的切入点和解决方式，我们把上面的问题，归因到两类：

　　团队（资源）的划分及使用

　　业产研协同模式

　　首先来看团队划分，团队的组织形式和工作方式的选择始终要与公司的发展阶段相匹配，得物技术部从早期的100+人规模到现在的千人规模，过程中也伴随着业产研团队协作方式的变化，资源要根据公司的发展阶段，以业务顺利开展为第一调整目标快速做到支撑。

　　团队组织方式的变化，先看下面的图例：　　

　　可以看到在调整之前，团队交付的组织形式是职能型的架构组织，资源按照共享的方式在使用，因为各业务都有自己的优先级，资源使用每次都要经过多轮沟通后才能达成一致，资源使用的沟通成本很高；在这个痛点下，与业务及产品沟通后，将技术部团队交付组织形式进行了调整，调整后的团队按照各个业务线进行了资源归属的划分，一个业务线团队支持着这个业务线下不同的产品或者功能交付；从这个虚拟团队的组织形式可以看到Spotify的影子，Spotify Tribe对应业务线；Spotify Squard与该业务线下下一级的功能交付团队相对应；Spotify Charter对应前后端等团队的职能组织。

　　这样的实践经过百人规模向千人发展之后，逐渐进行了沉淀，形成了最终特性团队(Feature Team)模式设计的矩阵型组织结构，旨在与业务模式相匹配，实现研发协同与管理模式的有效设计。该组织设计涉及横向职能维度和纵向交付维度的双向发力，具体体现在以下方面：

　　特性团队业务域PM聚焦端到端交付价值

　　根据业务领域划分特性团队：将研发职能团队划分为多个特性团队，每个团队负责一个或多个业务板块的研发交付工作，实现持续端到端交付用户价值。

　　设置业务域PM统筹各职能角色：业务域PM负责统筹各职能角色，协同推动特性团队实现业务目标。

　　职能团队TL聚焦组织发展&技术演进

　　职能TL专注组织发展：组织建设、人才发展，通过招聘、培训和指导，提升团队成员的技术能力和职业发展。

　　职能TL专注架构演进：职能TL聚焦技术基建、架构演进等工作，推动技术发展和创新。

　　通过这种组织架构设计，得物技术部能够实现跨职能协作、端到端交付、业务目标导向和技术创新驱动等目标。特性团队模式的应用有助于提高团队的敏捷性、创新性和协作效率，使得技术部门更好地适应快速变化的市场需求和业务挑战。　　

　　得物敏捷迭代在推广落地过程中并没有死搬硬套行业内的一些敏捷框架，诸如团队级的敏捷框架Scrum甚至是组织级的大规模敏捷框架SAFE等，而是结合自身业务和团队的特点，借鉴和落地好的敏捷实践，形成了自己特色的解决方案。

　　其次我们来看业产研的协同，除了在组织架构的设计上保持灵活性之外，还结合敏捷项目管理方法，定义了适合得物产研的协同模式。

　　价值导向

　　敏捷开发中，产研交付以用户价值为导向，传统项目管理的铁三角（成本、时间、范围）转变为“约束”，在固定的时间周期内（Timebox），结合可用资源，交付高价值&高质量的需求。　　

　　小步快跑

　　需求在没有上线之前只是假设（假设这样做可以解决用户的问题），敏捷开发中，通过需求拆分，高优先级需求识别及迭代交付机制，尽快将一个需求从提出推进到上线，能够尽早收集用户反馈，验证需求价值，并及时响应变化。　　

　　双周迭代

　　基于以上，得物选择了双周迭代模式。基于的思考如下，1周时间较短，无法交付相对复杂的需求，同时对于存在App端的互联网公司，频繁发布也会打扰用户。3周时间较长，对在做创新或者需要快速迭代的业务模式起不到试错的效果。所以2周是一个相对刚好的节奏。

　　但是2周是一个整体节奏，并不是意味着所有需求必须等到2周才能发布，2周是最晚的发布窗口，在版本结束之前达到发布标准的可以任何时间发布，但是如果没有赶上2周的窗口，那只能等下一趟；可以参考SAFe中的ART（Agile Release Train）的概念，火车不等人。

　　这里强调一下迭代周期和发布能力是要区分开的，对于APP的迭代周期来说是以两周作为维度，但是发布是可以根据实际情况单周进行甚至任意时间点进行的动作。

　　得物有很多的业务线和对应的业务类项目，在每个迭代周期结束后，所有团队都会同时调整资源的投入方向，甚至可能会在不同的业务域之间进行资源调配；在同一时间节点调整避免了因多迭代周期节奏在不同的窗口期调整带来的协作成本并降低了人为风险。

　　另外，团队规模变大后，一些效能相关度量指标及统计报告都会以迭代周期统计，如果各个业务域节奏不一，会导致数据的横向没有可比性，这也是在制定迭代周期时容易被忽视的地方。

　　最后，当解决了团队资源和产研协同的问题之后，持续改进效率问题就变得尤为重要，在这里我们不讨论coding本身的效率，一起来探讨如何有效的设置研发效能度量指标才能真正的帮助到我们做到持续改进。

　　研发效能度量

　　没有度量就没有改进的方向，设置合理的度量指标事半功倍，否则度量会变成笑话，给团队带来负面影响。

　　举个简单粗暴的例子：人均完成需求数/每迭代；我相信大家都不会选择这个指标是因为软件开发本身是一个基于变量（需求大小、人员成熟度、开发环境及上下游环节）进行的工作，这与机械制造行业的流水线工序是完全不同的工作，不能够用工业标准的思维来衡量软件质量开发。所以要做好研发效能的度量要有一些基本的原则，才能用指标更好的评估现状，为团队持续改进提供正确的方向。

　　指标更多的注重团队，而非个人；此处的意义与OKR的本质不谋而合，指标的设定是促进团队协作，共同达到组织目标，而并不是个人KPI

　　指标重要的是关注趋势而非绝对值；因为团队的差异性，指标绝对值很难做到绝对的横向对比，无法精确的定义；可以更多从趋势上去分析，把关注点放在进一步的改善上

　　指标注意平衡性，避免在单一指标上越走越远；指标既有北极星指标，又要有全面的群星指标，做到相互制约

　　指标也需要随着团队的能力提升做适时的调整；团队实时都在变化，指标的定义也要定期的回顾合理性，适合团队阶段的指标才能起到改善的指导意义

　　得物技术部基于以上的原则制定了研发和测试过程指标，从交付速率，内建质量，持续发布能力及线上质量几个维度定义了一系列指标，在此我们不一一展开。

　　三 Type—P规模化敏捷实践

　　对以上的思路进行整理，我们用以下一些字母来进行释义，可以简单的称之为：Type-P：

　　T：Time-bound，每个目标都有DDL，帮助人们在正确的时间内设置正确的优先级、计划，并保证目标可达成的交付原则

　　y：yauld，敏捷的、活跃的，在一个通用大框架下灵活变通，符合得物价值观：拥抱变化的原则

　　p：unity of purpose，业务目标、技术认知一致的、协作意识统一的合作原则

　　e：efficient、effective，高效+有效的，从流程→协作→工作产出均高效、有效的效率原则

　　P：Poizon，得物，Type-P，也就是得物特色的敏捷实践

　　在整体阐述Type-P时，为了方便理解，引用主流的规模化敏捷LESS、SAFE作为参考。

　　Type-P、LESS、SAFE是基于不同的背景、逻辑所构建的项目管理实践方法，只有左右之别，不存在高低之分。借鉴意义并非是非此即彼的。　　

　　Type-P的一些特点

　　整体节奏统一

　　由项目管理团队-PMO统一管理、发布：得物App版本发布日历；

　　技术部整体遵循相对统一的版本节奏时间要求：双周版本，固定服务端/客户端发布日，方便所有业务、产品、技术团队共识评审、交付节奏。

　　统一的单域敏捷标准/流程/规范

　　由项目管理团队-PMO统一收口技术部门级别的单域敏捷标准/流程/规范，并出版统一的项目管理白皮书，从需求阶段、开发阶段、测试阶段、发布阶段，分阶段阐述各阶段的关键活动、组织者、参与者、准入/准出标准、项目管理工具RDC操作指南。

　　统一的版本管理

　　相同的时间周期内进行研发交付工作，可以为数据收集和分析提供一致的时间框架，有助于建立统一的数据采集规范，提高数据准确性，使得各业务线横向的度量数据具有可比较性；

　　帮助PMO和管理者更好地识别潜在风险并加以解决，如某业务域出现的资源瓶颈，可以通过度量数据识别出同版本周期内人力相对富裕的团队，及时进行人力借调，以保障需求交付；

　　资源协调和透明度的提升可以在技术部所有团队的角度提供更大维度的操作空间。

　　灵活调整、裁剪的分域治理

　　分域治理：以业务条线维度整体划分业务域、分域治理：业务域X、业务域Y、业务域Z等等。

　　各类资源数各域固定；

　　各域单独一份product backlog，业务一号位决策，域内优先级决策高效。

　　各域流程灵活调整、裁剪。

　　在抽象出Type-P的核心原则的过程中，发现和Type-C的命名非常相似，也期望得物所特有的Type-P在经过过去、现在、未来的努力之后，不仅是得物特色，也能同Type-C一样，成为一种业界通用的“标准接口”，给更多同业/同行更多的参考、借鉴意义。

　　四 PMO团队实践过程中的演化

　　敏捷实践过程的落地离不开PMO团队，这个过程中PMO首先承担了以下的一些工作。

　　制定Type-P的组织级的项目管理框架、流程及维持运行一致，并持续优化

　　规划、建设统一项目管理工具：研发协同平台（简称：RDC），从流程、报表、资源、效率等维度支持部门级项目管理健康运行、监控、优化

　　分域支持各域项目管理个性化治理：确保符合各域在Type-P的大流程框架下，灵活增加、调整、裁剪，以适配业务/产品/技术团队的真实使用诉求

　　承接独立项目、在流程、机制、跨域协同中起到重要支持、提效作用

　　这些工作其实业内大部分团队是一样的，但是随着团队人数的增多，团队成熟度的变化，敏捷实践阶段的改变，PMO团队的定位和方向也是随着变化的。

　　从“吞吐优先”向“价值优先”过渡。流程落地、项目管理工具落地是在实践过程的前期一定会去做的事情，这个落地过程中的问题也会因为各种因素层出不穷，这个阶段的落地目标也会把团队的吞吐情况作为第一目标去完成。

　　当落地阶段完成之后，常规PMO团队所需要完成的事项就变成了基础工作，团队目标也从“吞吐率”转向了“价值”，这里的价值有两层含义：第一是需求和项目的交付更注重业务本身的价值，形成端到端的闭环，从需求提出本身的价值角度判断优先级，提升团队交付的意义。在业内，很多团队的闭环交付受到业务形态和外部因素的影响，在尾部复盘阶段会推行的很艰难。第二是PMO自身在职能团队和业务团队中的价值，帮助团队找到流程卡点和人效洼地，提出改进方案和提升研发团队效能产出。这需要PMO和团队建立足够的信任感，提升自身在团队的影响力，信任感的建立不是一朝一夕的，需要在日常的工作中真正帮助到了团队，才会逐渐形成。

　　这个目标看似简单，但是实际过程中还是会有很多难点，需要得物的PMO具备更强的个人综合实力和软技能，业务感知力、数据分析能力、谈判技巧、团队洞察力、社交能力等，迭代和项目管理是基本盘，需要花更多的时间在技术团队的人效提升上，哪怕是交流沟通去建立信任，也是一件花时间的事情。

　　五 小结

　　本文先从团队发展的角度，看我们遇到的一些挑战；第二部分针对这些挑战，不断去尝试解题思路；这些挑战是从实际出发，结合实际问题我们归纳到两类，一个是资源，一个是协同。那从资源协同的角度，我们怎么抽象化地解这个问题？解这个问题就两个思路，一个是解资源的，另一个是解协同的，协同上又用到了价值导向、小步快跑和双周迭代的思路。不管是协同、资源、还是问题也好，都会牵涉到「研发效能度量」，通过上文的思路和举措，基本上就是把我们遇到的挑战给解决了。另外，也补充说明了得物特色的敏捷管理思路Type-P，区分主流项目管理框架，因地制宜，打造了得物特色千人敏捷项目管理。

　　每家公司所处的行业，阶段各不相同，敏捷宣言也已经从1.0升级到了2.0，随着AI时代的到来，符合各自敏捷场景的落地又会有更多的变化和挑战，希望通过上面的一些介绍，能给大家在敏捷落地过程中有一些启发，也希望大家可以拥抱变化，一起交流，共同进步，开创一个属于我们自己的敏捷时代。