RCE（如漏洞利用）需在完成渗透测试、验证复现稳定性后提交，具体时间依项目流程而定，建议结合安全响应机制同步
RCE（需求/变更请求）的核心定义
RCE（Request for Change Event）指对项目范围、功能、进度或资源的正式修改申请，其核心目的是通过规范化流程控制变更风险，确保团队共识与目标一致，以下是具体提交时机及规则：
需提交RCE的典型场景
| 类别 | 具体情形 | 示例 |
|---|---|---|
| 新增需求 | 客户/干系人提出未包含在基线范围内的额外功能 | “增加多语言支持” |
| 缺陷修复 | 测试或运维中发现影响系统稳定性的重大缺陷 | “数据库连接池泄漏导致崩溃” |
| 范围调整 | 因业务策略变化需删减非核心功能 | “取消第三方社交登录集成” |
| 技术优化 | 为提升性能/安全性进行的架构级改进 | “替换过时的加密算法” |
| 外部依赖 | 合规性要求（如GDPR）、供应商接口变更等强制约束 | “数据存储需迁移至欧盟服务器” |
| 风险应对 | 原方案存在不可接受的技术/资源风险时的替代方案 | “改用微服务架构规避单体应用瓶颈” |
关键时间窗口建议
| 项目阶段 | 最佳提交时间 | 操作要点 |
|---|---|---|
| 需求冻结前 | ✅ 最优先时段 | 可在需求评审会前集中收集，降低后期返工成本 |
| 迭代周期内 | ⚠️ 仅限非关键路径改动 | 若涉及当前迭代交付物，需经产品经理特批并重新排期 |
| 测试阶段 | ⏳ 严格限制（仅高危漏洞可插队） | 原则上禁止新增功能，仅允许阻断发布的致命缺陷修复 |
| 发布后维护期 | 🔄 按SLA分级处理 | P0级故障需立即响应，普通优化纳入下一版本规划 |
| 里程碑节点前 | ❌ 禁止提交（除非紧急预案启动） | 防止打乱验收节奏，特殊情况下需召开专项会议决策 |
特殊情形下的处理原则
-
紧急变更通道
- 适用于生产环境宕机、安全事件等S1级事故
- 需附带详细风险分析报告+回滚方案
- 审批链缩短为：技术负责人→项目经理→CTO三级联签
-
微小文字修正
- 纯UI文案错别字/翻译校准无需走RCE流程
- 直接通过配置平台修改并记录审计日志
-
跨项目影响
- 若变更涉及共用底层服务/数据库表结构
- 必须同步抄送所有关联项目负责人参与评估
注意事项清单
| 序号 | 检查项 | 违规后果 |
|---|---|---|
| 1 | 未附受影响模块清单 | 被退回补充材料 |
| 2 | 缺少备选方案对比分析 | 延期决策导致进度延误 |
| 3 | 重复提交已拒绝过的同类请求 | 计入绩效考核扣分项 |
| 4 | 估算工作量超剩余缓冲时间的50% | 触发项目升级审查机制 |
| 5 | 未更新关联文档版本号 | 造成实施偏差且无法追溯责任 |
相关问题与解答
Q1: 如果遇到临时性的口头指示该怎么办？
A: 任何非正式请求都必须转化为书面RCE单，建议当场复述确认内容：“收到您的要求，我们将在今日下班前创建编号为[XXX]的RCE供您签字确认。”既体现专业性，又留下追溯依据。
Q2: RCE被拒绝后能否再次申诉？
A: 可以，首次驳回原因会明确标注（如成本超支/技术不可行），申诉时需补充新论据，例如提供替代技术方案的成本测算，或展示竞品
