“ 改进生产力也有成本。所以，我们的目标不只是要改进软件工程生产力，而且是要有效地做到这一点。
——本文节选自《谷歌软件工程》第七章”
1
这个问题才是工程效能要解决的问题：
「随着组织规模的线性增长，沟通成本也会呈二次曲线增长。」
增加人员对于扩大您的业务范围是必要的，但是沟通管理成本不会随着您增加人员而线性增长。不过，还有另一种方法来解决我们的规模化问题：我们可以让每个人的工作效率更高。如果我们能增加通过提高组织中单个工程师的工作效率，我们就可以扩大业务，而不会相应地增加沟通开销。
然而，提升生产力也有成本。所以，我们的目标不只是要提升软件工程生产力，而且是要有效地做到这一点。
在谷歌，我们通过创建一个致力于了解工程生产力的研究人员团队来解决这些权衡问题。
我们的研究团队包括来自软件工程研究领域的人和通才软件工程师，同时，还包括来自不同领域的社会科学家，包括认知心理学和行为经济学者。他们的加入让我们不仅可以研究工程师生产的软件工件，还可以了解软件开发的人的方面，包括个人动机、激励结构和管理复杂任务的策略。
该团队的目标是采用数据驱动的方法来衡量和提高工程生产力。
2
在我们决定如何衡量工程师的生产力之前，我们需要知道指标什么时候值得衡量。
测量本身的成本就很高：它需要人们测量过程，分析结果，并将其传播给公司的其他部门。
此外，测量过程本身可能很繁重，并会减慢工程组织的其余部分。
即使进度不慢，跟踪进度也可能会改变工程师的行为，可能会以掩盖潜在问题的方式改变。我们需要聪明地衡量和估计；虽然我们不想猜测，但我们不应该浪费时间和资源进行不必要的衡量。
在谷歌，我们提出了一系列问题来帮助团队从一开始就确定是否值得衡量生产率。
我们首先要求人们以具体问题的形式描述他们想要衡量的东西；我们发现，人们越具体地提出这个问题，他们就越有可能从这个过程中获益。当可读性团队找到我们时，问题很简单：一名工程师经历可读性过程的成本是否值得他们可能为公司带来的好处？
然后，我们请他们考虑他们的问题的以下几个方面：
您期望的结果是什么？为什么？
如果数据支持您的预期结果，将采取什么行动？
我们之所以这样问，是因为如果不采取行动，那么衡量就没有意义了。
请注意，如果已经有计划要这么变更，而如果我们没有此结果，则操作实际上可能是“维持现状”。
如果我们得到否定的结果，会不会采取适当的行动？
我们问这个问题是因为：在很多情况下，我们发现，即便最后得到了否定性结果，也不会改变行动决定。即：无论结果如何，都要这么做。
如果是这样的话，可能就不值得衡量了。我们发现：决策者对知道结果很感兴趣，但但，无论结果如何，他们也不会改弦易辙。
谁将决定对结果采取行动，他们将在什么时候采取行动？
我们要求这样做是为了确保请求测量的人是被授权采取行动(或直接代表他们这样做)的人。
最终，度量软件过程的目标是帮助人们做出业务决策。重要的是要了解这个人是谁，包括什么形式的数据能让他们信服。
通过提出这些问题，我们发现在许多情况下，度量本身根本就不值得…
这没什么大不了的！有很多很好的理由不去衡量工具或过程对生产力的影响。
下面是我们看到的一些不必去做度量的场景：
您现在负担不起更改流程/工具的费用
任何结果很快都会因其他因素而失效。
结果将仅用作虚荣心度量，以支持您无论如何都要做的事情
唯一可用的指标不够精确，无法衡量问题，并且可能会被其他因素混淆
当您成功地度量软件过程时，您并不是要证明假设是正确的还是不正确的；成功意味着向涉众提供他们做出决策所需的数据。
如果涉众不使用数据，那么这个度量研究项目就是失败的。
只有在基于结果做出具体决策时，我们才应该度量软件过程。
对于可读性团队来说，需要做出一个明确的决定。如果指标显示该过程是有益的，他们将公布结果。如果不是，这一程序将被废除。最重要的是，可读性团队有权做出这一决定。
3
在Google，我们使用目标/信号/指标(GSM)框架来指导指标创建。
Goal 是指：目标，即期望的最终结果。它是根据您想要在高层次上理解的内容来表述的，不应该包含对衡量它的具体方法的引用。
Signal 是指：信号量，就是你能知道是否你已经达到最终结果的方式。信号是我们想要测量的东西，但它们本身可能是不可测量的。
Metric 指标体系，它们是信号的代理。这是我们实际上可以测量的东西。这可能不是理想的衡量标准，但我们认为它已经足够接近了。
它可以防止路灯效应。
“在路灯下找钥匙”，比喻为：假如你只在你能看到的地方找丢失的钥匙，那么，你很可能找错地方了。
对于指标，当我们使用我们可以轻松获得的指标时，就会发生这种情况，无论这些指标是否适合我们的需求，都是可得到且且很容易衡量。
相反，GSM迫使我们思考哪些指标实际上将帮助我们实现目标，而不是简单地考虑我们现有的指标。
GSM通过鼓励我们在实际测量结果之前使用原则性方法提出适当的指标集，从而帮助防止指标蔓延和指标偏见。
GSM可以告诉我们哪里有测量覆盖范围，哪些是无法覆盖的地方。当我们运行GSM流程时，我们列出所有目标，并为每个目标创建信号。
目标 Goals
目标应该有一组属性，就像“平衡计分卡”一样。
信号 Signals
信号「Signals」是我们知道我们已经实现目标的方式。并不是所有的信号都是可以测量的，但在这个阶段这是可以接受的。信号和目标之间不存在1：1的关系。每个进球都应该至少有一个信号，但他们可能有更多的信号。一些目标可能也有相同的信号。
指标 Metrics
指标体系「Metrics」是我们最终决定如何测量信号的地方。指标体系本身不是信号；它们是信号的可测量代理。
因为它是代理人，所以，很可能不是完美的度量项。因此，当我们尝试对底层信号进行三角测量时，某些信号可能具有多个度量。
此外，某些信号可能没有任何关联的指标。因为这个时候信号可能根本无法测量。例如，度量代码质量。
4
5
回想一下我们的最初目标：我们想要采取行动，提高生产率。
在对一个主题进行研究之后，谷歌的团队总是会准备一份建议清单，告诉我们如何才能继续改进。
我们可能会向工具建议新功能，改善工具的延迟，改进文档，删除过时的流程，甚至更改工程师的激励结构。
理想情况下，这些建议是“工具驱动的”：如果工具不支持工程师这样做，告诉他们改变他们的流程或思维方式是没有好处的。相反，我们总是认为，如果工程师拥有合适的数据和合适的工具，他们就会做出适当的权衡。
5
在衡量生产率之前，不管结果是积极的还是消极的，都要询问结果是否可行。如果你不能对结果做任何事情，那么它很可能不值得衡量。
使用GSM框架选择有意义的指标。一个好的度量标准是您试图测量的信号的合理代理，并且它可以追溯到您最初的目标。
选择覆盖生产力所有部分的指标(定量)。通过这样做，您可以确保您不会以牺牲另一个方面(如代码质量)为代价来提高生产率的一个方面(如开发速度)。
定性指标也是指标！考虑建立一种调查机制来跟踪工程师信念的纵向指标。
定性指标也应该与定量指标保持一致；如果它们不一致，很可能是不正确的定量指标。
旨在创建内置于开发人员工作流程和激励结构中的建议。尽管有时有必要推荐额外的培训或文档，但如果将其构建到开发人员的日常习惯中，则更有可能发生更改。
6
每个指标的五大衡量属性QANTS ：
Quality of the code
Attention from engineers
Intellectual complexity
Tempo and velocity
Satisfaction
— THE END —
