已经带着带着大家学习了裁剪的含义、目的和价值，同时也理解了裁剪的原则、裁剪的对象和裁剪容易忽视的点，接下来我们来一起学习下裁剪的过程，把这一课补齐。

马丁接着说，在开课前先再给大家提个新鲜的观点，对于裁剪的替代方案，“神奇吧，裁剪还有替代方案”。也有说法是对于裁剪现有的框架，也可以使用业界未经修改的框架和方法论来代替裁剪，这样可以摸索着应用，可能有奇效。

业界的框架和方法论基本都会包括组织、过程、方法、工件和工具等方面。不过这些方法都是放之四海而皆准的通用做法，它们的指导说明都会指出：不应只是严格遵守一套工作流程或标准规范，而是要经过一个裁剪的过程以便根据项目的特定类型、规模和复杂性确定哪些要素最有用。对于一些经验不足的同学试图完完全全地应用该方法论，而不考虑项目规模、复杂性、持续时间或组织环境等因素，就会出现上面章节提到的各种“误解”。

为了避免这些误解，我们一起来梳理下裁剪的过程。PMBOK（第七版）中有提到裁剪过程的一张图，我们引用共同学习一下：

图5-12 裁剪的过程（插图来自PMBOK第七版）

（一）裁剪前的准备

我们先从进行裁剪时需要了解项目背景、目的和运行环境。项目的运行环境非常复杂，需要平衡下列潜在的互相矛盾的要求，包括但不限于：

（1）尽快交付。

（2）最小化项目成本。

（3）优化所交付的价值。

（4）创建高质量的可交付物和成果。

（5）遵守监管标准。

（6）满足不同干系人的期望。

（7）适应变化。

需要理解、评估和平衡这些因素，以便为项目创造切实可行的运行环境。当然有些情况也会限制项目团队的裁剪程度，如组织政策要求使用特定方法或合同强制规定了某种方法时。

（二）选择开发方法：“菜多多”的融合模式

马丁说，我们之前有章节聊过开发方法和生命周期绩效域。大家一起再回忆下，我们四种生命周期及开发方法。截止项目结束，既然大家都已经认识到，无论哪种项目生命周期都不是解决一切问题的终极方案，所有的痛点和问题存在即合理。我们要根据不同的团队、不同的场景，来选择合适的生命周期的方法。

建议每个组织一定要通过总结和提炼，梳理出适合自己组织的开发方法特征的合适性筛选器，我们来看看表5-6的模式，给大家一点启发。

表5-6 开发方法

从契合度来说，适应型和混合型比较适合于应用类产品（例如，App）的交付时，能发挥较好的价值。对基于预测型、适应型和混合型的剖析研究，理解应用这四种模式的三条关键原则：

（1）预测型、迭代型、增量型和敏捷型不是非此即彼的，而是可以相互融合的。

（2）融合既可以整体、也可以部分，那融合的程度、规模，从哪些层面进行融合，则取决于质量与成本的平衡，以及团队目标和客户价值始终保持一致。

（3）如何能统筹好融合的工作，则要从全局的视角进行规划，保持价值交付的连续性，不需要明确的界限划分。

由此可见，我们能顺利的实施融合模式，还是需要一些前提的，组织及文化的变化、交付周期的配合等，实施融合的主要前提：

（1）自上而下营造乐观开放、积极主动的文化氛围，敏捷思想的引入和多种项目生命周期模式的确立。

（2）相应的需求、架构、开发、测试、运维和安全等职能团队可以根据交付周期来相互配合，并保证全力支持。

（3）支撑多种项目生命周期模式的管理框架、交付模式，以及CI/CD（持续集成/部署到持续交付）能做到全自动化，全周期过程可视化、可量化等，相应的组织能力需要先具备。

如若满足以上，则多种项目生命周期的融合应用才可能真正达成。否则局部的融合应用，仍会受到目标范围、需求变更、部署配置、产品版本管理等相关因素影响造成效果不佳、阻断或者失败的风险。

望着大家恍然大悟的表情，咨询顾问嘴角微微一笑：“说到这里，我们“菜多多”要探究的模式是，实际上是要先通过大家熟悉的模式作为初始开发方法，再逐渐融入新的思想，尽可能规避各个项目生命周期已知的痛点，逐渐演化为敏捷开发方法。即基于预测型（瀑布模式）框架下，灵活运用“迭代+增量”，形成适合团队自己的融合型的模式。“菜多多”的最终开发方法，如图5-13所示。

图5-13 “菜多多”的最终开发方法（插图来自禅道）

（三）对组织“动手”

在回顾下我们之前裁剪的原则，有提到对组织的裁剪需要考虑的方面。那我们从“正解”的角度，由马丁老师带着我们来学习下对组织进行裁剪。

每个组织都有建立一套自己的项目管理的方法论，并以此形成项目流程制度或项目管理体系，这些都是组织较好的实践，经历过不同的项目反复磨炼和验证的结果。同时也加入了组织所在的环境一些政策规定或法律法规的要求，以及还包含组织内部对于合规审计、项目治理、数据标准等方面的要求。所以，组织对于这些特定的活动或内容进行裁剪时，也会建立相应的约束并形成规定，需要经过审批才行。

有必要的还会增加监督环节，确保落实到大家的实际执行中。例如，安全性方面的要求，数据标准方面的规定，对于“菜多多”来说，都是非常关键的。安全性方面有些是涉及客户的隐私，To C的产品，这点是非常重要的，即有法律的规定，也有客户的要求，所以裁剪时一定要注意确保安全性方面，关注客户隐私保护设计的环节。

为了确保裁剪的审批和监督的落实，一般组织会将这些职责归于组织设立的组织管理机构中。例如，项目管理办公室（PMO）或价值交付办公室（VDO），来对经过裁剪的开发方法或者交付模式进行审批和审查。不过VDO多承担着引导、促进的角色，而非监督。更侧重为项目团队提供教练式的辅导，以培养项目内部相关的技能和能力，并辅导张大牛、大鹏和陈恭更有效地承担这个角色。

我们需要了解这些也是对于裁剪前准备的复习。并确保大家考虑周全，因为对于组织的裁剪，不是在于管理体系上，也有体系对应的度量指标。组织会通过指标来验证对于体系的落地效果，为了确保我们准确落地管理体系，进行适应性的裁剪，既保证了符合项目个性要求，又确保了符合组织的合规要求。所以这些相对应的度量活动是需要在裁剪时考虑项目的现实情况，是否能满足度量指标的采集要求和频率。避免因为迁就度量指标，造成项目进度调整的情况，得不偿失。例如，“菜多多”的初始开发方法和最终开发方法，可以是两个形态。

这也是对于组织方法的裁剪可以包括取消、重新配置和增加，以便于该方法更适合组织。PMBOK（第7版）中对于这块儿也讲述的非常清晰，如图5-14所示。

图5-14 组织方法的裁剪（插图来自PMBOK第七版）

（四）对项目“动手”

接下来我们继续来谈下项目的裁剪，虽然之前章节也有提到，在这里我们从项目本身的视角说下项目相关的裁剪。例如，项目的交付物（含开发的产品）、项目团队和项目文化氛围等，以及项目过程的持续改进。

这些内容的裁剪，需要考虑相应的因素，我们来一一说明。

1.交付物（含产品）

(1)​ 我们从交付物的视角来探一探，有哪些在裁剪时需要考虑的因素，那么关于交付物的属性（PMBOK第七版中），也非常明确的列了相关内容，包括不限于：{没说完？}

(2)​ 合规性及关键性：交付物本身具有规范和标准，在过程中会进行相应的质量检查活动（即质量保证QA），所以对于产生交付物的活动和交付数量，以及规范标准的遵循程度是需要根据项目实际情况进行裁剪的。

(3)​ 交付物的类型：从交付物是否有形或无形的角度来看，有些交付物是可见的，有些交付物可能属于无形的。我们从“菜多多”的角度来说，有形的如商业画布、用户画像、项目策划方案等，无形的如大数据算法、隐私保护规则、黑名单机制等。有形的交付物便于质量控制、验收等，无形的交付物需要通过一些方法或手段来验证结果才能了解。

(4)​ 技术：项目中所使用的技术，也是需要考虑成熟度、是否有足够的能力或人员来应用。有些新的技术虽然看似站在解决已知技术的痛点之上，但也会产生新的问题，所以在不具有可以“驾驭”新技术的技术人员时，还是要适度地引入新技术或者新框架。

(5)​ 项目周期：这个大家都不陌生，不过涉及项目周期，一般都是固定的，都是期望在相应的时间内完成项目最终交付。项目周期不好裁剪，但对于项目内的一些阶段、迭代周期、发布计划等是可以进行裁剪的。

(6)​ 需求稳定性：对于需求的清晰或稳定，也是会影响裁剪的一个因素。对于在初期需求比较清晰的或者很明确的，可以考虑需求变更的一些适量管控，这样后续开发和版本管理的压力比较小，可以考虑裁剪预测型。如果需求模糊或无法明确的，则可以考虑裁剪为一些适应型，进行确保适应需求的不断变化。

(7)​ 安全性要求：涉及交付物的保密性或机密信息的管控要求，也需要在交付物裁剪时考虑到。

(8)​ 交付模式：对于交付物的一些交付模式，明确验收条件的，则裁剪时考虑按照标准来进行。如果需要通过客户的反馈作为交付物（含产品）的成果验证，则裁剪时可以考虑通过增量、迭代等模式，在过程中来通过提供客户部分可用的交付成果，再通过客户反馈来完善和后续优化，这样最终的交付结果也是会被认可的。涉及交付物的交付模式则根据交付物的特点来进行。

从“菜多多”在规划绩效域中，对于项目目标、生命周期和开发方法相结合之后分解的WBS。其中，明确列出了本项目的交付物清单，包含对应的负责人、计划交付时间等关键信息。我们整理后，将“菜多多”团队要输出的交付物清单，如表5-7所示。

表5-7 交付物清单

2.项目团队

项目团队的裁剪，我们列举一些注意事项，让大家能更清晰一些：

(1)​ 团队的规模：参与项目团队的人数，重点关注全职/兼职/按需，内部/外包。

(2)​ 办公模式（地理位置）：团队成员办公的模式，或所处的地理位置。主要是集中办公、远程办公，有些需要注意是跨地区、跨时区、多种语言等情况。

(3)​ 外部协作（组织分布）：团队之外的相关干系人的协作模式和分布。尤其是发起人、依赖的外部支持团队、相关营销、质量部门等的分布，要考虑相互协作的成本、效率和效果。

(4)​ 项目团队的经验：我们交付目标所在的行业领域，需要的行业经验、对应市场经验、对应产品的运营经验等，尤其行业所需要的知识技能、通用工具或特定的技术等。

(5)​ 客户参与：这点是对项目交付成果较为重要的，客户的参与程度、及时反馈等，需要我们重点裁剪。

从“菜多多”项目团队的裁剪前后变化，我们可以得知，随着对组织的裁剪、项目文化氛围的裁剪，以及交付物交付节奏的裁剪等一系列裁剪变化，也促使项目团队的结构从最初的智能层级管理，转变为自组织的扁平化团队结构，这样更有利于发挥项目团队的整体能力，更有利于应对创新项目的风险和困难。

“菜多多”的团队结构，如图5-15所示。

图5-15 “菜多多”的团队结构

3.项目文化氛围

项目团队的文化氛围，决定团队成员及相关干系人的直接感受。我们需要考虑一下的因素：

(1)​ 认同。对于所有团队成员的提议，是否可以表现出客观的态度，能否接受、支持和充分的认可。

(2)​ 信任。团队成员之间是否可以高度的相互认可，尤其对于团队成员的能力、品质。是否有能力完成项目分配的任务，是否致力于交付项目目标。

(3)​ 赋能。组织对项目、项目对个人、成员之间等相互的赋能。组织赋能项目自治，项目赋能个人进行自我挑战，不同技能的成员之间相互帮助和学习。这些都是赋能裁剪所要考虑的一些点。

(4)​ 组织文化传导。至于组织价值观的宣导，文化氛围的灌输，以及对于一些指定的组织检查，提醒项目需要关注的政策，需要请求的外部决策等，组织文化裁剪时，需要关注的内容比较广，更多的是组织所在环境的影响。

通过这些属性的评估，可以从组织指定项目相关参与、过程和工具的裁剪指南或决策。图5-16描述了这些取消和增加的项，其中“X”代表取消的活动，虚线框则代表增加的实验过程。

图5-16 取消和增加的项（插图来自PMBOK第七版）

在团队绩效域中，我们有建立过“菜多多”团队的文化氛围，如透明、诚信、尊重、对话、勇气、团队支持、无偏见环境及共同成功。这些不仅要在裁剪中体现出来，更需要团队的自我成长，自动形成成好的团队文化，并需要大家共同建立和持续维护。

“菜多多”团队的文化氛围裁剪，如图5-17所示。

图5-17 “菜多多”团队的文化氛围裁剪

4.项目的持续改进

大家印象中裁剪都是在项目启动时进行的一次性活动，之后则不会再考虑裁剪。在项目逐渐开展的过程中，项目团队的开发方法、交付模式、协作方式，以及交付物/产品的可交付物等方面，都会随着项目所处环境的变化、交付成果的客户反馈、项目目标的调整等进行渐进明细的演进。我们就需要进行过程的裁剪调整，有针对性地增加检查点、阶段准出关口，并通过回顾会议或复盘活动等进行审核和调整。

这样可以更多的让项目团队有主动性、培养自治能力，在参与过程的改进可以促使他们实施持续的交付和质量承诺。让项目团队可以自主找寻解决方案，尝试一些业界良好的实践，实施到改进措施中。经过项目实践和调整后，变为我们自己的知识资产，可以再提炼转化为组织的知识财富。这样既可以激发项目团队的主动裁剪意愿，不会安于现状的思维模式，又能体现组织对于项目团队赋能的信任。

图5-18显示了增加、变更和取消的过程。

图5-18 增加、变更和取消的过程（插图来自PMBOK第七版）

再提一个观点“组织的裁剪方式本身就是可以进行裁剪的”。大多数组织采取我们描述的四个步骤中的部分或者全部，其中使用的要素包括选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进。如图5-19所示。

图5-19 裁剪方式（插图来自PMBOK第七版）

对于“菜多多”项目持续改进，在开发方法和生命周期绩效域专门花了大篇幅讲述，这里我们简单总结下：为了保证更好地适应“菜多多”创新项目，团队选择从预测型到敏捷型进行演进，来保证融合模式的逐渐落地。

“菜多多”项目持续改进的过程，如图5-20所示。

图5-20 “菜多多”项目持续改进的过程

（五）对绩效域“动手”

绩效域是我们“菜多多”项目最重要的关注内容之一,因为项目的独特性需要对每个绩效域的相关活动及交付成果进行裁剪。项目管理的原则也为大家提供了指导，通过合适的裁剪来满足项目背景及所在环境的特定需要。

关于项目管理原则在PMBOK中总结的非常到位，从价值、领导力、驱动力变革、团队氛围、风险应对和质量内嵌等角度对管理进行诠释。以下为项目管理原则：

​ 聚焦价值；

​ 拥抱适应性和韧性；

​ 展现领导力行为；

​ 成为勤勉、尊重和关心他人的管家；

​ 驾驭复杂性；

​ 为实现预期的未来状态而驱动变革；

​ 营造协作的团队环境；

​ 有效干系人参与；

​ 优化风险应对；

​ 识别、评估和响应系统交互；

​ 将质量融入过程和可交付物中；

​ 根据环境进行裁剪。

对于项目管理原则指导项目绩效域的关系，目标就是“为适合项目背景而进行裁剪”。我们来看图5-21。

图5-21 项目管理原则指导项目绩效域的关系（插图来自PMBOK第七版）

总结来说，对于八大绩效域的裁剪不能简单地看理论，需要放到应用场景中描述。所以对于绩效域的裁剪，我们以“误解”的视角，需要在最后将糅合起来的效果，展现给大家。（详见常见的裁剪“误解”）。

（六）评估效果

诊断就是通过项目过程中的一些会议活动或反馈方法，来确定项目的实际运行情况，判断项目运行是否良好。例如，有些团队通过回顾会议或复盘会议等有效方式，持续性地评估现状、发现问题、记录问题和改进问题。有些团队没有设定回顾会议等活动的，就通过项目的过程中记录的问题、识别的风险、相关干系人的反馈，以及质量保证数据等活动中获取信息、迹象，进一步诊断或评估，裁剪调整的必要性或有效性。

表5-8中列出一些常见的情况及裁剪建议的指南，供大家来参考。

表5-8 常见的情况及裁剪建议的指南（插图来自PMBOK第七版）

（七）裁剪总结及持续

我们从裁剪的含义、目的和价值说起，从如何进行裁剪入手，通过裁剪的原则及明确裁剪的对象等方面，让大家充分地了解裁剪，形成裁剪的立体“形象”，打破对于裁剪产生固有印象，能让大家全体地、深入地了解裁剪的本质。

详细介绍了裁剪的过程，包含裁剪前的准备、选择开发方法、对组织进行裁剪、对项目进行裁剪、对绩效域进行裁剪、诊断和总结等。

裁剪的最终目标就是：为实现更快、更好、更高质量的基于价值的交付，明确适合项目背景而进行裁剪。

从“菜多多”团队上面说的实例来看，裁剪并不是一蹴而就，也不是最初开始仅执行一次的活动。需要在项目过程中根据各种可发现和识别问题的活动、数据统计、流程机制等环节，持续地发现不适应的问题，并持续进行裁剪及反馈的过程。