“数据团队下季度要不要加人？”
预算会上，老板把这句话问得很平静。数据负责人面前摊着一张需求表，二十七行，颜色很多。业务部门都把自己的那一行标成高优先级。靠窗坐着的财务同事翻到空白页，准备记下人数和成本。
负责人说：“现在确实忙不过来。”
老板又问：“是缺人，还是事情没排好？”
会议室里安静了一会儿。这个问题不好答。说缺人，像是在为管理能力找借口；说不缺，回去以后那几条凌晨告警、每周手工报表和半年没动的迁移任务，还得由原来几个人接着扛。
我见过不少团队在这里拿出三类材料：需求数量、加班截图和同事的疲惫表情。后两样都是真的，可它们很难进入预算。需求数量也未必有用，一条改字段的需求和一套结算链路，都是一行，显然不是同一种分量。
容量计划不是证明团队很忙，而是解释现有时间被什么占用、下一季度承诺什么，以及少掉哪一块会付出什么代价。
要把这件事说清，我更愿意准备五类证据：新需求、维护负担、事故响应、技术债和自动化收益。它们不是五个好看的栏目，而是五种不同性质的时间。只有分开记，老板才有可能判断：该加人、减承诺，还是先把工作方式改掉。
先算净容量，不要把“人数乘工作日”当答案
一个六人团队，每人一个季度大约有六十多个工作日。有人会很自然地做乘法，得到三百多个人天，再问：“这么多时间，为什么二十七个需求还做不完？”
这个乘法没错，只是它算的是日历容量，不是可承诺容量。
Microsoft Azure Boards 的容量规划工具会把成员休假、每日可用时间和活动类型分开记录，并用剩余工作与容量对比。它解决的是一个朴素问题：人坐在组织架构图里，不代表他的每一天都可以交给新项目。
数据团队尤其如此。有人轮值、有人维护核心链路、有人同时支援两个团队；月初忙结算，月末忙经营会，大促前后还有一段谁也不敢挪走的保障时间。若把这些都藏在“默认会处理”里，新需求就会在纸面上占满全部人天，事故则像天气一样临时出现。
我通常先写一个不复杂的式子：
净可承诺容量 = 名义工作日 - 已知休假与固定协作 - 日常运行负担 - 事故与波动预留 + 已兑现且尚未计入运行负担基线的自动化收益
单位可以用人天，也可以用团队自己长期使用的估算单位。关键是前后一致。若需求按故事点估算，容量却按人天计算，中间没有稳定的历史换算，数字看起来精确，实际只是两把尺子放在一起。
下面所有数字都只用于演示，不是行业标准。假设一个六人数据团队，每人 63 个工作日，下季度共有 378 个名义人天。扣掉休假、培训、固定会议和跨团队支持后，剩 320 个；维护与轮值在自动化改造前平均占 112 个；事故和波动预留 32 个。另有一项已经验收的自动化净释放 20 人天，这笔收益尚未计入 112 人天的维护基线。因此，真正能拿来承诺新工作和长期改造的是 196 人天：
320 - 112 - 32 + 20 = 196
老板真正要看的，不是“六个人很多”，而是这 196 个将被什么消耗。
第一类证据：新需求要写成承诺，不要写成愿望清单
需求池常常是一张礼貌的许愿单。每一行都有业务价值，每一行都希望下季度完成。若直接把它交给老板，老板只能按声音大小排序；数据负责人也很容易把“有人提过”误写成“团队必须做”。
容量计划里的新需求，至少要补四个字段：
- 谁会使用：具体到部门、岗位或业务流程；
- 完成后改变什么动作：减少手工、支持决策、满足合规，还是替换旧系统；
- 最晚何时有用：错过日期会损失什么，而不是只写“尽快”；
- 最小可交付范围：先交哪一段，才算真正产生价值。
然后再估工作量。估算不需要假装自己能预知三个月后的每个小时，但要把主要组成拆开：需求澄清、数据接入、口径确认、开发测试、业务验收和上线观察。只估写 SQL 的时间，通常会得到一种很乐观的文学作品。
还要给需求一个状态：已承诺、候选、等待澄清、明确不做。没有状态的需求会偷偷占两次容量——负责人一边说它还没确定，一边又让工程师提前准备。
真正进入预算讨论的，是已承诺与高概率候选。其余需求留在池里，但不假装已经排进日历。
第二类证据：维护负担不是“顺手”，它会按周来收租
数据团队有许多工作不会出现在项目排期里：修一条迟到任务，给业务补一份历史文件，处理权限申请，核对口径，重跑失败分区，回答“这个数为什么变了”。每一件都不大，合起来却能吃掉一个人的大半个月。
Google SRE 把一类重复、手工、会随服务规模线性增长的运行工作称为 toil。大白话就是：今天做完，下周还来；业务多一倍，这类活也跟着多一倍，却没有留下永久改善。
Google 在自己的 SRE 组织里会给运维类工作设置时间上限，并保证相当一部分时间用于能减少未来负担的工程项目。这个比例是 Google 的内部做法，不能原样抄给所有数据团队。真正值得借鉴的是另一点：维护时间必须被记录，否则它永远会被当成免费的。
