1 平衡原则

在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是容易忽视的，也是软件系统的用户、软件开发商、销售代理商不想正视的，那是：需求、资源、工期、质量四个要素之间的平衡关系问题。

需求定义了"做什么"，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。如果需求范围很大，要在较少的资源投入下，很短的工期内，很高的质量要求来完成某个项目，那是不现实的，要么需要增加投资，要么工程延期；如果需求界定清楚了，资源固定了，对系统的质量要求很高，则可能需求延长工期。

对于上述四个要素之间的平衡关系容易犯的一个错误，是鼓吹"多快好省"四个字，"多快好省"，多么理想的境界啊？需求越多越好，工期越短越好，质量越高越好，投入越少越好，这是用户常用的口号。

多：需求越多越好吗？

软件系统实施的基本原则是"全局规划，分步实施，步步见效"，需求可以多，但是需求一定要分优先级，要分清企业内的主要矛盾与次要矛盾，根据PARETO的80-20原则，企业中的80%的问题可以用20%的投资来解决，如果你要大而全，对不起，你那20%的次要问题是需要你花费80%的投资的！而这一点恰恰是很多软件用户所不能忍受的。

快：真能快起来吗？

"快"是用户、软件开发商都希望的。传统企业里强调资金的周转情况，软件企业里强调的是人员的周转情况，开发人员应尽快做完一个项目再做另外一个项目，通过快速的启动项目、结束项目来承担更多的项目，来获利。但是"快"不是主观的拍脑袋定工期可以完成的，工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。软件毕竟需要一行代码一行代码的写出来，他的工作量是客观的，并非?quot;人有多大胆，地有多大产"式的精神鼓动可以短期完成的。

好：什么是好软件？

软件系统的"好"字是难定义、难度量的。"让用户满意"是高目标，你可以做到，但是资金的投入与时间的投入用户能否承担的起呢？在硬件生产企业中，产品的需求是明确的，是有形的，质量目标是明确的，是可以分解到各个作业环节中去的，而软件生产不具备此特征。在硬件生产中，生产能力是基本稳定的，对人员的依赖性较小，质量的要求对进度的影响并不是差别很大，而在软件生产中质量的一点提高或降低可能会对工期、投入产生巨大的影响，尽管用户没有明确定义出质量要求，所以软件生产是质量敏感型的生产。

省：省到什么程度？

"一分钱一分货"，这是中国的俗话，他是符合价值规律的。甲方希望少投入，乙方希望降低自己的生产成本，省到乙方仅能保本的时候，再省，乙方亏损了。

正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功失去了一块坚实的理念基础。

企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。

2 高效原则

在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈， "产品早上市，早挣钱，挣的比花的多，所以一定要多挣" ，基于这样一个理念，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。

基于高效的原则，对项目的管理需要从几个方面来考虑：

    要选择精英成员
    目标要明确，范围要清楚
    沟通要及时、充分
    要在激励成员上下工夫

3 分解原则

"化繁为简，各个击破"是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。

项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成感。

作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。项目完工后总结下来的很致命的一个教训是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。

4 实时控制原则

在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。作者一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用"紧盯"2字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。