- 必须定义流程指标
- 必须捕获针对流程指标的实际绩效
- 定义标准指标绩效后，必须将当前绩效与标准进行比较
- 需要定义异常
- 需要设置警报以在发生异常时发出通知
- 需要将学习纳入流程改进
对于系统工程师、业务分析师和产品所有者来说，需求可追溯性（将需求追溯到下游开发、测试、验证、确认和风险活动的能力）是毋庸置疑的好事，也是毋庸置疑的需求。可追溯性是证明符合医疗设备、汽车、半导体、航空航天和金融服务等行业的相关标准所必需的。除了合规性要求外，可追溯性对于评估所需变更对所有相关要求和相关下游活动的影响也非常有帮助。但许多组织都错过了最大的潜在价值。
事后用例
上述可追溯性的两个主要用例都是对请求做出反应：需要向第三方证明标准合规性，以及需要分析变更请求的影响。这两个用例都将需求视为静态和被动的。需求被记录下来，并创建与软件、硬件和电气开发测试和风险评估中的下游工件的链接 – 存储在系统中。然后，系统等待外部请求，以记录已遵循流程或确定哪些元素受到变更的影响。这两个用例都反映了事后心态，这限制了从建立可追溯性的努力中可以获得的价值。
与其他业务关键功能的类比
要从新的角度看待我们自认为很了解的事物，将其置于不同的环境中并从新的角度看待它通常会有所帮助。所以，让我们尝试将产品开发过程中的可追溯性与新客户获取过程中的可追溯性进行比较。
对于工程师来说，这些流程乍一看似乎太过不同，无法进行恰当的类比，但从根本上讲，它们非常相似。两者都以记录的价值（需求与机会）开始，必须经过多个阶段并涉及许多其他功能才能达到预期结果（发布与赢得）——并且在此过程中可能会出现各种问题，从而导致延迟、成本增加和失败。
我想关注的方面是如何管理这两个流程。在销售过程中，价值要素（机会）是活生生的——每天都会积极衡量、分析和跟踪异常情况。关键流程指标定义为可接受的性能范围。根据所有机会在各个阶段的移动情况，自动计算当前流程绩效。如果机会停留在流程阶段的时间过长（相对于平均停留时间），则会发出警报，并根据系统中的机会预测未来期间的绩效。
相比之下，对于大多数产品开发组织而言，需求可追溯性是静态的，并且是在事后分析中，而不是以上述销售中的机会追踪方式进行。要使需求可追溯性变得生动（就像销售机会一样），可追溯性需要在以下领域采用软件支持的最佳实践：
一旦采取这些步骤来改进需求可追溯性，那么需求就会变得生动，而不是静态的，并且可以改进绩效：降低负面产品结果的风险，并提高流程绩效；产品开发流程可以像所有其他业务关键流程一样由数据驱动、衡量和管理。没有衡量，就无法与其他组织进行绩效对比。没有学习、了解和改进的方法。
最好还是蒙在鼓里？
有些人可能更愿意让产品开发过程保持神秘，避免数据驱动的分析、测量和流程绩效改进。过去，首席营收官 (CRO) 也有同样的感受。很难找到有这种心态的现任 CRO。那些能够通过数据引领并推动绩效改进的人会获得领导层的支持并提升他们的职业生涯。现在，产品领导层也面临着同样的机会，可以将需求可追溯性转化为生活需求，以降低负面产品结果的风险并提高端到端产品开发流程的绩效。
