引言：由于企业产品复杂程度的差别，开发工作也有全新开发、局部开发、优化改进等区别，所以不同产品的开发流程不可能是完全一样的，这就需要在企业已经定义的、相对比较完整和标准的产品开发流程的基础上，根据实际情况进行裁剪，形成适用于将要开发产品的流程。
流程裁剪时的常见问题
尽管企业已经制定了结构化的产品开发流程，当项目经理需要在项目中使用这个已定义好的流程体系文件时，面对厚厚的过程文件往往无从下手，心中也充满疑虑：
- 我的项目开发周期只有3个月，团队4、5个人，难道要完全按照公司定义的标准流程执行吗？如果必须执行所有的流程和子流程，生成所有要求的技术和管理文档，那项目的开发周期恐怕不是3个月，而是4、5个月了。那我的项目还能成功吗？
- 我听说过“裁剪”这个词，不过到底是“裁剪”还是“裁减”，我还没有弄明白。即便弄明白了应该是“裁剪”，是Tailoring，而非“裁减”，可具体该怎么操作？我可以随心所欲将自己认为不必要的或者很费时费事的过程裁剪掉吗？
- 如果公司有QA，也有《裁剪指南》，那就好办了，我可以在QA的帮助下使用《裁剪指南》裁剪得到项目的流程，执行就是了。但如果公司没有QA的角色，我就只能自己进行裁剪了。可是，裁减的结果需要有人批准吗？
在这里，我们假定完整的产品开发流程体系是包括了产品开发的方针、原则、流程、指南、模板和表格等一整套的体系。那么，项目经理该如何是好？
流程裁剪指南的目的和作用
建立裁剪指南的目的是用来指导项目对标准的产品开发流程进行裁剪，以形成符合项目特点的项目定义流程（Project Defined Processes，PDP）。
标准的产品开发流程包括了开发一个完整产品/项目的全流程，以及相应的支撑流程。因此，每个特定的项目都可能无法直接使用这个标准的流程。比如，标准的产品开发流程描述了开发一个系统级产品的完整过程，开发流程中包括了软件、硬件、结构、工业设计等开发流程。而某个特定项目仅仅包括纯软件的开发工作，在这种情况下，该项目无法也不应该盲目遵照执行完整的流程。或者，某个特定项目，项目的成功标准是按时交付，而客户要求的项目交付期特别短。为了达成这个目标，项目也不得不对流程进行裁剪以满足客户的需要。裁剪指南就是用来帮助项目组裁剪标准的产品开发流程，以形成项目定义流程（PDP），使用项目定义流程来管理项目，实现项目的目标。
裁剪指南能确保所有项目在定义项目特定的工程活动、需求开发和管理、计划、监控、测量分析、配置管理、质量保证过程时有一个共同基础。裁剪指南主要可在以下方面指导项目：
- 选择适当的产品开发生命周期（PDLC），由于各种生命周期模型在产品工程领域已经有深入的研究，业界对于瀑布模型、迭代模型、增量模型、螺旋模型等的使用场合等也基本达成了共识。因此，项目只需要将项目的实际特点与生命周期模型的应用场合相匹配，选择合适的生命周期类型即可。
- 剪裁标准的产品开发流程，结合所选择的产品开发生命周期，形成的项目定义流程（PDP），使之符合项目的具体特点。
如何进行过程裁剪
项目特点是裁剪依据和出发点。项目特点包括了：①项目规模，如大、中、小等，通常可以使用功能点（Function Point）或KLOC（千行代码）、单板数等单位进行度量；②项目类型，如开发、维护、功能增强等；③项目技术复杂度；④项目周期；⑤产品种类等要素。
裁剪指南应包括以下的内容：
可裁剪的对象。
可裁剪对象确定了裁剪的范围。
可裁剪对象不仅限于过程元素和活动，还包括标准、方法和工具、输出的工作产品及模板等。
裁剪所考虑的要素。对于某个裁剪对象，其范围、频度、正式度等都是裁剪要素。如，对于已有类似开发经验的项目，可以适当减少过程培训、业务培训等活动；对于开发周期较短的项目，可以适当合并一些评审活动，如概要设计和详细设计评审合并进行。
项目在进行裁剪时，由于裁剪指南很难枚举所有的裁剪情况，因此有时还是需要项目经理和QA依据经验进行判断和决定，这时，最根本的依据就是项目的质量要求和对风险的考虑。首先要分析如果一旦裁剪掉某些活动，是否会给项目带来风险，带来多大的风险，以及是否影响项目质量目标的达成。然后综合考虑后才能决定是否裁剪，如何裁剪。
另一方面，企业建立标准的产品开发流程的目的不是为了“为了规范而规范”，而是为了提高过程和技术的重用。因此，如果项目在裁剪时有很大的灵活度，每个项目定义流程（PDP）都很随意或者项目定义流程之间相似的内容很少，那么重用的目的就很难实现了。所以，规范度和灵活度是流程裁剪时需要平衡的另外两个要素。
概括之，流程裁剪的原则是：质量与风险并重，规范与灵活的平衡。
流程裁剪的主要活动包括：
- 根据标准的产品开发流程和裁剪指南，进行流程裁剪，以符合项目特征。项目经理在QA的协助下完成该项工作。
- 记录裁剪的理由，将裁剪的结果整理成项目定义流程文档。
- 由质量部门或EPG（工程过程组）审核裁剪理由和项目定义流程，并批准。审核的检查点主要包括：是否与标准的产品开发流程一致，是否符合本项目的特点，是否记录了充分的裁剪理由。如果审核不通过，则重新进行流程裁剪，或进行修改。
- 基于项目定义流程（PDP）制定项目计划，根据计划监控项目的实施。
“裁剪”而非“裁减”
常常见到企业的流程体系中赫然存在一份《裁减指南》，员工也往往认为裁剪就是大刀阔斧地“减少”完整的流程要求。如果项目时间紧、缺乏资源，就可以这么做。这是一个认识的误区。
所谓“裁剪”就是量体裁衣，根据项目特点量身定做最适合项目的流程，用最经济的流程实现质量目标。对于一个开发周期超过一年的系统级产品的开发，公司定义的四大决策评审点（Decision Check Point，DCP）：概念DCP、计划DCP、可获得性DCP和退出DCP，以及六大技术评审点（TR），TR1至TR6，可能“一个都不能少”。而对于一个快速定制开发的项目而言，一般将概念DCP和计划DCP合并，某些TR也可以合并。
有些项目经理认为裁剪得到了项目定义流程（PDP），然后就可以开始项目的具体工作了。但PDP并非项目计划，更不能替代项目计划。项目经理应基于PDP制定项目的WBS（工作分解结构），以WBS为基础进行工作量、规模和进度估算，制定项目进度表和完整的项目计划。后续工作要以项目计划为基础监控项目的实施。
有些企业在刚刚建立研发流程体系时，由于很难立即制定一份完善的裁剪指南，所以干脆一刀切，不允许裁剪流程。但这样硬性规定的结果是一些维护型、功能增强型的项目要么就是在搞不清状况的情况下照着完整的流程执行，生成很多文档，也延误了开发周期，降低了效率；要么干脆拒绝执行流程，仍然按照过去的工作方式开发。显然，这就违背了建立流程体系的初衷。
另一个极端是企业允许流程裁剪有很大的灵活度，却没有设定一些原则。这样的结果往往是项目随心所欲地裁剪流程，使开发流程的可重用性非常低，而项目的质量和效率也得不到保证。
