首先做一下自我介绍，我是2013年加入阿里巴巴，在阿里我先后负责过组织级敏捷项目的管理，包括项目管理，从传统到敏捷的转型落地，负责过大型战役项目级的管理，带过双11项目。今天和大家分享的案例是在一个创新部门，带领 PMO团队，探索出一套创新业务的项目运作机制。
在组建PMO团队的过程中，我把PMO定位为业务型PMO。什么是业务型PMO呢？业务型PMO是能在组织战略业务规划不清晰的时候，带领团队帮助我们所谓的业务一号位也就是CEO，还有各职能业务团队梳理出业务目标，并保证阶段性的业务目标，要对我们的战略起到支撑的作用。
我作为PMO的leader，带领PMO团队，要帮助各个业务拿到业务结果。在业务型PMO建设的过程中，做了大量的工作，其中最重要的一个工作，我认为应该是保障业务先赢，只有业务赢了，那么我们所谓的996、007这些过程的付出，才是有意义的。
为什么这么讲呢？接下来我给大家看一个公式，这个公式不管在公司内部也好，在外部也好，我已经引用过很多次了，这个公式比较简单，是一个非常简单的算术题，100×0=0。
今天为什么在一开篇的时候要和大家强调这个公式呢？是因为现在很多公司把交付效率放到了第一位，他们把研发效能拔得很高，甚至包括我们内部的团队也不例外，但是对于业务过程的关注却不够。我想知道现在听课的同学里，有多少个 PMO团队，或者PM也可以，是挂在研发中心或者是测试中心的，有没有同学能够在互动中告诉我？我想了解有多少同学是挂在大的研发队伍里面的。
已经有人答复我了，我见过很多团队，PMO团队很少会挂在公司级别，比如说CEO下面或者是公司整个业务团队下面，绝大部分都是挂在研发中心下面，这也就造成了我们的一个困境。
我们再看一下这个公式，100代表什么？100代表研发效能，0代表业务结果，我们即使把研发效能做得非常好，交付了大量的需求和功能。但是如果我们得不到期望的业务成果，那么对于我们整个大的团队，对于整个公司来讲，这个结果就是0。
如果公司的业务成果不好，那么作为我们个体，在公司大蛋糕不好的状况下，我们分到的果实也是非常小的，所以我认为，一定要把研发效能和业务价值放到一起看，要两者相辅相成，任何一个方面的短板都会影响到我们最终业务成果的达成。
所以我认为作为业务型的PMO要想拿到业务好的结果，就必须打造出持续的业务价值交付的项目管理体系。注意，这里定义的是业务型PMO而不是业务PMO，两者是有差别的。
当然它也不是单一的需求和功能的价值交付，你需要立足于全局的业务价值交付，只做到需求的交付效率，是远远不够的。还要关注业务价值的交付，我认为这两者是相辅相成，缺一不可的，要共同为业务结果保驾护航，如何才能做到业务价值的交付？接下来和大家讲一讲我们曾经遇到的一些问题。
今天我给大家分享的内容分为三个部分，我们先讲一讲我们看到的问题，然后再讲解法，最后把我们形成的价值管理体系的最终结果和对敏捷价值的思考分享给大家。
创新业务，新团队，新业务，特别是经过一段时间，业务可能在快速成长和人员扩张之后，组织能力和管理能力或多或少都会遇到一些问题。如果不能及时纠正和调整，它是一定会影响到业务的。以下我讲的问题，我相信它不是孤立的。
回到正题，在创新性的业务里面，大家对于业务的美好愿景往往都会有很多，比如我们要改变行业，我们要成为行业的number one，在这个愿景下，我们的战略是什么？新创建的新业务可能都是模糊的。
定位都是打出来的，那么战略呢？战略也是靠打出来的吗？这点我觉得不是的。战略是达到愿景的一个规划，是对美好愿景的一个长远的规划，它是一个比较远大的目标，也是我们在工作安排或者是说业务规划的行动的纲领和指导思想。
当时这家公司面临的问题是什么呢？公司的美好愿景也是有的，公司也有着非常好的技术背景，但是这个业务的未来是什么样的，大家都描述不清楚。因为没有一个信息确定的战略，他没有战略目标，所以业务部门就丢失了主心骨。
当时这个团队实际上是有几百号人的，几百号人是怎么运作的呢？都得干活吧？都得忙碌起来，对吧？不干活这个业务部门就要砍了，对不对？所以他们就发起了不少的项目，这么多的项目也开始了抢人大战，资源开始强大起来，资源强大之后怎么办？
-
对产品团队来讲：产品团队要疯狂的去提需求，我们要做这个，我们要做那个？把我们的前景描绘得非常的美好，随着功能不停的堆叠，开发团队就来不及做。结果就导致我们要“砍”需求，但是产品确实不容易砍，因为它背后的道理还是非常高的：它站在用户的立场，所谓的“客户第一”的一个制高点，可以说它的后援团队非常强大。
-
对研发团队来讲：我们真的做不了这么多需求，怎么办？要么加人，要么“砍”需求。双方最后协商的结果就是：我们也不“砍”人，我们也不加人，我们也不砍需求，我们换敏捷吧，反正现在敏捷也很火，即使最后真的失败了，也不是我们的原因，那是敏捷的原因。
其实，我告诉大家，产品团队为什么那么喜欢敏捷呢？虽然我和产品团队的关系非常好，和产品团队也有过深入的沟通，产品团队喜欢敏捷无外乎两个原因：
-
第一个原因是没有想清楚需求的时候，他需要为需求的变更开绿灯。
-
第二个原因是业务思路上没有什么太多想法，写了那么多的需求列表，里面没有内容，没有需求的细则，他怎么办？要拉到一帮兄弟们来做共创，所以它天然的需要敏捷的团队来为它的结果负责。不过这一点我也挺理解的。因为项目管理红宝书上说过“渐进明细”，项目管理需要渐进明细，其实业务上它也是需要渐进明细的。
可是等敏捷团队建立起来了，运作的过程中就会发现问题，为什么我们的功能在集成的时候，会发现链路不通了？为什么我对你提的需求你没有做？但是我没有跟你提需求了，当我们找过去的时候，你知道别人怎么回答的吗？别人说这需求是你的也不是我的，我自己的需求都没有资源做，我哪有资源做你的需求？在业务上表现出来了各自为战的情况，也就是我们所谓的“业务竖井也好，部门竖井也好”，我们应该怎么解决这个问题呢？
于是就想我要不要单独再搞一个系统，于是乎又来了一个新的系统，我们又重复的造轮子，所以就会发现我们在一个产品里面，有时候会出现非常类似的两个功能。
这里面出现的问题就是说对于一个单个团队而言，我们敏捷运转得很好，运用敏捷后我们团队的运行效率得到大大的提高，也有着非常高效的交付。但是对于多个团队来说，就会出现这样的问题：需求越堆越多，业务场景的规划也没有，特别是各业务团队之间的配合也没有了，这个数据效应问题就越来越明显。原因正是由于缺少了整体的业务规划，全链路的业务规划，没有人认真的从上去往下看。导致我们业务之间的关联关系，协同关系就越走越远。于是乎堆了一堆又一堆的需求，感觉上像是我们用堆需求的勤劳来掩盖我们业务规划的懒惰。
这样做之后有效果吗？有用吗？其实未必有用，我们又发现了新的问题。做了这么多功能之后，我们回头一看，我们前面做的功能被谁谁谁给抄走了，人家火了，我们为什么没火？或者是说我们为什么不温不火？大家会问，这不是谁谁提出来的一个功能么？
这个功能不是我们前几个月刚做过刚上线的吗？为什么我们没火，为什么他们火了？难道他们就有天时地利人和了吗？是我们的团队不行吗？我觉得肯定不是。
第三个问题：小步快跑、浅尝辄止，价值挖掘不深入。
我们曾经叱咤风云过，我觉得这可能在执行的过程中，大家被小步快跑给带偏了，小步快跑是一个非常重要的，也是我非常喜欢的交付的思想。但往往会出现一个问题，在被KPI的时间所限的情况下，在被研发效能的挑战、被IoI驱使情况下，我们只做了一点尝试，看到问题就退，碰到问题就退，导致我们走的路不够深，就像这张图里面的挖井，明明我们知道下面是有水的，但是怎么挖都挖不出来！
在这里我认为我们要相信业务的市场敏锐度，我们要相信他们对用户心理的把握，我们要给业务足够的机会。当然小本本也是要有的，我们还是需要秋后算账的。如果一个功能或者某个业务一直产出，结果都不好，那么他们还是应该为最终的结果买单的。
是什么导致这种情况的发生呢？从PMO团队定位的高度上去观察，我需要做一些事情进行一些改变。我从上文讲过的公司里得到了一些启发，用这个公式说服了整个公司的一众人接受，或者是做到改变。
-
业务要快速发展，在没有找到一个增长点的时候，就需要不停的尝试，响应各种变化。但是在变化的过程中，是没有形成合力的。
-
一是在执行的时候，相互之间的配合和协同根本没有做起来。同样一个比较有趣的功能点呈现给用户，我们只做到了分发，而竞品能做到全方位的立体包装，进行营销、造势、传播。竞品是海陆空同时上阵协同作战。但是我们却是孤军奋战，几个人单打独斗和别人的豪华阵容比拼，想到处做以少胜多的案例，还是比较难的。
-
二是在每一个项目里，每一个需求的背后，我们还是无法充分的挖掘价值。就像刚才讲的挖井，有时候一个点的体验或者是功能没有做到位，处在临门爆发的一脚上，在小步快跑的过程中，没有琢磨透，在复盘的时候就被匆忙的舍弃了。直到有一天别人做了同样的功能，并且火了之后我们才发现，原来我们离成功是这么的近。
驱动价值交付的三大法宝
针对前面描述的几个现象以及对根因的分析，所以在我组建PMO团队时，就刻意避免了这类情况的发生，用全链路的业务视角来考虑这个问题，来建设评估团队，因此才有了PMO的定位，才有了对应的项目管理机制。
我们先讲一讲目标对齐，目标对齐就是要做到价值交付，首先我们要做到业务目标的对齐，做到业务价值的交付，要敢于打破常规，把敏捷的持续交付，从需求领域扩大到业务领域。
下面是我们项目管理框架的大图，大家初看这张图是不是感觉很熟悉？是的。这就是敏捷的Scrum运作框架，是一个非常常规的框架。在创新型项目管理的体系化建设过程中，我在这个框架的前面和后面分别加了一些内容，并建立了一个闭环机制。
在Scrum的迭代计划会之前，增加了业务上的内容。有半年一次的业务规划，还有月度的产品规划，在迭代复盘（交付复盘）之后，增加了一个业务的复盘，业务复盘计划是双月一次的，但是我们在执行的时候做到每月一次，只是规模大小不同，是用大小月来区分的，一个月大复盘一个月小复盘。
在小规模的复盘中，我们要由业务团队、项目负责人自主的去跨团队找问题做改进。然后我们把团队的改进措施和问题点，统一收集整理。在大规模的复盘中，还要增加积极的反馈，依赖关系的梳理，战术的调整等内容。也会有一些共创，可能会比较简单。当然在过程中也会诞生出一些新的项目。
业务规划和复盘注定不是一个单业务的，也不是一个单项目的，我们一定要针对所有业务和所有的重大项目，在这些业务和项目里，要有一个共同的大目标，要进行横向的业务链接和依赖的梳理，这些变化代表着我们在项目管理机制的打造上，除了关注需求交付的效率外，还关注整体业务价值的交付，做到持续的业务价值交付。
在执行阶段，我作为PMO的leader，投入了非常多的精力在业务侧，包括制定业务目标，业务目标的拆解，确定业务的战术和打法等等。业务型PMO此时的作用就是当战略目标业务规划不清晰时，要能带领团队参与到每一个业务和每一个项目，帮助业务和项目讨论清楚战略目标、业务目标、业务规划。找出每个业务之间、每个大的战役项目之间的链接点，并且做到拉通。
经过一段时间的运转之后可以做到，虽然我不是最懂业务的，不是业务领域的专家，但是我能够做到最了解业务的全局，能站在全局的视角上，补位各业务和各项目。
我们讲的补位不是一句空话，要踏踏实实、真真切切的融入到业务活动中，要建立起我们的CEO、CPO的信任关系，并保持高效和高频的互动。在规划和回顾阶段，是最需要和CEO、HR配合作战的。在规划时我们是现场拍板给结论，非常考验CEO的智慧。一旦有疑问必须在会上有结论，如果在会上确实难以达成结论，我们会在会后及时的讨论，并且给出结论。哪怕这个结论在当前的情况下，不是最正确的，也需要给出一个结论，不能让业务等待。现场的组织，我们是通过CPO来负责的。为什么说HR的作用很重要，因为当新制定的规划确定以后，还会涉及到组织架构的调整，还会涉及到人员的招聘，这些都离不开HR。
在最近的半年里，我们实施了两次比较大的规划会，一个是上半年的规划会，一个是下半年的规划会，还有两次规模比较小的规划会，因为在打仗的过程中我们会发现一些新的业务价值，所以会带来一些新价值的探讨。小的规划会比较简单，在公司里找一个大会议室就可以，利用半天或一天的时间，把事情聊透，把项目调整做完，把负责人目标明确就完成了。
大的规划会略微复杂一些，我们有一个规划会开了两天，产出相对来说是比较单薄的。另外一场规划会开的比较隆重，特意去了沙家浜，一个比较有名气的红色旅游景区，规划会开了三天的时间。我建议大家开规划会，尽量把人都集中到外面去，这样仪式感会很好，参与度也会更好，在效率上也能得到更大的提升。然后再结合会议场地，做一些集体活动，增强所有参会人的信心，让大家能够自我放飞，抛开杂念，这样才能把规划做得更好。
规划会怎么开呢？方法各有不同的，这是一个大命题，这里就不多讲了。在规划会开始之前，PMO团队的同学一定要提前做好准备和思考，当业务或者规划会卡壳了，一定要有新的办法和新的方案，让大家换一种思路来讨论问题。比如左侧的这张图，就是在规划会卡壳的时候，我们换了一种思路，把事情聊明白的。
这里有4幅图，虽然不一定能够贴切的反馈出规划会上的各种情况，但是它能够从各个方面代表了我们在规划会中遇到的一些问题，和一些好的现象。从上面两张图中我们可以看到，各个团队的协作是非常紧密的，参与度也是非常高的。在这个过程中能够建立起高效的沟通，相信这两张图的参与方一定能达到高效的决策。
下面两张图则是截然相反，一个人在讲PPT的规划，其他人呼呼大睡。另外一张图大家坐成一圈又一圈，远远的看着中间那个人讲他的规划，这是规划会吗？这不是规划会，这是一个宣导会。做业务规划，我们一定要培养团队精神，让每一个人都能参与其中，并且做到积极的互动，要保证参会人的沟通是足够有效的，当出现意外情况时，我们要及时调整，当遇到死胡同时，我们要有保底方案，能够把大家带出去。
制定目标的原则是什么？
这张图是唐僧师徒4人取经图，他们是一个团队，是一个非常伟大的团队，后面讲组织保障时还会提到他们，他们从战略到个人目标的设计和支撑做的都非常好。
唐僧一开口就讲战略，说贫僧从东土大唐而来，前往西天拜佛求经，这是他的战略目标。其实战略目标他只讲了半句，后面还有半句他不经常讲，就是西游记的后半部分，取得真经，普度众生，那是他回到大唐之后要做的事情。唐僧的战略目标是非常清晰的，而且言简意赅，4个徒弟的目标也都非常清晰，每个人都有自己的目标。
孙悟空取得真经以后，要去掉头上的金箍，回花果山做他的美猴王逍遥自在。猪八戒回到他的高老庄去做他的上门女婿，沙僧他因为犯下过失，被打到流沙河去了，那个环境是非常恶劣的，他要改善他的生活。白龙马也是一样的道理，它原本是一个龙王三太子，失手打破了一个什么东西？被发配了，他还想回到他应得的荣誉里面去。
这是他们每个人的目标，那么大目标他们是要送唐僧取经，这个目标是大家都认可的，而且非常匹配战略中的一个阶段，先到西天灵山取经。这里我们看到他不但做到了目标的一个匹配，个人与组织的目标匹配，还做到了横向对齐，上下能够形成有效的支撑，一致的目标，大家能够随着业务一起成长，各自取得各自所需的东西。
在目标的制定上有4个原则：匹配战略、阶段聚焦、要可衡量、要一致认同。当然这个目标它是符合smart原则，但是在宏观上它要满足这4个特点。
-
匹配战略是要求，不管是公司目标还是团队的目标，项目的目标他必须要和战略规划要匹配起来，必须对战略的目标起到有力的支撑。如果和战略目标是不匹配的，我们宁愿放一放或砍掉它。比如说我们今年战略上说要聚焦一个方向，那么所有的目标都不能偏离这个方向，我们为什么要给树剪树枝？因为我们要剪掉那些乱七八糟的树枝，是为了让树能够更好地生长，剪掉的那些树枝都是一些折断的枯死的或者是犯病的树枝，减掉他们才能保证树木的健康生长。
-
阶段性聚焦就意味着我们整体要有个节奏，比如我们的规划要求上半年做什么，下半年做什么，再往下我们要求我们这个月做什么，下个月做什么，一定要有一个聚焦，只有聚焦之后做到月度聚焦，季度聚焦，还有我们的半财年的聚焦，我们才能够让多个团队形成合力，也能形成跨团队的合力，最终我们的产出才能被整合放大。
-
可衡量的这个就是比较简单的了，以前我们有些目标定义是什么？是上线，某某产品2.0版上线，3.0版上线，这是不行的，在我这里是行不通的。上线它是必须有一个评估标准的，达到什么样的标准才能上线？要找出核心的优化点，比如在性能优化上，我们要求能启动，它的时间要小于两秒，帧率要大于8fps。如果说没有这些客观指标怎么办？我们就找一些主观指标，我们会通过投放问卷、用户调研，来找出我们的主被动推荐的nps，当这个比值达到一个我们特定的要求，比如说80的时候，我们才能让产品正式的面向所有用户。对于一些非常重要的项目，或者一些重要的发布，我们往往是客观的指标，主观的指标都要看到，只有两者都能达到，我们才能上线。因此为了做客观指标，我们背后还维系了一批的种子用户。
-
一致认同，相对来说简单一点了。意思就是讲大家对这个目标的认同度，大家觉得这个目标合不合理，当然这里也有两层意思：第一层意思是说下面对上面的目标要认可，也就是说公司的目标，CEO直接管的人要认；团队的目标，团队所有成员他要认，如果不认怎么办？你要想办法搞定他。第二层意思是讲跨团队的目标的认可。因为我们很多项目它不是一个单一的，和任何其他的项目或者是任何其他的业务没有偶合度的，一定是没办法做到完全切割的，那么怎么办？我们要想办法，要有我们的依赖方搞定他，让他们有足够的动力来配合完成我们对他的要求，或者是我们对他的一个目标。
目标我们讲很重要，不但要有统一的大目标，还要采集到每个团队，每个项目的小目标，更重要的是我们还要把我们的目标拆解到月度，有些长运营的目标，我们甚至拆解到月，拆解到周或者拆解到天，因为运营的项目它有时候会比较短暂，本身就只有一个星期的时间，所以我们衡量标准也是按天，或者是说我们也是按时来做数据分析，做及时的调整。
在这里我要讲个小故事，有一个心理学家他做过一个实验，他让三组人走同样的路程，去不同的村庄。那么第一组人他对整个路况一无所知，第二组人知道村庄的名字，也就是说他们要去的目标还有路程。第三组人他不但知道村庄的名字和路程，而且他还知道每一个公路旁边，他走的路的公路旁边，每一公里的地方就有一个里程碑。
由于各个组对情况了解的不同，那么最后看到的测试的结果也是不一样的。
-
-
第二组人，他因为知道路程，当他们情绪低落的时候，只要有人说快到了，大家又能加快步伐，跑起来。
-
第三组人他因为目标明确，心中有数，于是越走情绪越高涨，所以很快就能到达终点。
这说明我们在目标拆解的过程中，首先我们要有目标对吧？
目标有了之后，我们还要注意拆解，拆解成一个个小的里程碑，这小里程碑是要求我们阶段性能达到，一步步累加，达到我们最后的大目标。
目标拆解的过程中，我们要注意两个点：第一是要左右的横向对齐，第二是要上下形成有效的支撑。
-
左右对齐是说跨团队的协同和步调要一致。例如：运营说我们12月份要上一个运营活动，比如说要做圣诞节的营销，他也定了目标来匹配月活和流程。但如果产品研发没有资源配合，或者资源力度不够，这肯定是不行的。所以研发和产品都要为这个目标配合并做出关键性的成果。产品的目标可能是10月份发布个版本，保障APP的用户更新率要高于80%，让用户可以在12月份能够正常参加新的活动。对于研发它也会有相应的一个指标，比如说活动页面的内存使用量、帧率、crash率等等，它要保证运营活动性能的稳定性。往往这么一个活动，它也需要市场和PR的配合，所以他们也会有相应的目标。比如说内容的一个曝光量、传播量，甚至包括刚刚我们Bob老师也讲了，我们要比拼分享数据对不对？分享数值也是PR一个的目标。要做我们就认真的做，绝对不能应付了事。要能把各方的资源都能充分调动起来，打海陆空的一个多兵种的配合战，保障方案的落地，要充分挖掘项目的用户价值，让收益最大化。
-
上下的有效支撑，这个就比较好理解了。它就是一个项目（或者说一个功能）产生的价值到底对公司的目标是不是能够形成有效的支撑？这个是要拿出来通晒的。通晒的内容包含：目标、策略、抓手，还有需要的资源。如果是大家认的，那么这个项目就能定下来，我们就能够启动它，给资源。如果说有争议了，那么这就需要考验CEO的智慧了，他需要站在一号位的高度上，以及他对行业的理解和判断上来进行决策，这个项目到底值不值得做，是不是一个机遇，是不是值得我们去尝试的？
当业务目标拆解以后，会形成各种项目，那么整个公司业务目标的推动，也会随着一个个项目的启动来实现。那么我们是怎么排项目资源的呢？我们的经验是成立决策小组，每一个项目的核心干系人里面我们会有一个决策小组。决策小组它要包含PMO，他要保证最终的目标的一个落地，他对整个项目来负责。当然这在日本也叫做阿米巴小组，大家感兴趣的话可以去查一查。刚刚在目标拆解的时候，我们已经明确了项目的目标，也确定了最终的PMO，但这只是开始，也只是说从组织上确定要做了什么事儿，谁对结果负责，后续的执行落地需要再进一步的拆解。
项目的拆解更多的是从两个维度来做的：一个是需要多少资源，需要什么样的资源；第二个收益怎么样，性价比怎么样？
在同一个时间段如何协同好资源的调配，这是非常考验PMO以及我们自身团队的智慧的。比如：当我们确认做项目的时候，要怎么样才能让项目运转起来，而且还能拿到业务结果。通常的做法是我们要么加资源，要么砍需求，要保证用户的体验原则是不能降低的。加资源的办法也有很多，我们要招人，我们要外部借调，或者说我们要996或者007；砍需求，肯定不能毫无章法的乱砍一通，要深入到需求当中，讨论有没有更优的解法，有没有之前功能可以复用的点，当然也可能卡正在运作的其他项目上，我们来释放其他项目的核心的资源，来解决我们的资源瓶颈问题。
核心项目会成立决策小组，也就是我刚刚说的阿米巴小组的一个模式，小组里面必须有PMO的一个深度参与，要对整体的结果负责。在执行的过程中，PMO团队会产生一张项目大图，里面会清晰的标注好我们项目的资源、目标、里程碑，这个是要做到全员周知的，每一个人都能在这张表上找到自己的位置，以及自己资源分配的占比。这个列表它也包括了优先级，从上到下优先级，从上到下它意味着项目的优先级是从高到低的，这样我们能够保证我们项目的优先级，项目的威信。因为要透明，那么我把项目的名称改了，那么人、目标、里程碑都给打满了。这个项目大图是动态的，目标也会调整，人员也会调整，那么优先级也是会调整的。
项目当然也有一个结项和发起，那么项目确认以后，接下来我们就要做KO了，项目的组织建设确认之后，我们要准备立项、准备KO，因为KO前大家做足了充分的准备，所以我们的KO大会大家的压力也不会特别大。这里我写了4句顺口溜送给大家，细节就不再展开讲了。
顺口溜是“团结轻松要仪式，高层站台表重要，目标组织要讲清，保障机制要配套。目标组织的讲清是要告诉大家我们统一的目标是什么，我们谁要对哪一块的结果负责。
对于战役性的项目来讲，我们往往在项目级下面会分子项目级，子项目，还有一些专项，我们要确定好每一块的负责人是谁？每一块的目标是什么？保障机制要配套，这是说我们关于人才招聘的保障，关于人才投入投资的保障，以及我们比如说加班，甚至包括我们的一些额外奖金的一个保障和配套。
当项目明确以后，我们在执行的时候，如何做到高效交付的？那么从现在开始我要讲一讲过程的高效交付。过程的高效交付，它是需要做好业务结构的梳理以及人员职责的处理，需要我们把节奏带起来，需要这个过程的有效透明。
业务的梳理我们刚刚已经讲过了，接下来我们看看我们对于人的选择力又是怎么划分的。我们把不同职能、不同角色，还有不同的活动串联到一张宽表上来，这样大家就能明白在什么阶段是谁要对什么样的结果负责，应该要协同的团队有哪些？这里绿色的区域表示是负责人，蓝色的区域表示参与方，红颜色的这个内容是代表它是一个卡口的节点，比如我们项目的立项，在需求规划关键的阶段，我们要做内容的showcase，我们所有的产出必须要经过决策小组和管理层的确认。
-
第一，所谓的战略规划其实在这里，也包括业务规划的，也就是说我们前面说的半年一次的大规划，小规划得按需进行，小的规划通常都是打单点的，对于一个确定的方向或者规划进行讨论，看一下是不是值得做以及我们要怎么做。第
-
二， PMO全流程参与项目活动，在不同的阶段介入的形式是不一样的，比如PMO团队的身份，就是通过项目决策小组的形式来介入的。
-
第三，线上反馈是我们重点关注的内容之一，还要包括用户的反馈，业务数据的反馈。为此我们还建立了新赛道机制来保障线上的反馈能够快速的落地。
每一个流程下面，我们还有更详细的图，比如提测发布：
下面我们还会有你平时怎么做，要怎么注册标准，还有提测怎么提测，还有我们的冒烟怎么冒烟、以及冒烟通过的标准是什么？
也包括我们的非控机制，我们的发布机制，还有包括我们线上监控和非控机制等等这些细则。
仅仅有这些规则还是不够的，还需要落地执行。
落地执行过程中，我们要做到统一，统一的指挥，还有统一的步调，在行进中节奏很重要，就好比我们踏步走121一样，这个口令要喊起来，口令节奏，我们PMO会来带。在节奏中，我们不但定了节奏的规则，我们同时还是司号员，我们要做到到点我们要吹响集结号，整个公司的迭代基本上都是按照双周的迭代模式来执行的，我们把每个节点的时间固定下来，比如每周五我们进行发布评审，下个周的周二我们要正式发布上线，这就是我们所谓的班车机制。
那么多团队和业务方，点对点的发布沟通很难做。所谓婆婆太多，众口难调，那么通过班车机制的建立，我们要做到到点发车，让每一个业务团队，让每一个项目方，他们能按照节奏来自动的去匹配。好比我们要找人，给了他明确的地址和人员特征以后，他只按照这个图来按图索骥、自行匹配就可以了。
总而言之，我们要不但建机制，还要建节奏，还要把这个节奏给带起来。带节奏的过程中，我们有一个法宝，叫做过程透明，在业务和项目的执行中让一切透明，让数据说话是我们的手段，这也能让团队之间形成一种赛马机制，也会形成一种就事论事的通用的一个沟通方法。
透明我们是通过看板来做的，我们有物理看板，也有电子看板，通过这两种看板的结合，我们要做到既有仪式感，也能收集到数据。我们的物理看板它其实不只是一个需求看板，还包含了业务目标的一个达成情况。每一周都会做更新的。当然了，物理看板我们不是每个项目都有的，有的项目根据业务的管理，他要求用的是电子看板，数据的电子看板当然也是一个非常必须的，但我一般都会要求我们要把最大的目标做成物理看板，每天或者每周做了更新，要么我们就用电脑在一个特定区域投出来。不光是看板不一样，站会我们开的也是不一样的。我们的站会通常是在晚饭前开，一般是在5:30左右，因为有些人是用在多个项目里面，我们会允许开会的时间往前或往后调。
为什么选择这个时间呢？因为我们白天通常会有很多很多的会，在这个点我们要收一下，把大家的心给拉回到干事上，就这个点我们要收一下，我们要让大家整理一下思绪和心情。白天会议中我们达成了非常多的那么一致性的结论。在这里我们要广播一下，我们要同步给我们这个项目团队的同学，弄完之后早点吃饭。吃完饭干嘛？吃完饭回来，我们要集中写需求写代码了，我不知道大家有没有这种感觉，晚饭以后才是我们这一天肉眼可见的这么一个产出的高峰期。
那么站会上我们讲的内容也是有差别的，我们会讲今天的结果，讲今天的结果，我们是要告诉下游要做好接受的准备了。看看接手有没有风险，有什么计划和安排。那么讲明天，我们要讲明天的计划，告诉上游今天要做好交付的准备，你什么事情你必须在我明天上班前要做好准备了，或者我明天就没法干活了，明天都要干活了，今天你如果还交不出来，那你说这个压力大不大？
另外，我们在讲的地方要做有解法的问题或者讨论，我们要做到全员的同步，没有解法的问题，我们要记录下来，会后再讨论。一般来讲，如果需要上升的讨论和问题，我们当天无论如何一定要拿到上层的带O的那几个人，帮我们做出最后的决策，通常不会延太久，延太久这个事情我们是不接受的。那么通过这个会，我们把进展信息都做了对齐和拉通，那么这是一个日常，对于突发问题我们要怎么办？
于是我们又建立了我们的新赛道机制，前面我们也提过了，通过我们的系统监控，还有一些种子用户的反馈，还有KOL发现的一些问题等等，或者是说老板们他们抓住的一些市场的机会和热点，我们要能及时的快速的响应，并且做到产出和交付。因此我们建立了新赛道机制，我们成立了我们的特种兵团队，来保证我们过程的及时响应和快速决策。
当然这是机制上的，我们通过这种机制，我们还催生了一些产品和研发效率的一些改变和提升。比如在某些运营活动上，我们能够做到朝闻夕上，上午有一个比方说在上午我们听到或者是我们决策好，要做一个运营的项目，我们这一块可以做得到，下班前能够发布上线。当然这绝对不是一个搭一个小页面，搭一个小页面就是分分钟钟就能搞定的事情。那么遇到一些紧急的需求，我们会有应急机制来响应，保证快速决策，快速落落地。
那么对于线上bug，我们也建立了一个故障的应对处理机制，保证对用户的伤害降到最低。那么面向用户，我们采取了在线客服，并且建立了日常值班小组，负责解答用户的问题。日常值班小组是非常重要的，当有突发情况的时候，我们能够方便的快速的找到人，做到及时响应，再也是非常关键的一点，研发同学在专注工作的时候，其实也不只研发了，其实所有同学都是这样子，只有在他要在专注工作的时候都不想被打扰到，特别是达到巅峰状态的时候，你如果是打扰到别人，别人都有可能会和你急眼。那么通过日常值班小组的建立，每个人来融资，这样既能够避免到每个人都能够被既能避免每个人都被打扰，又很受研发小哥哥的喜爱，这些都是做到高效交付的一个基本保证。
这个背后我们也离不开组织保障，在组织保障上，从我们要什么样的人才这个点开始，要做到把人要带到哪去，通过什么样的氛围来打造，以及我们的手段是什么等这三个大的方面来进行阐述。
首先我们来看一看我们对人才的要求，组织的活力来源于人员的优势，人才是最宝贵的，组织保障，它最重要的就是一个人才标准的确定，以及人才梯队的建设。
我们建立了员工的能力模型，我们对pmo的能力模型也提出了一些新的要求。
通过这些模型的建立，我们能告诉我们这几百号员工，我们倡导并且要达到的目标是什么？同时也是招聘衡量的一个维度，我们需要什么样的人才加入，只有志同道合的人在一起，我们大家的同心力才会足。当然志同道合，他绝对不是要求我们所有的员工一模一样，性格特点都一样，绝对不是的。
人才的多元化也是非常重要的。人有了，军队打仗，还要有士气。我们还有营造各种各样的团队氛围和项目氛围。在氛围的营造上，我们注重仪式感，但这种仪式感大部分都是轻量级的，要做到就地取材。我们可以看到右边这张图有个同学拿个锣，这是收工锣。
那意思是说我们这个事情做完了，在项目的冲刺阶段，我们也会调动所有人的积极性，做一下紧张氛围的调节。不用刻意的去做，不用刻意的去想一些点去堆叠，这个就要求贴近我们的生活，贴近我们的同学，借助我们一线员工，借助我们日常发生的事，要学会抓点。
比如在我之前跟过的一个项目做预言的时候，有一个同学他出现了多个低级的错误，每出现一个他都会说放心，我知道问题在哪，今天我一定能搞定。大家也知道在预演过程中这个小问题太多了，大家体感一定是不好的，对不对？
我就利用这个机会，让这句话成了一个打趣的点：放心，我知道问题在哪。一出问题我就说那个人又会说了，“放心，我知道问题在哪”，大家的氛围就得到了缓解。所以pmo团队的每一个人都要有团队建设的能力。
第二，在氛围的营造上，我们要让大家不断的享受胜利，我们为什么把大目标拆解成多个阶段的小目标？为什么我们要制定里程碑？因为小目标的达成往往在难度上不会太吓人，随着小目标一个的达成，大的目标其实也在不知不觉之间也可以达成，让一个个的不可能变成一个不知不觉的已达成的大目标。
最后一看，原来虽然事情过程很难，但是结果也大，能拿能达到也会让大家感到一些意外和震惊的。这里就能让大家感觉到他的成就感，觉得他能做成事儿，这样我们能够在不断的创造一些我们的属于我们的奇迹，那么也让大家能够从一个胜利走向另外一个胜利。目标达成以后，我们不能只让马儿跑，我们还得让马儿吃草，过程有付出，也能达到这个目标，结果我们肯定是要激励的。
除了每半年的一次的绩效认可，还有每年的年终奖以外，我们还会有季度的颁奖会，颁奖会最重要的是要奖励拿到结果的项目和团队，这个奖励是公司级别的，全员都会出席，我们要为结果买单，我们要为过程鼓掌，没有拿到奖励的，也是值得鼓励的。所以我们在全员大会的第一个仪式上，我们就是要做互相感谢。每次我们感谢的方式也不一样，我们有各种玩法，比如我们会把那种力量传能量传播带，就好比我们看球的时候，我们会把能量传播带，我们还会帮前面后面主要同学揉揉肩按按摩之类的。
在整个公司的组织架构中，那么PMO的价值是非常难以用数字的指标来衡量的。大家其实还是能感觉到PMO的作用和重要性的。那么很明显的对比就是我来到这家公司之前公司是什么样的，以及我来到这家公司之后，公司又是什么样的，大家有一个切身的非常明显的一个体感。公司也没忘记我们PMO团队，还特别给我们颁发了一个侠影的神秘大奖，这个就是来奖励我们团队在台前幕后的一个付出，奖励我们为整个公司带来的一个价值。
三个“一”打通业务价值
最后我们来看一下，我们是通过目标对齐，高效交付，还有组织保障，我们做到了什么？发挥了什么样的价值？
-
一张图是指业务一张图，通过不断的跨团队的对齐和拉通，我们做到了业务目标，朝战略对齐，团队和项目的需求，我们要朝着业务目标对齐，我们开发任务和我们的交付要靠需求对接，建立了一个目标分解术，做到了上下的一个有效支撑，还有左下左右的一个横向对齐。
-
一场仗是指我们的行动一场仗，通过一系列的活动，比如业务规划会、需求排期会、站会、办事机制等等，我们要形成统一的一个指挥，建立起我们的节奏感，核心要围绕着业务目标，做到业务的一个快速调整，人力部署的一个快速响应。在过程中我们能够把我们的节奏感建立起来，并且形成一个良好的势能，走下去。
-
一颗心，是指团队一颗心，通过生产关系的梳理和组织结构的优化，从分散的团队到弱矩阵，得到虚拟的特性团队，组织上我们要做到充分的授权，通过一系列的透明化的协作和一系列大大小小的战役，建立起我们的战友情，引起我们整个业务团队的战斗力来。
通过半年的努力相比上一个半年，我们的双周迭代和按需发布的产品的版本发布频率，我们都得到了非常好的改善。我们的发布能够做到10天，我们就能发一个版本。当然这是因为和我们的双周迭代机制是有关系的，并不是说我们做不到10天以内5天内一次的发布或者是一天一次的发布，这是和我们迭代机制有关。
另外我们需求的leadtime也做了也得到了非常大的一个降低。从以前的10来天就可以做到我们最后的三五天。在业务结果上，我们有两个关键性的指标，它的增长都能超过预期的达成。当然这些目标在当初我们做设定的时候，没有人能够觉得我们这个目标能够达成，所以这个结果还是不错的。
在持续价值交付的道路上，随着越走越远，我对敏捷的四个价值观也有了更多的理解和补充。个体和互动，在这里我的理解就是要打破职能边界，要对新目标，确保我们的步调要一致。
在互动的过程中，我们要做两件事情，第一让业务更清晰更可执行，第二让过程更透明，执行更高效。可工作的软件，不但要快速交付真实的用户价值，还要和客户协作共建一个有价值的产品。在交互上我们不能只关注研发效能，还要关注整体交付的业务价值，要让两者相辅相成。
我们要在一起响应变化，要提供系统性的项目管理框架，比如我刚才讲的整个项目管理的机制，要帮助业务创新和试错。在项目管理的过程中，我们要善用一些套路和方法，但是也不要唯方法论，不管碰到什么问题，我们总要想办法去解决和克服。
总之通过持续深入的做价值交付，让业务目标、项目目标对战略目标形成有力的支撑，并且做到聚焦，横向团队要做到目标对齐，要做到海陆空的协同出击。在执行过程中，我们做到过程透明，数据透明，建立一些日常的节奏和运行机制来快速的响应业务新机制，及时的解决用户碰到的问题。对于阶段性结果，我们还要做到及时激励，及时复盘，及时修订。
最后我们做到了有业务目标一张图，行动一场仗，团队一颗心，通过合力做持续的价值交互，让业务拿到结果，让我们每个个体获得成长。
内容来源：敏捷+社区线上直播010期，《从持续的需求交付到价值交付》分享实录
分享者：阿里巴巴 彭鑫（公亮）
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）