122 lines
4.4 KiB
Markdown
122 lines
4.4 KiB
Markdown
|
# AI-Box设计评审流程规范
|
||
|
|
|
||
|
|
## 1. 设计评审适用范围
|
||
|
|
|
||
|
|
### 必须进行正式设计评审的重要设计结果：
|
||
|
|
- **系统架构设计方案** (孙大圣负责)
|
||
|
|
- **产品需求规格书(PRD)** (猪小杰负责)
|
||
|
|
- **核心模块详细设计文档**
|
||
|
|
- **接口定义和协议规范**
|
||
|
|
- **电源管理策略设计**
|
||
|
|
- **安全性和可靠性设计方案**
|
||
|
|
|
||
|
|
### 可以简化评审的常规设计：
|
||
|
|
- **工具脚本和辅助程序**
|
||
|
|
- **非核心功能模块设计**
|
||
|
|
- **文档格式和排版调整**
|
||
|
|
|
||
|
|
## 2. 飞书审批流集成方案
|
||
|
|
|
||
|
|
### 2.1 审批流配置需求
|
||
|
|
由于当前飞书应用权限限制，需要申请以下审批流相关权限：
|
||
|
|
- `approval:approval_instance` - 审批实例管理
|
||
|
|
- `approval:approval_template` - 审批模板管理
|
||
|
|
|
||
|
|
### 2.2 临时审批流程（当前可用）
|
||
|
|
在获得完整审批权限前，采用以下临时流程：
|
||
|
|
|
||
|
|
#### 步骤1: 文档创建与初审
|
||
|
|
- 设计者在飞书云文档中创建设计文档
|
||
|
|
- 在文档开头添加 **【设计评审】** 标识
|
||
|
|
- @相关评审人员进行初步技术评审
|
||
|
|
|
||
|
|
#### 步骤2: 评审会议组织
|
||
|
|
- 在 **04 项目会议** 文件夹中创建评审会议
|
||
|
|
- 邀请所有相关干系人参加
|
||
|
|
- 会议议程包含：设计介绍、问题讨论、决策确认
|
||
|
|
|
||
|
|
#### 步骤3: 评审结果记录
|
||
|
|
- 在会议文档中记录评审结论
|
||
|
|
- 明确标注：**通过/有条件通过/不通过**
|
||
|
|
- 列出所有需要修改的问题项和负责人
|
||
|
|
|
||
|
|
#### 步骤4: 文档更新与确认
|
||
|
|
- 设计者根据评审意见修改文档
|
||
|
|
- 在文档修订历史中记录修改内容
|
||
|
|
- 评审人员确认修改后，在评论区回复 **【确认通过】**
|
||
|
|
|
||
|
|
### 2.3 正式审批流流程（权限开通后）
|
||
|
|
一旦获得审批流权限，将升级为正式审批流程：
|
||
|
|
|
||
|
|
#### 自动化审批触发
|
||
|
|
- 设计文档保存时自动触发审批流
|
||
|
|
- 系统自动识别文档类型并分配相应审批人
|
||
|
|
- 审批流包含：技术评审 → 架构评审 → 项目经理确认 → 最终批准
|
||
|
|
|
||
|
|
#### 审批状态跟踪
|
||
|
|
- 实时显示审批进度
|
||
|
|
- 超时自动提醒审批人
|
||
|
|
- 审批历史完整记录
|
||
|
|
|
||
|
|
## 3. 评审角色与职责
|
||
|
|
|
||
|
|
### 3.1 评审委员会组成
|
||
|
|
| 角色 | 人员 | 职责 |
|
||
|
|
|------|------|------|
|
||
|
|
| **技术评审员** | 孙大圣 | 技术可行性、架构合理性 |
|
||
|
|
| **产品评审员** | 猪小杰 | 需求符合度、用户体验 |
|
||
|
|
| **项目经理** | 唐小僧 | 进度影响、资源协调 |
|
||
|
|
| **质量保证** | 测试团队 | 可测试性、质量标准 |
|
||
|
|
|
||
|
|
### 3.2 评审标准
|
||
|
|
- **技术先进性**: 是否采用合适的技术方案
|
||
|
|
- **需求符合度**: 是否完全满足产品需求
|
||
|
|
- **可实施性**: 开发团队是否具备实施能力
|
||
|
|
- **可维护性**: 后续维护和扩展的便利性
|
||
|
|
- **风险可控性**: 技术风险是否在可接受范围内
|
||
|
|
|
||
|
|
## 4. 评审流程执行细节
|
||
|
|
|
||
|
|
### 4.1 评审准备
|
||
|
|
- **提前通知**: 评审前至少24小时通知评审人员
|
||
|
|
- **材料准备**: 提供完整的背景资料和参考文档
|
||
|
|
- **环境准备**: 确保演示环境和测试数据就绪
|
||
|
|
|
||
|
|
### 4.2 评审会议
|
||
|
|
- **时间控制**: 单次评审会议不超过2小时
|
||
|
|
- **议题聚焦**: 严格按照议程进行，避免偏离主题
|
||
|
|
- **记录完整**: 指定专人记录会议要点和决策
|
||
|
|
|
||
|
|
### 4.3 评审后续
|
||
|
|
- **问题跟踪**: 所有问题必须有明确的解决计划
|
||
|
|
- **状态更新**: 每周更新评审问题的解决进度
|
||
|
|
- **闭环验证**: 问题解决后必须进行验证确认
|
||
|
|
|
||
|
|
## 5. Gitea与飞书协同机制
|
||
|
|
|
||
|
|
### 5.1 双向同步规则
|
||
|
|
- **飞书为主**: 设计文档以飞书版本为准
|
||
|
|
- **Gitea备份**: 评审通过的最终版本必须同步到Gitea
|
||
|
|
- **版本对应**: 飞书文档版本号与Gitea提交哈希对应
|
||
|
|
|
||
|
|
### 5.2 同步时机
|
||
|
|
- **评审前**: 在飞书创建和编辑文档
|
||
|
|
- **评审后**: 评审通过24小时内同步到Gitea
|
||
|
|
- **重大变更**: 任何重大修改都需要重新评审
|
||
|
|
|
||
|
|
## 6. 应急处理机制
|
||
|
|
|
||
|
|
### 6.1 紧急设计决策
|
||
|
|
对于紧急情况下的设计决策：
|
||
|
|
- **快速通道**: 项目经理可授权临时决策
|
||
|
|
- **事后补审**: 72小时内必须补办正式评审
|
||
|
|
- **风险评估**: 必须记录决策的风险和应对措施
|
||
|
|
|
||
|
|
### 6.2 评审争议处理
|
||
|
|
当评审出现重大分歧时：
|
||
|
|
- **升级机制**: 提交给更高层级决策
|
||
|
|
- **专家咨询**: 邀请外部专家提供意见
|
||
|
|
- **原型验证**: 通过快速原型验证方案可行性
|
||
|
|
|
||
|
|
---
|
||
|
|
**本规范自发布之日起生效，所有重要设计结果必须遵循此评审流程。项目经理负责监督执行，并根据实际运行情况进行优化调整。**
|