4. 变更评审角色与职责
适用场景
本章节适用于PRD版本变更申请通过初步筛选后，进入正式变更评审环节的组织过程。在评审会议召开前，需要明确各参与角色的具体职责与权利边界，确保评审过程高效、决策有据、责任到人。此场景常出现在以下阶段：
- PRD版本修订完成、发起变更评审请求时
- 跨部门需求变更影响范围评估会议前
- 版本基线更新前的正式审批流程中
前置条件
- 已完成PRD版本变更申请的登记与初步筛选（通过/驳回）。
- 变更发起人（通常为产品经理）已准备变更摘要与影响范围说明。
- 评审委员会成员名单已确定，包含产品、开发、测试、运维四方的授权负责人。
- 具备统一评审会议平台（如Jira、Confluence、协同工具）或会议纪要模板。
操作步骤
- 角色确认：由变更控制委员会（CCB）或项目管理员确认本次评审的各角色人选，确保具有决策权限。
- 职责分发：向各角色负责人分发《变更评审职责卡》（参考下方表格），明确各自在评审中的具体任务与裁决范围。
- 材料预审：各角色在评审会议前查阅变更文档，填写《预审意见表》，提出技术或业务层面的初步疑问。
- 会议评审：按职责分工依次发表意见并进行交叉质询，记录争议点与最终决议。
- 签字确认：评审通过后，各角色负责人在《变更评审记录》上电子签名或确认，代表承担对应责任。
输入输出物
| 类型 | 名称 | 来源/去向 |
|---|---|---|
| 输入 | PRD变更申请单（版本号、变更描述、影响范围） | 发起人 → 评审组 |
| 输入 | 《预审意见表》（每人一份） | 评审人 → 会议主持人 |
| 输出 | 《变更评审记录》（含角色签字、决议说明） | 评审组 → 配置管理库归档 |
| 输出 | 角色职责确认回执（无异议） | 各角色 → CCB备档 |
责任边界
每个角色在评审中的职责边界不可交叉，避免决策模糊。以下为职责矩阵：
| 角色 | 决策范围 | 否决权 | 不可替代职责 |
|---|---|---|---|
| 产品经理 | 业务价值、需求完整性、用户影响 | 是（业务层面） | 最终确认变更是否满足市场或客户需求 |
| 开发负责人 | 技术可行性、实现复杂度、代码影响面 | 是（技术方案层面） | 评估开发资源投入与潜在重构风险 |
| 测试负责人 | 测试覆盖、回归范围、质量风险 | 是（质量风险层面） | 制定变更对应的测试策略与准入/准出标准 |
| 运维负责人 | 发布影响、系统稳定性、回滚方案 | 是（运营风险层面） | 确认变更的发布窗口、灰度策略及应急预案 |
专家提示：当某个角色的否决权被触发时，变更自动进入搁置或驳回状态，需发起人修订后重新评审。严禁出现“职权空白”，即评审环节必须有四方代表或其授权代理人到场，否则评审结果无效。
记录材料
评审过程中需完整保留以下材料，作为版本基线追溯的依据：
- 《变更评审角色确认表》：包含各角色姓名、职位、授权日期。
- 《预审意见汇总表》：同步记录每位评审人的意见及会议讨论后的响应说明。
- 《评审会议纪要》：记录讨论要点、分歧点及最终表决结果。
- 《角色签字页》：包含四方负责人手写签名或企业级电子签章，不可代签。
异常处理
- 角色缺席：若某角色负责人临时无法参会，须出具书面授权委托书给具有同等决策权的代理人。无授权则暂停评审。
- 跨角色分歧：当开发与测试对技术方案有重大分歧时，由产品经理仲裁，若仍无法达成一致，上报至CCB或项目总监。
- 职责推诿：评审过程中若发现某个评估点（如数据库变更影响）未被任何角色认领，立刻补充“专项技术顾问”加入到本次评审中，不可遗漏。
验收标准
- 四方角色均在《变更评审记录》中签字确认，无缺失。
- 每个角色的意见栏均有明确结论（同意/有条件同意/驳回）。
- 所有争议项已记录进《会议纪要》并标注最终处理方案。
- 评审记录已上传至版本管理工具（如Git、SVN或专用PMS平台），并与对应PRD版本号关联。