第2章
研发效能的进阶解读

研发效能是一个极其繁杂的问题，之所以繁杂，其本质还是软件开发工作的复杂性造成的。软件生产作为智力密集型活动，掺杂着大量人的因素，很难严格地标准化。此外，对软件生产过程的管理和实施也会遇到相同的难点，再加上软件行业的需求变化多，概念抽象等因素，复杂度呈指数级上升。

在1986年的IFIPS会议上，有一篇著名的论文《没有银弹：软件工程的根本和次要问题》[1]，预言了10年内没有任何编程技巧能够给软件的生产率带来数量级的提高，引起了极大的反响，甚至作者不得不在他的新版书籍中专门花了一章解释这个论断。可以看到，这些争议的背后是整个IT界对软件生产率和度量方法没有产生共识的一个缩影。对此，我们要做的不是消极等待某个魔术般的解决方案的出现，而是应该脚踏实地地进行探索、分析和实践。

软件质量和效能是密切相关的，在《人月神话》中，作者提出类似的观点：关注质量，生产率自然会随之提高。我们同样坚信，质量和效能是“既要、也要”的关系，效能的提升能够将软件研发中的风险更快、更及时地暴露出来，同时减轻人脑负担，反过来又能提升质量本身。

Martin Fowler有一句名言——“If it hurts, do it more often”（提前并频繁地做让你感到痛苦的事）。体现在软件工程中就是，高频的工作能够带来更早的风险暴露，继而更好地保障质量，而高频的前提就是高效。可见，效能和质量是互为保障的两个环节。

另外，IT界的研发提效和降本工作是急迫的。2020年，新冠肺炎疫情给国民经济带来了巨大的冲击，大量企业反思了过往的粗放式管理，开始重视效能，纷纷开源节流。与此形成对比的是，我们在很长一段时间对研发效能的关注是不够的，这也引发过业界对“996”等工作模式的激烈讨论，甚至是论战。从整个行业的角度来说，我们迫切需要方法论的指导和推动，从而切实有效地提升研发效能。