一个播客项目的得失总结

    但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个bug接一个bug，完全没法交付；项目经理累的要死，项目却仍然处于失控状态这样的问题和局面？在一个差点失控的项目刚刚结束后，这些问题难道不值得好好的总结和反思吗？虽然我在项目管理方面的能力有限，但是我仍然希望通过这样的总结，让下次的项目尽量避免和改进这次出现的问题。我很高兴，因为我依然走在“好好学习，天天向上”的道路上……

    最近在看《快速软件开发》这本项目管理方面的书，本来想按章按条的对照这个项目来写出总结，但是我发现那样的死书读来又有何用呢？那样得出的结论还是你真正实际感受到的项目方面的问题吗？那样的文章还会有人看吗？那样条目的罗列还能给别人和自己以启示吗？所以，最终我放弃了那种想法，而采用这种可能词汇上很“外行”，但是却是来自亲身经历的感悟的方法来写。

    时间真的够吗？

    也许是我做日本外包项目时间比较长了，所以当我听到这个《播客》项目需要在一个月内从无到有的出来的时候，我很惊讶，因为这样的“人月”资源可能只相当于我以前在日企“人月”资源的1/5，甚至更少。也许你会说我们不需要那么多的文档，那么严格的流程。所以如果把“需求分析”的时间去掉，把“概要设计”的时间去掉，把"详细设计"的时间去掉，而且我们不需要程序员去测试，我们有专门的测试小组。所以既然去掉那么多的步骤了，所以时间缩短到1/5应该完全是可以的吧。但是你知道吗？项目管理不是简单的“3-1“再"-1"那么简单的加减运算。当你用3-1的时候得到的不是2，而是1，甚至更少，过于冗余的东西的确可以被精简掉，但是很多的东西，当你在初期认为是可以精简的时间而精简掉的时候，后期会花费2-10倍的资源来弥补，那将是得不偿失的，例如“需求分析”。我很遗憾的看到这次项目竟然没有“画面迁移图”。所以导致后来页面的跳转很乱，甚至出现，一些页面虽然做出来了，但是却没有入口的情况。

    听团队里一个资历较老的同事说，他们上一个项目经理，从不考虑时间够不够，上面定的完成时间从来都不反驳。上面说一个月完成就是一个月，上面说一个星期完成就一个星期。“那能完成吗？”，我问。“当然完不成了，加班呀！死加！结果加班也完成不了，然后就对上级说程序员效率低。把责任都推给下面的人。” 结果，后来整个团队的人心全散了。而赵就是在这样的情况下接下了摊子，所以我听了这个故事以后很为他捏了把汗。

    参考解决方案

    时间估算是个有力的工具。在项目初期可能估算的差浮很大，但是在每个“里程碑”的阶段以后再次作出的时间估算将更准确一些。直至最项目完成时，时间估算将趋于精准。这给予我们的启示是——

    1：项目初期，不要把时间期限限定死了，而是应该在一个范围内。“对不起，在没有作出充分评估和分析之前，我不能回答你准确的完成日期，但是初步估算，这个项目需要1个月到3个月之间。最有可能完成的时间是2个月”。这样的回答将是比较好的。很可能上面会被你的“3个月”这个上限吓住，但是，当你的项目真实的是在2个月的时候完成的时候，那么最终你的评价将会更好。讲个小故事：我小时候就是喜欢吃糖果。特喜欢附近小店1块钱10个的那种硬糖，每次买一块钱的。每次去买时，如果是老板娘，她总喜欢，抓一小把先放到我手里（大约5个），然后再一个一个地加到10个。而老板的话，他却喜欢抓一大把放在我手里（大约15个），然后再一个一个地拿走，直到我手里还剩10个。不知道何故，我超喜欢老板娘，却恨死了老板。

    2：每次进行到一个“里程碑”的工作之后都要重新进行时间估算，以提供更为准确的时间范围。同时也便于总结为什么上一个阶段花费了那么多的时间。

    到底做成什么样子？

    作出时间估算的最基本的依据就是需求分析。到底要做成什么样子？到底在什么环境下使用？到底需要哪些功能？到底有多少页面？各个页面之间到底是如何跳转的，这个页面的是从什么地方进来的，又可以从什么地方出去？……有多少项目是在真正搞清楚这些需求后才开始的？还是更多的是——“差不多就是做成那个样子”，“先做着，一些功能反正以后可以再加”，“策划部说，现在能不能把这个功能也加进去？”……需求不明确就开始动工的危害我就不多说了，但是有个数据我还是要列举一下——“初期花费1个资源单位能够解决的雏形问题，如果发展到后期将需要2-10个资源单位来解决”。

原文转自：http://www.ltesting.net