03 | 效能度量：如何选对指标与方法，真正提升效能？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何正确使用效能度量来衡量团队的研发效能。作者首先回顾了效能度量的定义、作用和使用误区，强调了度量指标的重要性，并分享了一个关于团队研发效能提升的真实案例。接着，作者提出了效能度量的指标分类，包括团队和个人两个维度，分别涵盖速度、准确度、质量和个人效能。在此基础上，作者提出了效能度量的原则，强调度量不应与绩效挂钩，而应作为参考和工具，帮助团队提高效能。最后，作者推荐了四个度量使用方法，包括目标驱动、度量对的事等。整体而言，本文强调了度量指标的重要性，以及正确使用效能度量的原则和方法，为读者提供了一些实用的技术指导。文章内容涵盖了团队效能提升的实际案例、度量指标分类和原则、以及度量使用方法，为读者提供了全面的指导和思考。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(35)
- 最新
- 精选
陈磊@Criss问题：dev工作block了作者回复: 对啦。厉害！
2019-08-28211
Xin需求评审完后在开发过程中频繁加需求及修改，开发过程中不停应对不同部门的咨询打断各种都强调优先级，这是最痛的😂作者回复: 这个问题在开发资源被共享的情况下的确是很常见，也很棘手。我看到有两个可能的处理办法，第一个是。有一个统一的接口人来对接这些优先调节优先级的要求，挡住一些，并且根据全局情况进行合理调节。第二个方法是改变开发资源的共享方式，从按智能划分团队，转变成按产品划分团队，或者是矩阵式管理。
2019-08-2839
囧囧冰淇淋老板：效能度量不能与绩效挂钩，那我怎么知道你们提高了啊？我现在看到的就是，我们的产品经常上不了线，产品部和运营部那边经常抱怨。我看了下XXX公司（同行但非顶尖），他们用的这套绩效考核很有用，我们要多向他们学习学习，这套指标先定下了。 在小公司比较容易发生，老板会拿比自己好一些的同行对比。大公司不知道会不会发生这种质疑：因为业务的进展缓慢，从上至下产生不信任感，导致团队开始埋怨和打混。 以下是自我理解： 老板： 1.需要开明，问题可以从外部去参考，但不能直接套用到团队上，要考虑公司整体情况。比如需求经常被更改，经常着急上线，那就要把产品，运营，软件一起叫进来讨论，坚决抵制互相甩锅，而是每个团队做哪些可以便利下一个部门效率，形成一个整体提升。 2.允许员工反对，倾听员工的想法，让相关人员围绕问题一起谈谈，可以不用马上得到答案，把它当成一种倾听、持续改进的沟通方法。 3.允许一定的失败，小公司是在磕磕碰碰中长大的，经验欠缺，人员不齐，不要出了问题就大骂一通。 4.关心员工，成功或者失败了，大家都付出了努力，还可能经常加班，加班可是没有工资；失败后的大骂，成功后的轻描淡写都让给团队丧气。 5.提供一些工具或者课程帮助员工。 6.公司和团队成长后提供更好的待遇。作者回复: 从我的经验看，对开发工作，绩效考核通过360反馈，通过相对主观的方式，反而比较有效。
2019-08-2875
Johnson本地构建是指的工程师在自己的笔记本上？还是说工程师通过本地笔记本登录到的开发服务器上？工程师的笔记本环境有可能有多种，比如有的同事入职时选的PC，有的选的MAC，如果在笔记本上构建，那这个环境很不好维护啊作者回复: 本地构建指的是在自己的开发机器上，也就是代码所在的地方进行构建。如果代码是在远程的开发服务器上，那这个本地指的就是远程的服务器，如果代码是在笔记本上，那这个本地就是笔记本。 在你的例子当中，如果大量的开发都是在笔记本上进行的。那么虽然环境维护有一些麻烦。还是很值得投资的。大不了在Windows上面做一套环境，在Mac上面做一套环境。具体方法，最直接的是使用脚本自动化。 另外这个环境最好和你们的生产环境保持一致。避免在本地构建出来的东西，在生产环境上会出现因为环境不同而造成问题。
2019-08-2835
舒偌一大概在11前产生了大量的bug，之后在修改之前的任务，dev没有接受新任务。作者回复: 答对了！赞
2019-08-283- Geek_eddy本地开发机使用线上数据验证对开发来说确实很爽，Facebook是如何保证线上数据安全性？
作者回复: 这一部分我也不是特别了解细节。但是知道主要原则大概有几个： 1. 数据库中都有特定的Field指出是否是测试数据 2. 能够快速恢复。这个是基本 3. 强大的监控。开发人员账号触碰到生产数据，如果是TA本人不应该有权限的，必须要有任务ID才能有Access。这些行为都会被记录下来。
2019-08-2823 
小炭问下，调查问卷有推荐的方法和工具吗作者回复: 方法的话NPS不错：https://community.verint.com/b/customer-engagement/posts/net-promoter-score-nps-criticisms-and-best-practices 国内的问卷星还是不错的。
2019-12-142
传说思考题分析啊～ 1.dev休假 2.购买了软件产品 3.需求做不了作者回复: 从图上看到的是开发被阻塞了，没有接受新的开发任务。你这个直接给出开发被阻塞的三个可能原因，哈哈，厉害 ：）
2019-08-282
xin1195研发效率的提升来源于这样的一个个小的优化点，看起来小，但是对效率提升确实很大。应该给与足够的重视。 这个列子让我想起在工作中遇到的同类型案列：当时在shein工作时，由于灰度环境只有一个，每次发版都的协调灰度环境的使用权和使用时间，如果前面的使用者超时，就会导致我们的灰度测试时间不够，甚至影响到我们的上线时间。而且每次灰度测试的发布时间都在半小时以上，非常影响到研发测试的效率。当时也和公司提过在搭一套灰度测试环境，但是公司给的回复是非常麻烦，也就不了了之，现在想想，是自己当时的认知不够，不能从更高的角度看待这个问题，才会导致可以改善的点，因为一点点挫折，就放弃了。反思：全体员工的认知不够，是导致这个问题长期存在的关键。作者回复: 在一个环境时间时间长，往往会习惯当下的环境，觉得常态就是这样。这个时候就需要能够跳出来。推荐阅读关于黑客之道的内容：https://time.geekbang.org/column/article/162869。
2020-05-201
章皓老师，关于累积流程图由几个问题请教： 1、请问有什么工具比较方便产生这个累积流程图 2、纵轴的任务数量，由于任务有大小之分，统计时应该是每个任务有时间估算，然后估算时间加总作为纵轴数值；要画出这个图需要需求，开发，测试都做好时间估算才行；目前在团队中，大家都不太愿意花时间去做估算工作作者回复: （不好意思回复较晚。最近特别忙） 1.1 In Jira: https://confluence.atlassian.com/jirasoftwareserver/cumulative-flow-diagram-938845656.html 1.2 Excel 模版：https://hakanforss.wordpress.com/2011/06/17/cumulative-flow-diagram-how-to-create-one-in-excel-2010/ 2. 关于任务大小不同，实际上，任务大小不会影响从中观察交付周期、WIP等数据。事实上你可以从图中看到不正常的情况，倒退回去查看当前是不是有和其他任务大小差别很大的任务存在。 如果希望看到稳定的flow，如果团队任务数量多的话大小，这些任务的平均值会减少影响。如果还是不行的话，有两个办法，第一就是要估算工作量然后进行加权，但是更好的一个办法是在任务拆分时大小差别不要太大。 另外，画这个图的时候，是根据已经发生了的情况进行统计，不需要事前估算。只需要一个人搜集历史数据制作这个图即可。
2020-05-161
