项目管理--防范式与疏导式项目管理

在面临同样一个项目问题的时候，会出现两种甚至几种不同的看法。比如以前做项目的时候，经常出现的问题是产品开发出来后，到客户项目上还需要做大量的二次开发才能满足客户的需求。针对此类问题，一种是思路是，加大需求调研的粒度，把握好需求，避免出现和客户真实需求的大的偏差。另外一种思路是，在产品研发过程中，尽早发布一个可运行的版本，让客户参与开发之中，培训、试用、反馈，有什么问题在早期就解决掉。

    这两种方法都是可行的。第一种方法是软件研发的一贯思路，严格控制每个阶段的质量，达到控制整个产品质量的目的，按照这个方式来研发软件已经几十年了。这是典型的防范式管理的思路，为了防止以后出现问题，所以，现在就要解决掉出现问题的隐患。听起来很美。

    但是这种方式有两个问题：

• 成本高，总是假想会出现各种各样的问题，这些问题是不同项目收集而来的，如果在某一个项目中都需要防范，显然会做很多看似合理但是实际无用的工作。更重要的是，假想的问题没有出现，到底是防范起到了作用，还是本身项目就不会出现这个问题？这很难说清楚，那你下个项目还这么做么。
• 失败率高，最理想化的情况下，如果每个部分如需求、设计、开发、测试都做好，那么项目应该是成功的。事实上不是如此，防范式管理的核心依据是每个阶段都做的足够好。实际上极少项目能在一个阶段把本阶段要做的工作做得很完美，比如在需求分析阶段，无法一次性把需求搞定，需求分析贯穿整个项目始终；开发阶段亦是如此，开发的Bug经常会存在于整个产品生命周期。在高复杂度下（软件），高协同下工作（人员），预测并防范会出现哪些问题变得极为吃力不讨好，特别是需求，比如预测用户可能喜欢什么，你试着为用户做了10个功能，其中只有2个他们经常用，另外，他需要另外加5个功能。所以，每个阶段没做好，我认为是“非不为也，实不能也”。

    当然也有采用瀑布模型(典型的防范式模型)做得很成功的，而这些做得成功的项目，更多是类似“制造业”，整个项目没有业务、技术、资源等风险。其实，软件项目管理的最初的理论来自传统行业，比如建筑业、制造业。这些管理理论虽然总体上没有什么问题，但是真的符合软件的发展规律么？未必。

• 传统行业的产品是需要材料成本的，软件只要人力成本。
• 传统行业在产品开始生产后是很难更改的，软件可以很方便的更改（重构）。

    传统行业因为材料成本高，建好后也无法更改，也就是说“变更成本”异常高昂，所以，在前期做大量的防范性的工作是非常必要的，防范的成本比变更的成本低。而软件变更简单，成本低，如果防范成本高于变更成本，将变得不划算。

    如何降低软件产品的变更成本？在后一阶段修复缺陷的成本比在前一阶段修复的成本要高，这是经常讲的一个理论，但是对于这个理论，我认为应该修正为：在项目后面时间修复缺陷的成本比前面时间修复的成本要高，这样更加准确。一个10个月的项目，在第1个月就发现缺陷并修复，显然比在第10个月发现并修复，成本要低的多，而不要关心在第1个月或者第10个月到底是在做需求、设计、编码、还是测试，不是么？

    所以需要减少防范性的措施，把产品成熟阶段目标梳理清楚，引导整个产品向着如何尽快暴露缺陷的方向前进，这个思路就是疏导式的项目管理方式。如何实施疏导式的项目管理，我认为有如下措施：

• 确定产品内部版本，如原型、阿尔法、贝塔等版本，确定每个版本的发布时间，确定每个版本的的质量要求，前面版本质量要求低，后面版本质量要求高。
• 以产品的最终状态为目标，减少不必要的中间环节，降低中间环节的要求（注：中间环节指需求、设计、管理、文档、会议等对最终产品没有直接作用的环节）。
• 在产品一个版本期间内，模糊每个阶段的界线，使每个阶段向前、向后延伸。如设计阶段，可以在需求阶段开始、在编码阶段去完善。测试阶段在设计阶段就介入等。集成测试工作穿插在开发之中。原型版本客户就参与试用等。
• 对于在此过程中出现的任何问题，就事论事，迅速响应，缩短解决问题的周期，个别出现的问题解决就可以了；对于已经出现比较普遍的问题，可总结后统一检查和处理。

    疏导式的管理思路，有如下好处

• 降低了无直接产出的工作，降低了防范的工作，成本最低
• 能在每个阶段衡量产品成熟度，有问题能早发现，风险低
• 看着产品“生长”，简单直观，变更容易，检验更容易
• 客户、老板、员工的信心是随着时间推移而增强的