资源需求图之所以经常过期，根源往往在于组合层面的变更没有被登记回图，而不在于数据本身难维护。立项、暂停和人员变动这三类事件一旦发生，需求行、角色供给和有效期就需要同步调整。本文按这三类事件给出一套可执行的维护流程，包括触发规则、字段责任、复核节点和验证指标，并说明如何借助 ONES 承载需求登记与状态流转。
要点总览（TL;DR）
- 资源需求图过期的根源是组合变更未登记回图，维护方式应从定期重画改为按事件触发更新。
- 把立项、暂停、人员变动设为三类触发事件，分别对应新增需求行、释放容量、替换角色供给，并规定提交人、复核人和更新时限。
- 每条需求行保留来源项目、角色、投入比例、起止时间、状态和版本，使需求可追溯、状态可识别。
- 推行前需收敛组合决策入口、统一角色字典，并接受项目负责人登记负担增加这一代价。
- 用变更登记覆盖率、需求行与项目状态一致率等示例指标做改进前后对照，持续观察两三个周期判断机制是否生效。
当前做法与目标：资源需求图现在怎么维护
多数团队维护资源需求图的方式可以归为两种。一种是定期重画：每季度或每月由组合管理者牵头，收集各项目的最新人员安排，汇总成一张新的需求表。另一种是临时口头调整：项目负责人发现人手不够或人员离场，在例会或即时沟通中提一句，图上的数字靠人工记忆修改，缺少统一记录。两种方式各有问题，前者滞后于决策，后者依赖个人自觉。
资源需求图要回答的问题其实很具体：在组合层面，当前和未来一段时间可以承接哪些项目，每个项目需要什么角色、投入多少、从什么时候到什么时候。它服务于立项取舍、暂停决策和资源再分配，是一张决策辅助图，而非精确到人天的工作量台账。
由此可以确定维护目标：图与组合决策保持同步。具体表现为三条：
- 组合层面每做出一次影响资源占用的决策，图上对应的需求行在约定时限内完成更新；
- 每条需求行都能追溯到来源项目和当前状态，读者能判断这条需求是否仍然有效；
- 图上的角色供给与在岗人员情况一致，不出现已离场人员仍占容量的情况。
追求数据绝对精确既不现实也无必要。资源需求图的价值在于支撑判断，允许一定颗粒度的估算，但要求变更可追溯、状态可识别。
三类触发事件下，需求图失真的具体环节
失真不是一次性发生的，而是在三类事件的交接处逐步累积。理解每个断点，才能设计对应的更新动作。
立项：需求停留在评审材料里
立项评审时，项目负责人通常会在材料中写明所需角色和投入，评审通过后项目进入执行。问题出在评审材料与需求图之间没有回写动作：材料归档，需求图未新增对应行。结果是组合层面看到的需求总量低于实际已承诺的项目，后续再立项时容易高估剩余容量。另一种情况是需求行加了，但只写了角色没写起止时间，图上看不出这条需求何时开始占用资源。
暂停：需求行未释放，形成虚占容量
项目暂停往往由组合层面决定，但暂停通知传到需求图之间存在断点。项目状态已改为暂停，图上的需求行仍按原计划占用角色容量，其他项目在评估可承接性时被这部分虚占容量挡住。虚占时间越长，组合层面的资源判断偏差越大。部分团队会在暂停时口头说明“这个项目先不算”，但图上没有状态标记，新接手的人无法识别。
人员变动：角色供给未同步，需求与可用人力错位
人员变动包括离场、转岗、新加入和投入比例调整。需求图通常记录的是需求侧，即项目需要什么角色；供给侧的信息若未同步更新，就会出现需求行指向一个已经不在该项目的人员，或者某成员的实际投入比例已变化而图上仍按旧比例计算。这类错位在多人协作的项目中尤其隐蔽，因为单个角色的偏差会被其他角色的余量掩盖。
跨事件叠加：重复计入与遗漏
三类事件同时发生时，失真会叠加。典型情形是一个项目暂停后其人员被调往新立项的项目，若暂停未释放、立项未新增，同一批人力在图上既算在旧项目又未算入新项目，形成一漏一重。另一个情形是人员变动后需求行被替换，但旧行未标记失效，同一角色出现两条有效记录，容量被重复占用。这些问题的共同点是缺少统一的事件登记入口，每次变更各自处理，没有交叉核对。
优先改进动作：把三类事件接入同一更新流程
改进的核心是把三类事件从“各自处理”改为“同一流程登记”。每类事件定义触发条件、更新时限和责任人，需求行保留统一字段，复核节点固定。下表给出三类事件的对照规则，时限可按团队节奏调整。
| 触发事件 | 触发条件 | 需更新的内容 | 提交人 | 复核人 | 建议时限 |
|---|---|---|---|---|---|
| 立项 | 组合评审通过，项目进入执行 | 新增需求行：来源项目、角色、投入比例、起止时间、状态置为“有效” | 项目负责人 | 组合管理者 | 评审通过后 2 个工作日内 |
| 暂停 | 组合层面决定暂停或终止项目 | 需求行状态改为“暂停”或“关闭”，释放对应容量，注明暂停起始日 | 项目负责人 | 组合管理者 | 决定生效当日 |
| 人员变动 | 成员离场、转岗、新加入或投入比例变化 | 替换需求行上的角色供给，调整投入比例，旧记录标记失效 | 项目负责人 | 组合管理者 | 变动生效后 2 个工作日内 |
需求行的字段规范是流程能否落地的基础。建议每条需求行至少包含：来源项目、角色、投入比例、起止时间、状态、版本。来源项目保证可追溯，角色和投入比例描述需求内容，起止时间界定占用窗口，状态区分有效、暂停、关闭，版本用于对比变更前后的差异。字段不必多，但缺一项就会在某一类事件中失去判断依据。
分工上，项目负责人负责提交本项目的变更，因为其最清楚项目状态和人员安排；组合管理者负责复核，重点检查变更是否与组合决策一致、是否与其他项目产生冲突。复核不是重新审批，而是确认登记完整、状态准确。对于暂停和人员变动，还需明确释放与替换规则：暂停项目的需求行保留记录但不再计入可用容量；人员替换时旧行标记失效、新行生效，避免同一角色两条有效记录并存。
变更留痕与版本对比是防止回退的手段。每次更新记录变更时间、变更人和变更原因，定期对比相邻版本，识别哪些需求行被反复调整、哪些长期未更新。长期未更新的需求行本身就是失真信号，应纳入复核清单。
在工具承载上，需求登记与状态流转可以放在同一套工作项体系中管理。ONES 提供资源规划视图，管理者可以按业务优先级安排和计划团队资源，在可用资源与需求之间做平衡；其资源和工时管理方案支持跨项目团队资源规划，并可查看项目和团队的资源利用率与负荷度。把立项、暂停、人员变动对应的需求行变更作为工作项状态流转的一部分登记，复核时直接对照资源视图核对容量，可以减少变更停留在会议纪要中的情况。具体字段配置和状态联动方式需按实际环境核验。
适用前提与代价：这套维护方式需要什么
这套机制要运转，前提是组合层面有明确的决策入口和责任人。立项、暂停这类决策需要有固定的评审场合和记录，否则触发条件无从判断，更新时限也无法起算。如果组合决策分散在多个团队各自做出，需求图的统一维护就缺少依据，此时应先收敛决策入口，再推行事件登记。
代价方面，最直接的是项目负责人的登记负担。每次立项、暂停和人员变动都要提交变更，事件频繁时负担明显。缓解办法是设定批量更新窗口，例如每周固定一次集中登记，紧急变更单独处理；同时把字段控制在必要范围内，避免为了完整性增加填写成本。
角色口径不统一是另一项前置工作。不同项目对“前端”“测试”“架构”的定义可能不同，需求图上的角色若各说各话，汇总后的容量判断就不可比。推行前需要先统一角色字典，明确每个角色的职责边界和投入比例的计量方式。这项工作一次性投入较大，但缺少它，后续所有对比都失去基准。
事件频繁时还需设定例外处理规则。例如短时间内连续暂停又重启的项目，可以合并为一次状态变更；人员临时支援不超过约定天数的，可暂不调整需求行，但需在备注中说明。例外规则要写清楚适用条件和审批人，避免成为不登记的借口。
效果验证：怎么判断需求图不再过期失真
验证的目标是判断改进是否减少了未登记变更，而非证明图绝对准确。可以从三个角度取数，指标口径为示例，需按团队实际调整。
- 变更登记覆盖率：统计一定周期内实际发生的立项、暂停、人员变动事件数，与需求图上登记的变更数对比。覆盖率接近 100% 说明事件基本都进入了流程；明显偏低则说明仍有变更走口头渠道。
- 需求行与项目状态一致率：抽查需求行，核对其状态与来源项目的实际状态是否一致。暂停项目仍显示“有效”、关闭项目仍有有效需求行，都计入不一致。
- 抽查核对：每月抽取若干项目，将图上需求行的角色、投入比例、起止时间与实际投入对照。抽查重点放在近期发生过变更的项目上，这类项目最容易出现遗漏。
对照方法上，建议在改进推行前先记录一个基线的覆盖率与一致率，推行一到两个周期后再取数对比。对比时注意区分相关性与因果：覆盖率上升可能同时受到组合决策频次变化的影响，需结合事件总数一起看。若事件总数稳定而覆盖率上升，改进的作用更可信。
复核周期与失真上报渠道要固定下来。组合管理者按固定周期复核需求图，项目负责人在发现图与实际不符时通过约定渠道上报，上报记录本身也作为验证材料。指标用于发现趋势和定位问题，不必追求单次数值的精确，持续观察两三个周期的变化更能说明机制是否生效。
常见问题
项目暂停后又重启，需求图上的需求行应该怎么处理？
建议把暂停和重启视为两次独立的状态变更，而不是在原记录上反复修改。暂停时将需求行状态改为“暂停”并注明起始日，该行保留记录但不再计入可用容量；重启时新增或恢复一条状态为“有效”的需求行，起止时间按新的计划填写。这样处理的好处是暂停期间的容量释放有据可查，重启后的占用窗口也清晰。若暂停时间很短、重启计划明确，可以在团队约定中合并为一次变更，但需在备注中写明暂停区间和重启日期。
人员临时支援其他项目，投入比例只变了一小部分，也要更新需求图吗？
是否更新取决于变动是否影响组合层面的容量判断。如果支援时间短于团队约定的天数、且不改变原项目的关键角色供给，可以在需求行备注中说明，暂不调整投入比例；一旦超过约定天数或涉及关键角色，就应按人员变动事件处理，替换角色供给并调整投入比例。关键是把这条例外规则写清楚，明确适用条件、天数和审批人，避免例外变成不登记的借口。例外记录本身也应纳入复核清单，定期检查是否有长期未回归的临时支援。
组合决策分散在多个团队各自做出时，这套事件登记流程还能用吗？
可以先用，但效果会打折扣。事件登记流程依赖触发条件可判断，如果立项和暂停由各团队自行决定、没有统一的评审记录，更新时限就无从起算，需求图的变更也缺少核对依据。可行的做法是先在一个决策入口相对集中的范围内推行，例如由组合管理者统一评审的项目集合，积累登记习惯后再逐步扩展。同时把分散决策中影响资源占用的部分纳入定期汇总，作为过渡期的补充登记渠道。收敛决策入口是这套机制真正生效的前提。
需求图上的角色口径不统一，先统一角色字典还是先跑流程？
建议先做一轮最小化的角色统一，再跑流程。角色口径不一致时，汇总后的容量判断不可比，流程跑起来也会不断返工。最小化统一不必一次覆盖所有角色，可以先明确组合层面用于容量判断的核心角色，约定每个角色的职责边界和投入比例的计量方式，其余角色在后续迭代中补充。统一角色字典是一次性投入较大的工作，但它决定了后续所有对比是否有基准，值得在推行事件登记之前完成。
用 ONES 承载需求登记时，哪些能力可以直接用，哪些需要按实际环境核验？
根据现有资料，ONES 提供资源规划视图，管理者可以按业务优先级安排和计划团队资源，在可用资源与需求之间做平衡；其资源和工时管理方案支持跨项目团队资源规划，并可查看项目和团队的资源利用率与负荷度。ONES Resource 还支持通过甘特视图做资源规划与进度跟踪、筛选分组查看成员在不同项目的投入比重。把需求行变更作为工作项状态流转的一部分登记，是可行的承载方式。需求行是否随项目状态自动释放、版本留痕的具体实现方式，以及各版本方案的功能差异，资料未作说明，需按实际环境核验。
