引言：
如果标题改成《被管理总结》的话，我可以滔滔不绝的说上个半天，但是如果是管理项目的话，我实在肚里的货有限，因为到至今做过的最高职位不过是个“班长”而已。
但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个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”的话，整个项目将危如累卵了——
对自己的代码极为不负责任，垃圾代码过多，对自己的代码从来不进行测试，以程序跑通为最高准则。
从来不考虑代码的运行效率，用最简单的方法完成功能即可。
对于bug从来都是抵触，推托责任，甚至对自己的bug拒绝修正。
独立独行，不服从上级安排。
蛊惑人心，以尽可能的破坏团队文化为乐趣。
拒绝与上级配合，甚至与上级争吵。
更多危害项目开发的行为……
其实很多的人也并不是很乐意做坏苹果，也许是因为上一个项目经理太让人寒心，也许是上个项目经理把整个团队带散了，也许是项目制度出现了问题，也许……，有太多的也许，但是事实是——我们的团队真的出现了坏苹果。
参考解决方案——
也许对坏苹果最快速和有效的解决方案是——开掉！但是那真的是最好的办法吗？有没有想过是什么土壤滋生了这些“坏苹果”？我就在我们的公司中发现了2个很不好的问题——
1：没有明确的奖励制度。就如同以前文革的时候吃“大锅饭”一样，干好干坏一个样，反正每个月就是那么多的工资。如果每个人真的都那么想的话，那么惰性就出来了。
2：只有不合理的惩罚措施，虽然技术中心还没有这样的措施，但是听说编辑那边，上传的文章如果出现了错别字是要扣钱的。我最反对的就是“扣钱”这样的措施。因为特别容易激起员工的“抵触情绪”。也许你会说，如果上班迟到不扣钱的话，那么大家都迟到要怎么办？其实，扣钱和奖钱是相对的。将本来应该给予的钱抽出一部分（当然下面的员工是不知道的）。然后做的好就在全额发下去，如果有违规就去掉一部分，然后将余下的发下去。就如同很多企业所谓的“全勤奖金”一样。没有什么深奥的东西，心理策略而已。
所以虽然“开掉”是最有效和快速的方法，但是如果很多滋生坏苹果的土壤不改善的话，再怎么开也没有用，坏苹果还是会一个接一个的冒出来。建立良好的团队文化，合理的公司制度，一个积极向上的团队才是最根本的解决方案。
责任编辑：张瑶
您现在的位置： 