6.6

事后诸葛：设备管理子系统项目Postmortem总结

---

1. 设想和目标

1.1 目标清晰度

• 解决的问题：设备全生命周期管理（采购至报废），覆盖8个模块，实现数字化、流程化管理。
• 用户与场景：典型用户（现场工程师、班组长、工区长、主管领导）和场景（故障处理、巡检、保养等）定义较清晰，但部分边缘场景（如多设备并行处理）未充分覆盖。
• 用户接受度：核心功能（如故障销号、人脸识别）接受度较高，但部分用户对智能照片审核的严格性反馈较多，认为操作繁琐。

1.2 计划与共识

• 计划时间：时间较紧张，需求评审阶段耗时较长，导致开发周期压缩。
• 意见分歧：在“智能照片审核”的规则设计上存在争议，最终通过优先级投票决定先上线基础规则。
• 改进点：提前进行用户调研，明确关键需求优先级，预留更长的需求确认时间。

---

2. 计划

2.1 完成情况

• 交付内容：8个模块均完成，但“智能照片审核”的模糊度检测功能因算法问题延迟上线。
• 无效工作：部分台账字段设计过度复杂，后期发现使用频率极低。
• 任务定义：开发任务定义清晰，但测试用例覆盖不全，导致部分边界场景漏测。

2.2 执行与缓冲

• 计划偏离：因第三方人脸识别服务接口调试超期，延误2周。
• 缓冲区：预留1周缓冲期被占用，后期通过加班弥补。
• 改进点：
  • 对第三方服务依赖项增加风险评估和备用方案。
  • 预留更灵活的缓冲时间（如分阶段缓冲）。

---

3. 资源

3.1 资源分配

• 人力资源：开发人员充足，但测试人力不足，导致后期测试压力集中。
• 时间估算：开发时间估算较准，但测试时间低估（尤其是照片审核逻辑的兼容性测试）。
• 非技术资源：UI设计进度滞后，因对“带水印照片”的交互设计反复修改。

3.2 效率优化

• 任务分配：部分前端重复工作可复用组件，后期才优化。
• 改进点：
  • 提前识别可复用模块，减少重复开发。
  • 增加测试自动化投入（如照片审核的自动化校验）。

---

4. 变更管理

4.1 变更响应

• 通知机制：变更通过企业微信和站会同步，但部分细节未及时传达（如字段调整）。
• 优先级管理：通过“MoSCoW法”划分需求，但“人脸识别防代审”因安全要求临时升级为“Must Have”。
• 应急计划：无备用方案应对人脸识别服务故障，临时改为人工审核。

4.2 改进点

• 建立变更分级通知机制（关键变更需确认回执）。
• 对高优先级功能提前制定降级方案。

---

5. 设计/实现

5.1 设计过程

• 设计阶段：需求分析后直接进入开发，缺乏原型评审，导致部分交互返工。
• 争议解决：通过“决策记录表”明确争议点的取舍依据。

5.2 代码质量

• 测试覆盖：单元测试覆盖核心逻辑，但集成测试不足（如多级审核流程的并发问题）。
• Bug分布：照片上传模块Bug最多（兼容性、水印生成失败等），因未覆盖低端机型测试。
• Code Review：执行较好，但未强制要求测试用例关联。

5.3 改进点

• 增加原型设计阶段，减少开发返工。
• 加强设备兼容性测试，尤其是Android低版本。

---

6. 测试/发布

6.1 测试执行

• 测试计划：有测试用例，但未覆盖“超时未审核”的提醒触发逻辑。
• 验收测试：用户验收时发现“满意度评分”未保存，因接口漏测。
• 发布问题：初始版本照片水印时区错误，紧急发布热修复。

6.2 改进点

• 增加端到端流程测试（如“故障报修→销号→评分”全链路）。
• 发布前检查依赖服务的配置（如时区、密钥）。

---

7. 总结

7.1 团队成熟度

• CMMI级别：初步达到已定义级（Level 3），有流程但执行偶有偏差。
• 团队阶段：从磨合期过渡到规范期，协作效率提升，但创新不足。

7.2 里程碑对比

• 改进点：需求评审更规范，Code Review覆盖率提升。
• 待改进：测试左移（提前介入需求分析），减少后期缺陷修复成本。

7.3 最需改进的方面

测试策略优化：

• 自动化覆盖核心流程（如照片审核、多级审批）。
• 建立更严格的发布准入标准（如性能测试通过率）。

---

最终结论：项目目标基本达成，但需在需求管理、测试深度和变更响应上加强，以提升下一阶段的交付质量。