结论简单，教训深刻：一个大型项目关于需求工程的反思

项目回顾摘要

某公司在开展一个新行业的大型软件项目时，面临了多个挑战。项目计划工期为2年，实际用时2.5年，投入了近100人年的工作量，但浪费了约25人年，主要因需求返工所致。项目结束后，作为外部咨询顾问，我参与了项目的回顾过程，并总结了以下经验教训。

保持的做法：

1. 小范围的需求沟通与交流更有效，有助于清晰透彻地理解需求。
2. 每日召开例会来准备和总结需求调研，确保调研的方向和重点。
3. 多轮面对面沟通和现场调研，以深刻理解客户需求。

放弃的做法：

1. 避免没有领域专家参与需求调研与分析，以免理解不透彻。
2. 不依赖中间人传递的需求，减少误解和返工。
3. 制定销售人员作业规范，避免过多不实际的客户承诺。
4. 确保需求决策者直接参与项目，防止需求确认延误。
5. 及时让客户确认需求，避免大规模返工。
6. 对参与需求调研的人员进行专业培训，提高需求质量。

新增或加大投入的做法：

1. 在需求描述中明确系统能做和不能做的事项。
2. 设立组织级需求规范，指导需求分析。
3. 需求访谈前准备问题清单。
4. 了解客户背景和企业文化。
5. 让测试人员参与需求调研，评价需求的可测试性。
6. 在开发前确认需求原型。
7. 项目结束后总结领域经验，构建知识库。
8. 对紧急需求修改采取结对设计、结对修改模式。

项目管理铁律：

1. 项目中一定要有领域专家参与。
2. 让客户进行阶段性验收，以三个月为最长周期。
3. 采用迭代或增量模型开发，而非瀑布模型。
4. 在开发前使用原型法确认需求。
5. 保证项目参与者对项目真正负责。

总结上述经验，我们认识到大项目的失败往往在于宏观的项目管理策略，且在项目进行中难以意识到选择的错误。这些惨痛的教训是我们成长的宝贵财富。

想要了解更多内容？

查看原文：结论简单，教训深刻：一个大型项目关于需求工程的反思

文章来源：

麦哲思科技任甲林

扫码关注公众号

入门必看！IPD（集成产品开发）模式下，这些团队都要干啥？团队分工指南来了！

了解更多