指南 › 指南

变更请求模板

每个项目都有这样一位干系人，会说“就加一个小小的需求”，通常是在周五下午 4:55。变更请求就是把这个“小小的需求”变成有人签字的决定，而不是一个您默默消化的意外。

变更请求是用来做什么的

变更请求是一份简短的书面提案，用于更改已约定的范围、进度、预算或质量。它的作用是让提出需求的人在变更发生之前就看到代价，也让批准的人为后果签字。

控制在一页以内。如果一项变更要写十页才能说清，它多半是披着风衣的一个新项目。

表单：可复制的字段

把这个结构粘贴到您自己的文档里，并按您的治理要求调整措辞。

• 编号、标题和提出日期。
• 提出人（具名）以及需要提交给的发起人。
• 用两三句平实的话描述变更。
• 原因：它解决的问题，或带来的机会。
• 优先级：必须有、应该有或锦上添花，并注明需要完成的日期。
• 状态：已提出、已评估、已批准、已拒绝、已推迟或已实施。

影响评估

这是把意见变成决策的部分。在请任何人批准之前就要填好。

要具体。“要多做几天”不算影响；“三个工作日开发加一天测试”才算。

• 范围：哪些交付物被增加、修改或删除。
• 进度：受影响的任务、新的完工日期，以及关键路径是否移动。
• 成本：额外工作量、采购和动用的应急余量，以变更前后的合计呈现。
• 风险：新产生的风险，或被加重的既有风险。
• 依赖关系：同样必须变更的其他团队、供应商或项目。
• 效益：业务能获得什么，以及效益论证是否仍然成立。

方案与建议

除了“什么都不做”，至少提供两个方案，例如全部批准、批准缩减版、推迟到后续阶段。然后说明您推荐哪一个及理由，要用一句话，让忙碌的发起人在电梯里就能读完。

• 方案 A：什么都不做，以及这样做的代价。
• 方案 B：按提出的要求批准，附上述影响数据。
• 方案 C：更便宜或更晚的替代方案。
• 您的建议，以及用一句话写明理由。

决定与后续落实

只有当合适的人以书面形式表态，变更才算获批。记录谁做了决定、何时决定，以及计划因此改变了什么。然后真正去更新基线，否则下一份报告拿您与一个没人遵循的计划做对比。

在 Senshin 中，决定记录在 RAID 日志里，紧挨着它所影响的计划任务和成本行，当有人问日期为什么变了，这条线索就在那里。

• 审批人姓名、决定、日期和附带条件。
• 更新后的完工日期、预算和范围，同时保留旧值以便对比。
• 计划更新的负责人及完成日期。
• 在下一份 SteerCo 报告中列一行，避免有人靠传闻得知。

它在 Senshin 中的位置

常见问题

更多指南

最后更新: 2026-10-22