裁剪可以从不同的层面过程广度上进行裁剪，也可以从不同的成熟度的深度进行裁剪。也会考虑开发方法、过程、项目生命周期、可交付物及团队成员等。裁剪过程根据《项目管理标准》的指导性项目管理原则、组织价值观和组织文化的驱动。

从组织的每个层级或功能都可以拥有标准过程或资产集，总结来说就是：充分吸收组织的养分，去滋养项目，让项目茁壮成长。

那我们接下来说说，以往大家对裁剪的“误解”，我们给出一些建议：

（一）认为裁剪就是“裁减”

我们在裁剪时，不能光想着减少，也可以进行增加、修改等操作，以及混合、调整等各类变化。那我们用“菜多多”举例来给大家说明下：

（1）增加，针对项目一些交付目标，在标准工作规范中增加特定内容。例如，从“菜多多”的角度看在初期是对预测模型基础上增加了迭代模式，同时也根据政策规定在设计阶段增加客户隐私保护规则等，这些都是需要增加的内容。

（2）修改，为了让项目团队更好的完成项目，则会修改一些内容，例如，由于对敏捷不熟悉，可以先以需求分析代替用户故事一小段时间，在需求拆分中，慢慢引导大家使用“Given…When…Then”去表达。或者再举个团队有色弱或视力不好的成员，则会调整项目文档的颜色或者格式，来适应每个人。

（3）取消，能让项目团队更快、更多的交付成果，取消一些不必要的环节或交付物。例如，“菜多多”团队是集中办公的，大家相互沟通良好，则可以取消会议记录，因为在测试过程中大家都针对缺陷及时沟通，所以可以取消缺陷评审活动之类的。

（4）混合，提高项目团队交付的价值，可以将一些不同模式的实践混合使用。例如，马丁建议的在预测型中，使用项目计划和迭代计划来做计划的分级管理，既有顺序阶段，又可以在阶段中体现每个迭代的具体交付目标。大鹏在需求分析阶段引入商业画布的方法等，都是为了更好地完成价值交付。

（5）调整，往往是针对实际的场景，大家一起商讨标准或度量指标的调整。例如，陈恭提出对于产品设计和开发编码的工作量评估，需要通过转换为人天的方式来保持进度跟踪的一致性。或者木宇通过将需求条目化、用户故事、开发编码、测试案例和缺陷、迭代上线版本对应的方式来统计覆盖率。

（二）裁剪只是针对过程裁剪

其实，裁剪不止于过程和交付物，还可以对项目人员、工具、方法，甚至参与程度等方面的裁剪。

项目团队是由人员组成，谈到人员就不得不谈的两个主要方面：一是人员的技能和能力；二是团队的自治和整合。使用流程方法组织大家进行协作，再通过工具提高项目团队的效率等。我们下面几个方面展开：

（1）人员裁剪：技能和能力。我们需要评估项目领导层和实施团队的技能和能力，然后根据项目交付目标和交付周期，考虑需要哪些技能，以及该技能的熟练程度。例如，在“菜多多”初期，就需要既能做产品需求分析，又能以技术架构的视角划分产品的应用功能架构。

（2）开发方法和生命周期裁剪：我们需要考虑对于我们要交付的目标，产品、服务或结果而言，合适哪种开发方法，哪种生命周期有助于我们能更好地发挥项目优势。例如，“菜多多”在规划阶段，选择先以预测型方法开展项目，在过程中结合增量型方法和迭代型方法过渡确保团队的适应，最终完成了向敏捷型方法的转变。既保证了合理规划，又保证了客户认可的结果。

（3）项目团队裁剪：自治和整合。这次项目发起人张大牛决定最大限度地给予项目团队的自治和决策，减少公司运营部门对于项目的监控。那么从资源整合的角度来说，裁剪更多的体现各方干系人的配合及配合的程度，以及参与的频率、决策的范围等，这些裁剪对于一个新的项目团队是非常重要的。

（4）工具裁剪：团队自己最了解适合项目的工具，所谓“武林高手都有称手的兵器”。只是在选择过程中，需要考虑项目团队的所有人员是否都熟悉、工具的学习门槛，以及工具成本等。有时为了创新或者优先现在的工具体系，决策者也会提出一些期望或要求。例如，“菜多多”团队虽然集中办公，但为了应对疫情，工具裁剪时要考虑远程协作工具作为应急方案，并且在项目过程中就加入使用来提高熟练度。

（5）方法和工件：项目过程中会用到很多实践和方法帮助我们更好地交付，以及这些实践或方法需要的项目环境，这部分裁剪的目的就是让项目团队能在组织的环境下，使用适合的实践和方法来完成更高质量的交付。有些方法，如商业画布、故事点估算、迭代、新的技术架构等，这些都是需要组织环境能提供相应的支撑，项目团队才好去落地的。

（三）只是基于组织要求进行裁剪

裁剪除了考虑项目过程及组成人员，也可以对组织的支持和团队的决策范围进行裁剪，当然这得取得管理层的认可。这次“菜多多”对于菜菜网络有限公司来说也是一个全新的尝试，所以项目发起人张大牛在决策层进行管理程度裁剪时，减少了高层管理介入和监督、调整了绩效考核的标准，给予项目团队更大的自治空间，充分放权、充分信任。

那么张大牛总都进行了哪些操作呢，从上面短短的两句话描述，能看出是组织层面的事情，说白了也就是从公司层面、从管理层角度对于一个项目的管理要求，那我们基于上帝视角来说一说，这些对于我们项目在不确定性、测量、干系人和规划都有什么帮助。

1.基于不确定性和测量的裁剪

每个公司都有自己的一套对于项目成功与否的评价体系，对于个人能力也是。这些评价体系有形成制度的管理规范，有形成机制的考核标准（即KPI）。如果一个创新的项目，仍然按照以往传统项目的管理和考核，到相应的阶段就该交相应的成果、公布相应的考核数据，必然是束手束脚的。

你这边才搞清楚市场的需求，出了一个MVP版本，那边就说需求不完善，存在较大风险。需求框架不完整，达不到准出标准。领导三番五次地请您去办公室“喝茶”，你还能坚定的创新么。得，搞了半天都白瞎。

所以需要先取得管理层的充分理解，同时要对公司的运营要求和考核机制进行对应的裁剪，才能确保有利于“菜多多”项目。

2.基于干系人和规划的裁剪

创新是个风险活，碰到的都是新问题。别想着请教领导和专家，可能大家也没遇到过。所以需要不断试错，马上纠正，再次试错的勇气和容错的氛围。而不是面对后果，不敢越雷池一步，这是没法创新的。这就需要给予“菜多多”项目团队更大的管理空间，能及时决策。同时给予足够的信任，让团队敢于决策。

所以，减少一定的高层管理介入和监督，就是为了让项目团队减少管理顾忌，敢于挑战难题，在项目成本的范畴内进行充分自治。同时，主动汇报、及时报备，不要给领导们制造“惊喜”，才能赢得管理层的充分信任。

至此，大家都明白了组织裁剪的要义了吧。通过张大牛总的一番操作，我们可以看出对于组织裁剪的两个要点：一是组织裁剪对于创新项目非常重要；二是对组织管理的裁剪也是项目成功的关键因素之一。

所以，大家在进行项目裁剪时，不要局限于项目的内部，对于项目所在组织的裁剪也是我们应该尽早进行的重要事项。

3.依靠经验从单一层面进行项目工作和交付的裁剪

对于项目工作的裁剪，我们可以从组织级、项目级、团队级、个人级等，不同的层面进行裁剪，也可以从交付物、项目团队、绩效考核，甚至是项目团队的文化氛围等不同的领域进行裁剪。之所以把这点作为“误解”提出，主要还是因为这块儿确实有些“偏门”，也是经常被大家忽略和遗忘的。但对不同领域的裁剪思路，却是对项目影响较为重要的方面。

马丁说，为了给大家扩宽裁剪的“思路”，我们专门来谈下这个点，让大家不要受到惯性思维的限制，能从多个层面来考虑裁剪的程度，而不仅仅站在流程及交付物的角度。

我们梳理从多个层面和多个领域的视角表达相互作用，表5-9可以作为大家裁剪的指引，便于大家可以找到切入点。

表5-9 裁剪的指引

以上描述是给大家从更深入的角度、从不同视角，来给大家剖析对于裁剪的解读。同时也给大家一些启发，帮忙大家能“真正”地了解裁剪及其深层次的涵义。陈恭见大家已经听得非常入神，又一次感受到了对于知识的震撼。不禁感慨，“裁剪的影响这么大”。