如何建立一份真正被使用的需求追溯矩阵
当一个项目结束、客户指着某项他们期待却从未收到的东西时，争议几乎总能追溯到同一个缺口：一条需求在早期被确认，随后却在范围变动、人员更替和决策堆积的过程中丢失。需求追溯就是这样一项功夫：为每条需求保留一条有据可查的线索，从它的来源，经过设计与建造，一直延伸到确认其已满足的那项测试。做得好，它是一份不起眼的保险；做得差，它就是一份没人打开的表格。
在2021年初，许多交付团队仍在远程办公、部分供应链尚不可预测，这条线索比平时更为重要。过去在走廊里就能定下的决定，如今散落在聊天记录和通话录音里；三月里悄悄被舍弃的一条需求，到九月可能演变成一场纠纷。下面这份矩阵正是务实的解药。
追溯矩阵的用途
需求追溯矩阵（RTM）是一张简单的表格，把每条需求与四样东西连接起来：它从何而来、解决方案的哪一部分满足它、将如何验证它，以及它当前的状态。其目的不是为了文档而文档，而是让你在任何时刻都能回答两个问题：每一条已批准的需求是否都有着落？是否正在建造任何没有需求要求的东西？
如何一步步建立
为每条需求赋予一个稳定的编号。 首先，给每条需求一个永不更改的唯一编号。有了编号，就能在设计文档、测试用例和变更请求中明确无误地引用某条需求，即使其措辞已被修改也不混淆。
记录来源。 写下需求的出处——工作说明书中的某一具体条款、某项法规，或某位相关方在某日提出的请求并附上姓名。来源让你日后能为一条需求辩护或将其撤销，而不是凭猜测。
向前连接到设计与建造。 对每条需求，注明满足它的交付物、组件或工作包。空缺暴露出无处落地的需求；而孤立项则暴露出背后没有任何需求支撑的工作。
连接到验证。 把每条需求与将证明其得到满足的测试用例、检查或验收核对挂钩。一条没有验证路径的需求，就是一句你无法证明自己兑现过的承诺。
跟踪状态与变更。 增设一个状态列（已提出、已批准、进行中、已验证、已延后），并将其与变更日志相连，使矩阵随范围一同变化——也让你清楚地看到究竟是什么发生了变动。
让它保持鲜活
大多数矩阵之所以失效，是因为它们只被建立一次，从不再核对。用几个习惯来避免这一点：把更新RTM作为每次变更请求的标准步骤，而非事后补救；在重大里程碑处对其复查，确认双向覆盖；并使其足够精简、便于阅读——一份聚焦要害的矩阵，胜过一份无人信任的详尽矩阵。在混合办公的团队里，指定唯一一名矩阵负责人，以免它在各人的本地副本之间被割裂。
回报出现在验收之时。你无需重新争论当初承诺了什么，而是带着客户逐行走过一张表：每条已批准的需求旁边，都有来源、有交付物、有一项通过的测试。对话便从记忆与印象，转向了证据。
如果你希望拥有一套交付框架，让需求从批准到验证始终可追溯，XNM的项目与项目群交付咨询服务可以帮你建立一套你的团队真正会去维护的体系。