正如我们在Healthcare.gov上的朋友们维修，更新和维护医疗保健市场一样，他们似乎在跟踪数百个标准指标，例如申请人数量，注册人数，缺陷数量，系统停机时间，系统错误率和响应时间。

这些指标很重要，并且可以很好地反映系统的当前状态。这些指标的趋势线可能会帮助您进行系统故障排除或系统风险管理策略。

但是，这些以系统为中心的指标无法提供改进项目管理或业务分析流程的见识。它们无法帮助您评估BA角色的价值或跟踪利益相关者的满意度。

尽管您可能未参与所有BAs的Healthcare.gov等复杂的，备受瞩目的项目，但仍需要评估和改进其流程。以下三个指标可帮助BA评估其有效性，价值和效率：

1）缺陷层

您能否想象诸如Healthcare.gov之类的系统的缺陷日志的大小？

随着时间的流逝，大多数大型系统都会形成缺陷层。一个有10个缺陷的项目上线了。这些缺陷的修复导致更多缺陷，依此类推。缺陷和遗漏的需求问题有多少层？

与组织和广管局合作时，我通过询问 “这项工作源自什么？” 对于每个项目/增强/错误修复。我经常听到以下情况之一：

• “这是另一项无法正常工作的增强功能。”
• “这是上个月上线的项目的新要求。”
• “这修复了去年上线的项目中的一个缺陷。”
• “这解决了我们误解的另一个缺陷带来的问题。”

然后我再问一次 “这项工作源自什么？” 我得到相同的答复。在许多情况下，我会多次问这个问题，并且发现每个项目下隐藏的缺陷层超过五层。

我发现许多组织将80％的时间和金钱花在本质上是返工的项目上，这些特性和功能源于遗漏的需求，被误解的需求，未正确测试的需求等。

这项永无止境的维护工作表明需求流程中的薄弱环节。返工浪费了本可以用于创新和战略能力的资源。

跟踪缺陷层或完成修复损坏或遗漏的工作所占的百分比将有助于组织评估其BA甚至测试过程的运行状况。广管局应使用此指标来确定如何“在第一时间做到正确”并释放资源，这将为利益相关者提供更多战略价值。

与该指标之间的平衡是，如果您期望返工是由于敏捷方法引起的，那么返工实际上就是学习和发现，并且是流程的一部分。在这种情况下，应从指标中删除这些项目的返工。

2）商业赞助商成功项目的百分比

成功的定义因项目而异。当我想到Healthcare.gov时，我可以想象成功的许多不同定义：

• 项目团队：“系统将在预算内按时交付。”
• 消费者：“我希望该系统像医疗保健的amazon.com。”
• 民主党领导人：“我希望该制度能帮助我们确保担任总统8年以上。”
• 共和党领导人：“我希望该系统惨败，以帮助我们确保房屋，参议院和总统职位的安全。”
• 媒体：“我希望系统引起争议，因此我有消息可以填补我的24小时周期。”
• 已经拥有良好医疗保险的人们：“什么系统？”

广管局需要从多个角度考虑成功的定义。但是谁的观点最重要？

当我问PMO办公室的负责人，他们的项目成功的百分比是多少时，他们通常会回答80-90％。当我问业务发起人相同的问题时，我一次又一次听到，他们的项目中只有20％到30％是成功的。是不是很有趣？

PMO：我们项目的80％-90％成功
商业赞助商：我们项目的20％-30％成功

那么，我问他们如何衡量呢？

• PMO通常按成本和进度来衡量
• 商业赞助商的衡量标准是：“我是否根据所支付的钱获得了期望的价值？”或“该项目值得做–我的生活会更好吗？”

广管局的主要工作是识别和保护赞助商的价值主张，因此成功指标需要由赞助商对价值的感知来驱动。这对要求和BA角色至关重要。

在许多情况下，广管局需要留出时间和预算，并根据价值开展工作。

在某些情况下，价值会与时间和预算相抵触（啊，是的，healthcare.gov！）。当您认识到这种冲突时，您需要与PM和/或赞助商就您的担忧进行合作。

广管局如何提高成功率？

• 了解赞助商最看重的结果以及原因。
• 在发起人的期望与项目团队的期望之间寻找不一致之处？
• 确定如何防止不一致。
• 确定如何提前获取价值-尽快提供赞助商价值。

3）过于细化而导致的返工

好。我再次将您拖到Healthcare.gov。我无法开始想象分析师在这种环境中开始提出需求时所承受的压力！我只能假设中小型企业的资源非常有限，并且紧迫的期限导致广管局选择了一条路径：所有细节还是没有细节。

根据我的经验，大多数从事复杂项目的分析师会直接从高级业务需求或范围文档跳到细节上。他们感到时间紧缺或无法获得足够的资源，因此他们会收集和记录尽可能多的详细信息，而不会导致利益相关者从整体上了解。

对细节的深入研究似乎是有效的，但是随着项目的进行，通常会导致大量的返工，并且难以管理：

• 您可能难以完成可交付成果，因为您仍需要在引出时重新编写。
• 当详细的要求没有与更高级别的功能或流程的联系时，可追溯性就会变得复杂并且会出现空白。
• 如果将设计详细信息添加到需求文档中，变更控制将成为噩梦。对需求文档进行基线设置后，设计将发生变化，每次更新都会给您带来变化控制的麻烦。

因此，问问自己：

• 我需要花费多少时间重写或更新需求？
• 我会因为在启发过程中学习到的新知识而重写吗？
• 我会因为功能增强和缺陷而重写吗？

然后，改善您的返工指标：

• 提前完成更高级的建模和要求。
• 非正式地捕获细节，但是在批准更高级别的模型之前，不要将其添加到正式的项目文档中。
• 避免管理可追溯性并更改到将要更改的详细程度（即屏幕设计）

优秀的BA知道如何通过从概念到细节的逐步启发过程来指导利益相关者。他们通过了解何时以及如何提供详细信息来管理返工和变更控制。

您发现哪些指标最有价值，为什么？

不要忘记在下面留下您的评论。