生产环境让规则变得具体

客户说，法规没有覆盖全

功能上线以后，客户陆续遇到了一些情况。他们看着结果，觉得哪里不对，最后把问题归到了法规上：系统没有把要求算完整，可能要重新计算。

这句话分量不轻。如果法规真的漏了，后面讨论什么体验优化都没有意义。但如果计算本来就是对的，贸然改公式，反而会把一套合规逻辑改出问题。

客户后来发来了 39 个使用场景。与其继续争论“到底有没有覆盖”，不如把这 39 个场景一个个摊开看。

我逐条对照法规、现有规则和客户期望的结果。每个场景都问同样几件事：法规在这里要求什么，系统现在做了什么，客户为什么仍然觉得这件事没有完成。

看到后面，规律慢慢清楚了。现有计算没有漏项，法规要求已经被严格覆盖。真正反复出现的，是法规要求的一份文档，以及和这份文档有关的日期。

但这并不意味着客户应该亲自追踪那个日期。把这件事画成 RACI 以后，责任边界很清楚：实际处理文档的一方是 R，客户是 A。客户需要为结果负责、确认要求得到满足，却不应该接手原本不属于他们的追踪工作。

问题也因此换了位置。计算层面已经合规，责任划分也没有改变；产品缺少的是一层可见性，让承担 A 的客户能够看见文档及其日期是否已经被正确处理，而不是靠系统外的消息和人工确认去拼出状态。

如果沿着最初的说法直接修改计算，团队会动到一套本来正确的法规逻辑，同时仍然没有解决客户为什么觉得事情没有完成。

新的方案保留现有计算，在产品里补上文档日期的追踪与呈现。日期由系统承接，不是把一项新的手工任务交给客户。客户仍然是 A：需要知道要求是否已经落实，但不必为了获得这个答案，去代替 R 完成记录和追踪。

这不是法规修正，而是产品优化。法规告诉系统最低限度必须满足什么；产品还要考虑，不同责任的人怎样在不越过边界的情况下完成自己的工作。

这次怎么判断

完成分析以后，我和客户重新过了一遍结论。我们没有停在“系统已经合规”，而是站到客户的工作里继续问：如果产品能够追踪这个日期，他们实际会少做什么？

答案不是少维护一个字段。日期追踪本来就不属于客户的执行责任，但这个日期会直接影响他们何时需要安排人员、需要安排多少人。产品把日期变得可靠可见，客户就不必再用额外的组织协调去弥补信息缺口，也能减少由此产生的人员成本。

客户因此确认，需要的不是另一套计算，也不是把日期维护工作接到自己手里，而是把日期作为人员分配的依据。PO 随后批准进入研发。

到这里，分析和产品决策都已完成。需求下一步进入团队统一的优先级排序。

客户最初说“法规没有覆盖全”，是在描述一种真实的不便：系统给出了合规结果，却没有提供足够的信息，帮助他们以 A 的身份安排后续所需的人员。

这次分析没有为了证明系统合规而否定客户的不便，也没有为了回应不便去修改正确的计算。39 个场景和一张 RACI 把问题重新放回了正确的位置。

法规已经算对，但一个好用的产品并不能满足于“合规而已”。