小团队先定时间预算，再谈需求范围

最近和朋友聊起一个小团队的状态：三个人，产品还在早期，需求列表长得像购物车。每个人都觉得自己手里的需求是关键的，最后什么都想做，什么都没做完。

这不是优先级排序的问题。排序解决的是“先做哪个”，但小团队真正缺的，是“这个阶段总共能投入多少时间”。没有时间预算，排序只是把焦虑从左移到右。

为什么先谈时间预算

我以前也犯过这个错。接到一个需求，先想它的功能范围，再估算需要多久。结果每次估完都觉得时间不够，然后压缩功能，最后做出来一个谁都说不满意的版本。

后来我换了个顺序：先看这个迭代或这一周，团队总共能腾出多少小时。再把这些时间分给少数几个目标。最后才是需求的具体范围——在固定时间内，能做到什么程度就做什么程度。

这个顺序背后的逻辑很简单：时间是硬约束，需求是弹性约束。在硬约束下做弹性决策，比在弹性约束下幻想硬时间要现实得多。

具体做法可以分成四步。

第一步，算出可用时间。别用“每天八小时”这种理想值。要扣掉会议、沟通、上下文切换、修bug、回复用户消息的时间。一个小团队，真正能用在开发上的时间，往往只有名义工时的50%到60%。

第二步，给时间分桶。不要只分“开发”和“非开发”。可以分得更细一点：新功能开发、修复线上问题、技术债清理、运营支持。每个桶给一个上限。比如这周新功能开发不超过20小时，修bug不超过5小时。

第三步，用预算约束需求。一个新需求进来，先问的不是“要不要做”，而是“这周还有多少时间在‘新功能’桶里”。如果已经用完了，那就只能下下周再说。这比靠意志力拒绝需求要可靠得多。

第四步，留出缓冲。永远不要把一个迭代排满。至少留出20%的时间给意外——紧急修复、用户突然反馈的问题、某个库突然不兼容了。没有缓冲的计划，本质上是运气计划。

有了预算之后，范围决策就变成了一道算术题。

比如这周新功能预算是15小时，一个需求预估要20小时。这时候你有几个选择：砍掉一半范围，做核心场景；或者花10小时做更简单但能满足60%用户需求的版本；或者直接不做。

关键是，这些决策都不是从“需求有多重要”出发，而是从“时间够不够”出发。需求的重要性用来决定优先级，时间预算用来决定范围。两者结合，才是一个可执行的计划。

举个例子（这是示例，不是真实经历）：一个小团队做一个AI写作工具，计划一周内上一个“改写语气”的功能。理想情况是想支持正式、轻松、幽默三种语气。但估算下来，三种语气需要24小时开发。而这一周新功能预算只有16小时。

那就不做“幽默”——这个场景占比最低，而且模型输出的稳定性最差。先上“正式”和“轻松”两种，16小时内完成。剩下的“幽默”放在下一迭代，如果用户反馈强烈再补上。

这个决定不难做，但前提是先有预算意识。否则团队很可能硬撑着做三种语气，结果每一种都做得不完整。

即使有了预算，还是可能超支。这时候不要立刻追加时间，而是回到预算表，看哪个桶可以挪。比如这个迭代的技术债清理可以推迟，那就把那个桶的时间挪过来。

但如果所有桶都满了，那只能砍范围。砍的时候，优先砍掉那些“以后可以补”的部分，而不是砍掉核心体验。比如一个设置页面的视觉细节，比一个核心交互的流畅度更容易砍。

小团队不缺想法，缺的是对自己时间使用的诚实。先定时间预算，再谈需求范围，是一种把“我们想做什么”变成“我们能做什么”的方式。

它不解决所有问题，但它能让你在每个迭代结束时，至少能拿出一两个做完整的东西，而不是一堆做了一半的残次品。

PaxLee