← AI学习中心 / 项目与协作
怎样把变更请求写成范围影响与待确认项
文中企业场景、人物与业务数字为教学示例，不是客户成果记录。
【直答】变更请求只写三块内容：原范围与新范围的差异、受影响的交付物和需要重估的因素、目前还答不了而必须逐项确认的问题。文中不写同意或不同意的结论，是否接受变更由授权人决定，变更材料的任务是让决定有据可依，而不是替人拍板。
【业务场景·合成演示】一家建站服务商的项目进行中，客户在电话里提了一句顺便加个多语言版本。团队觉得不大，直接排进开发。两个月后才发现三个问题没人确认：翻译资料由谁提供、多语言页面上线顺序是否调整、验收标准按哪个语言算。上线时间开始不可控，而变更发生时这些都可以写清楚。
【具体做法】第一步，收到变更先冻结受影响部分的执行，填一张变更记录卡，先记录后动工。第二步，差异栏写清新增、删除、修改了哪些范围条目，并引用原需求文档或合同里的编号，让差异可以对着原文看。第三步，影响栏列受影响的交付物清单，以及需要重估的因素，例如工作量、工序顺序、外部依赖，只列因素不下结论。第四步，待确认栏列当前答不了的问题，每条注明向谁确认、期望什么日期前得到答复。第五步，把记录卡交给授权人决策，决定与日期由授权人填写，团队不得代填。第六步，决定形成后才更新计划表；若决定是带条件执行，把条件原样写进待办，不先动工后补卡。
【示例表·合成演示】建站项目变更记录卡：
| 栏目 | 内容 |
|---|---|
| 变更内容 | 新增两种语言版本页面；原需求文档编号PRD-07未含此项（编号为合成演示） |
| 受影响交付物 | 页面设计稿、翻译文稿、测试用例、验收单 |
| 需重估因素 | 翻译资料来源与交付节奏、上线顺序是否调整、验收标准是否分语言分别约定 |
| 待确认项 | 翻译初稿由客户提供还是外包，待客户方对接部门确认，期望10月20日前答复 |
| 授权人决定 | 留空，待批复后由授权人填写并注明日期 |
【可复用空模板】
| 变更内容（含原需求编号） | 受影响交付物 | 需重估因素 | 待确认项（向谁确认加期望答复日） | 授权人决定与日期 |
|---|---|---|---|---|
【反例·合成演示】另一个项目把客户提出的加一个站内搜索框记成一行小改动，直接进入开发。做完才发现搜索依赖的数据接口权限从未确认，功能接不上数据，只能空置。错误不在改动本身，在于记录卡里没有待确认栏，未知被当成了不存在。
【常见疑问】问：特别小的变更也要填卡吗。答：可以设小额快速通道，卡面缩短，但差异、影响、待确认三栏仍各写一行，一行也不能省。问：客户催着先做怎么办。答：把待确认栏拿给客户看，确认越快动工越稳；是否先带条件开工，由授权人决定，团队不自行突破范围。
【来源说明】本文变更记录卡的栏目设计与测试思路，受Google Workspace博客中把团队规则整理成参考文件并加以测试的思路启发（https://workspace.google.com/blog/product-announcements/teach-gemini-your-teams-know-hows-with-skills-in-google-workspace）。该来源描述的是规则模板参考文件与测试思路，不推断任何国内产品可用性；文中场景、编号与表格均为编辑设计的合成演示，未经实际运行验证。
【收尾思考】最近一次让你们返工的顺便小改动：它缺的是差异描述，还是那条没人写下来的待确认项？