做项目的随机应变---裁剪

做过项目的人都知道，项目分大项目和小项目，除去想靠做大项目出业绩的，大家本能上都喜欢做小项目，这是因为小项目做起来轻松，而这轻松背后，其实就是因为小项目相比较大项目有更多的裁剪，工作包上、流程上都会轻量很多。

今天我们来聊聊裁剪。

裁剪的本质呢，就是将现有的组织过程资产调整到更适合一个独特项目，但注意裁剪概念并不是简单地减少，而是一个恰当组合，是一个对诸如“又要马儿跑，还要马儿不吃草”之类矛盾的平衡。

此外，由于软件刚刚进入汽车行业，敏捷会越来越受重视，裁剪必要性和灵活性（也就是裁剪方法的裁剪）的提高也会是一个大的趋势，行业的发展需要我们更加随机应变。最新的PMBOK第7版还专门设置了独立的一章讲裁剪，也是一个例证。

明白了它的重要性，再来看看咋做呢。

做项目裁剪的第一步，是先确定选择何种开发方法，是传统的预测型（即瀑布型），还是要适应型（迭代型、增量型、敏捷型），或者混合型。

大家都知道的简单逻辑是，稳定的、成熟的产品或环境下，预先充分计划的、按部就班的、文档驱动的传统预测型模式更合适；对于多变的项目，就需要不断适应变化，随时改变策略了。

当然，实际工作中，由于公司项目、产品模式相对有稳定性，整个开发体系的变化并非易事，并非是哪个项目团队可以自由选择的。

总的来说呢，从当下情况来看，汽车行业大大小小的涉及到软件的公司普遍都在自上而下地推行更敏捷的模式，以应对外界环境的变化，这倒也是个有趣的循环，因为要敏捷，所以要裁剪，而裁剪呢，又要裁到敏捷上。

不过呢，由于传统汽车业整体对于软件的经验尚显不足，比较重的ASPICE或ISO26262也同样被重视了起来。弱化流程去追求“快”和加强流程去追求“对”，目前尚处于融合平衡阶段，这两个看上去有些矛盾的两面，也是汽车软件质量或PMO从业者要考虑的问题。

那么，大的开发方法后，就是针对具体项目过程的枝枝丫丫进行修剪了。尽管项目要敏捷，裁剪要灵活，但依然需要被有效管理起来，否则必然会乱套，也就是说裁剪必须得有方法和标准，很多时候还需要得到管理者的监督与批准。首先要确保的是，项目层面的裁剪不会对组织的更大战略有不利影响，甚至违背。

按道理，我们裁剪时需要考虑到组织和项目的方方面面，如人员、时间、规模、成本、文化、客户等等，但对于汽车行业里这些多数是以交付产品（物理零件或软件）为目的的公司，产品的特点及其变更范围往往是裁剪的起点和核心点，其他的东西一般处于相对稳定状态，在产品视角识别清晰后，其他方面处理手段的选择也有了判断依据。

前面从理论层面解释了裁剪。那么，企业里目前一般具体是如何落地的呢？

绝大多数项目都是基于现有的量产产品修修改改，极少从0到1，裁剪的主要对象也是这类项目，裁剪的手段多是“复用”已有，即自身不做。

修修改改的范围也就是项目的原始需求，我们的产品经理、项目经理、系统工程师等角色会基于这个改动范围进行评估，改动越小，我们可以裁剪的越多，因为可以复用的越多。

但是到底怎么算是改动大？怎么算是改动小？哪些要复用？哪些要新做？如果完全给项目组做决定，能力强和认真的项目团队做得好一些，经验少和散漫的也基本是乱来了。

标准的建立依然是非常必要的。

基于系统、软件、硬件、测试等的变化点，进行项目等级的评估，然后针对不同的等级对应设置所需的不同的过程、人员参与、工件（模板、文件、输出或项目可交付物等）等。

而对于如何评级，要结合具体的产品和业务特点来定，比如，新需求是否超过多少条、电路设计布置是否变化、BOM清单是否更新、是否有额外的HW或EMC测试、有多少新的软件功能feature点、要做多少次软件集成、要改多少行代码、要更改多少标定参数以及其他特定的产品特点……这里具体数值其实是来源于组织的经验数字了。

对应于评级，就是设定做不做、做什么、什么时候做、怎么做和做到什么程度，这个也是难以有恒定的准则，有些东西是无论如何都必须要有的，比如需求分析，有些东西又是根据情况可能没有的，比如架构设计，有的东西可能有但程度不一，比如质量阀的数量……诸如此类，不一而足。

实际上，我们很难脱离业务来谈具体而精准的方法，以上仅能从逻辑上辅助理解如何做这件事情。