PMO 是干什么的？不就是个拉会的嘛？
这种根深蒂固的误解，就像，你说你是学计算机的，别人以为你是修电脑的。如果你是这么想的，那这篇文章应该会重新认识项目管理，以及PMO这个角色。
我们之所以写这篇文章，一是觉得国外传到中国来的PMO守则、指导方针等，存在水土不服的问题，我们现在遇到的问题甚至可能都比国外还要复杂。二是，我们在得物飞速发展的过程中结合理论与实战积累了一些经验，希望可以跟相关从业者探讨和交流。
文章从得物技术团队的发展不同阶段遇到的挑战出发，PMO在不同阶段的工作方向重心，实践沉淀，能力建设演进等。
近几年来，得物的业务百倍增长，得物技术团队作为业务快速扩张的重要支撑，团队规模在2年多时间内也发生了指数级的变化，以20倍+的速度快速增长，在此过程中，得物项目管理团队-PMO和技术er协同摸索、实践总结出了一套得物技术千人量级的规模化敏捷实践。
图片
与单个敏捷团队通常选择Scrum或者Scrumban的模式相比，得物PMO认为需要在此基础上选择适合自己的大规模敏捷框架，同时需要根据团队发展的不同阶段及时调整框架，而不能照搬业界熟知的框架，需要进行自创和优化。
本文将从得物技术部的敏捷迭代在落地过程中的实践出发，对比敏捷行业敏捷实践的共性及差异性，以大规模团队的实践做为切入点，以点带面带大家了解千人规模的敏捷迭代在得物的落地实践。
电商业务本身属于长流程业务，从产品上架到用户下单再到履约，涉及到商品管理、订单处理、支付结算、物流配送等多个方面。长流程的业务存在较重的上下游依赖情况，业务模式的复杂度叠加组织快速发展：新人快速进场、多地协同，端到端交付的协作复杂度呈指数级上升。
这些问题在不同行业、不同团队规模、不同团队成熟段阶段都可能会遇到，大家都会有不同的切入点和解决方式，我们把上面的问题，归因到两类：
首先来看团队划分，团队的组织形式和工作方式的选择始终要与公司的发展阶段相匹配，得物技术部从早期的100+人规模到现在的千人规模，过程中也伴随着业产研团队协作方式的变化，资源要根据公司的发展阶段，以业务顺利开展为第一调整目标快速做到支撑。
团队组织方式的变化，先看下面的图例：
图片
可以看到在调整之前，团队交付的组织形式是职能型的架构组织，资源按照共享的方式在使用，因为各业务都有自己的优先级，资源使用每次都要经过多轮沟通后才能达成一致，资源使用的沟通成本很高；在这个痛点下，与业务及产品沟通后，将技术部团队交付组织形式进行了调整，调整后的团队按照各个业务线进行了资源归属的划分，一个业务线团队支持着这个业务线下不同的产品或者功能交付；从这个虚拟团队的组织形式可以看到Spotify的影子，Spotify Tribe对应业务线；Spotify Squard与该业务线下下一级的功能交付团队相对应；Spotify Charter对应前后端等团队的职能组织。
这样的实践经过百人规模向千人发展之后，逐渐进行了沉淀，形成了最终特性团队(Feature Team)模式设计的矩阵型组织结构，旨在与业务模式相匹配，实现研发协同与管理模式的有效设计。该组织设计涉及横向职能维度和纵向交付维度的双向发力，具体体现在以下方面：
根据业务领域划分特性团队：将研发职能团队划分为多个特性团队，每个团队负责一个或多个业务板块的研发交付工作，实现持续端到端交付用户价值。
设置业务域PM统筹各职能角色：业务域PM负责统筹各职能角色，协同推动特性团队实现业务目标。
职能TL专注组织发展：组织建设、人才发展，通过招聘、培训和指导，提升团队成员的技术能力和职业发展。
职能TL专注架构演进：职能TL聚焦技术基建、架构演进等工作，推动技术发展和创新。
通过这种组织架构设计，得物技术部能够实现跨职能协作、端到端交付、业务目标导向和技术创新驱动等目标。特性团队模式的应用有助于提高团队的敏捷性、创新性和协作效率，使得技术部门更好地适应快速变化的市场需求和业务挑战。
图片
得物敏捷迭代在推广落地过程中并没有死搬硬套行业内的一些敏捷框架，诸如团队级的敏捷框架Scrum甚至是组织级的大规模敏捷框架SAFE等，而是结合自身业务和团队的特点，借鉴和落地好的敏捷实践，形成了自己特色的解决方案。
其次我们来看业产研的协同，除了在组织架构的设计上保持灵活性之外，还结合敏捷项目管理方法，定义了适合得物产研的协同模式。
敏捷开发中，产研交付以用户价值为导向，传统项目管理的铁三角（成本、时间、范围）转变为“约束”，在固定的时间周期内（Timebox），结合可用资源，交付高价值&高质量的需求。
图片
需求在没有上线之前只是假设（假设这样做可以解决用户的问题），敏捷开发中，通过需求拆分，高优先级需求识别及迭代交付机制，尽快将一个需求从提出推进到上线，能够尽早收集用户反馈，验证需求价值，并及时响应变化。
图片
基于以上，得物选择了双周迭代模式。基于的思考如下，1周时间较短，无法交付相对复杂的需求，同时对于存在App端的互联网公司，频繁发布也会打扰用户。3周时间较长，对在做创新或者需要快速迭代的业务模式起不到试错的效果。所以2周是一个相对刚好的节奏。
但是2周是一个整体节奏，并不是意味着所有需求必须等到2周才能发布，2周是最晚的发布窗口，在版本结束之前达到发布标准的可以任何时间发布，但是如果没有赶上2周的窗口，那只能等下一趟；可以参考SAFe中的ART（Agile Release Train）的概念，火车不等人。
这里强调一下迭代周期和发布能力是要区分开的，对于APP的迭代周期来说是以两周作为维度，但是发布是可以根据实际情况单周进行甚至任意时间点进行的动作。
得物有很多的业务线和对应的业务类项目，在每个迭代周期结束后，所有团队都会同时调整资源的投入方向，甚至可能会在不同的业务域之间进行资源调配；在同一时间节点调整避免了因多迭代周期节奏在不同的窗口期调整带来的协作成本并降低了人为风险。
另外，团队规模变大后，一些效能相关度量指标及统计报告都会以迭代周期统计，如果各个业务域节奏不一，会导致数据的横向没有可比性，这也是在制定迭代周期时容易被忽视的地方。
最后，当解决了团队资源和产研协同的问题之后，持续改进效率问题就变得尤为重要，在这里我们不讨论coding本身的效率，一起来探讨如何有效的设置研发效能度量指标才能真正的帮助到我们做到持续改进。
没有度量就没有改进的方向，设置合理的度量指标事半功倍，否则度量会变成笑话，给团队带来负面影响。
举个简单粗暴的例子：人均完成需求数/每迭代；我相信大家都不会选择这个指标是因为软件开发本身是一个基于变量（需求大小、人员成熟度、开发环境及上下游环节）进行的工作，这与机械制造行业的流水线工序是完全不同的工作，不能够用工业标准的思维来衡量软件质量开发。所以要做好研发效能的度量要有一些基本的原则，才能用指标更好的评估现状，为团队持续改进提供正确的方向。
得物技术部基于以上的原则制定了研发和测试过程指标，从交付速率，内建质量，持续发布能力及线上质量几个维度定义了一系列指标，在此我们不一一展开。
对以上的思路进行整理，我们用以下一些字母来进行释义，可以简单的称之为：Type-P：
在整体阐述Type-P时，为了方便理解，引用主流的规模化敏捷LESS、SAFE作为参考。
Type-P、LESS、SAFE是基于不同的背景、逻辑所构建的项目管理实践方法，只有左右之别，不存在高低之分。借鉴意义并非是非此即彼的。
图片
各类资源数各域固定；
各域单独一份product backlog，业务一号位决策，域内优先级决策高效。
在抽象出Type-P的核心原则的过程中，发现和Type-C的命名非常相似，也期望得物所特有的Type-P在经过过去、现在、未来的努力之后，不仅是得物特色，也能同Type-C一样，成为一种业界通用的“标准接口”，给更多同业/同行更多的参考、借鉴意义。
敏捷实践过程的落地离不开PMO团队，这个过程中PMO首先承担了以下的一些工作。
这些工作其实业内大部分团队是一样的，但是随着团队人数的增多，团队成熟度的变化，敏捷实践阶段的改变，PMO团队的定位和方向也是随着变化的。
从“吞吐优先”向“价值优先”过渡。流程落地、项目管理工具落地是在实践过程的前期一定会去做的事情，这个落地过程中的问题也会因为各种因素层出不穷，这个阶段的落地目标也会把团队的吞吐情况作为第一目标去完成。
当落地阶段完成之后，常规PMO团队所需要完成的事项就变成了基础工作，团队目标也从“吞吐率”转向了“价值”，这里的价值有两层含义：第一是需求和项目的交付更注重业务本身的价值，形成端到端的闭环，从需求提出本身的价值角度判断优先级，提升团队交付的意义。在业内，很多团队的闭环交付受到业务形态和外部因素的影响，在尾部复盘阶段会推行的很艰难。第二是PMO自身在职能团队和业务团队中的价值，帮助团队找到流程卡点和人效洼地，提出改进方案和提升研发团队效能产出。这需要PMO和团队建立足够的信任感，提升自身在团队的影响力，信任感的建立不是一朝一夕的，需要在日常的工作中真正帮助到了团队，才会逐渐形成。
这个目标看似简单，但是实际过程中还是会有很多难点，需要得物的PMO具备更强的个人综合实力和软技能，业务感知力、数据分析能力、谈判技巧、团队洞察力、社交能力等，迭代和项目管理是基本盘，需要花更多的时间在技术团队的人效提升上，哪怕是交流沟通去建立信任，也是一件花时间的事情。
本文先从团队发展的角度，看我们遇到的一些挑战；第二部分针对这些挑战，不断去尝试解题思路；这些挑战是从实际出发，结合实际问题我们归纳到两类，一个是资源，一个是协同。那从资源协同的角度，我们怎么抽象化地解这个问题？解这个问题就两个思路，一个是解资源的，另一个是解协同的，协同上又用到了价值导向、小步快跑和双周迭代的思路。不管是协同、资源、还是问题也好，都会牵涉到「研发效能度量」，通过上文的思路和举措，基本上就是把我们遇到的挑战给解决了。另外，也补充说明了得物特色的敏捷管理思路Type-P，区分主流项目管理框架，因地制宜，打造了得物特色千人敏捷项目管理。
每家公司所处的行业，阶段各不相同，敏捷宣言也已经从1.0升级到了2.0，随着AI时代的到来，符合各自敏捷场景的落地又会有更多的变化和挑战，希望通过上面的一些介绍，能给大家在敏捷落地过程中有一些启发，也希望大家可以拥抱变化，一起交流，共同进步，开创一个属于我们自己的敏捷时代。
本文链接：http://www.28at.com/showinfo-26-80830-0.html千人规模敏捷迭代实践分享，你学会了吗？
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： .NET WebAPI 自定义返回类：实现统一与灵活的API响应
下一篇： 面试官：听说你很懂线程池？
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
