软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到："拥有多年的丰富的项目管理经验"，但在实际开发中，"丰富的"管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于"无间"（十八层地狱）。一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。 记得一个格言曾经说过"人类最愚蠢的行为在于忘记常识"。另外一句较为相仿的格言则是"不知道历史的人必然会重蹈覆。作为项目管理来说亦为同样的道理。很可惜，我们中的大多数管理者口口声声"软件工程"，工作时"用程序代替用户需求"，极具政客的嘴脸。其结果必然如目前媒体"程序员生存状况"所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。

    如何改善我们的软件开发管理，一条便捷之道便是"尊重常识，尊重历史经验教训"。在软件项目管理中，有许多的原则和经验可以供我们借鉴。

一、 计划原则

    没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为"变化比计划快"，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清?混沌"状态。此外，对于开发人员来说，"目标导向（Objective Oriented）"是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。

二、 Brooks原则

    向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，"人多力量大"也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性
所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。

三、 验收标准原则

    我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。

四、 默认无效原则

    你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为"沉默意味着同意"。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。

五、 80-20原则

    80-20原则在软件开发和项目管理方面有许多"实例"。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在"最好有"这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。

    80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以"经验"这样的思维定势来做决定。导致的结果如系统论所言：由于"抱怨"的作用和反作用循环，结果是大家都不欢而散。