那份自动汇总我们缓了，但没写什么时候再看

做仓储系统时，操作员和运营的反馈攒到一起，每一版总有一批得往后放。“这一版先不做”可以说得很明确。但它只说明眼前的安排，没说下一次讨论要等什么。后面只剩一条躺在需求池里的标题，时间久了，很难分辨这是已经不需要了，还是仍然需要、只是一直没有合适的机会。两种情况都安静，含义相差很大。

一条真缓过的需求

拿一条刚缓过的需求来说：运营希望增加一份定期自动汇总，现在可以手工导出数据再整理。暂缓的理由如果是整理频率低、现有办法负担尚可，那么值得重评的变化就是使用频率增加，或者人工整理开始占用明显更多时间。反过来，暂缓如果是因为数据定义还没统一，只看处理量变大就决定开做，原来的障碍其实没有消失。

那份汇总，要的是出入库量。手工导出一次，只要几分钟。

几分钟，听起来确实撑得住，这也是我们缓下来的主要理由。可几分钟只是导出那一下。导出以后要整理成运营要的样子，要按固定的周期做，做的人还得记着去做。单次几分钟，放进每个周期里，放进一个人一直记着这件事的负担里，就不只是几分钟了。

我不是说当时缓错了。几分钟的导出，确实不值得马上排开发。只是写暂缓理由时，写了导出只要几分钟，没写整理和记着的那部分。以后重评，如果只看导出耗时有没有变长，可能永远等不到变化，因为会变的是另外那部分。

暂缓至少有几种不同的前提。问题确实存在，但当前影响有限；影响不小，只是还不知道方案能不能解决；价值和方案都清楚，只是这一轮没有资源。它们不该都靠“以后有空再做”来解释。缺证据的需求，即使腾出了人，也未必该立刻开发；缺资源的需求，也不需要每次回来都重新证明它有价值。

写重评条件之前，先要说清楚这次不做依赖什么判断。所谓“现有办法够用”，是有人能够完成，还是能够持续完成而不挤占其他必要工作？暂时能做出来和长期承受得住，中间有距离。这个判断只是估计，就该保留估计的性质，不能过一阵子被当成已经验证的结论。

自动汇总暂缓了，手工整理仍然要人做。把这一点省略，暂缓在计划里就像没有成本。我不认为所有手工工作都该马上自动化，有些任务确实不值得投入开发。但决定保留手工方式时，至少得知道工作由谁承担、需要什么资料、出现差异时能找谁确认。不能只在方案对比里写一句“可人工替代”，就把后面的劳动算成免费。

出入库量这类数据还有个特点：量本身会跟着业务变。旺季出入库多，同样是几分钟的导出，要整理的量就不一样。重评条件里把旺季写进去，可能比写一个固定的耗时更实在。

重评条件不一定都能写成一个数字。频率和耗时可以观察，业务规则改变、依赖系统调整、原有替代办法不再可用，同样可能推翻暂缓的理由。我更愿意把这些变化和原理由对应起来，而不是凭空定一个显得客观的门槛。没有基础记录时，写得很精确也只是一种猜测。

条件写得太宽也没有用。“有新反馈再看”几乎等于没有约定。有人再问一次算不算新反馈？同一处不方便被不同的人提起，是否说明影响扩大？需要区分重复表达和情况变化。重复表达不该被轻视，它可能提醒原来的判断漏了什么；但也不能自动用催促次数替代业务影响。

我更希望约定一种能带回信息的方式。在这份汇总需求里，重评时可以带回近期整理的范围、哪些步骤仍需人工、原先的耗时估计是否成立。它不必变成一份很重的申请材料，更不该让提出问题的人独自负责收齐证据。产品侧既然作了暂缓判断，也要知道该向谁了解后续变化，不能把再次发起讨论的成本全交出去。

有人负责留意，比一句“我们会持续关注”具体。不过这也要有限度。不是每条低优先级需求都该安排专人每周检查，否则维护需求池本身就成了很大的工作。有些可以跟着常规版本规划再看，有些需要业务条件变化时提醒，有些信息不足，值得约一次补充沟通。观察的投入，和问题的重要程度相称。

说实话，每条暂缓的需求都写重评条件，我自己也未必坚持得了。需求池里的条目很多，每条都认真写原理由和重评条件，写需求的时间会明显变长。更现实的做法，大概是重要的认真写，其余的偶尔写上几句，至少写清楚当时缓下来靠的是哪个判断。

最容易引起误解的，是把重评时间说成了交付时间。约定下次版本规划时再讨论，只是承诺到时不让问题凭空消失，不代表已经答应排进那个版本。这两件事应当直接分开说。重评之后仍可能不做，但需要根据新信息解释，而不是复制上一次的理由。

也要允许需求不再回来。仍以这份汇总为例，业务改了流程，那份汇总已经没有使用者，原来的需求就可以明确结束；新的办法已经覆盖目标，也没必要为了兑现旧标题再补一个功能。留下重评条件不是给每个想法一个最终上线的保证，而是让暂缓有机会变成继续、调整或者关闭中的一种。

暂时不做当然要解释清楚，却不必把解释写成一份证明自己正确的文件。我更希望它能帮下一次讨论省一点力：原来的问题还在不在，原来的替代方式还撑不撑得住，哪条理由已经变了。等这些有了新的答案，再决定要不要做，比让一条需求一直挂着“后续考虑”诚实。