既然程序员一到deadline干活效率超高 ，那为什么不把距离deadline时间定的很短？ 第1页

我以前听过一句名言：“deadline是第一生产力”，这句名言，我不知出自谁之口，但我做为一位四岁的技术型创业公司的最上面的管理者，我可以掷地有声的说，立足于项目开发而言，这是最大的谎言。如果哪个开发团队打算利用“最后期限”来提高效率，做为同行，我会为他哭泣。

以下是我的思考：

首先，“堆代码这件小事情”她不是简单的堆砌工作，她需要一个系列的思考过程，没有堆代码经验的小伙伴可以脑补一下自己搞科研写论文码文章时的体验和思考过程——她至少是分阶段的：适应，准备，熟悉，起步，冲刺。

那，这句“deadline是第一生产力”的名言在什么情况下成立并让人深信不疑呢——我猜了一下，是这样的：deadline其实是“冲刺”的代名词。前面的工作已经准备好了，最后就剩下组织和冲刺阶段，这个时候，所有的条件都具备了，只需要大家集体做冲刺，然后目标就完成了。

所以，就给不懂行的管理者造成“deadline才是生产力”这个误会。

当然，deadline还是很有作用的，很多时候，团队的人都必须在一起，并且只能做执行（按规范），不能自己再去做选择。有经验的领导会知道什么时候做deadline冲击，并且为deadline做好准备。

架构一个程序需要系列的工作，包括前期熟悉业务，查找资料，做测试模型，思索更有序的方法，前面的工作可能看不到，但是实际上为最后的交付工作做准备——你吃第四个包子的时候立刻就饱了，那你不能只吃第四个啊。

有的程序员哥哥有一个不太好的特质，老是完美主义，如果没有项目经理盯着他，他总是在找最优雅的解决方案，整一个磨洋工。到了项目后半期，碰到deadline了，前期想好的方法拿过来用就可以了，前期还没想好的，随便哪个方案用就可以了。这样会让不懂行的项目经理觉得，最后deadline效率才最高，其实没有前面的准备和积累，是不可能出来的。

一个好的项目管理，需要定义好项目周期，什么时候研究，什么时候消灭工作量，什么时候冲刺，都需要规定好阶段有节奏的进行，

有经验的项目经理会把项目划分成一个个小周期，让项目有节奏的迭代，既保证高质量，又不会长时间处于deadline状态，造成压力和效率低下。

而没经验的项目经理只会不停叫，上周那么快，这周怎么这么慢，你们是不是在偷懒。

所谓强调996的项目经理就是这样的人。

最后想说的与主题无关。但很重要，如果“低级的堆砌”只能保证稳定的输出而已，那什么样的模式才会有高质量的结果输出呢？

答：符合思维规律的。一个程序员如果明白 “思考力的差距造成收入的差距”，你的收入也就上去了。