转自本人运营的公众号“ 携程技术中心PMO”（ID：cso_pmo）

作者简介

杨大鹏，某互联网平台PMO团队负责人，10多年软件项目和技术团队管理经验，在日本工作生活多年，曾服务于外资银行及金融互联网企业，对复杂项目管理、跨团队协作、甲乙方技术团队管理有丰富的落地经验，目前正致力于推动技术团队敏捷转型及赋能型PMO建设。

文末获取大鹏哥在AUG上海站分享的《大型跨团队项目的协同流程》

先扯点文史哲

一本红楼梦，因读者的眼光不同会有各种解读。“经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事”，这是鲁迅先生的感叹。莎士比亚也有句名言，“一千个读者,就有一千个哈姆雷特”。上升到哲学高度，《老子》开篇的“道可道非常道”更是微言大义。

针对同一事物，除了不同理解以外，还会有不同动机。一个有趣的例子在《厚黑学》里，厚黑教主指出“召陵之役，不责楚国僭称王号，只责他包茅不贡”。有兴趣的同学可以去百度这段历史。

由于有不同环境、不同角度、不同思考维度、不同参照系等一切主客观不可控因素，针对同一事物总会有不同的认知，这也造就了我们这样一个充满无数矛盾共同体的有趣世界。

 “敏捷”（Agile）也是这样。“敏捷”在IT及互联网领域被作为一种“济世良方”而被寄予厚望。基于各种动机，众多企业在开展敏捷实践，懵懵懂懂的IT小伙伴被裹挟在其中，被动参与到各种敏捷实践中，随波逐流，晕头转向。

典型案例：

为了提高研发效率，IT部门领导要求推进敏捷。然后无论大家是否能够理解敏捷原则和实践意图，也没有定量数据证明效果的情况下，经过几次Scrum培训，Scrum就被仓促上阵，各种角色设定起来，计划会、站会、回顾会开起来，大家都忙得不可开交。过个一年半载再看，敏捷实践仍然停留在召开Scrum会议的阶段，不但拿不出提高效率的证明，反而往往产生大面积的质疑和牢骚。

这是一个典型的失败案例，当问题得不到解决的时候，所有的实践必然会变成应付，最终走向不了了之，这种肤浅的实践注定不会起到实质性作用，对企业和个人是一种双输。你的企业是这样吗？

敏捷实践的四个范畴

DP哥是一家互联网平台企业的PMO负责人，操盘了整体的敏捷实践，在实践过程中历经了太多的纠结，面对过各种小伙伴的各种问题，进行过无数次的复盘、反思。DP哥不喜欢吐槽，但希望和大家分享思路，因此尝试从动机的角度去分析敏捷实践，希望能帮助小伙伴们厘清问题思路，摆正自己在敏捷实践中的位置，也希望能使小伙伴们感知到“敏捷对自己的好”，提高对敏捷实践的信心。

从开展敏捷实践的动机方面进行分析，DP哥认知简述如下：

1）基于动机角度，敏捷包含四个范畴：

• 组织的敏捷转型
• 适合敏捷的项目任务
• 规模化研发与DevOps
• 个人及小团队的敏捷化

2）四个范畴分别代表了：组织的动机，项目任务的动机，协同与效率的动机，个人与团队成长的动机。

3）这四个范畴尽管有共同的敏捷内涵“以人为中心、价值驱动、鼓励合作、拥抱变化”，但对于IT小伙伴来讲，却是基本没关联的独立话题。

4）在讨论敏捷的时候，首先确认话题的范围属于哪个范畴，避免双方不在一个频道上。

下面DP哥分别阐述下这四个范畴。

组织的敏捷转型

目前能够看到一些现象：最热衷于投入重金“从上至下”推动敏捷转型的，往往是一些大型成熟企业、跨国集团、大型银行等，反而不是互联网企业，分析其动机，是因为他们在这个VUCA时代遇到了需要用敏捷来应对的局面。

传统组织架构面临着巨大的挑战

传统组织架构来源于“泰勒”的“科学管理”理论，其基本出发点是，为支撑起大规模的工业时代，需要一部分高能力的人去预测出生产方式，并且规划、拼接、协调庞杂的生产流程，另一部分人只要执行就好。其成功点是将“管理”制度化作为纪律，管理者负责思考、规划，工人们负责执行。处于决策顶端的人负责战略决策，每个层级的管理者会检视目标并进行拆解，从而规划出好的执行方法；处于底层的人物，则应当根据指示行动。这个理论的基础在于事物的可规划和可预测性，并且将规划和执行互相分析，它改变了世界，仍然是当今管理理念的基石。

当企业发展到一定规模，不可避免会出现所谓大企业病，包括深井式的组织架构、孤岛式的信息系统、导致隔阂的部门墙、只知发号施令的领导作风，职能的臃肿，决策效率的低下，官僚主义盛行，创新能力衰弱，所有的问题都被甩锅给流程和最高领导，如果说在工业时代的极少数对极少数模式，大企业病通常并不会导致致命，但现在已经不一样了。在这个VUCA时代，情况已经变得更复杂，市场从极少数对极少数模式，演变成了多对多模式，行业的转折点可能不经意就会来临，如不能成功进行战略转型，会被最终干掉，诺基亚殷鉴在前。

而决策者经常恐惧的发现，企业发现自己陷入一种无法掌控的生态系统和价值网络中，几乎无法预测或规划自己的命运，针对价值判断的难度，已经超过了决策者的理解范围。

组织的敏捷转型动机

而在探索这些问题的解决方案时，任正非说“让听到炮火的人呼叫炮火”；阿米巴模式提倡“全员参与经营”；丰田重视长期理念并建立学习型组织；德鲁克明确指出，管理者应该激发和释放人本身固有的善意潜能，来创造价值，工业时代的“胡萝卜加大棒”方式对与知识工作者已经完全不起作用。

究其根因，是因为决策者们不约而同的认识到，自己做出的决策，不见得比一线团队更好。最靠谱的方法，应该是让掌握最多信息的一线团队去自己试试，如果这个一线团队比较强，成功的可能性会更高一点。

为了建立这种机制，企业需要调整组织架构，打破层级架构，建立网状组织，确保底层和前线的声音能被上层听到，又要打造能力超群和韧性十足的基层团队，并且实现互信和目标共享，即建立敏捷型组织。

为了建立敏捷型组织，领导最应该做的是要为团队赋能，在快速响应市场变化的过程中，组织领导需要“双眼紧盯、双手放开”，赋予一线团队更好的“试错”和成长机会，赋予一线团队更多的安全感和自主性。在未来，“英雄式领袖”会越来越少，领导者应该是敏捷型组织环境、组织文化、组织氛围的建立和维系者。这需要领导者改变自己的思维，不要再试图以“突出的能力，强大的意志”“英雄式”的牢牢控制一切，而是要带领企业走向敏捷转型。

你实践的是组织的敏捷吗？

敏捷转型是艰巨的侵入式变革运动，需要使组织的流程、制度、文化发生本质的改变，方式方法也会伴随着战略方向的调整而不断调整，在组织敏捷转型所遇到的障碍中，排在前三位的是“改变组织文化的能力，人们对组织变革的抵制，组织现有的瀑布式流程”。

那么，小伙伴们，你所在的组织在进行敏捷转型吗？你在参与实践吗？高层领导在改变吗？你的部门主管在改变吗？项目运作流程在改变吗？如果大大小小的主管不理解敏捷，不拥抱变革，不改变管理模式，而只是在下属团队中开展敏捷实践活动，那么敏捷实践一定会遇到阻碍。如果敏捷实践只在研发内部开展，产品管理团队仍然以瀑布的方式提供产品需求，他们也往往成为敏捷实践的拖累者。

如果连你的主管和重要干系人也认为敏捷转型与他们无关时，你还能标榜自己的团队在进行敏捷实践吗？

如果你只是实践了Scrum方法，或者实践了极限编程和持续集成，你仍然是在用正确的思路在提高自身和团队的技术水平，你默默的继续做就是了，但不要标榜自己在进行敏捷实践或转型。关于这个话题，在第四个范畴中会详细解释。

推荐一本畅销书，建议小伙伴浏览下。

《赋能》（Team of Teams）这本书精妙而又全面的阐述了相关观点，这本书的副标题就是“打造应对不确定性的敏捷团队”。

适合敏捷的项目任务

项目有多种形式，也有多种实施方式。需要根据项目的实际情况，选择合适的项目推进方法，而方法并没有对错之分。

项目的四种生命周期

PMI的官方资料，根据项目的特征，项目可以分为四种生命周期。

预测型生命周期：项目在开始时就确定项目范围及所需的时间、成本，以顺序的方式执行。项目应该具备如下特点：项目的可交付成果描述清晰，团队有较为丰富的类似项目经验。项目从高确定性的明确的需求，稳定的团队和低风险中获益，但不会在项目结束前交付商业价值。项目管理的目标是减少变更和管理成本。

当遇到变更或需求分歧，使得技术解决方案变得不再简单明确时，预测型项目就会产生意向不到的成本。瀑布模型是预测型生命周期的典型代表。

迭代型生命周期：通过不断的验证来改进产品或成果。针对同一需求，团队可能会连续的收集各种见解和不断返工。在复杂度高、受不同观点支配和变更频繁时，迭代生命周期会有优势，但它是为学习而优化，而不是为了交付速度，相比预测型可能需要更长时间和成本。

增量型生命周期：客户可能无法等待全部事情都完成，而是愿意接受解决方案的一部分。为为了加快交付速度，这种少量成果的频繁交付成为增量型生命周期。

敏捷型生命周期：团队预料到需求会发生变更，希望尽早交付来获得反馈和商业价值。

没有好与坏只有是否合适

没有哪个生命周期能够完美地适合所有项目。每个项目都需要根据其特征，找到最佳方式，并实现最佳平衡。这种方式可能是混合的，比如项目的一部分采用预测型，一部分采用敏捷型，或者前期整体评估采用预测型，过程中采用短迭代的增量交付以及站会回顾会等。又或者以一种为主，另一种为辅。选择了某种生命周期，也并不意味着就要僵化地执行下去，需要根据项目的综合情况来判断分析。项目管理的目标是在给定的当前环境下，尽可能以最好的方式创造商业价值，采用哪种方法并不重要，重要的是“我们怎么做才能成功”。

小伙伴们，你们在做的研发项目，适合哪种情况呢？

敏捷研发取得成功的，多是面向人的业务系统，或者toC的互联网产品。 用户故事（User Story）里面的第一项内容就是“作为...角色的用户，她/他想要....,因此才能....”. 这种需求收集是以用户为中心的。因此，但凡遇到重交互的系统，敏捷方法都可以很好的工作。

反之如果是中后台系统，或者数据采集和分析系统，大量的工作都是经过抽象的业务模型和数据计算逻辑，这种STORY的需求分析的方式就不容易适用了。再加上中后台的产品技术团队往往并不接触业务前线，也很难判断业务价值，采取以瀑布为主的方式反而更加合适。

对于纯技术性质的探索和尝试通常的做法是采取小范围尝试，切入少量流量或系统进行快速验证和收集反馈，然后不断迭代重构以及扩大范围，这是典型的“经验型过程控制”（Empirical Process Control）—一种根据实际项目中的现实观测而做出决策的流程，这是是符合人的自然认知规律的。无论你是否“敏捷”，你都会这么做。只是在当前，大家也把这个列入“敏捷”范畴。 

中国互联网行业的特点：应用驱动型创新

中国的互联网行业发展迅速，每一个风口都会出现一哄而上，迅速形成激烈的竞争局面。而成功存活下来的互联网企业无一不是能够很快的响应市场变化，打造出优秀产品，快速形成价值，总结成一句话那就是“快速响应用户的需求变化”。无论他们是否标榜敏捷，其过程都是符合敏捷定义的。那么中国互联网是怎样一个情况呢？

在发达国家，互联网带来的进步是渐进的，在原先良好的基础上逐步升级产业。而中国在进入互联网时代时，由于部分行业市场成熟度较低，许多市场需求无法被满足，从而留下大量空白。而互联网提供了解决方案，解决了原有产业痛点，得到了跳跃成长的机会，在某些领域甚至成为主导市场的力量。

加上中国拥有多层次的经济和社会结构，导致需求的高度多元化，因此在中国也就出现了数量众多的独特创新，并展现出令全世界吃惊的创新精神和能力。这也导致中国互联网企业更偏向商业模式、应用、内容层面的应用驱动型创新。

这一创新偏重，一方面导致了中国互联网行业的竞争门槛相对较低，能够快速吸引了众多的新企业加入竞争，容易形成对风口和热点的集聚追逐，导致竞争更激烈。这就要求企业要更善于挖掘多变的市场需求、更追求创新频率和短期见效，因此节奏变化更迅速，市场波动性更大。回顾近年来中国互联网行业的几大风口，无一不呈现出资本迅速汇集、竞争迅速白热化、高峰期企业数量多、企业存活率低的现象。相对应地，在中国互联网行业也更加容易“一夜成名”。

在这种情况下，互联网的IT项目就面临了两方面的压力。一方面，希望快速交付并满足业务使用，以最快速度吸引眼球抢占市场，一方面求能够随时应对变化，甚至要不断试错，要求以尽量小的成本验证各种可能性。同时，多变的节奏打破了原来的协作方式，针对新衍生出来的工作任务，在旧有组织结构的语境中经常会出现模糊空间，很难快速理清这些任务究竟应该谁来做。

在这种背景下，涌现出了大量适合敏捷生命周期的项目，如果这些企业能从流程、制度、绩效等方面提供“敏捷”支持，确保敏捷交付与商业实践的良好协作，那么必然会给企业带来相应的商业价值。

写到这里突然想到了传统美食金拱门的例子。

你可能没有想到，麦当劳也会有优秀的敏捷实践案例。DP哥曾经在一些敏捷交流的场合与麦当劳的伙伴有过深入沟通，后来在网上找到了一篇《麦当劳中国化》的文章，文中提到，麦当劳曾经拿出选土豆的追求完美精神，用五年时间打造出一款没有BUG的APP，面向全世界推出后但没有被市场所接受。文中如是说，“最早上线的麦当劳的APP评分并不高。之前的版本是在麦当劳全球的框架里面开发的，用户体验也来自于全球统一的标准流程。”麦当劳中国数字业务副总裁冯莲说，‘这个经历还是蛮痛的，如果说一个产品不采用更敏捷的方式去做，当最终生成、推出市场的时候就已经过时了’”。而在中国，在2017年，麦当劳用了40天的时间就勇敢的上线了小程序，成为首批实现小程序应用的企业，而小BUG和不完善也没有影响用户对小程序的使用热情。有兴趣的伙伴们可以自己去找找这篇文章。

C端的情况：携程的优秀实践

携程面对的是C端客户，我们看看他们是怎么面对适合敏捷的项目任务的。

典型案例：

业务场景：让旅客退房后无需将行李寄存酒店然后再折返去取，或者到达后不用专门去酒店放行李。从而节约半天至一天的游玩时间，节省折返酒店的费用。当时市面上还没有类似线上业务，也不知道市场有多大。

（行李寄送在美国、日本、新加坡是一种线下标准服务，一般由快递公司经营。DP哥当年在日本东京生活过，回国的时候，由于行李太多银子太少，选择了从大阪坐船回国，近百公斤的几大箱行李由“宅急便”上门揽收，直接邮寄到了轮船的托运安检口，而在美国听说有航空公司上门办理登机托运的。在中国，相关业务并没有得到大规模的发展。）

创意来源：来自携程内部创新工场的讨论。但由于成本、安全、时效的考量，大家并不看好。调研阶段：虽然不被大家看好，但一名产品经理并不死心，着手收集资料，联系当时了提供线下行李寄送的6家公司，调研成本、安全、时效等解决方案，终于得到领导的尝试许可。

最初阶段：该产品经理在携程APP的一个角落里发布了一张图片和预定电话，并亲自充当客服，24小时接听客户咨询和下单需求，在一段时间之后，得出结论，这个业务是有需求的，然后开始立项（携程的OK制），目标是日均100件行李。截至此时，经手的人仍只有这名产品经理1人。

立项上线：立项后开始设计原型和交互，加入进来2名团队成员，1名后端研发，1名前端研发。二周后上线，时间是2016年11月1日。

项目成长：立项后加入两名商拓的伙伴，开始拓展线下供应商以及酒店合作，在不断改进的同时，业务覆盖范围从8个境内城市，2个境外城市，到后面20个境内城市，10个境外城市。通过不断的发展，团队越来越大，范围越来越广，截至2017年2月，仅仅三个月，就达成了第一个小目标，日均100件。于是设定了第二个小目标：10倍增长……

这是DP哥用自己手机在携程APP截的几幅图（2019年4月7日）。

一个符合敏捷生命周期的项目，被完美地用敏捷的方式实现了。

这是个典型的ToC端的案例，如果说这个创意是一粒种子，在携程的土壤中，长成了大树。我们可以看到，在项目推进的每一步，组织都提供了合理的支持。小伙伴们，你所在的企业会有类似的项目吗？如果有，那么恭喜你，你们的项目任务天生适合敏捷。你要做的，就是把这些创新想法，努力的去落地实施。

携程是经过了敏捷转型的，他们这么描述自己，“过程就是一部真实的血泪史，团队经过了漫长的5年时间，终于修成正果，完成了一个小目标，那就是研发团队的敏捷方法覆盖率达到80%”。同时他们实现了“让团队以最短路径完成业务目标”。

他们在创新管理、业务驱动、保持高效、激活创业激情、培养创业型人才、塑造文化上下工夫，他们的实践包括：创新的组织结构（OK制）、高效的运营管理（OKR）、创业型激励机制（投名状）、人才培养管理（黄埔训练营）、文化塑造与改造（管理层理念革新）。

推荐一本书，《大产品，小团队：携程敏捷技术与管理转型实战》，这本书只讲实战不谈理论，可以看看他们是怎样利用敏捷的生命周期去做项目，并在竞争愈演愈烈的市场中立于不败之地的，“OK制”等名词的解释，可以在书中找到答案。

B端的情况

ToB端的情况会复杂，研发者天然不是用户，用户往往不是买家，因此更需要分析市场趋势，作长远的规划，你需要全面地考虑各个方面的因素，比如竞争对手的情况，行业规范监管条例，客户的内心诉求，你要形成长期的产品愿景，长期的战略规划图，这个长期往往是1年半到2年。落实在平台系统的建设上，可以以三个月为周期建立开发路线图，并分解成项目组合、项目集，并衍生出大大小小的项目，这个过程通常由PMO团队协助完成。

非常重要的一点是，无论对内对外，都要坚定的传递这样的信息：一切都是按照战略规划图在有条不紊的进行！

对于这些衍生出的项目中，根据各自特征安排合理的生命周期就好了，瀑布也好、敏捷也好、亦或是混合的，综合考虑确定性、效率、资源、交付周期、反馈等情况，寻找最佳实践和最佳平衡。

未完待续...

编者按

工具可以做为技术的辅助，但更重要的是使用者的思想认识；我们既要尊重现实情况，又要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成能够落地的协同，最终形成合力共同迈向目标。

关注公众号“ 携程技术中心PMO”（ID：cso_pmo）

回复“协同”获取《大型跨团队项目的协同流程》分享材料

推荐阅读

• 携程 | 如何管理敏捷团队知识资产
• 携程行业分享 | 规模化敏捷实践
• 携程PMO | 年度热文回顾
• Scrum Master 新官上任三把火

部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们。

Key Word：敏捷总动员,携程技术中心,敏捷实践干货,OKR,携程技术,大规模敏捷,敏捷沙龙,敏捷社区,携程PMO,Atlassian,Jira,Confluence,Atlassian社区