“效率” 和 “效能” 是不同的。
“效率” 是一个比值，是有效产出占总投入的比例。
In general, efficiency is a measurable concept, quantitatively determined by the ratio of useful output to total input.
而 “效能” 则是指产生期望结果的能力。
Effectiveness is the capability of producing a desired result or the ability to produce desired output.
效率强调资源的有效利用，以最少的投入得到最大的产出，也就是 “正确的做事”，
效能重视组织目标的达成、重视结果，追求 “做正确的事情”。
本文主要介绍，我对软件研发效率、效能的理解。
软件研发常以 “项目” 的形式存在，
是指一群人在资源有限的情况下，完成目标的活动。
正因为资源有限，所以我们应当关注 “效率”，以更好的利用资源，
也因为项目是以完成目标为本的，所以还要关注 “效能”，才能达到期望的结果。
那么对于软件项目而言，
如何更好的利用资源，如何正确的设定项目目标呢？
衡量方式
软件研发是一种知识工作，
知识工作与体力工作成果的衡量方法是不同的。
彼得·德鲁克 在《卓有成效的管理者》中提到，
对于体力工作，我们所重视的只是 “效率”。体力工作的成果，通常可以用数量和质量来衡量。我们已有一套完整的衡量方法和制度，但是这种衡量方法和制度，并不能适用于知识工作，衡量知识工作主要应看其结果。
虽然开发者们经常自嘲在从事体力劳动，但实际上软件研发正是一种知识密集型的活动。
比起建筑行业来看，软件研发并不像大家一起在盖房子，
更像是合伙写一本书。
开发者们平时所应对的是不可见的抽象概念，
如何确保对这些抽象概念理解一致，如何完美的契合到一起，
才是比较困难的事情。
软件研发项目都有一个 “不可见” 的沟通成本，正如《人月神话》中所言，
软件开发的真正困难不在于如何表示一个抽象概念，而在于如何将这个抽象概念传递给其他人。向进度落后的项目中增加人手，只会使项目更加落后。
事实上，拼命编写大量难以理解的代码，正是软件研发活动迟缓的罪魁祸首之一。
而产生这种状况的原因之一，
正是一些管理者使用了不恰当的方式，通过代码行数来衡量开发者的成果。
因此，要想优化组织的效率和效能，
首先要做的事情是，改变组织内部不恰当的衡量手段，
衡量方式决定了优化目标。
过程管理
没有好的过程，就难以产生好的结果。
很多人在进行软件项目管理的时候，容易陷入一个误区，
那就是对 “流程” 盲目的相信。
认为造成当前研发活动 “较慢” 的原因在于，没有一个好的流程。
其实软件研发过程，并非如此这般简单。
非瓶颈资源的利用程度，并不是由其生产潜力来决定，而是由系统中的其他制约因素来决定。
也就是 “木桶原理”。如果软件研发过程中，存在一个瓶颈，
那么不消除这个瓶颈因素的话，提高其他环节的利用率，是没有意义的。
这就得出了软件研发过程管理的一个常用方法，
识别并设法减少瓶颈因素，直到瓶颈因素不再对效能产生约束；消除一个瓶颈之后，又会涌现出另外一个新的瓶颈，如此循环不已。
这种方法以迭代的方式，通过识别和消除瓶颈，系统性的提升效能。
由消除一个又一个瓶颈来不断演化发展出一个新过程。
所以，软件研发过程管理，其实是瓶颈的识别和消除过程，
并非简单的使用一个 “预先设计好的” 流程，就可以凑效的。
可见性
有了上述理论之后，为了更好的识别和消除瓶颈，
人们通常要做的事情是，提高项目的可见性，
即，让项目的所有参与者，一目了然的看到项目的瓶颈（制约因素）在哪里。
提升项目的可见性有很多好处。
其一，有助于项目管理者，知道瓶颈在哪里，对过程不断的进行优化。
其二，有助于项目中各利益相关者，权衡自己的决策，尽可能让多方满意。
这后面一点通常不被人们所重视。
其实，资源有限的情况下，最终方案是各方权衡的结果，
很难是让所有人都满意。
比如说，产品经理在研发团队交付能力之外，试图增加额外的功能，是没有意义的。
因为当前研发瓶颈在于交付能力上。
这时最好的办法不是赶工做出来，而是进行协商。
赶工会影响软件质量，不赶工又会影响功能，到底应该怎么做？
这个决策交给研发团队自己来决定，是非常有风险的，
因为他们不知道，最终应以什么样的底线，以什么样的优先级交付功能。
这件事其实应是产品、测试、研发，三方都要参与权衡的结果。
提升项目的可见性，会使得权衡过程变得透明，更有利于项目达成多方预期的目标。
无独有偶，在《软件系统架构》中，也提到了类似的想法，
A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs.
好的架构应满足各利益相关者的需求。
软件工具
软件研发产物，可以用来提升软件研发本身的效率。
这是一件很有意思的事情，是一种反馈效应。
“反馈” 是控制论中的概念，
是指将系统的输出返回到输入端，以某种方式改变总输入，进而影响系统功能的过程。
软件研发团队可以不用每次都从零开始，
最好每次都能 “站在自己的肩膀上” 继续前进，或说 “吃自己的狗粮”。
这就需要建立 “产物” 要能被下次可用的意识。
其中一个最容易想到的做法是制造 “工具”，工具可以辅助开发，
让重复性的人工操作，变成自动化处理。
然而同时，软件工具又会引入新的复杂度，那就是学会如何使用这些工具带来的成本。
不要小瞧了这看似 “微不足道” 的成本。
有一个认知偏误，称为 “知识的诅咒”，
指的是，知道知识的人，其实很难理解不知道知识人的处境。
所以事实上，工具会比我们料想的更难使用。
在《软件架构师应该知道的97件事》，也曾提到过，
Reuse is about people and education, not just architect.
设计优良的工具，细致考虑并精巧实现的框架，并不会自然而然的就被人们使用。
人们要能够使用它，需要满足一些条件：
大家知道它们存在；大家知道如何使用它们；大家认识到利用已有资源好过自己动手。
综上，我们应避免盲目的制造工具，
而是应该把精力着眼于整个系统上，看清楚工具到底带来怎样的反馈效应。
有些时候，工具反而拖累了研发效率也说不定呢。
项目目标
一个正确的目标，在项目早期是很难确定下来的，
所以才出现了各种各样的软件研发策略，例如 敏捷开发、极限编程。
近来越来越多的团队，采用了 “迭代式” 的研发方式，
采用不断增长的方式逼近目标。
即，如果暂时无法明确目标的话，就不妨延迟决定，先向前走。
在《Clean Architecture》中有这样一段话，
Good architects design the policy so that decisions about the details can be delayed and deferred for as long as possible.
然而很不幸，软件团队又不得不身处于一个 “传统” 的更大型的商业组织之中。
这样的组织通常有个特点是，先有目标才能有预算，
如果在立项的时候无法确定目标，组织就不能判断是否值得开展。
有了预算，研发团队才申请到更多的资源，
争取到更长的项目周期，或者争取到更多的研发人员。
团队售卖的是 “期望”，买回来的是 “资源”。
这并不是仅仅通过一个好的 “研发策略”，或者好的 “架构” 就可以解决的。
一个好的管理者会有商业头脑，让团队一开始就工作在 “可以达成” 的项目之中。
很多项目之所以失败，根本原因可能并不是团队的交付能力问题，
而是一开始就在 “死亡行军”。
做出改变
现在我们已经了解了影响效率和效能的种种因素了，
但是，谈到对现有组织作出改变，仍然是很难的。
这是因为组织的行为，是受大环境潜移默化而影响的，
组织中的每个个体，都已经尽量达到了自身收益的最大值，
虽然这种状态并不一定是组织整体收益的最大值状态。
博弈论中有一个经常被提及之 “囚徒困境” 的例子，
两个囚徒中的每一个人，在不论对方如何选择的情况下，选择 “招供” 都是收益最大的。
人们称这样的决策状态，是达到了 “纳什均衡”。
很显然，两个囚徒一起选择 “不招”，才是对他们两个同时最优的决策，
他们为什么没有这样做呢？这是由局中人的收益决定的。
改变收益是打破纳什均衡最有效的方法之一。
对组织做出的任何改变也是如此，
如果没有来自公司层面的赞成和支持，及时的调整 “奖惩制度”，
那么谈论改变，就失去了意义。
换句话说，想要人们在研发效率和效能上提升，就得鼓励这样的行为，
《乌合之众》中，有这样一句话，
人一到群体中，智商就严重降低，为了获得认同，个体愿意抛弃是非，用智商去换取那份让人备感安全的归属感。
结语
整篇分析下来，可能会有些悲观。
软件研发牵涉到的因素特别多，健康的研发活动反而是一个不太稳定的状态，
只要 衡量方式、研发过程、可见性、软件工具、项目目标，有一个出现问题，
都会产生灾难性的结果，导致 “稳定的” 失败结局。
软件研发涉及 项目、架构、管理，等等多个专业领域，
一群人不得不紧密合作各取所长，才能实现当初的 “承诺”，
因此，人员才是最核心的竞争力之一。
最后，软件研发活动不是孤立存在的，它总是从属于更广泛的商业活动之中，
我们难以改变自己，因为外界的 “奖惩规则” 影响了人们的选择，
即使改变了自己，作为一个整体仍需按照外界的 “游戏规则” 抢夺资源。
这真是现代信息化战争的一个主战场呢。