痛苦的进度安排

有一位程序员忙着编写程序，经理问他还需要多久才能完成。
“明天就可以完成。 ”程序员立即回答。
“我想这是不切实际的，实话实说，到底还要多少时间？”经理说。
“我还想加进一些新的功能，这需要花两个星期。 ”程序员想了一会儿说。
“即使这样也期望过高了，只要你编完程序时告诉我一声，我也就满足了。 ”经理说。
几年以后，经理要退休了。在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：
可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]
程序员也期望每天早晨能在 7:00 准时起床，可老是一觉醒来就到中午了。项目落后于
进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：
（1）上级领导主管臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进
度表开展工作。
（2）客户的需求发生了变化，但没有对进度表作出相应的修改。
（3）低估了项目的规模与难度，导致投入的人力和物力不足。
（4）并未预见到存在难以克服的技术障碍。
（5）并未预见到开发人员会发生问题，如生病，辞职等等。
（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。
所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议：
（1）制定进度表的人最好就是项目负责人，他最了解项目和开发人员。进度表要经过开发
小组的讨论，在得到大部数人的支持后才能实施。避免出现一厢情愿的局面。
（2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事，后做难度
低的事。也就是辛苦在前，轻松在后。
小时候我对一位老先生吃饭很感兴趣：他总是先把一大盒的米饭吃光了，然后再幸福地
品尝一小盒菜。父母告诉我这是中国的传统美德，叫“先苦后甜” 。从此我铭记在心，按此
道理去学习和工作。可如今在饭店里，人们总是先把菜吃完了，最后才吃点米饭。天哪，生
活真是太复杂了，我究竟该“先吃饭”  还是“先吃菜”？
（3）开发一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任
务可以同步进行。程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。里程碑就象心
灵的灯塔，使忙碌的人群不混乱，不迷失方向。
（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。因为人们对即将要
做的事情知之甚少，所以要留一些时间以防不测。Microsoft 公司的一些开发小组甚至制定
了“50%  缓冲规则”[Cusumano 1996]。对许多项目经理而言，容忍进度表中存在缓冲时间，
不啻为观念上的一个飞跃。
（5）如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争，请求放宽期
限、调整进度。当客户的需求发生变化时，就要对进度表作出相应的修正。不要觉得修改进
度表很困难很麻烦，不修改才会产生真真的麻烦。很多人认为戒烟很困难，但马克·吐温曾
说： “戒烟很容易，我一年就戒几十次。 ”

 

看后感同身受，我就是这样的，N次被经理问还需要多久才能完成，我就说大概一天吧，可是我自己都不知道多长时间可以完成。

好像他们是老大，我们没有谈的，就问我不管你什么时候开始的，我就问什么时候能够完成。很悲哀，后来就有“你看着办？”只有拿半成品给客户看。

这样自己也很被动。。。但也期待着明年新的开始，可以有个新的团队来做事情，一直很努力，天天加班，可是整个公司都dota，我也无能为力。没一个人去学习新的技术可能业务老大不明白程序员，逼的效果可能适得其反。我是这样认为的。继续努力了