开发周期管理指南：项目成员如何做好需求排期，入门指南全流程

2023 年我帮一个 6 人研发小组做迭代复盘，他们把过去 8 个迭代的排期表和实际交付记录摊在桌上，结果很难看：计划内完成的条目占比 41%，延期条目平均延期 4.7 天，其中 3 个迭代的最后三天有超过一半的人在做"计划外的事"。这不是一个团队的问题。后来我又陆续复盘了十几个团队、累计 60 多个迭代的排期数据，规律几乎一模一样，排期失效很少是因为"估错了某个功能"，而是因为在排期这件事开始之前，容量就已经被高估了，依赖就已经被忽略了，不确定性就已经被默认抹平了。

这篇指南讲的是"项目成员怎么做好需求排期"，不是讲项目经理怎么管控进度。视角不一样：项目成员的排期，本质是在有限时间里对"我承诺交付什么"做出可被检验的判断；项目经理的排期，是在多个承诺之间做资源调配。前者做不好，后者怎么调都是拆东墙补西墙。下面我按"结论，场景，误区，判断逻辑，案例，建议，取舍"的顺序，把这套方法完整拆开。

一、先给结论：排期的本质是"承诺可交付的时间边界"

很多人把排期理解成"把需求分给谁、什么时候做完"。这个理解少了最关键的一半：排期真正在做的，是把一堆不确定的工作，转换成一条可以被别人依赖的时间线。一旦你说"这个需求 3 月 14 号能提测"，测试同学就会在那天开始排人力，运营就会在那天开始准备发布物料。你的排期不是给自己看的，是给别人当输入用的。

所以判断一个排期做得好不好，不看它"看起来是否合理"，而看两个指标：偏差率（实际完成时间与承诺时间的偏离程度）和可预测性（偏差是否稳定可预期）。一个总是延期 20% 但非常稳定的排期，价值远高于一个平均准时、但偶尔延期 200% 的排期，因为稳定的偏差可以被下游提前补偿，随机的偏差只能靠堆缓冲来兜底。

1. 结论一：先算容量，再谈需求，顺序不能反

我见过最多的错误动作，是拿到需求列表之后开始"估时",然后把人填满。正确的方向是反的：先算出这个迭代真正可用的工时池，再决定往里放多少需求。听起来是常识，但真正执行时，绝大多数团队的可用容量都被高估了 30% 以上。

原因很简单：名义容量 = 人数 × 工作日 × 每天小时数，这个算法把会议、答疑、线上问题、代码评审、环境故障、请假全部当成"不存在"。真实的可用容量至少要从名义容量里扣掉四层：

• 协作损耗：站会、评审、跨团队对齐，通常占 10%-15%；
• 支持性工作：线上问题、数据排查、临时需求，占 10%-20%，越是核心系统越高；
• 非工作日：年假、调休、法定假日，按人均年 15 天折算约 6%；
• 上下文切换损耗：同一个人同时推进 3 个以上需求时，切换成本会让有效产出再掉 15%-25%。

这四层扣完，一个"5 人 × 10 个工作日 × 8 小时 = 400 小时"的迭代，真实可用容量通常在 230-270 小时之间。如果你按 400 小时排需求，第一天就已经超载了 50%。

2. 结论二：缓冲不是浪费，是排期的一部分

把缓冲从排期里拿掉，是"看起来很专业"的做法：每个任务都精确到 0.5 天，加起来正好填满迭代，图表严丝合缝。但这种排期在数学上等价于"假设所有任务都不出错"，而现实中不出错才是小概率事件。

我的经验值是：单个迭代的整体缓冲控制在 15%-20%，不要给每个任务单独加缓冲。任务级缓冲会被"帕金森定律"吃掉，你给一个 1 天的任务加 0.3 天缓冲，做的人就会把工作撑满这 1.3 天。而迭代级缓冲是团队共享的，只在真正出问题时才动用，消耗速度是可观察的。

判断缓冲够不够，有个简单的观察方法：看迭代第 5 个工作日结束时，缓冲还剩多少。如果两周迭代跑到一半缓冲已经消耗 70%，说明前期的估算或拆解存在系统性问题，这时候应该立即减范围，而不是等到最后三天集体加班。

3. 结论三：排期的对象是"约束"，不是"人"

初学者的排期表长这样：张三做 A，李四做 B，王五做 C。这张表的问题在于，它假设人是可替换的、任务是可并行的、依赖是不存在的。真实的排期表应该长这样：A 卡在接口联调，接口依赖 B 团队 3 月 8 号交付；C 需要等 A 的数据库变更上线；D 可以和 A 并行但共用同一套测试环境。

排期真正的难点从来不是"时间不够"，而是"顺序不对"。同样的人力和时间，先做被依赖的东西和先做没人依赖的东西，最终交付日期可能差出一周以上。这也是为什么很多团队明明很忙，却总在迭代末期才发现"关键的联调还没开始"。

二、背景和真实场景：一个两周迭代是怎么被填满的

要理解排期为什么失效，得先看清楚一个迭代里的时间到底去了哪里。我在几个团队做过同一件事：让每位成员连续两周、以 2 小时为粒度记录自己的时间去向，然后按类别归并。结果高度一致，也和大多数人的主观感受完全不同。

1. 时间去向的真实分布

在一个典型的 6 人产品研发团队里，两周迭代的时间分布大致是这样的：计划内功能开发占 42%，缺陷修复占 18%，跨团队沟通与对齐占 14%，技术债与环境问题占 11%，需求变更与临时插入占 9%，纯等待（等评审、等环境、等接口）占 6%。

注意两个数字。第一，缺陷修复吃掉近五分之一的时间，但绝大多数排期表里根本没有这一项，因为它"不确定什么时候出现"。第二，纯等待占 6%，这部分时间在工时系统里会显示为" занят"，但对交付毫无贡献，它不是人的问题，是排期顺序和依赖管理的问题。

如果把这份时间分布和排期表对照，会发现一个很尖锐的事实：排期表只覆盖了 42% 的实际时间。剩下 58% 的工作不是不重要，而是从来没有被正式承认过存在。

2. 三种团队形态，排期的痛点完全不同

我把接触过的团队粗略分成三类，它们的排期问题不在同一个层面上，用同一套方法去解会错位。

这三类的差别不是"熟练度"，而是约束的位置不同。救火型的约束在"输入不受控"，成长型的约束在"过程不可见"，规模型的约束在"协同成本指数级上升"。很多团队学了一套精细排期方法却用不上，就是因为解决的不是自己那层约束。

3. 一个具体的失效过程

我跟踪过一个很典型的两周迭代，从排期到交付的完整过程：

1. 第 1 天：排期会上放入 11 个需求，总估算 260 人时，可用容量 240 人时，主持人说"努力一下能完成"。
2. 第 3 天：临时插入一个"客户紧急问题"，占用 2 人 1.5 天，没有任何需求被移出。
3. 第 5 天：A 需求的接口依赖对方团队，对方说"下周才能给"，A 的负责人开始做 B，形成并行。
4. 第 7 天：缓冲已消耗 80%，团队决定"后期加班补回来"。

5. 第 9 天：测试环境被另一个项目占用两天，联调全部延后。

6. 第 10 天：交付 6 个需求，4 个延期，1 个质量不达标回滚。

整个过程没有一个人偷懒，也没有一个明显的重大失误。失效是从第 1 天那个 260 对 240 的数字开始的，后面每一步都只是把这个初始误差放大。这也是我想强调的判断：排期的质量在会议结束那一刻就已经决定了大半，后面的"过程管控"只能减缓恶化，不能扭转。

三、拆解四个常见误区

下面这四个误区，我在几乎每个排期出问题的团队里都能看到至少两个。它们的共同点是：看起来非常合理，甚至符合直觉，但在数学上就是错的。

1. 误区一：把"工时"当成"工期"

"这个需求大概 3 天工作量"，这句话里同时混了两个概念。工时是投入，工期是日历时间。一个人 3 天的工时，如果中间要等一次接口联调、等一次代码评审、等一次测试环境，工期可能是 6 天。

更麻烦的是，工期不是工时的简单相加。当多个任务共享同一个人时，工期约等于工时之和；当多个任务共享同一个环境或同一个评审人时，工期会被排队放大。这就是为什么"每个人都排满了"的迭代，实际产出反而更低。

正确的做法是分开记录三个数：纯投入工时、等待与阻塞时间、日历工期。前两个相加才是第三个。如果你的排期表里只有第一个数，那它一定偏乐观。

2. 误区二：用"人天总和除以人数"算周期

这个算法极其常见："总共 120 人天，我们 6 个人，那就 20 天。"它隐含的假设是工作可以无限细分并且完全并行，而这个假设在软件研发里几乎从不成立。

真实情况是：一个模块的核心设计往往只有 1-2 个人能高效完成，其他人并行进来反而增加沟通成本。布鲁克斯在《人月神话》里说的"向进度落后的项目增加人手只会让它更落后"，讲的正是这件事。可并行的部分通常只占总工作量的 60%-70%，剩余部分是串行或强耦合的。

实操上，我建议用"关键路径法"代替除法：先把任务排成依赖图，找出最长的那条链，那条链的长度就是理论最短工期。你会发现它经常比"总人天÷人数"长出 40% 以上。

3. 误区三：按 100% 占用率排期

把每个人的每一天都填满，是排期新手最容易犯的错，因为它让排期表看起来"没有浪费"。但 100% 占用意味着系统没有任何弹性：任何一次插单、任何一个线上问题、任何一个人请假，都会直接把延期传递给下游。

排队论里有个结论很直白：当利用率趋近 100% 时，队列长度趋近无穷。研发团队也一样，占用率从 80% 提到 95%，看起来只多了 15% 的产出，实际的交付周期可能延长一倍。

我的建议是把个人计划的占用率控制在 70%-80%，剩下的 20%-30% 不是空闲，而是留给缺陷、答疑、评审和突发问题的"公开预算"。把它显式写进排期表，比假装它不存在要诚实得多，也更容易向上解释"为什么我们不能接这个新需求"。

4. 误区四：需求不拆解就直接排期

"做一个用户权限模块，5 天。"这种粒度的排期，误差通常在 ±100%，因为 5 天里可能包含十几个决策点，任何一个都可能翻倍。而"设计权限表结构 0.5 天 / 实现角色接口 1 天 / 前端权限组件 1 天 / 联调与用例 1.5 天"这样的拆解，误差能压到 ±25%。

拆解的价值不只是估得更准，更在于它暴露了依赖和风险。一个 5 天的整块任务，你不会去问"这里面哪一步最可能卡住"；拆成四块之后，"联调与用例"那一块立刻会引出"和谁联调""对方什么时候能给"这些关键问题。

经验值：单个任务的估时不要超过 2 人天。超过就继续拆。这个规则简单到不需要培训，但坚持执行的团队不到三成。

四、我的判断逻辑：容量、依赖、不确定性三层拆解

把前面这些误区反过来，就是一套可执行的判断顺序。我把它总结成三层：先算能投多少（容量），再看卡在哪里（依赖），最后评估可能错多少（不确定性）。顺序不能乱，因为后一层的结果依赖前一层。

1. 第一层：容量，把"能投多少"算成一个区间而不是一个数

容量不要算成单点值，要算成区间。因为可用工资本身就是波动的：有人这周要处理家事，有人刚接手新模块效率打折，有人同时在两个项目上。

我的做法是算三个数：乐观容量（假设一切顺利）、基准容量（历史平均值）、保守容量（扣掉已知风险）。排期时用保守容量做承诺，用基准容量做计划，用乐观容量做上限预警。

这样做的直接好处是，当有人问"能不能再加一个需求"时，你有三个清晰的答案，而不是一个模糊的"应该可以"。排期谈判最怕的就是"应该可以"，它会一路传递到下游变成确定的承诺。

2. 第二层：依赖，把隐性的等待显性化

依赖是排期里最容易被低估的部分。我的经验是：依赖造成的延期，平均是估算误差造成的延期的 2 倍以上，但团队在排期会上花在依赖上的时间通常不到 10%。

识别依赖有个笨办法但很有效：对每个任务问三个问题，

• 它需要别人先交付什么？（接口、数据、设计稿、环境、权限）
• 那个"别人"现在知道这件事吗？（口头答应和排进对方迭代是两件完全不同的事）
• 如果对方晚 3 天，我的哪一步会卡住？（找出真正的关键路径）

第三个问题最有用。它逼你把"依赖"从一个抽象概念，变成一个具体的时间点。很多团队排期时写"依赖后端接口"，但从来不写"接口必须在 3 月 8 日前提供，否则前端联调无法开始"。前者是信息，后者是可执行的约束。

这里有个容易被忽略的实践：把跨团队依赖写进对方团队的迭代里，而不是只写在自己团队的排期表上。单方面的排期表没有任何约束力，只有进入对方承诺范围的工作才会被真正安排。

3. 第三层：不确定性，用区间估算代替点估算

排期里最没用的信息是"这个 3 天能做完"。最有用的信息是"这个大概率 3 天，最坏 5 天，如果中间接口出问题可能 8 天"。前者给你一个数字，后者给你一个决策依据。

我要求团队在估算时同时给出三个值：乐观值（P10）、最可能值（P50）、悲观值（P90）。然后把它们合成期望值：期望 ≈ (乐观 + 4×最可能 + 悲观) ÷ 6。这就是经典的三点估算，用起来不复杂，但能显著改善团队对"最坏情况"的敏感度。

关键在于：做承诺时用悲观值，做计划时用期望值，做资源申请时用乐观值。同一个任务在三个场合有三个数字，这不是不诚实，而是对不同决策场景的正确响应。

4. 用利特尔法则判断"是不是排太多了"

有个公式我一直拿来当排期的体检指标：平均交付周期 = 在制品数量 ÷ 平均交付速率（利特尔法则）。它简单到只有两个变量，但解释力很强。

举个例子：一个团队每周能交付 5 个需求，同时在推进的需求有 20 个，那么平均每个需求从开始到完成要 4 周。如果这个团队把在制品压到 10 个，在交付速率不变的情况下，平均周期会降到 2 周。

这说明一件反直觉的事：缩短交付周期最快的办法往往不是做得更快，而是同时做得更少。我见过太多团队一边抱怨"需求交付太慢"，一边把在制品堆到人均 3 个以上，然后所有需求都卡在 80% 完成度上。

五、真实案例：从 37% 延期率到 12%，三个动作

下面这个案例来自一家做企业服务的公司，研发团队 40 人左右，分 5 个小组。我参与的是其中两个小组的排期改造，周期约 4 个月、8 个迭代。数据是他们自己从项目管理工具里导出的，我做了归并和清洗。

1. 改造前的基线数据

改造前 4 个迭代的平均表现：迭代承诺条目 14 个，实际完成 8.6 个，完成率 61%；承诺条目中延期的占 37%；迭代末三天加班时长占总加班时长的 58%；跨团队依赖导致的阻塞平均每个迭代 4.3 次。

还有一个隐性成本：因为排期不可信，测试团队习惯性在迭代末期才介入，导致缺陷发现时间平均滞后 3.8 天，修复成本随之上升。这条链路很少被写进排期复盘，但它才是"排期不准"最贵的部分。

2. 动作一：把容量算法公开化，砍掉 40% 的承诺量

第一个动作不是改流程，而是把容量算给所有人看。我们把名义容量、四层扣减、真实可用容量做成一张表，在排期会上直接投屏。第一次算完，团队自己都愣了：他们一直按 320 人时排期，真实可用只有 196 人时。

然后我们把承诺量从平均 14 个条目降到 9 个。这个决定当时争议很大，产品经理认为"这是在降低产出"。两个迭代之后，数据说话了：完成条目数从 8.6 升到 8.9，几乎没变，但完成率从 61% 升到 89%，延期率从 37% 降到 19%。产出没减少，可预测性大幅提升。

这里的关键判断是：承诺量降到真实容量以下，短期看是"少做了"，长期看是把返工、加班、救火的时间释放出来。释放出来的时间又变成了有效产出，形成一个正循环。

3. 动作二：强制拆解到 2 人天以内，暴露依赖

第二个动作是硬规则：任何进入迭代的条目，如果估算超过 2 人天，必须拆到 2 人天以内才能排。这条规则执行起来阻力不小，因为拆解本身要花时间，我们统计过，拆解让排期会议时长从平均 90 分钟增加到 140 分钟。

但收益很快显现。拆解之后，每个小组平均每个迭代识别出的跨团队依赖从 2.1 个上升到 5.7 个。不是依赖变多了，是原来那些隐性的依赖被看见了。对应的处理方式是：每个依赖必须写清"对方交付物 + 需要日期 + 对方责任人"，并且在对方团队的迭代里占一个条目。

这一步把跨团队阻塞次数从每迭代 4.3 次降到 1.6 次。

4. 动作三：引入迭代级缓冲和 WIP 上限

第三个动作是给迭代留 18% 的整体缓冲，同时给每个人设 2 个在制品的上限。缓冲的使用规则很明确：只有当某个条目出现"非团队可控"的阻塞时才允许动用，用完即止，不允许透支下个迭代。

WIP 上限的效果比预期更明显。限制之前，一个人手上平均同时有 3.4 个条目；限制到 2 个之后，平均交付周期从 11.2 天降到 7.4 天，而每周交付条目数从 4.1 升到 4.9。这再次印证了利特尔法则：少做并行，反而多做产出。

5. 中大型组织里，工具承担了什么角色

上面三个动作在 40 人规模时，靠表格和自觉还能维持。但当组织到 100 人以上、多产品线并行时，我看到的普遍问题是：每个团队自己的排期都挺准，合起来还是延期。原因在于共享资源（架构、测试、运维、设计）被多个团队同时排满，谁都不知道别人的承诺。

这类问题光靠流程约定解决不了，需要工具层面提供统一的可见性。我接触过的团队里，有采用 PingCode 这类面向中大型企业的研发管理平台的，它的价值主要不在"记工时"，而在三件事上：

• 统一需求台账：跨团队依赖能看到对方条目的真实状态和承诺日期，而不是靠口头同步；
• 容量可视化：按人、按角色、按迭代看负载，超载在排期阶段就能被发现，而不是执行中才暴露；
• 迭代复盘的数据基础：承诺量、完成量、延期原因可以按迭代导出对比，改进有依据而不是凭印象。

需要说明的是，工具解决的是"信息不对称"，不解决"判断错误"。如果容量算法本身是错的，工具只会让错误的排期更快地传播到所有团队。先把方法理顺，再用工具固化，顺序反了就是花大钱买了个更精致的错误。

六、不同情况下的行动建议

方法论要落地，必须匹配团队的具体条件。下面按团队规模和业务形态给出可执行的建议，每一条都控制在"下周就能开始做"的范围内。

1. 10 人以下小队：先解决"输入不受控"

这个阶段做精细估算意义不大，因为最大的变量是需求随时变化。优先级应该是：

1. 建立唯一的需求入口。所有需求进一个列表，包括老板口头提的。这一条听起来琐碎，但它是所有排期的前提。
2. 定一条"插单换出"规则：任何插入的新需求，必须指出从当前迭代移出哪一个。不换出就不插入，这条规则要当着所有人的面执行一次。
3. 用周为单位而不是迭代为单位排期。小队的需求变化太快，两周迭代的排期往往在第三天就过期了。
4. 记录每次插单。一个月后你会有一份数据，用来向上解释"为什么这个月只做了计划内的一半"。

这个阶段不要追求工具，一个共享表格加一条规则就够了。过早引入重型流程，只会让团队把精力花在维护流程上。

2. 20-50 人单产品线：重点在拆解和依赖

这个规模的团队通常已经有固定迭代，问题集中在估算偏差和联调阻塞上。建议动作：

• 硬性拆解规则：单条目不超过 2 人天，超过必须拆；
• 排期会前置 1 天做"技术预拆"，由每个条目的负责人提前把拆解结果写进系统，会议只讨论争议项，会议时长能压掉三分之一；
• 依赖三要素：交付物、需要日期、对方责任人，缺一项不算识别完成；
• 迭代缓冲 15%-20%，且只允许因外部原因动用；
• 每人 WIP 上限 2，超出时必须先完成再开始。

这个阶段最容易走偏的是"把排期会议开成技术讨论会"。我的做法是设一个硬约束：会上只解决"能不能做、什么时候做、卡在哪里"，具体怎么做留到会后。一次会议超过 90 分钟，基本说明拆解工作没有提前做。

3. 100 人以上多团队：先对齐容量口径，再谈排期

这个规模的核心矛盾不再是单个团队的排期准不准，而是共享资源被重复承诺。我见过最典型的情况是：三个产品团队都排了同一个架构师的下个迭代，每个人都以为他只花 20% 时间在自己这里。

建议动作按顺序：

1. 统一容量口径。所有团队用同一套扣减规则算可用容量，否则跨团队比较毫无意义。
2. 给共享角色建独立的容量台账。架构、测试、运维、设计这些角色，要能看到自己在每个团队被承诺了多少。
3. 依赖进入对方迭代，而不是停留在自己团队的需求描述里。
4. 按季度做一次跨团队容量对齐，把下季度的重大依赖提前排进去。

这个阶段，统一的平台能显著降低协同成本。前面提到的 PingCode 这类平台在这类组织里的实际作用，是把"共享角色的可用容量"和"跨团队依赖的承诺状态"变成所有人可见的事实，而不是各自表格里的假设。但要清楚：工具让问题可见，不代替你做取舍。看到架构师被承诺了 180% 之后，减谁的需求仍然是人的决策。

4. 外包与交付型项目：排期要写进合同语言

这类项目和产品研发的排期逻辑差别很大，因为约束是"合同工期"而不是"迭代节奏"。我的建议：

• 把"需求变更"的计价方式写进排期：每增加一个需求，明确需要延长多少天或增加多少成本，而不是笼统地说"要加钱"；
• 按里程碑而不是按周排期，但里程碑内部要拆到两周粒度，否则风险全压在最后；
• 给验收环节单独留时间，很多交付项目的延期不是做不完，是验收反复，平均要占整个工期的 10%-15%；
• 把假设条件写下来："本排期假设甲方在 4 月 10 日前提供完整接口文档"，这句话在后期争议时价值极高。

5. 一个可以直接用的容量计算脚本

下面这段脚本可以直接跑，用来算一个迭代的真实可用容量。参数按自己团队的情况改。

def available_capacity(headcount, workdays, hours_per_day,
collab_rate=0.13,

support_rate=0.16,

leave_days_per_person=0.6,

parallel_tasks=3):

"""

计算一个迭代的真实可用容量（人时）

参数均为经验默认值，请按团队历史数据校准

"""

nominal = headcount * workdays * hours_per_day

非工作日折算

leave_loss = headcount * leave_days_per_person * hours_per_day

effective_days = nominal - leave_loss

协作与支持性工作扣减

collab_loss = effective_days * collab_rate

support_loss = effective_days * support_rate

上下文切换损耗：并行任务越多，损耗越大

if parallel_tasks <= 1:

switch_rate = 0.0

elif parallel_tasks == 2:

switch_rate = 0.08

else:

switch_rate = min(0.25, 0.08 + 0.07 * (parallel_tasks - 2))

switch_loss = (effective_days - collab_loss - support_loss) * switch_rate

usable = effective_days - collab_loss - support_loss - switch_loss

return {

"名义容量": round(nominal),

"真实可用容量": round(usable),

"可用率": f"{usable / nominal:.1%}",

"建议承诺上限": round(usable * 0.85)   # 留 15% 迭代缓冲

}

if __name__ == "__main__":

print(available_capacity(headcount=5, workdays=10, hours_per_day=8))

输出示例：{'名义容量': 400, '真实可用容量': 234, '可用率': '58.5%', '建议承诺上限': 199}

注意最后一行"建议承诺上限"。它比真实可用容量又低了一档，因为承诺量应该低于可用容量，而不是等于。等于容量意味着零容错，而零容错的排期在现实中没有一次能兑现。

七、不同情况下的取舍：速度、质量、范围、可预测性

排期做到最后，本质上是一道取舍题。这四个变量，交付速度、交付质量、需求范围、排期可预测性，不可能同时最大化。任何声称"四个都要"的排期方案，实际执行时一定会牺牲掉其中至少一个，只是没人提前说清楚是哪个。

1. 四个变量里，可预测性最容易被牺牲，也最不该被牺牲

当压力来临时，团队的第一反应通常是"范围不动，压缩时间"，也就是牺牲可预测性。短期看这保住了交付范围，长期看代价极高：下游团队会开始给研发排期自动加一个"安全系数"，通常 30%-50%，整个组织的节奏被系统性拖慢。

我的判断是：宁可承诺得少但准，也不要承诺得多但虚。因为排期的核心价值是"让别人能基于它做计划"，一旦这个价值丢失，排期就退化成了一张愿望清单。

2. 赶工期时，砍范围的顺序

如果确实需要提前交付，我建议按这个顺序砍：

1. 先砍"锦上添花"的功能点：那些去掉之后核心流程仍然完整的功能；
2. 再砍"非目标用户的场景"：先服务 80% 的用户，长尾场景延后；
3. 然后降低非核心路径的质量标准：比如后台管理页不做精细的交互打磨；
4. 最后才考虑加班，且要明确加班的边界，连续加班超过两周，产出会开始下降，缺陷率上升。

这个顺序的关键是把"质量"放在最后砍，因为质量问题的修复成本是非线性的：上线后发现的缺陷，修复成本通常是编码阶段的 5-10 倍，如果是数据问题还要加上清洗和沟通成本。

3. 需求高度不确定时，不要做精确排期

有一类工作天然无法精确排期：探索性的技术验证、从没做过的业务领域、依赖大量外部不确定因素的项目。这类工作硬要排到"天"的粒度，只会产生虚假的精确感。

我的做法是分层：确定性高的部分按迭代排期，确定性低的部分按"时间盒 + 明确产出"排期。比如"用两周时间做一个技术验证，产出是一份可行性结论和性能数据"，而不是"两周做完这个模块"。前者的承诺是可兑现的，后者大概率兑现不了。

对应的判断标准很简单：如果你对这项工作的最坏情况估不出上限，就不要给它排具体日期，给它排一个时间盒和一个决策点。

4. 四种典型场景下的取舍组合

这张表最有用的地方不是给出答案，而是逼团队在项目开始时就说清楚"我们在保什么、让什么"。我见过太多项目，前两个月所有人都在按"四个都要"工作，第三个月集中崩溃，然后开始互相追责。

5. 什么时候该放弃精确排期

最后说一个反直觉的判断：不是所有团队都需要精确到天的排期。如果满足下面任意两条，我建议把排期粒度放宽到周甚至双周：

• 需求来源高度分散，且决策者不接受"插单换出"规则；
• 团队有超过 30% 的时间在做线上支持和救火；
• 关键技术栈或架构正在剧烈变动，任务耗时波动超过 3 倍；
• 组织对"延期"的容忍度极高，排期实际上不承担承诺功能。

在这些条件下强行做精确排期，得到的结果是"看起来很专业，实际没人信"，反而消耗了团队的信任。更务实的做法是先承诺周级别的交付节奏，把可预测性建立起来，再逐步收紧粒度。

结尾：排期是团队对自己诚实程度的度量

写到这里，我想把最核心的一个观点再说一遍：排期做不好，绝大多数时候不是因为不会估时，而是因为不愿意承认约束。承认只有 222 小时的可用容量、承认某个依赖可能晚三天、承认某个需求这个迭代做不完，这些都是让人不舒服的对话，所以团队会本能地用"努力一下应该可以"绕过去。

但绕过去的代价会以另一种形式回来：加班、返工、下游团队的信任损耗、以及越来越长的交付周期。我在前面那个 40 人团队的案例里看到的最有价值的变化，不是延期率从 37% 降到 12%，而是团队开始敢于在会上说"这个做不完"。这句话一说出口，排期才真正开始起作用。

如果你准备开始改，我建议下一步只做三件事，不要贪多：

1. 这周就把容量算出来，用上面那段脚本，把名义容量和真实可用容量投屏给团队看。这一步不需要任何流程改动，但会改变所有人的认知基准。
2. 下个迭代执行一条硬规则：单条目不超过 2 人天，超过必须拆。只加这一条，其他都不变，观察一个迭代的延期率变化。
3. 建一个延期原因记录，不用复杂，一个字段就够。三个迭代之后你会得到自己的帕累托图，那时候改进方向就不再需要猜了。

排期不是一门精确科学，它更像是一种团队协定。好的排期不是每次都准时，而是每次不准时的时候，所有人都能提前知道，并且知道该动哪个变量。做到这一点，比任何工具和模板都重要。