项目管理读书笔记--Manage it --识别和避免schedule games（8）

我们做项目，做模块，做一个功能，甚至是写一个方法，什么叫做完成？什么叫做完成50%？什么叫做完成10%？
定义很模糊，基本上基于每个程序员自己的判断。
通常，当我们写完所有的代码，编译通过，运行通过，我们认为：完成了；实际上，可能还有40%以上的工作要干。
我们做完了一个项目90%的feature，我们说：我们完成了90%的工作；实际上，可能才只完成了50%。为什么？未知最可怕，程序员高估自己的进度是恒古不变的话题。
很久以前在另外一个单位，有一次跟我的领导喝酒吃饭，他说：“通常你们给我的estimate，我要加上20%的buffer，再乘以2。为什么呢？那20%是给你们完成代码的时间，乘以2是测试并修改bug的时间。这样才是真正的项目的评估出来的时间”。也许是我们水平太烂，就这样我们还有很多次延迟交付，可见，高估的有多厉害。
我看到一个功能，跟以前做过的很相似，我说：“一天之内肯定能搞定”。两天以后，我满头大汗，跟经理说：“没想到这破玩意儿这么费劲，谁知道还要改注册表啊，以前做的这个跟这个根本完全是两个难度级别的嘛”。每个人都认为了解一切，结果确是一无所知。
尝试解决这些问题，尝试如下方法：
1，如果你是项目经理，尝试帮助项目组成员尽量分解工作，让工作单元尽量的小，这样更容易评估，评估的准确性越高。你可能需要坐下来和程序员交流，“这个东西需要多久，这周有哪些这样的工作要做？等等”。
2，使项目组成员的状态可见，促使项目成员及时报告自己的状态，帮助他们解决问题，而不是追问进度。评估任何他们提交的东西，并给予及时的反馈和意见。
3，指导项目组成员跟踪他们的estimate，一起观察他们最初的评估的准确程度，并改正存在的问题使下一次评估更准确。

帮助项目组成员成长，会让项目经理的工作更轻松，如果developer，tester等项目组成员能准确的评估工作量，那项目经理的工作就变成了加减乘除了，easy work easy life。你可能觉得最为项目经理你很忙，但是你有没有回想当你还是个developer的时候，你对你的项目经理有什么感觉呢？我觉得，项目经理对项目组成员的反馈非常重要，一个项目经理应该经常和自己的组员在一起，及时听取他们的反馈并提供意见，指导他们独立思考，指导他们学习业务领域知识，而不是一个问题抛出来从此不见踪影，回来问：“写完了吧？”，程序员吐血而亡。与高层频繁的会议也许对个人提升有帮助，对项目的成功带来的好处微乎其微。在我看来，45%给客户，45%给项目组，10%给公司，已经足够了。