关键字：管理
软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：“拥有多年的丰富的项目管理经验”，但在实际开发中，“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于“无间”(十八层地狱)。
一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管(40-50岁左右)，向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。
记得一个格言曾经说过“人类最愚蠢的行为在于忘记常识”。另外一句较为相仿的格言则是“不知道历史的人必然会重蹈覆辙”。作为项目管理来说亦为同样的道理。很可惜，我们中的大多数管理者口口声声“软件工程”，工作时“用程序代替用户需求”，极具政客的嘴脸。其结果必然如目前媒体“程序员生存状况”所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。
如何改善我们的软件开发管理，一条便捷之道便是“尊重常识，尊重历史经验教训”。在软件项目管理中，有许多的原则和经验可以供我们借鉴。
计划原则
没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务(活动)之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗?需要付出项目失败的代价吗?还有很多项目管理人员常常错误认为“变化比计划快”，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清的“混沌”状态。此外，对于开发人员来说，“目标导向(Objective Oriented)”是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向(通过各个具体任务计划促使项目总计划的达成)。
Brooks原则
向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，“人多力量大”也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。
帕金森原则
帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。
时间分配原则
在项目计划编制过程中，我们常常将资源可用率(人、设备)等设置为100%，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“无知”，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80%就已经时很不错的了，我个人比较倾向于60%左右(黄金分割点)。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划(该计划没有考虑到资源可用率)的4/3-5/3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。
文章来源于领测软件测试网 https://www.ltesting.net/
