05　阿里巴巴从需求交付到价值交付

作者介绍

彭鑫　阿里巴巴淘宝某业务PMO团队负责人，2018年双十一大促的项目经理。2013年加入阿里巴巴，从事研发管理和项目管理工作，组织过多地大规模项目研发的管理、业务线敏捷研发转型、产品级规模化敏捷的全生命周期项目管理工作，近期负责淘宝战役级项目管理和业务型PMO团队的建设。

案例综述

作为业务型PMO，不仅要关注最基础的业务价值的持续交付的能力，更要思考业务和战略，关注业务目标的持续达成以促进战略的完成。组建业务型PMO，完成一系列的活动，在达成战略目标的同时，也很好地诠释了阿里的文化——一张图、一场仗、一颗心。

案例背景

1.没有价值的交付等于没有交付

随着敏捷方法的普及，越来越多的团队引入了敏捷以推动业务的快速迭代、小步快跑，及时地响应市场变化。在各种敏捷框架的指引下，交付效率得到提升，可以很容易地做到持续的需求交付。有了高效率的需求交付就一定能拿到业务结果吗？并不尽然，需求的交付集合只代表了功能的完成，并不能代表业务的价值。如果用100代表交付效率，0代表业务价值，两者结合的最终业务成果为100×0，也一定是0。因此，只关注需求的交付效率是不够的，还要关注交付的业务价值，二者相辅相成、缺一不可，共同为业务结果保驾护航。

2.交付的三大痛点

在推行敏捷的过程中我们发现，有的团队本身就有一些和敏捷方法无关的业务问题或者组织问题，这些问题通过敏捷实践被暴露和放大，最终会影响业务价值的交付，拖累业务结果。主要表现为以下几个方面：

1）没有战略目标，丢失了业务主心骨。主要表现为战略不清晰，目标不聚焦。这是许多公司的通病，这类公司往往有着美好的公司愿景，比如要改变行业或成为行业第一，但战略规划却是模糊的，找不准定位和坚持的方向。战略是对美好愿景的长远规划，是远大的目标，是公司活动的纲领和指导思想。正因为战略是如此的重要，管理层一定要明确公司的战略目标。

2）用堆需求的勤劳掩盖业务规划的懒惰。团队引入敏捷之后，就单个团队而言运转很好，Scrum Team的沟通效率得到了大大的提高，有着非常高效的交付。但是，与此同时也出现了新的问题，需求越堆越多，但业务没有长远的规划，各业务团队之间也没有配合，“竖井效应”越来越明显。正是缺少业务规划，建立不了各业务之间的关联关系，导致协同作战也越来越困难。

3）业务价值没挖透，却想着“天上掉馅饼”。在堆砌了很多功能之后，突然发现竞品刚刚推出的活动“火”了，但这个活动我们刚刚做过。这时候我们会陷入思考，为什么我们做的没有“火”，但竞品“火”了？是我们公司的员工和用户的问题吗？其实不是！这里有两个原因，一是在被误解的“小步快跑”交付思想下，许多业务的价值点没有挖透；二是职能团队之间没有形成联动，只做了功能的交付和自运营。可以想象，一个单一功能的交付，怎么可能比得过一个由产品、运营、PR、市场、渠道等多职能协同的业务交付呢？

3.找到根因才能解决问题

归根结底，以上问题的原因有2个。一是创新业务的不确定性。创新业务在高速发展阶段，本身有许多的不确定性，而管理机制却不能满足业务的需要。二是价值挖掘的不充分性。在执行时各职能的配合没有形成合力，例如同一个活动上线，靠自增长肯定比不过全方位协同作战。

针对以上的问题，我们在业务目标对齐、过程高效交付、组织保障配合三个方面进行了实践，做到持续价值交付，并促进业务目标达成。

案例实施

1.业务目标对齐

（1）武装业务价值交付的思想

要做到业务价值的交付，就要敢于打破常规，把敏捷的持续交付从需求领域放大到业务领域。如图5-1所示，业务流程的中间区域是敏捷方法中经典的Scrum运作框架，在此基础上增加业务的反馈闭环，既在链路前端增加半年一度的业务规划和月度的产品规划，也在链路后端增加了双月一次的业务复盘。业务复盘也可以固定到月，还可以按需不定期地召集，业务复盘中还可附带轻量级的共创，其结果可能是关闭一些项目或启动一些新的项目。

业务规划和复盘，一定不是单业务、单项目的，而是面向所有业务和重大项目的，规划会上会产生新的共同目标，会有横向的业务链接和依赖梳理。业务型PMO在此时的作用就是，当战略目标、业务规划不清晰时，要带领团队制定战略目标、弄清楚业务规划、找到各业务之间的链接并拉通。

图5-1　业务流程

（2）以规划会为价值交付的起点

业务规划会需要CEO、HR配合好，规划会、复盘会需要CEO现场给结论、做决策，不能拖延。尚不清晰的业务不要启动，业务不具备启动条件的也不要启动，要做到恰到好处。当然，这并不是停滞不前，业务不清晰就要继续分析，有人才缺口就要及时招聘。HR不仅要负责后勤保障，还要参与其中，要根据业务的决策结果会做组织架构的调整，也还要根据需要落地招聘。

大型共创会建议在公司以外的场地来开，比如沙家浜、井冈山等著名的红色旅游景区。一是仪式感非常强，还能做一些集体活动打开大家的心扉，为执行做好铺垫；二是避免日常的打扰，提高大家的参与度，在效率和产出质量上都能有很大的提升。

（3）战略目标的原则

我们在制定战略目标时需要注意4个原则：匹配战略、阶段聚焦、可衡量、一致认同。特别要强调的是，一致认同不仅要团队内部认同，也要横向团队的认同以便更好地进行跨团队协同和配合。

（4）将目标合理拆分

战略目标制定之后，要将其转化为每个业务的目标、每个项目的目标，还需要制定阶段的可衡量目标以及阶段的业务打法和策略。所有的拆解颗粒度至少以月为单位，要让目标与成果共同支撑业务发展。对于重运营的项目，还要拆解到周甚至是日。

有一个心理学家做过一个实验，他让三组人走同样的路程去不同的村庄。第一组人仅知道村庄的名称，第二组人知道村庄的名字和路程，第三组人不仅知道村庄的名字和路程，还知道公路旁每一公里处就有一块里程碑。由于各组掌握信息情况的不同，测试的结果也不同。第一组人由于对路况一无所知，越走情绪越低落，尚未到达终点，队伍就已经解散；第二组人因为知道路程，所以当他们情绪低落时，只要有人喊一句“快到了”，大家就又加快了步伐；第三组人因为目标明确，阶段可衡量，于是越走情绪越高涨，很快到达了终点，而且花费的时间远少于第二组人。

在项目上，我们不仅要拆解好目标，还要注意目标下各职能团队的子目标对总体目标的支撑。比如说我们12月份要上一个圣诞节的营销活动，确定了总的目标为活动的总参与人数、留存，拆解到产品团队就要保证对应的版本尽早发布，保证营销活动的App升级率达到80%；技术团队的目标是要保证活动页面的稳定性，包括内存使用量、流畅度；市场团队也会有相关的目标，比如内容量、分发量等。要充分调动各方资源，进行多方配合，保障方案落地，充分挖掘项目的用户价值，让收益最大化。表5-1可以作为目标拆解的参考。

表5-1　目标拆解的工作计划表

2.过程高效交付

（1）明确权、责、利

要做到高效交付，必须明确参与人员的权、责、利。我们把不同职能、不同角色、不同活动放置在一张宽表中，这样大家能明白在什么阶段，是谁对什么结果负责，应该协同的团队有哪些等。如图5-2所示，不同的区域代表不同的职能，而PMO的工作将会贯穿于链路的每一个环节。

图5-2　明确项目参与人员的职责

图5-2只是经过提炼的粗表，实际上在每个流程下还有更详细的流程和分工，比如提测发布的下面还会涉及TC评审、自测、冒烟、灰度、发布、线上监控和回滚机制等流程，其中不仅包括负责人，还包括规则等执行细则。关于流程，每个业务需要立足于自身的组织特点而设定不同的制度和机制，切勿完全照搬。

（2）班车机制

仅仅有规则还是不够的，还需要有节奏。业务要有业务节奏，项目要有项目节奏，这就像行进中的军队，在统一的号令下才能保障各兵种协同亮剑。基于同一个产品的发布，我们引入了班车机制，每周五做发布评审，下一个周三正式发布。一个产品由很多业务团队集成，点对点的发布沟通十分困难。在班车机制中，我们“到点发车”，每一个业务方和团队都能按照这种规律化的时间安排自己的业务节奏。

（3）过程透明与高效决策

让一切透明，让数据说话是业务和项目的执行中的不二法门。数据的透明，能让团队形成就事论事的沟通方法。除了电子看板，我们还有物理看板，通过两种看板的结合，既有仪式感，也能收集到过程数据。除了需求看板外，还有业务数据看板，业务数据看板会依据业务的实际情况，每周或者每天更新数据。以上的内容也可以使用电子看板来展现，但我们通常会配一台大屏电视来实现落地。

为了保障研发效率，站立式会议（以下简称站会）通常会选择在晚餐前开。这个时候，白天的各种信息可以进行收敛和同步，其后根据进展进行赶工，保障对下游的交付。在站会上，我们不强调每个人都讲，而是需要根据需求交付的最终状态的大节点来重点关注，比如风险中、阻塞中或者一个状态太久没移动的需求要被重点关注。对于协同性要求比较高的项目，我需要参加多个站会，此时我就会安排多个站会按顺序执行。日常的项目，我们也会通过SoS站会来关注进展和风险。

为了快速响应用户的问题，建立了需求快速决策机制、线上故障应急机制，为降低用户使用产品的门槛引入在线客服。客服背后有对应的日常值班小组，由各个职能团队的小伙伴轮值，这样既能帮助用户解决问题，又能走进用户，了解用户痛点。日常值班小组不仅解决了突发情况的快速响应问题，还能保证大家在工作上保持足够的专注力，避免被频繁地打断。

3.做好组织保障

一个团队的是否高效取决于团队的人才优势是否足够，因此我们建立了员工能力模型，告诉大家我们需要到达什么样的“段位”，同时也是对外招人的衡量标准。只有志同道合，才能万众一心，当然，志同道合并不是说要让团队成员一模一样，人才是需要多元化的。

在氛围营造上我们需要仪式感，大部分的内容就地取材加以有意放大。某个项目的第一次预演会上，一个前端人员出现了多个低级的Bug，每出现一次他都会说：“放心，我知道问题，今天搞定”。我抓住机会，把“知道问题”临场放大为“什么都知道”，不仅缓解了相关人员的压力，也让整个项目氛围变得更融洽。因此我要求，PMO必须有团队建设的能力。

真正的胜利，是鼓舞心中的希望。把看起来无法达成的大目标拆解为一个个踮起脚尖可达成的阶段目标，随着一个个阶段目标的达成，大目标也在不知不觉间达成。通过大家的努力，一个个的不可能变为可能，大家都获得了成就感，证明了每一个人的价值。

目标达成后，我们不仅让马儿跑得欢，还要给马儿草吃，因此每个季度我们都会对拿到结果的优秀团队和优秀项目进行激励。激励会上还有一个保留的节目，即感谢身边同事的共同努力，大家拉拉手、揉揉肩，为结果买单，为过程鼓掌。

4.三个“一”打通业务价值

通过一系列的活动和机制的运作，最终形成了阿里巴巴的文化——一张图、一场仗、一颗心。

“一张图”是指业务一张图。通过不断地跨团队的对齐和拉通，做到了业务目标朝战略对齐，团队和项目的需求朝业务目标对齐，开发任务和交付朝需求对齐，建立了目标分解树，做到了上下有效支撑，左右横向对齐。

“一场仗”是指行动一场仗。通过一系列的活动，比如业务规划会、需求排期会、站会、班车机制等形成统一指挥，围绕核心业务目标，做到业务快速调整，人力部署快速响应，在过程中建立了节奏感。

“一颗心”是指团队一颗心。通过生产关系梳理和组织过程结构优化，从分散的团队到弱矩阵再到虚拟的特性团队，组织上充分授权，通过透明化的协作、和一系列大大小小的战役建立友情，凝聚了整个业务团队的战斗力。

通过半年的努力，相比上一个半年，通过双周迭代和按需发布产品版本的发布频率降低到10天一次，提升了220%，需求的leadtime也降低了167%。在业务结果上，两个关键的指标增长超过预期，完成度达到108%，而曾经没有人觉得这一目标能达成。

案例总结

在持续价值交付的路上，我对敏捷有了更多的理解。

1）个体和互动就是要打破职能边界、对齐目标、确保步调一致。互动可以让业务更清晰、更可执行，让过程更透明、更高效。

2）可工作的软件不仅要快速交付真实的用户价值，还要与客户协作，共建有价值的产品。在交付上，不只关注研发效能，也要关注交付的业务价值，两者相辅相成。

3）响应变化就是提供系统性的项目管理框架，帮助业务创新、试错。在项目管理的过程中，我们要善用套路和方法，但也不能唯方法论。不管遇到什么问题，我们总有办法解决和克服。

总之，通过持续、深入地做价值交付，让业务目标、项目目标聚焦于战略目标，形成有力的支撑，横向团队做到目标对齐、协同出击。在执行过程中要做到过程透明、数据透明，建立日常节奏和应急机制，及时响应和解决业务新机会和用户遇到的问题。对于阶段结果，要做到及时激励、及时复盘、及时修订。最终我们要做到“业务一张图、行动一场仗、团队一颗心”，通过合力持续交付价值，让业务拿到结果，个体获得成长。