本文计划用5-7篇文章来描述一个软件项目的管理在一个管理咨询公司中的处境，以及自己的一点点见解。

作为第一篇文章，将讲述常见的几个导致失败的情况。

软件项目，不外乎为开发、测试和实施。

在软件项目的开发中，特别是当我们提及项目计划的时候，每一个项目经理都会感觉到有一种痛苦和悲凉的感觉。但是软件项目的开发的现实是：一个没有项目计划的软件开发过程将是一场灾难。在很多次与项目经理们的沟通后发现，项目计划的制定是何等的艰难，软件项目的需求变更对项目计划带来的不可预估的可怕影响。

在很多的项目管理的书中都提及WBS制法，可是在实际的情况中，“计划没有变化快”“用程序来代替用户需求分析”，大量的这种情况式的程序开发人员变成了一个真正的民工，以开发人员的时间牺牲为代价来换取项目的结束成为常事。

目标导向计划

计划的制定，不应该是越详细越好。我认为应该是详细到开发人员能够理解，并且能够指导项目的开发为宜。

一个计划能够告诉你什么时候应该做什么。不少项目经理只是告诉组员需求是什么就扬长而去，没有给出相关认为之间的说明，这种计划过于粗糙和不切实际，好听的说法是给程序人员充分的自由度，其实就是一种失职。导致的后果有一半左右的时间都花在了返工上面，因为计划中并没有提及某一项关键性的基础性的任务，这个项目就可能宣告失败。

一个项目的计划并不会花费比占项目时间一半的赶工时间还长，定制一个计划又何妨呢？

“计划不如变化快”——很多管理人员常常错误的认为这样就不必制定详细计划，反正总会变的，何必花时间呢，但实际的情况是，如果因为惧怕变化而不定制计划的话，整个项目都在剪不断理还乱的混沌状态。

项目任务分配

在制定计划的时候，项目管理人员下意识的想让任务平均分配，可实际上项目开发的过程中是存在2-8原则的，少部分开发人员担当大部分的任务。在做计划的时候，一个聪明的管理人员将会考虑互补性和人员能力大小和多样性。但实际上，项目管理人员认为依据自身多年的经验来分配更好。这是一个非常严重的错误，没有考虑开发人员自身的能力特点，依照自身的经验性的情况猜测来做分配的任务可能只适用于这个管理人员自己去做开发任务。导致的结果如系统论所言：由于抱怨的作用和反作用循环，结果是大家都不欢而散。

程序开发人员的效率不是每天都100%

计划下意识的按照开发人员效率每天100%来设定，但是在实际中，开发人员是在解决问题而不是流水线的工作，不属于计件式的作业状态，另外他们还需要吃饭、休息、开会以及对之前的项目做回顾和维护等等，绝对不可能在项目开发工作上把每天的所有时间都头在上面，这还没有考虑人员的工作效率每天都保持为恒定的水平上。

项目计划中每天8小时的开发任务，其实是对开发工作的不了解导致的，管理人员不了解这相关的规律导致开发人员被迫拼命加班，导致的疲劳式的工作效率降低，再加班的恶性循环，工作成本不断攀升，团队的组织和凝聚力逐渐下降。一个全职的开发人员每天能有60%-70%的时间用在开发上已属于很高的比率了。

项目是变化的

项目管理中，唯一不变的就是变化。我们不是先知可以预测到所有的未来。但是一定要做好余量来作为风险储备，虽然这个储备并不能解决所有的问题，但是一定会比拆东墙补西墙式的修补和改变来的实用些。