也就是从近几年开始，软件开发已经进入到数据时代，
不论做什么产品、什么需求，大家言必谈之如何度量。
关于数据的重要性，当然不言自喻，也无需再多强调，
但很多言论却矫枉过正，大家可能太过偏爱数据了。
前段时间读了一本《Google 软件工程》，
书中对数据的认识，让人醍醐灌顶。
我在想终于有人能头脑如此清醒的讲明数据/度量的来龙去脉了（好处/注意事项）。
而不是被趋势所洗脑，坚信某一种主张。
作者写到，
只有当基于度量结果能够做出具体的决策时，我们才应该去度量软件的过程。
以证据为导向，但也要意识到，无法度量的东西可能仍然有价值。
这两点可能在大兴数据建设的时候，是没人愿意提的，
因为都不想唱反调，但显然数据都不是万能的，它也有其局限性。
所以，保持清醒的办法，不是坚守，而是弄清楚坚守的原因。
换成我自己的话，重新表述一遍
要想优化，并不一定非得度量
度量必须要能影响决策，才有意义
下文为来分析一下大家比较关心的，研发生产力的度量问题。
目标不应该是度量而是优化
在度量之前，我们应当明确的是，
我们的目标是，提高生产力
我们的目标不是，如何对生产力进行度量
这是截然不同的两个问题。
有时候根据经验，我们明显的知道效能瓶颈在哪里，但是很难度量，
也有时候，我们能够度量出来，但是又没办法优化。
所以，能否切身实地的进行优化，才是重要的，
哪怕优化方向，优化程度难以量化。
我们只是缺少了纠偏的手段，但无法纠偏未必一定是错的。
说到纠偏，就不得不提到科学方法，这也是为什么我们需要纠偏的理论依据。
科学方法讲究的是，观察-假设-实验-更新循环。
不断的与自然界交互，来订正自己的认知。
很多事情的推进，都是类似的这种 纠偏、近似解逼近 的思路。
比如软件开发中的 Scrum 方法论，引入 Sprint 概念进行迭代，
每日站会，每周迭代会议，就是促进反馈循环，帮助我们调整认知。
又比如，持续交付、用户访谈，只有不断的将功能展示给用户，
我们才能尽快拿到反馈，帮助我们调整需求的优先级，甚至对需求的认知。
总之，通过建立反馈循环，在近似解中频繁进行迭代，
可以帮助我们更快的达到更优解。
度量是有帮助的，但没有度量未必不行。
只有这样才能避免自己陷入度量的陷阱中，识别到自己真正的目的是什么。
度量对行为的影响
要想对现象进行度量，首先我们要知道以下两个效应。
在科学实验中，由于观察者预测某些测试结果，于是无意识的以某种形式操纵了实验步骤，或错误的解释实验结果，以达至他们期望得到的结论。
是心理学上的一种实验者效应，是指当被观察者知道自己成为被观察对象而改变行为倾向的反应。
度量本身也是有风险的，要么得到了我们本来预期的结论，
要么影响了被观测对象，让他们变成了预期的样子。
这在实际执行过程中，会给我们一些启示，
如果我们想要影响被观测者的行为，只要设定相应的度量指标就行了。
一个案例是，当我们设定了代码行数作为生产力度量指标的话，
大家毫无疑问的都会 “卷” 代码数，甚至用工具生成无意义的代码。
另一个案例，当我们设定了单测覆盖率这样的指标的话，
大家都会只为了追求覆盖率，而编写单测，并未考虑功能尚未完善的问题。
综上，我们需要谨慎的选择度量指标，这些指标需能对生产力起到激励作用。
否则，还不如不度量。
为什么项目管理如此重要
项目组是软件交付的最小单元，就好比军队的最小作战单元是 “班”（而不是个人）。
在软件开发中，不论任何形式的价值交付，我们需要成立项目，
用项目管理的方法论，来管控资源和预期。
我常说项目管理是 “熵减” 的过程，优秀的项目管理方法是一个 “不稳定点”。
稍不注意，我们就会沦为混乱、延期、预算超标。
为了避免这一点，需要优秀的项目管理者跟进，保障项目交付。
这就是项目管理者价值，他们是在跟人性和自发的趋势做对抗。
优秀的项目管理实践，考虑的不是按期交付，而是考虑，
如何能在限定期限的情况下，优先交付最重要的（价值最高）的那部分成果。
所以，比起个人研发生产力而言，我更倾向于衡量项目（最小的交付单元），
精益开发的影响，我会衡量项目交付的流畅程度（流速）。
在制时长：在制品的加工时长，没有交付的软件功能，充其量只是一堆可参考的资料
停顿时长：最后有进展到现在的间隔时间，总是有进展至关重要
上下游提醒频次：总是被提醒，意味着优先级没有对齐，价值流割裂
面向交付编程
有了以上度量指标后，能为被观察者建立科学的交付观。
不要面向功能进行编程，而是要面向交付。
如果功能不可演示，或者对最终用户没有价值，代码写的再多没有用。
此外，我们应当交付的更加频繁，让进展持续发生。
卡顿会导致在制品的积压，或者 TODO 列表事项积压。
导致整个软件交付过程，存在过多浪费。
这一点是非常反直觉的，大部分人接到开发任务的第一反应是做完，
而实际上，不论项目管理者还是一线开发，都应该纠正自己，
不是要考虑做完，而是要考虑在限定截止日期下，做完哪些内容。
产生这一误区的原因可能在于，产品经理和开发者，分属不同的团队。
产品经理可能会认为，无法交付是因为开发者懒惰造成的。
但实际上，大部分功能的后 20%，其实既会花费更多精力，价值也不高。
我们应当设立小目标，并总是达成。
如果不能达成，那就应该将目标重新拆分成更小的。
小结
以上介绍了我对生产力度量和软件交付的想法，现总结如下，
度量要能影响决策，不然还不如不做
没有度量也能优化，并不一定非要通过数据来纠偏
度量可以影响被观测对象的行为，可用来推动生产力
做项目应当增加流速，识别卡顿
以上这些观点，可能会涉及技术因素，也可能会涉及非技术因素。
所以，提升生产力并不是简单的提升系统性能就可以了。
性能的提升可能是冰山之一角，更多的则是帮助开发者建立科学的交付观。
让大家更好的协同，不断的消除瓶颈。
这正是：不识庐山真面目，只缘身在此山中。