商业价值是 IT 部门衡量进步的主要指标

我们的首要任务是通过尽早持续交付有价值的软件来满足客户的需求。
— “敏捷宣言背后的12项原则”

在我职业生涯的早期，衡量我的 IT 项目成功与否的标准是按时、在预算范围内交付、质量足够好。“足够” 通常意味着根据各种标准分类的数百个错误仍然悬而未决。我甚至不想考虑负载和性能测试。工作软件是衡量进步的主要标准。这已经够困难了！

当时，基本假设是规格将满足客户需求并为公司创造附加价值。没有人真正问过公司及其客户的实际结果或收益；如果有人问我，我就无法回答。我们没有衡量这些价值——我们甚至没有能力这样做。

这已经改变了。作为一个行业，IT至少在十年前就解决了工作软件的问题。在许多情况下，各行各业的公司，尤其是数字原生企业，都有能力衡量其 IT 计划的成果和业务价值。他们利用这些知识在战略和战术上设计产品路线图并相应地交付。

衡量我的组织发布的版本创造了什么价值（如果有的话），对我来说有很大的不同。这种能力帮助我们以不同的方式指定需求。实际上，我们不再是具体说明，而是在快速的构建-测量-学习周期中进行实验。这种快速的学习使我们能够更好地满足客户需求。我们能够证明，基本业务指标因我们的活动而发生了变化。

当我们为公司的成功做出了显著贡献时，我的组织突然被视为利润中心而不是成本中心——一个不仅提供功能而且提供实际业务价值的利润中心。因此，对我的组织进行了投资，人才可用性成为我最大的问题。我必须继续优化成本，尤其是在运营方面，但是为新产品开发团队提供资金已不再是大问题。

我已经在谈判桌上赢得了一席之地，不再被视为（平庸的）供应商，而是业务创新的重要推动力。

衡量IT计划和组织进展的主要标准是它提供的业务价值。

你如何衡量商业价值？使用客户趣闻支持的业务关键绩效指标 (KPI)，而不是您发布的功能数量。但是对于许多组织来说，确定其IT计划（或任何计划）的价值并不容易。

你是怎么做的？

1。在业务和 IT 之间联手

许多组织将 IT 视为外部服务提供商并将其视为外部服务提供商，使其与企业和客户保持距离。有时，IT 组织通过表现得像外部服务提供商来强化这种看法。当 IT 组织将其大部分应用程序外包并充当 IT 采购和协调部门时，通常会出现这种情况。

如果你想改变这种误解，可以引入跨职能团队和部门，这些团队和部门包含满足客户需求所需的所有角色。为这些团队提供共同的价值观、原则和目标。最后，重新考虑您的外包策略，将由业务价值和变更频率决定的与业务相关的应用程序进行内包。

2。从考虑关键绩效指标开始

关键绩效指标使客户行为和反馈切实可见。每当你想为客户开发一些东西时，都要问问自己：

• 好看是什么样子？
• 我们怎么知道它真的很不错？
• 哪个 KPI 需要朝着正确的方向改变？

在你开始考虑解决方案之前就定义这些内容。这样的关键绩效指标可能是贵组织所有努力的战略北极星。

3。实现分析访问权限的民主化

这种方法的支柱是让合并后的IT/业务产品开发组织中的每个人都可以使用分析功能。尝试从您当前的分析基础架构中生成正确的问题和答案。然后利用这种经验以渐进的方式调整基础架构。只有当你遇到根本的结构性问题时，才能启动一个建造新的革命性基础设施的项目。

也要投资于你的员工。您的团队应具备超过平均值和总和的基本统计知识，包括百分位数、分布、同期群和中位数。正确读取、分析和可视化数据的能力很重要，电子表格和可用商业智能工具的高级知识也很重要。组织通常会购买很棒的工具，但只使用其一小部分功能。

4。将 A/B 测试作为标准程序

很难知道某项更改、功能或服务是否会对您的客户产生影响。影响你的 KPI 的因素有很多：天气、季节、品种等。我在职业生涯中发现的最好、最可行的方法之一是对所有变体进行 A/B 测试。

A/B 测试是一种方法，通过这种方法，您可以同时向用户展示软件的不同版本。在实验期间，每个用户只能看到该功能的一个版本。这创建了两个群组，您可以就相关的关键数据进行很好的比较。例如，电子商务网站上产品搜索的变化会带来更多还是更少的销售额？A/B 测试允许在功能之间进行直接比较。从技术、文化和流程的角度投资您的 A/B 测试能力。

如果你能衡量你的IT项目和版本的成功，那么下一步就是使用小型、独立和可衡量的实验和版本来确定路线图的优先顺序。— 马蒂亚斯