抓一小把先放到我手里（大约5个），然后再一个一个地加到10个。而老板的话，他却喜欢抓一大把放在我手里（大约15个），然后再一个一个地拿走，直到我手里还剩10个。不知道何故，我超喜欢老板娘，却恨死了老板。
2：每次进行到一个“里程碑”的工作之后都要重新进行时间估算，以提供更为准确的时间范围。同时也便于总结为什么上一个阶段花费了那么多的时间。
到底做成什么样子？
作出时间估算的最基本的依据就是需求分析。到底要做成什么样子？到底在什么环境下使用？到底需要哪些功能？到底有多少页面？各个页面之间到底是如何跳转的，这个页面的是从什么地方进来的，又可以从什么地方出去？……有多少项目是在真正搞清楚这些需求后才开始的？还是更多的是——“差不多就是做成那个样子”，“先做着，一些功能反正以后可以再加”，“策划部说，现在能不能把这个功能也加进去？”……需求不明确就开始动工的危害我就不多说了，但是有个数据我还是要列举一下——“初期花费1个资源单位能够解决的雏形问题，如果发展到后期将需要2-10个资源单位来解决”。
参考解决方案——
如果真的时间很紧的话（毕竟对于软件或者网站来说，特别是商业软件或者商业网站来说，发布时间、抢占市场是第一位的），我认为像详细设计这样的东西的确可以精简一些，但是需求分析，画面迁移图这样的东西还是要求严格一些比较好。其实项目的初期，很多的人都是很闲的，一些东西完全可以先由比较空闲的人来完成，然后大家讨论然后定论一下来完成。这样不仅可以完成这些至关重要的东西，而且对于团队的热身和保持活力很有益处。不会出现“闲的时候闲死，忙的时候忙死”的现象。
注意，这些东西都需要文档，而不是口头上的决定。
坏苹果
因为就如同我面所提到的，上个项目经理把这个队伍带散了，整个人心都乱了，所以这个团队根本没有什么团体文化而言。甚至出现了“拿工资混日子”的“bad apple”。但是如果仅仅是“拿工资混日子”那样的话危害好像还不是很大，如果出现这样的“worse apple”的话，整个项目将危如累卵了——
- 对自己的代码极为不负责任，垃圾代码过多，对自己的代码从来不进行测试，以程序跑通为最高准则。
- 从来不考虑代码的运行效率，用最简单的方法完成功能即可。
- 对于bug从来都是抵触，推托责任，甚至对自己的bug拒绝修正。
- 独立独行，不服从上级安排。
- 蛊惑人心，以尽可能的破坏团队文化为乐趣。
- 拒绝与上级配合，甚至与上级争吵。
- 更多危害项目开发的行为……
其实很多的人也并不是很乐意做坏苹果，也许是因为上一个项目经理太让人寒心，也许是上个项目经理把整个团队带散了，也许是项目制度出现了问题，也许……，有太多的也许，但是事实是——我们的团队真的出现了坏苹果。
参考解决方案——
也许对坏苹果最快速和有效的解决方案是——开掉！但是那真的是最好的办法吗？有没有想过是什么土壤滋生了这些“坏苹果”？我就在我们的公司中发现了2个很不好的问题——
1：没有明确的奖励制度。就如同以前文革的时候吃“大锅饭”一样，干好干坏一个样，反正每个月就是那么多的工资。如果每个人真的都那么想的话，那么惰性就出来了。
2：只有不合理的惩罚措施，虽然技术中心还没有这样的措施，但是听说编辑那边，上传的文章如果出现了错别字是要扣钱的。我最反对的就是“扣钱”这样的措施。因为特别容易激起员工的“抵触情绪”。也许你会说，如果上班迟到不扣钱的话，那么大家都迟到要怎么办？其实，扣钱和奖钱是相对的。将本来应该给予的钱抽出一部分（当然下面的员工是不知道的）。然后做的好就在全额发下去，如果有违规