name: 设计评审管理 description: 用于正式设计评审准备与执行的技能(初步设计评审/关键设计评审) allowed-tools:
- Read
- Write
- Glob
- Grep
- Bash
metadata:
specialization: 机械工程
domain: 科学
category: 设计评审文档
priority: medium
phase: 7
tools-libraries:
- PLM系统
- 需求管理工具
- 演示工具
设计评审管理技能
目的
设计评审管理技能为准备和执行正式设计评审(初步设计评审/关键设计评审)提供能力,实现对设计成熟度和利益相关者一致性的系统性验证。
能力
- 设计评审议程准备
- 评审标准和检查清单制定
- 技术演示指导
- 行动项跟踪与管理
- 评审委员会协调
- 设计成熟度评估
- 门径标准验证
- 评审会议促进
使用指南
设计评审类型
评审门径框架
| 评审 | 时机 | 目的 | 关键问题 |
|---|---|---|---|
| 系统需求评审 | 需求阶段 | 需求完成 | 需求是否被理解? |
| 初步设计评审 | 初步设计 | 设计方法获批 | 设计能行得通吗? |
| 关键设计评审 | 详细设计 | 设计准备就绪可构建 | 设计是否完整? |
| 测试准备评审 | 测试准备就绪 | 准备进行鉴定 | 我们能测试这个吗? |
| 生产准备评审 | 生产 | 准备就绪可制造 | 我们能制造这个吗? |
初步设计评审
进入标准:
- 需求已基线化
- 初步设计完成
- 关键权衡研究完成
- 风险评估已执行
- 初步分析完成
退出标准:
- 设计方法获批
- 需求验证可行
- 主要风险已识别并缓解
- 开发计划获批
- 资源已分配
关键设计评审
进入标准:
- 详细设计完成
- 所有分析完成
- 图纸已发布供评审
- 物料清单完成
- 制造计划草案完成
退出标准:
- 设计冻结
- 分析获批
- 图纸获批可发布
- 制造计划获批
- 测试计划获批
评审准备
议程制定
标准评审议程:
1. 介绍与目标(15分钟)
2. 需求评审(30分钟)
3. 设计概述(45分钟)
4. 分析总结(30分钟)
5. 制造方法(30分钟)
6. 测试方法(30分钟)
7. 风险评估(30分钟)
8. 进度与成本(15分钟)
9. 行动项与收尾(30分钟)
评审包
-
文档
- 设计描述
- 需求验证矩阵
- 分析报告
- 图纸/模型
- 风险登记册
- 开发进度表
-
演示材料
- 概述幻灯片
- 技术深入讲解备份
- 支持数据
- 行动项日志(来自前次评审)
评审检查清单
设计检查清单(机械)
需求:
[ ] 所有需求已分配并可追溯
[ ] 衍生需求已记录
[ ] 接口需求已定义
[ ] 验证方法已分配
设计:
[ ] 设计满足所有需求
[ ] 设计意图已记录
[ ] 材料选择理由充分
[ ] 公差适合功能
[ ] 维护可及性
[ ] 安全考虑已解决
分析:
[ ] 结构分析完成
[ ] 热分析完成
[ ] 疲劳寿命充足
[ ] 重量预算满足
[ ] 余量已记录
制造:
[ ] 设计可制造
[ ] 公差可实现
[ ] 特殊工艺已识别
[ ] 供应商能力已验证
[ ] 成本估算完成
风险评估检查清单
针对每项风险:
[ ] 风险明确定义
[ ] 可能性已评估
[ ] 后果已评估
[ ] 缓解计划已定义
[ ] 责任方已分配
[ ] 目标关闭日期已设定
[ ] 状态已跟踪
评审执行
评审委员会组成
| 角色 | 职责 | 必需/可选 |
|---|---|---|
| 主席 | 领导评审,决策 | 必需 |
| 秘书 | 记录行动 | 必需 |
| 总工程师 | 技术权威 | 必需 |
| 设计负责人 | 呈现设计 | 必需 |
| 分析负责人 | 呈现分析 | 必需 |
| 制造代表 | 评估可生产性 | 必需 |
| 质量代表 | 合规性验证 | 必需 |
| 客户代表 | 需求所有者 | 视情况而定 |
决策标准
评审结果:
- 批准:所有标准满足,进入下一阶段
- 有条件批准:在特定条件下继续
- 未批准:返回上一阶段
投票流程:
- 一致同意批准
- 记录不同意见
- 未解决问题升级路径
行动项管理
行动项内容
必需信息:
- 唯一ID
- 描述
- 分配给
- 截止日期
- 优先级(高/中/低)
- 状态
- 关闭标准
- 解决摘要
跟踪流程
行动项生命周期:
1. 评审时开启
2. 分配并确认
3. 进行中
4. 提出解决方案
5. 评审并验证
6. 关闭
流程集成
- ME-024:设计评审流程(初步设计评审/关键设计评审)
输入模式
{
"review_type": "系统需求评审|初步设计评审|关键设计评审|测试准备评审|生产准备评审",
"project_info": {
"name": "字符串",
"phase": "字符串",
"schedule_date": "日期"
},
"review_scope": {
"systems": "数组",
"requirements": "需求ID数组"
},
"previous_actions": "行动项数组",
"attendees": {
"required": "数组",
"optional": "数组"
}
}
输出模式
{
"review_package": {
"agenda": "文档引用",
"presentation": "文件引用",
"checklists": "检查清单引用数组"
},
"review_results": {
"decision": "批准|有条件批准|未批准",
"conditions": "数组(如有条件)",
"action_items": [
{
"id": "字符串",
"description": "字符串",
"assigned_to": "字符串",
"due_date": "日期",
"priority": "高|中|低"
}
]
},
"maturity_assessment": {
"overall_score": "数字(1-5)",
"by_area": "对象",
"gaps_identified": "数组"
},
"meeting_minutes": "文档引用"
}
最佳实践
- 提前分发评审包(至少提前1周)
- 就关键问题向主要利益相关者进行预简报
- 评审时间聚焦于决策,而非演示
- 记录所有行动项并明确责任人
- 在下一次评审前跟进行动项
- 跨项目保持一致的评审标准
集成点
- 与需求分解连接以进行验证
- 为设计变更提供变更管理输入
- 为验证证据支持测试规划
- 与质量部门集成以确保合规性