之前写了两篇文章，分别介绍 “软件研发效能的负面清单”、“软件研发的十大浪费”，今天算是对软件研发效能的负面东西做一个总结，挖掘出背后的原因。从本质上看，都是人性的弱点，这些弱点成为软件研发效能的阻力，甚至把软件研发效能拖下水。
一宗罪：自私
- 为了自己升职或保自己的位置，希望自己的团队快速扩展，自己管的人越多越好，而不管效能是否低下；具体讨论，可以参考之前写的一篇文章：许多研发管理者并不想提升研发效能，这才是最大的问题！
- “各人自扫门前雪，休管他人瓦上霜”，有些管理者，只关注自己一亩三分地，而不管全局利益，局部效能看似不错，但整体效能上不去，甚至会产生严重的冲突，1+1<2, 而不是1+1>2；
- 资源浪费：自己有好的资源（包括人力资源）、好的学习材料占为己有，而不会主动向大家喊：这里有好的资源、好材料，你们想用吗？
- 缺少分享精神。做出好的设计、写出好的代码，从中获得的经验和启发不愿分享，甚至都不想让同事知道。
二宗罪：爱面子、虚荣心作祟
- 形象工程：愿意花巨资建一个大屏幕，呈现一些漂亮的数字，如100%自动化测试率、100%版本构建成功率、每天发布10个版本、一次发布平均高达10个用户故事......但交付的质量如何？是不是用户想要的？用户满意度如何？一些关键的数据倒是没有；例如100%自动化测试率，而实际测试的投入成本居高不下，效能其实不高。
- 追求好看的指标和有利于自己的解读：即使是相同的数据，看我们怎么解读，如果只是为了好看，就会有好的解读。而且想要什么就度量什么，如果只是想要好看，你就会度量有利于自己的指标，甚至我们都不能低估人们在追求“好看指标”上的“创造性”。但实际上，我们往往希望数据帮我们发现问题，和“爱面子”相反。
- 喜欢大而全的平台（包括开发平台、效能平台、度量平台、测试平台），而不是专而精的工具，造成平台使用麻烦、流转效率低下；
- 有些工程实践也是为了充门面，常常沦为一种形式或只是口号，甚至滥竽充数，包括效能度量、单元测试、自动化测试，演示起来很漂亮，但实际项目中则一塌糊涂，而且自己内心还不一定认可其价值。有些文档制作得很漂亮，却是为了应付一些所谓的国际认证、内部审查而事后补做的，所以实质上没有提升效能，反而严重拖效能的后腿。
三宗罪：欲望
- 欲望永远填不满，为了填充一些人的欲望，软件研发常常付出不少代价。
- 如占有欲，有些工作（包括工作岗位，如开发经理、测试经理等）不适合他，但因为来得早，占了天时地利，却迟迟不愿让出来，阻碍着研发变革（如开发和测试的融合）。
- 有些工作完全则是为了满足自己的金钱欲望，例如，重复造轮子是为了自己的业绩，为了自己能涨工资和获得奖金，其实市面上已有现成的且好用的工具（领导可能不知道），自己造出的轮子还没有开源的工具好用（领导可能不知道）；
四宗罪：喜新厌旧
- 喜欢写新代码，开发新功能，代码不断累积，但从不优化，这样就导致了一个臃肿、脆弱的代码基础，难以进行有效地维持。
- 追求新的技术、新的编程语言、新的设计模式，不断尝试新的东西，不断在不同的技术、语言和模式之间切换，浪费了多少代码和多少时间，全然不顾；而且新的技术不成熟，让系统的质量不稳定，甚至很糟糕，导致大量的返工。
五宗罪：骄傲、盲目自大
- 盲目迷恋自己工具，即使很难用，也不舍得抛弃，结果劣币淘汰良币；
- 总觉得自己做的设计或写的代码就是好，测试人员发现缺陷，不怀疑自己的代码，反而是质问测试人员：你是不是搞错了？从而影响沟通和协作，降低研发效能。
六宗罪：崇洋媚外
- 拿来主义：不管上下文，只要是欧美大厂（如Google、Apple、Amazon等大厂）的实践就是好实践，拿来就用。一些中小型企业的研发团队不了解自己的团队，不了解自己所处的环境，照搬欧美大厂（甚至国内大厂）的实践，导致水土不服，效能不升反而下降。殊不知，南橘北枳。正如同样的药给大象吃可以治病，而给你吃可能直接丧命。不变革等死，但变革不对，会死得更快。变革是需要，一定要因地制宜。别人的经验可以参考，要弄清楚上下文，然后进行调整。适合自己的路终究要靠自己走出来，拔苗助长只能是昙花一现。
- 不懂装懂，盲目跟风，不了解某种实践的起源，解决的是什么问题，只要人们说好的，只要大家都在用，就拿来用，也有可能一命呜呼。
七宗罪：懒惰
- 懒惰是万恶之源，可见懒惰带来的危害之大。
- 能偷懒就偷懒。写代码时没有验证输入这样的错误常常犯，病从口入，许多普通的安全漏洞（如缓冲区溢出、SQL注入攻击等）、因空指针导致系统崩溃，都是因为“没有验证输入”。代码缺少注释行，代码可读性差，单元测试能不做就不做，代码评审走过场，... 都是由懒惰造成的。
通过这篇文章和下面4篇文章，我们比较彻底地了解软件研发的本质和软件研发效能负面的方方面面，下周我们开始考虑如何克服这些问题、把软件研发拉上正道，如何持续提升效能...
