学步园

这是我根据我们公司现在的情况总结了几条，大家补充。

1.我们没有明确的任务完成标准，不知道怎么样就叫做完成了一项任务。比如，"需求调研"这项工作，完成标准是什么？在一个没有Process的组织里，可能不同的人回答都不一样。

2.我们对范围不够明确。我们喜欢"先开始吧"，后面的慢慢来。好了，在失去阶段性控制的同时，由于范围在不断扩大，因此2个月的项目变成了4个月才勉强结束。

3.我们总是忽略了一些重要的、但是总是不在开发人员眼球中的事情，如制作安装包、安装调试、书写用户文档，等等；还有返工（Rework），这是被忽略的最严重的！

4.我们还没有学会分解工作。我们往往对着一个很大的名词来估计工作量，如"水电费管理"。要知道越大的可交付成果（Deliverable），不确定性的东西越多、可控性越差、估计越不准确。

5.我们缺乏估计的经验，不知道如何做好工作量估计。

举个例子：

        一个vb程序，估计一下做个安装包要多少时间？有的人会马上告诉你半天，不就打个包嘛（或许还是很悲观的估计呢）；有的人可能说3天、甚至5天。为什么差别这么大？

        如果这样说：一个vb程序，做个安装包，要保证能在2000 Professional、2000 Server、XP、2003下面都可以用。那么那个说半天的要开始伸舌头了。

        如果再这样说：一个vb程序，做个安装包，要能在2000 Professional、2000 Server、XP、2003下面都可以用，并且包含数据库的安装以及系统的数据初始化。这样好像就要花点功夫了。

        再加上版权保护如序列号、用户注册、在线检测用户合法性等功能呢？这样一来你是不是都无法估计时间了？在这个范围不断扩大的过程中，其实问题的复杂度在不断加深，增加了很多不确定性。你还得不停的做好一个安装包测试，然后返工。

        这个例子基本上涵盖了上面说的几点。试想，如果一个项目的各个活动的估计都是按照半天那样的习惯估计的话，这个项目的执行结果会让老板疯掉：你跟我说1个月，现在都3个月了还什么东西没看到。