跨部门的数据需求，先定谁能插队

数据侧最常被抱怨的是「我上周提的需求还没做」。抱怨的人通常不知道自己排在第几位，也不知道前面有哪些需求。数据同事解释的时候也只能说「前面还有几个」，说不出具体是哪几个、什么时候能轮到。

这种状态持续下去，两边之间的信任会先崩。业务开始绕过数据侧自己取数，取出来的口径没人把关。

不排队的需求池，实际是嗓门排序

我们第一版需求管理是个共享文档，谁有需求就往上加一行。看起来是先到先得，实际执行的时候是谁催得急谁先做——因为数据同事每天在群里被 @，最吵的那个自然被处理掉。

催得急和需求重要是两回事。业务那边临时被上级问了一个数，会非常急，但那个数可能只用于一次汇报。另一边一个不急的需求是要给下季度选品定口径的，晚两周做会影响整季。

嗓门排序的代价是：重要但不紧急的需求永远排在后面，直到它变得紧急，然后挤掉别人。

四级优先级

四级优先级，每一级的插队权限不同

第一级，止血类。链接被下架、账号出问题、正在亏钱且金额在扩大。这一级不排队，来了就做，一天内出结果。

第二级，决策类。选品立项、砍 SKU、定备货量，有明确决策日期的需求。按决策日期倒排，决策日期越近越靠前。这一级占了池子里的大部分。

第三级，改进类。优化报表、补维度、改看板。这类没有硬截止，按季度批量处理。

第四级，好奇类。想看看某个数、想验证一个想法。这类进池子但不排期，每季度清一次，没被引用过的直接关掉。

插队名额要显式分配

插队完全禁止是不现实的，总会有临时需求。与其让它变成私人沟通的结果，不如把它变成明面上的配额。

配额用完之后的路径写清楚也很重要：要么等正常排期，要么升级到我这里批。没有这条，被拒绝的人会去找数据同事私下说。

需求单上必须填的两列

第一列是决策日期。这个需求做完之后，哪天要拿它做决定。填不出来的，一律归到第四级。

第二列是不做的后果。这一列要求写具体后果，不接受「影响效率」这类表述。「选品会推迟一周，错过旺季备货窗口」是合格的写法。

这两列的作用是把需求从「我想要」变成「我要用它做什么决定」。填完之后，池子里大概三成的需求会被提出人自己撤掉。

排期公开才有效

现在整个季度需求池对全公司可见，包括排在第几、预计什么时候开始、因为什么被插队。公开之后最大的变化是抱怨变少了。抱怨多数来自不知道排在第几位，少数才是真的等不起。

我们同步公开的数据还有一个：上一季度完成率和平均等待天数。完成率低于七成的时候，说明该加人了，或者该砍需求了，这个判断不能只靠感觉。