两个项目挤在一起时，我怎么做排期决策

两个项目挤在一起时，我怎么做排期决策

去年有一段时间，我在同时维护语言学习App和一个AI写作工具。两个产品都在增长期，但团队只有我和一个兼职开发。每周三早上，我们都会面对一个熟悉的难题：两边都有紧急需求，该先做哪个？

最初我试过各种项目管理工具：看板、甘特图、时间块。但工具只能记录，不能替我判断。排期冲突的本质不是时间不够，而是选择不清——你不敢对任何一个项目说“不”。

资源冲突的真正原因

小团队的多项目冲突，往往不是因为工作量超过了产能，而是因为三个隐含问题：

• 项目之间的依赖没有被显式标注。比如AI写作工具需要一个新API，而那个API的改动会影响语言学习App的语法解析模块。
• 每个项目的“紧急”是来自不同人的主观判断。客户说急、合伙人说急、自己觉得也急，但没有人把它们放到同一把尺子上量。
• 我们没有区分“必须现在做”和“最好现在做”。很多紧急需求其实是“最好现在做”，拖一周并不会死。

一个简单的排期决策框架

后来我设计了一个三点评估法，每次遇到冲突时，把两个项目的需求分别打三个分：

1. 存续性影响（1-5分）：不做这个需求，项目在未来一个月内是否会遇到可量化的风险？比如用户流失、收入下降、关键依赖断裂。这不问“会不会更好”，只问“会不会变差”。
2. 窗口敏感性（1-5分）：这个需求有明确的时间窗口吗？比如苹果审核规则变更必须在下周四前适配，或者竞争对手新功能上线前必须跟进。窗口一旦错过，价值可能归零。
3. 资源独占性（1-5分）：做这个需求需要完全占用某一特定资源吗？比如只有兼职开发能写这个模块，或者需要我亲自部署服务器。如果资源可替代，分数降低。

然后取两个需求的总分，优先做总分高的。如果总分相近，再看资源独占性更低的那个——因为它可以片段式完成，穿插在其他任务里。

这个框架听起来太简单了？对，但它的价值不在数字，而在迫使你把“为什么这个更重要”写下来。每次打分时，你都会发现原来自己之前只是在凭直觉说“这个急”。

一个真实的失败假设

假设我按上述框架给两个项目打分：

• 项目A（语言学习）：存续性4（新赛季活动不发布，月活跃会掉10%），窗口5（活动必须下周一上线），资源独占2（前端可以找替换）。总分11。
• 项目B（AI写作）：存续性2（只是界面优化，不做用户也能用），窗口1（没有时效性），资源独占4（必须兼职开发写，他正好有空）。总分7。

显然应该先做A。但如果我只看资源独占性，可能会让兼职开发先做B，因为“他正好有空”。实际上一旦B占用了他的时间，A就到临期才匆忙赶工，质量下降还错过了窗口。

这个案例是假设的，但类似的场景我在很多小团队里见过。关键点是：资源是否空闲，不应该决定优先级；优先级应该由目标和风险决定，然后安排资源。

执行中的边界与调整

三点评估法不能解决所有问题，它有三个明显弱点：

• 分数带有主观性，不同人打分可能差很多。初期可以由同一个人（比如我）统一打分，减少方差。
• 它假设需求之间独立，但实际项目可能有依赖关系。这时候需要先画出依赖图，把有依赖的需求捆绑成一个“需求包”再打分。
• 它没有考虑长期战略权重。如果一个项目是探索性的（比如新方向），存续性可能很低，但战略价值高。这时我会额外加一个“战略乘数”因子，最多乘以1.5。

另外，每个季度我会做一次复盘，把过去三个月里做过的排期决策和结果对比，看哪些打分偏差大。比如曾经把“存续性”打高了但实际没影响，下次就调整自己的判断尺度。

写在最后

资源冲突是小团队的常态。你不是缺时间，你是缺一个说“不”的方法。三点评估法不是万能药，但它给了我一个可以讨论、可以复盘、可以修正的决策起点。如果你也在几个项目间挣扎，不妨试试下周的冲突会议，不先看工具，先拿出笔给每个需求打三个分。然后你会知道自己真正该做什么。

PaxLee