“技术债”可能是软件工程领域有史以来最成功的术语之一。
这并不是因为它解决了问题。技术债依然无处不在。但它从根本上改变了对话的方式。在这个术语出现之前，工程师们很难解释为什么看似无害的捷径最终会变得代价高昂。将其称为技术债，为商业领袖提供了一种他们早已理解的语言。债务会产生利息。债务伴随着风险。债务需要引起重视。
这是一个绝妙的比喻。这个比喻并没有消除技术债，但它改变了组织对技术债的思考方式。如今，没有任何一家严肃的工程组织会质疑技术债是否存在。对话的重点已经从这是一个真实的问题吗？转变为我们应该如何应对它？这就是语言的力量。今天，我们的行业面临着另一个同样普遍的问题。
开发人员整天都在与缓慢的构建系统、脆弱的内部框架、不可靠的工具链、不必要的流程、无休止的上下文切换以及组织摩擦作斗争。这些因素中的每一个都在悄然削弱组织构建优秀软件的能力，然而我们很少将它们作为战略性的业务问题来讨论。对此，我们有一个名称。
开发者体验。
而我认为我们选错了名称。这并不是因为底层理念有误，而是因为这个名字未能传达出真正利害攸关的内容。
错误的对话方向
乍一看，开发者体验似乎是一个完全合理的名称。毕竟，没有人质疑客户体验的重要性。整个组织的建立都是围绕改善客户体验展开的。
那么，为什么开发者体验没有产生同样的影响呢？我认为答案出奇地简单。客户体验与业务绩效之间的关系是显而易见的。满意的客户会购买产品、保持忠诚并向他人推荐。高管们本能地理解为什么客户体验值得投资。而开发者体验与工程绩效之间的关系则远不那么明显。
当高管们听到开发者体验时，许多人会下意识地将其归类为一种内部生活质量提升计划。一种在更重要的业务优先事项得到解决后，锦上添花的改进措施。
具有讽刺意味的是，这些高管同样深切关注工程绩效。当昂贵的工程团队交付缓慢时，他们会担忧。当质量下降时，他们会担忧。当创新停滞时，他们会担忧。他们只是没有自然地将这些结果与我们目前所称的开发者体验联系起来。这就是问题所在。这个名称掩盖了真实的业务影响。
因此，关于开发者生产力的对话往往朝着不健康的方向漂移。我们没有询问如何构建一个让工程师能够持续发挥最佳水平的环境，而是提出了如下问题：
- 我们如何衡量开发人员？
- 我们如何增加产出？
- 我们如何发布更多功能？
- 人工智能如何让开发人员更快？
这些问题都假设绩效是从人们身上提取出来的东西。我认为这是本末倒置。
绩效是一种涌现属性
想象一支精英运动队。没有人期望世界级的运动员仅仅因为拥有更好的鞋子就能赢得冠军。高绩效组织会在整个系统上进行投资：
- 教练指导
- 训练
- 营养
- 恢复
- 医疗护理
- 运动心理学
- 团队动态
- 装备
- 领导力
- 目标使命
没有人相信任何单
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
