制定项目计划就像给一个即将出生的婴儿写传记一样困难。如果可以在项目结束后再制定计划，那就会容易得多，并且可以百分之百准确。

在制定软件项目计划时，应该摒弃一切浮夸的风格。只有了解项目的规模、难度和时间限制，才能制定合理的项目计划。了解项目规模、难度和时间限制是指要了解“知彼”。了解可用资源的数量，比如可调用的程序员有多少？他们的水平如何？软硬件设施如何？这是指要了解“知已”。

1 充分了解对手和自己

首先要了解项目的规模、难度和时间限制，才能确定需要投入多少人力和物力来完成项目。这个问题需要在可行性分析阶段考虑。但不幸的是，人们往往很难在陷入项目无法自拔之前准确估计项目的规模和难度。这时候经验起到了至关重要的作用。

项目的时间限制有两类。一类是在合同中明确规定了项目应该完成的日期，如果延期了，开发方就需要承担相应的赔偿责任。另一类是开发自己的软件产品，虽然只确定了大致的发行日期并允许有延误，但如果拖延太久就会失去商机并造成损失。

项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”。

（1）人是最宝贵的资源。项目计划的制定者需要确定开发人员的名单，并根据他们的专长进行分工。

（2）可复用的软构件是次宝贵的资源。复用软构件可以提高软件的质量和生产效率。软构件并非一定要自己开发，也可以向专业的软件供应商购买。

（3）软硬件环境虽然不是最重要的资源，但却是必不可少的资源。原则上，软硬件环境只需要符合项目的开发要求即可。有些项目可能需要特殊的设备，因此需要提前做好准备，以免在需要时找不到而影响进程。

2 进度安排

一位程序员正在忙着编写程序，经理问他还需要多久才能完成。

“明天就可以完成。”程序员立即回答。

“我觉得这不太现实，实话告诉我，还需要多少时间？”经理说。

“我还想加入一些新的功能，可能需要两个星期。”程序员想了一会儿说。

“即使这样也期望过高了，只要你编完程序时告诉我一声，我也就满足了。”经理说。

几年后，经理要退休了。在他去参加退休午餐会时，发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]

程序员也期望每天早晨能在7：00准时起床，可老是一觉醒来就到中午了。项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：

（1）上级领导主观臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。

（2）客户的需求发生了变化，但没有对进度表作出相应的修改。

（3）低估了项目的规模与难度，导致投入的人力和物力不足。

（4）并未预见到存在难以克服的技术障碍。

（5）并未预见到开发人员会发生问题，如生病，辞职等等。

（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。

写进度表不能像小学生写决心书那样充满幻想，这是很重要的。以下是一些建议：

（1）最好由项目负责人制定进度表，因为他最了解项目和开发人员。进度表要经过开发小组的讨论，并得到大部分人的支持后才能实施，避免出现一厢情愿的情况。

（2）进度安排并不一定要按照逻辑顺序。应尽可能先做技术难度高的事情，再做难度低的事情，也就是辛苦在前，轻松在后。

小时候我对一位老先生吃饭很感兴趣：他总是先把一大盒的米饭吃光了，然后再幸福地品尝一小盒菜。父母告诉我这是中国的传统美德，叫“先苦后甜”。从此我铭记在心，按此道理去学习和工作。可如今在饭店里，人们总是先把菜吃完了，最后才吃点米饭。天哪，生活真是太复杂了，我究竟该“先吃饭” 还是“先吃菜”？

（3）开发一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。里程碑就象心灵的灯塔，使忙碌的人群不混乱，不迷失方向。

（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少，所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”[Cusumano 1996].对许多项目经理而言，容忍进度表中存在缓冲时间，不啻为观念上的一个飞跃。

（5）如果发现项目应交付的期限非常不合理，就要跟领导或客户据理力争，请求放宽期限、调整进度。当客户的需求发生变化时，就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦，不修改才会产生真正的麻烦。很多人认为戒烟很困难，但马克·吐温曾说：“戒烟很容易，我一年就戒几十次。”

需要推荐靠谱PMP/软考/NPDP/CSPM机构的同学可以关注我后台回复【推荐机构】

备考资料分享如下：