一个播客项目的得失总结

世贸专员

这个话题很热门的。

小白

引言：
  如果标题改成《被管理总结》的话，我可以滔滔不绝的说上个半天，但是如果是管理项目的话，我实在肚里的货有限，因为到至今做过的最高职位不过是个“班长”而已。
  但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个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个资源单位来解决”。
  如果真的时间很紧的话（毕竟对于软件或者网站来说，特别是商业软件或者商业网站来说，发布时间、抢占市场是第一位的），我认为像详细设计这样的东西的确可以精简一些，但是需求分析，画面迁移图这样的东西还是要求严格一些比较好。其实项目的初期，很多的人都是很闲的，一些东西完全可以先由比较空闲的人来完成，然后大家讨论然后定论一下来完成。这样不仅可以完成这些至关重要的东西，而且对于团队的热身和保持活力很有益处。不会出现“闲的时候闲死，忙的时候忙死”的现象。注意，这些东西都需要文档，而不是口头上的决定。
坏苹果
因为就如同我面所提到的，上个项目经理把这个队伍带散了，整个人心都乱了，所以这个团队根本没有什么团体文化而言。甚至出现了“拿工资混日子”的“bad apple”。但是如果仅仅是“拿工资混日子”那样的话危害好像还不是很大，如果出现这样的“worse apple”的话，整个项目将危如累卵了??