如果你正在寻找度量的完美方案，那可以告诉你的是，度量目前来看还无完美的方案。
我们常说，任何指标都是有副作用的。我们要思考的是在什么情况下，正作用>副作用，才有使用的价值。当然，你还要综合考虑度量的整体成本，度量也从来不是免费的。
我们可以设计上百个指标出来，我们需要通过了解现状是什么，通过哪些指标，能够解决现阶段的问题，这才是正事。
指标的动态性，不要企图使用一个或一组指标长久使用并且高效。不同阶段，你想要解决的问题不一样，团队的问题本身也是在动态发展的，指标需要调整。
什么时候该切换指标？当看到某个指标数据，你都不知道能做什么的时候，不能够发现十分有价值的问题的时候，你应该切换了。
度量事，而不应该度量人。IT行业的事情本身就十分难度量，关注在事的完成上，更有益于把事情解决。毕竟，大部分情况下，咱们不是为了解决掉人。人被数字化是件很可怕事情，本质上其实就是被贴标签了。
不要做违背人性的度量方式，你如果试图把人的头砍下来，还问别人为什么不把脖子伸出来。思考一下你的度量方式是这样的吗？
指标需要分层分级使用，达成目标即可。举个例子来说，冒烟通过率，站在小队级别，当发现存在问题的时候，可以使用起来，是一个很好阶段性指标。帮助量化问题，并做复盘分析。如果组织级使用此指标，没有人会搏傻，难道开发不好，测试好得了。有人说，“我们测试部门是独立的”，这难道就能保障公正性？除非测试组不想和开发组合作了，才会把开发质量问题暴露给组织层面。站在组织层面，也很难做，不跟踪，怕被认为形式主义。一跟踪，又上升到一个高度，让这个小队成为万众瞩目的焦点，同时组织层级好不容易听到一点声音，误判为这是一个普遍现象，以点带面的进行什么运动，下次谁还敢同步问题。组织级，还是多关注生产质量等偏结果类指标吧。
居于信任的度量，而非堵漏式度量。度量的模式，trust but verify。我们要相信我们的各层级有能力做好各层级的度量，让小队，部落制定自己的指标做好内部度量，不去质疑或横向检视比较小队部落级指标。让小队自下而上的提供近期的发现的问题，具体的改善项。组织级能够通过赋能（访谈，非正式沟通等）的方式，帮助小队部落如何去应用指标。
不作标题党，说是时候放弃XXX指标了。因为有太多高大上的指标，十分难度量，也十分后置，找到自己阶段性指标，行动起来，无效果就快速调整，帮助团队自度量才是根本。
