然而这并没什么卵用！程序员照样可以在你眼皮底下搞出Bug来，原因很简单——臣妾做不到啊！

• 【应对策略】

说起来比较简单，找几个牛逼的程序员，把那些做支持性工作的人都赶走（留一个搞搞服务，需要设备给设备需要安慰给安慰），这样基本就OK了。

假如招人很难，那管理者就要注意创造宽松、积极的环境，让我们的程序猿们愿意抛开不合理的基于技能的分工，把自己培养成一专多能的猿中之王。

3个能力与需求匹配的程序员的生产率，超过错配的10个人。

绩效导向

你知道技术经理、项目经理、部门经理的绩效是怎么评估的知道程序员的绩效是怎么评估的面都有什么问题议看看我之前在微信订阅 “程序视界”发布的文章——“绩效/加薪/年终奖，虐你如初恋”。

对于技术管理、项目管理类的一线管理者，他们所带的队伍干的活越多，并行的工作越多，发布的版本越多，交付得越快，他们的绩效就越好。

由于这样的绩效导向，很多团队的技术经理、项目经理实际上就容易重视数量和速度，忽视质量和可维护性，最终就会导致只管拉屎不管擦屁股的管理作风。尼玛，先上了再说，先满足领导的时间要求再说。

所以，技术方案选择，快定快定快快定，差不多就行了。架构设计，快定快定快快定，赶紧开始写代码吧。开发进度，今天20%明天50%后天就90%了。当一个程序员忧心忡忡地表示技术方案不合理、架构设计存在缺陷、代码写得太快又脏又乱深海潜雷又多时，得到的答案往往是“来不及了，后面有时间再重构再完善吧”。

这要不出问题，就真日了鬼了。

所以，后面你就看吧，拆东墙补西墙，这边贴膏药，那边打补丁，服务不稳定就再写个监控服务管着它，内存泄露经常把服务器搞死就定期重启，今天Hotfix，明天紧急修复……作为程序员，你要不被折腾操折腾走那就是有人烧香保佑你了。

God Bless You！

• 【解决方案】

要从管理层就贯彻下面的原则：

在一段时间内，做好做精一件事。

要用数据让管理层明白：

匆匆上马的软件产品的维护成本远远大于（通常数倍于）开发成本，求快反慢，求廉反贵！

调整绩效指标，引导绩效指向：

要把软件发布后的运行情况作为绩效考核的一个重要参考因素。

有问题再说的思想

你有没有过这样的经历：

• 明知道代码有潜在问题也懒花时间得改
• 明知道贴块膏药打个补丁只能暂时规避问题可还是那么做了
• 明知道张三的代码逻辑上有个漏洞还是睁一只眼闭一只眼算了
• 明明有时间把某个模块的代码梳理一下重构一下想想没什么外在回 就放弃了
• 明明看着需求莫名其妙还是接受了
• 明明某个界面的UI设计反人类还是从了
• 写完代码编译通过就扔给测试去测

这都是很常见的现象，很多程序员都遇到过，都想想算了，先这样吧，有问题再说，反正有的是理由：

• 时间紧任务急，考虑不了那么细
• 别人定的，我管不了那么多，干好我自己的就成了
• 出力不讨好，不定还被谁不待见
• 反正回头还会Bug回归，先往前赶进度要紧
• 对得起老板给我的这么点钱就行了

一件事你不想做不想做好，总是找得到理由的。然而，在软件开发这件事上，你总得有一个环节需要认真，而且这个环节越靠前越好，越往后付出的代价越大效率越差效果也差。

要么你在需求分析时认真，要么你在设计和编码时认真，要么你在测试时认真，要么你在运维时认证，要么你在处理故障时认真……你总需要在一个地方认真，假如你什么地方都不认真，那就只好认真找工作了……

然而《无间道2》里的倪永孝早看穿了这一切：

我想要说的是，对技术要有一颗严谨和敬畏的心，想清楚了再干，干好了再给别人用。对技术负责，对产品负责，就是对你自己负责。

相关阅读：
– 大龄程序员的未来在何方
– 月薪3万的程序员都避开了哪些坑
– 这10个问题去哪儿啦
– 每周一书：致加西亚的信

更多精彩文章，参看“漫谈程序员”专栏或关注微信订阅 “程序视界”(programmer_sight）。