探析软件项目管理九大原则

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

　　六、帕金森原则

　　帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。

　　七、时间分配原则

　　在项目计划编制过程中，我们常常将资源可用率(人、设备)等设置为100%，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“无知”，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80%就已经是很不错的了，我个人比较倾向于60%左右(黄金分割点)。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划(该计划没有考虑到资源可用率)的4/3-5/3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。