Martin Fowler：关注成效而非产出
极客时间编辑部
讲述：丁婵大小：5.90M时长：04:18
你好，欢迎收听极客视点。
被称为软件开发教父的 Martin Fowler 认为，软件开发应该重点关注成效，因为如果一个团队提供了很多功能，无论是用代码量、功能点、还是用户故事来度量这些功能，只要它们没有帮助用户改善生产活动，那么都是无用功。
假设有一个开发在线电商的团队，如果我们关注团队的产出，可能会考虑他们在上个季度中开发了多少新功能，或者考虑跨功能的提升，例如页面加载时间减少了多少。但是，如果考虑成效，增加销售收入或减少产品支持电话数量才是真正有价值的度量。关注成效而不是产出，就会更加倾向于构建那些可以提高软件用户和客户效率的功能。
与任何专业活动一样，从事软件开发的人也希望学习如何能够更加高效。这对于希望改善自身绩效的个体开发者，希望改善组织内团队的管理者，都是如此。造成这方面学习困难的原因之一是没有明确的方法来衡量软件团队的生产力。在此之上，考虑基于产出还是成效评价有效性，让这个问题变得更加复杂。
曾有一个反对使用基于成效作为观察点的论点 —— 要想针对成效提出可重复的度量，要比针对产出难很多。但是，众所周知，度量软件开发的纯产出是困难的，即使不玩复杂的游戏，代码行也是无用的度量。功能点或故事点的可复制性更差，不同的开发者针对同一事项会做出不同的评估。当然，确实有很多成效的度量是比较棘手的，比如客户满意度，但其中任何一个都不会比软件功能开发困难。
仅将某事项称为“成效”并不能使其成为正确的关注点，并且选择正确的成效进行观察确实是一项技能。 Seiden 提出过一个简单判断，他说成效应该展现在对组织有利的用户、雇员或客户的行为变化之上。他进一步区分了“成效”和“影响”，前者是易于观察的行为变化，后者是对组织更广泛的效果。在开发 EDGE 框架时，Highsmith，Luu 和 Robinson 建议，针对客户价值（洗碗机可靠性）的成效度量要比关于业务价值（保修维修成本）的成效度量更为重要。
使用成效作为度量的一个结果是指标分解到软件开发团队相对困难。假设有一个使用软件来帮助他们跟踪供应链中商品质量的客户团队，如果根据最终消费者的拒单数来度量，那么到底有多少是由于软件本身造成的呢？有多少是由于质量分析师制定的质量管理过程产生的呢？还有多少是由于另外一项旨在提高原料质量的举措而产生的呢？
指标分解的困难是比较不同软件团队效能的巨大障碍，比如希望判断使用 Clojure 是否有助于提高团队开发效率这样的场景。类似也有典型案例，开发人员可以很好地工作并提供出色且有价值的软件来跟踪质量，但是质量管理过程却拖了后腿。最后的结果是尽管开发人员有出色的贡献，但拒单率并没有下降，该改进举措被视为失败。
但是，分解面临的挑战不应作为观察错误事项的理由。人们常说“度量什么，得到什么”，在这种情况下，更像是“尝试什么，得到什么”。如果你将成功的评估重点放在产出上，那么每个人都会考虑如何增加自己的产出，即使和最后的成功毫无关系。因此，即使很难确定团队的工作如何影响最终成功，促使大家思考成效，以及如何改善成效，比任何对比团队无真正实效产出的努力都值得。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
墨池很有道理，但很难执行。 因为有些项目或产品功能产出少，但成效非常好！如果大家都去做这类项目，架构负债管理的幕后英雄就没有了！ 感觉教父没有这么肤浅，反观阿里的业务中台就明显很有组织管理优势，前中后台要分开看产出，前台应该更加偏关注成效。1
收起评论