么可能会有一个“包打天下”的流程呢?现在很多企业的业务模式既有OBM(自主品牌制造商)、又有ODM(原始设计制造商)、OEM(原始设备制造商)业务;产品开发类型既有全新产品开发、衍生/改进产品、Costdown产品、特定规格改变类型等等;还有多种多样的产品线。一个流程当然不能适应各种不同情况。因此，为了适应不同的开发型态，有些企业又走上了另一个极端，那就是针对不同的开发型态建立不同的流程。殊不知，这样做建立、维护、优化这些流程的成本有多高?更为重要的是，公司员工可能会面临今天执行这个流程明天执行那个流程的窘境，开发效率必然下降。
面对多样的开发型态，最好的办法就是在公司层面建立标准的产品开发流程和针对不同开发型态建立基于标准流程的流程裁剪规范。这样的话，开发项目组选择流程就有了统一的原则与标准，可以做到在“规范与效率”、“质量与风险”之间的有效平衡。
特别是当项目Deadline成为一个强约束时，流程裁剪是一个非常好的有助于时间目标达成的途径。流程裁剪规范为项目组提供了裁剪的原则和标准，避免了随意的删减。比如，某一特定项目为了赶进度，决定降低测试覆盖度以节约时间。但是减少测试工作将导致产品质量无法得到保证，因此项目组应该增加更多的子评审活动以便发现更多的潜在问题，避免因为减少了测试而带来产品质量的下降。
这才是裁剪，而非裁减!
l 7、流程的异步并行
当遇到项目时间压力很大时，可以将以前串行的活动改为异步并行，将有效缩短产品/项目的开发周期。
很多情况下，研发团队内部会有明确的分工，有人负责硬件，有人负责软件、有人负责采购、有人负责市场。这些不同专业领域内的人并行工作，将大大缩短产品交付/上市的周期。
那么在技术领域内来看，该如何异步并行呢?这首先要求项目团队能够将产品/项目进行恰当的分解。如上图所示，如果能够将产品分解为三个部分组件A、组件B、组件C，那么就可以首先完成组件A的需求分析，然后同时开始组件B的需求分析和组件A的设计工作，依次类推。
在应用这种方法进行异步并行时，应注意以下几点：
首先，产品应能够分解为更小的组件/子系统，并且这些组件/子系统必须相对独立，相互之间的影响较小。如果相互关系紧密，可能出现严重的返工事件。比如在对组件C进行需求分析的时候，才发现组件A的需求由于C的影响需要更改，这势必导致组件A的设计和实现工作重新来过。因此为了避免这种“欲速则不达”的情况出现，首先需要考虑的就是组件之间是否相互影响。如果相互影响则需要首先界定它们是如何相互影响的，然后明确之间的接口关系，然后再实施异步并行。
另外，异步并行需要投入更多的人力资源，以便同时开展工作。
l 8、先分析再设计后实现的开发方式——终极手段
产品开发是具有本质规律的，这些规律不应该被打破。无数的经验教训和数据告诉我们，产品开发在总体上应该遵循“先分析、再设计、后开发”的过程。这是一种“谋定而后动”的开发模式，笔者称之为产品开发中这“纸上谈兵”。
右图说明这一点。H公司4年来产品开发周期显著下降。为什么会又这样的效果呢?从图上可以看出，最大的差别就在于概念阶段与计划阶段所占整个开发周期的比例显著增加。在99年，H公司的产品开发项目普遍很快就进入开发阶段[3]，这样做大家都能够很快看到了成型的产品，似乎就可以早一点“开庆功宴”。但是可以预料的是后期阶段问题百出，只能依赖于不断地返工来查缺补漏，时间当然也被一点一点地耗尽。正所谓“没有时间一次把事情做正确，却有时间不断的返工啊!”。
显然，I公司采取了与H公司99年完全不同的策略，它的概念阶段——明确产品包需求——和计划阶段——明确产品的总体设计方案和产品设计规格——几乎占了整个开发周期的40-60%，这反而是一种“磨刀不误砍柴功”的做法。
上面这八个手段只是基于项目管理的三个平衡三角形所演化出来的应对Deadline的部分方法。但是从这些方法可以看出，当项目面临时间压力时，可以采取的措施是多种多样的，而不仅仅是我们凭直觉采用的加人和加班的方法那么简单。
三个平衡三角形不仅点明了项目管理的精髓，也同时为我们提供了很好的解决问题的思考出发点，帮助我们在面对项目困境时能够全面地思考和权衡，以找到最好的问题解决之道。