有的流程或者工具会促进工程生产力（工程师的生产效率），有的就不会，比如代码规范，代码的可读性规范，会促进工程生产力，那么怎么样去衡量是真的促进了工程生产力，还是假的呢？用了如下的方法。
来自于《Software Engineering at Google》这本书，好奇 google 是怎么样去评价工程师的生产效率的，发现主要是用了一个叫做 Goals/Signals/Metrics (GSM)的框架，
- Goals(目标)
- Signals(信号量)
- Metrics(指标)
Goals(目标)
单一目标有可能不全面，所以 Google 用了一个多维度的目标，从如下几个方面去考虑：
Quality of the code（代码质量）
生成的代码质量如何？测试用例是否设计的足够好？架构设计的是否健壮？
Attention from engineers（工程师的专注度）
我认为工程师最怕被打断了，因为工程师非常需要专注，比如代码正好写了一半，被打断，需要很长时间才能恢复，所以 google 关注一个工程师需要多长时间才能进入状态？他们多大程度上被消息或者通知打断？工具是否有利于工程师做工作上的上下文切换？
Intellectual complexity（知识的复杂性）
完成一项任务需要多少认知负载？ 要解决的问题的内在复杂性是什么？ 工程师是否需要处理不必要的复杂性？
Tempo and velocity（节奏和速度）
工程师能多快完成他们的任务？ 他们能多快推出他们的版本？ 他们在给定的时间范围内完成了多少任务？
Satisfaction（满意度）
工程师对他们的工具有多满意？ 工具如何满足工程师的需求？ 他们对自己的工作和最终产品的满意程度如何？ 工程师是否感到筋疲力尽？
举例（readability process）
在 google ，非常重视代码可读性过程 readability process ，所以用代码可读性来举例，分别应用到 5 个上去上。
Quality of the code（代码质量）
由于有可读性过程(readability process)，工程师们写出了更高质量的代码；由于可读性过程(readability process)，他们写出了更一致的代码；由于可读性过程(readability process)，他们向代码健康文化致敬。
Attention from engineers（工程师的专注度）
可读性与注意力目标没有任何关联，这也是可以的， 并非所有有关工程生产力的问题都涉及所有五个领域的权衡。
Intellectual complexity（知识的复杂性）
工程师通过可读性过程了解 Google 代码库和最佳编码实践，并在可读性过程中接受指导，没有增加复杂性。
Tempo and velocity（节奏和速度）
由于可读性过程，工程师可以更快、更有效地完成工作任务。
Satisfaction（满意度）
工程师看到了可读性过程的好处，并对参与其中非常满意。