就是扯扯蛋了。
项目管理、软件工程是很专业的，我就一程序员，往高里说叫“软件开发工程师”，通俗说就是“码农”，大道理我不会讲，我就讲讲对身边事的一些想法。
目录
要做什么？
做成了什么？
把测试组砍掉
要进度还是要结果？
我周围很多项目都很失败的，都是一地鸡毛。有这么一些共同特征：
- 前期不着急，时间多着呢
- 中期不着急，“我们有，稍微改改就行了”
- 后期很着急，“下个星期上线”
- 延期、延期、又延期，无止境（有些项目客户直接终止项目了）
- 额外解释一下，前期中期不着急不是躺着睡觉呢，忙别的项目呢
总之就是所有项目一团糟。其实吧，这些项目也不算很难，做对的话虽然不敢担保多么精彩，起码不至于搞砸，四平八稳收到大部分项目款还是可以的。
稍微尊重一下软件开发和软件工程师，并没有那么难，软件项目的核心不过是下面两个问题：
- 要做什么？
- 做成了什么？
要做什么？
“要做什么？”就是需求，我要说“要做好需求”大家肯定说“这我们早知道呀，需求当然很重要啦”。
话都会说，做到什么程度才算做好了呢？这个话很难讲，但是有简单的讲法：做到程序员清楚就行了。
反过来说就是，如果程序员不停地跑来问你要做成什么样，或者做出来的不是你想要的，那就是你需求还没做好啊。
如果程序员没问你但是拿给客户客户不停地要求改，你要是还觉得自己没啥问题那你就是问题了。
做成了什么？
最终客户得到的是你做成的东西，你做成了什么？是一个好用的、解决了用户需要的东西，还是一个步步是坑、碰一下就崩溃、逻辑匪夷所思、功能不知所云的……垃圾？
不完善的系统拿给用户是愚蠢的行为，不要让用户替你测试，那只会毁掉用户对你的信心。也不要拿原型给用户用，用户只要用上一下觉得行就会希望明天就上线（当然，更多时候是我们写了个原型就觉得完成了拿给用户用最后一地鸡毛）。
不要为了赶时间而仓促上线，把不完善的系统强行上线只会给后面带来更大的困难。系统一旦运行起来，想停产更新是很麻烦的。宁可慢一点，不要胡来，客户是通情达理的——前提是你不要胡来。
把测试组砍掉
不要测试组？嗯，是这个意思。
我对测试组没有意见，相反，大部分情形下测试组工作勤奋、效果显著——发现了大量低级错误和致命错误。
“低级错误”？是的，测试组辛勤工作发现的都是些低级错误——那些本该在写代码的时候自己就解决的问题，为什么由测试组发现？程序员自己不测试的吗？
“致命错误”？是的，程序启动都启动不了、操作一下就崩溃，这种东西你拿给测试组测试？脸呢？
有太多低级错误和致命错误的系统是没法深入测试的，因为流程根本走不下去。
对付这种情形就好的办法就是把测试组砍掉，让研发自己去测试，测试完才算交工，而不是“我已经提交测试了”。
没有低级错误和致命错误的系统才能交给测试组去发现那些需要专业测试人员去发现的BUG。
要进度还是要结果？
当然是要进度，30%-50%-80%-90%-95%-95%-95%……永远到不了100%。
进度压力之下必然伪造结果，伪造结果骗得了excel骗不了客户。
任务分得越细，效率越低，参与的人手越多，扯皮等待越多。大家都有责任，就是大家都不用负责任。
（这里是扯淡结束）
