引言：如果标题改成《被管理总结》的话，我可以滔滔不绝的说上个半天，但是如果是管理项目的话，我实在肚里的货有限，因为到至今做过的最高职位不过是个“班长”而已。
但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个bug接一个bug，完全没法交付；项目经理累的要死，项目却仍然处于失控状态这样的问题和局面？在一个差点失控的项目刚刚结束后，这些问题难道不值得好好的总结和反思吗？虽然我在项目管理方面的能力有限，但是我仍然希望通过这样的总结，让下次的项目尽量避免和改进这次出现的问题。我很高兴，因为我依然走在“好好学习，天天向上”的道路上……
最近在看《快速软件开发》这本项目管理方面的书，本来想按章按条的对照这个项目来写出总结，但是我发现那样的死书读来又有何用呢？那样得出的结论还是你真正实际感受到的项目方面的问题吗？那样的文章还会有人看吗？那样条目的罗列还能给别人和自己以启示吗？所以，最终我放弃了那种想法，而采用这种可能词汇上很“外行”，但是却是来自亲身经历的感悟的方法来写。
正文：
时间真的够吗？
也许是我做日本外包项目时间比较长了，所以当我听到这个《播客》项目需要在一个月内从无到有的出来的时候，我很惊讶，因为这样的“人月”资源可能只相当于我以前在日企“人月”资源的1/5，甚至更少。也许你会说我们不需要那么多的文档，那么严格的流程。所以如果把“需求分析”的时间去掉，把“概要设计”的时间去掉，把"详细设计"的时间去掉，而且我们不需要程序员去测试，我们有专门的测试小组。所以既然去掉那么多的步骤了，所以时间缩短到1/5应该完全是可以的吧。但是你知道吗？项目管理不是简单的“3-1“再"-1"那么简单的加减运算。当你用3-1的时候得到的不是2，而是1，甚至更少，过于冗余的东西的确可以被精简掉，但是很多的东西，当你在初期认为是可以精简的时间而精简掉的时候，后期会花费2-10倍的资源来弥补，那将是得不偿失的，例如“需求分析”。我很遗憾的看到这次项目竟然没有“画面迁移图”。所以导致后来页面的跳转很乱，甚至出现，一些页面虽然做出来了，但是却没有入口的情况。
听团队里一个资历较老的同事说，他们上一个项目经理，从不考虑时间够不够，上面定的完成时间从来都不反驳。上面说一个月完成就是一个月，上面说一个星期完成就一个星期。“那能完成吗？”，我问。“当然完不成了，加班呀！死加！结果加班也完成不了，然后就对上级说程序员效率低。把责任都推给下面的人。” 结果，后来整个团队的人心全散了。而赵就是在这样的情况下接下了摊子，所以我听了这个故事以后很为他捏了把汗。
参考解决方案——
时间估算是个有力的工具。在项目初期可能估算的差浮很大，但是在每个“里程碑”的阶段以后再次作出的时间估算将更准确一些。直至最项目完成时，时间估算将趋于精准。这给予我们的启示是——
1：项目初期，不要把时间期限限定死了，而是应该在一个范围内。“对不起，在没有作出充分评估和分析之前，我不能回答你准确的完成日期，但是初步估算，这个项目需要1个月到3个月之间。最有可能完成的时间是2个月”。这样的回答将是比较好的。很可能上面会被你的“3个月”这个上限吓住，但是，当你的项目真实的是在2个月的时候完成的时候，那么最终你的评价将会更好。讲个小故事：我小时候就是喜欢吃糖果。特喜欢附近小店1块钱10个的那种硬糖，每次买一块钱的。每次去买时，如果是老板娘，她总喜欢，