结论简单,教训深刻:一个大型项目关于需求工程的反思
发布于 2024-10-01
1999
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
项目回顾摘要
某公司在开展一个新行业的大型软件项目时,面临了多个挑战。项目计划工期为2年,实际用时2.5年,投入了近100人年的工作量,但浪费了约25人年,主要因需求返工所致。项目结束后,作为外部咨询顾问,我参与了项目的回顾过程,并总结了以下经验教训。
保持的做法:
- 小范围的需求沟通与交流更有效,有助于清晰透彻地理解需求。
- 每日召开例会来准备和总结需求调研,确保调研的方向和重点。
- 多轮面对面沟通和现场调研,以深刻理解客户需求。
放弃的做法:
- 避免没有领域专家参与需求调研与分析,以免理解不透彻。
- 不依赖中间人传递的需求,减少误解和返工。
- 制定销售人员作业规范,避免过多不实际的客户承诺。
- 确保需求决策者直接参与项目,防止需求确认延误。
- 及时让客户确认需求,避免大规模返工。
- 对参与需求调研的人员进行专业培训,提高需求质量。
新增或加大投入的做法:
- 在需求描述中明确系统能做和不能做的事项。
- 设立组织级需求规范,指导需求分析。
- 需求访谈前准备问题清单。
- 了解客户背景和企业文化。
- 让测试人员参与需求调研,评价需求的可测试性。
- 在开发前确认需求原型。
- 项目结束后总结领域经验,构建知识库。
- 对紧急需求修改采取结对设计、结对修改模式。
项目管理铁律:
- 项目中一定要有领域专家参与。
- 让客户进行阶段性验收,以三个月为最长周期。
- 采用迭代或增量模型开发,而非瀑布模型。
- 在开发前使用原型法确认需求。
- 保证项目参与者对项目真正负责。
总结上述经验,我们认识到大项目的失败往往在于宏观的项目管理策略,且在项目进行中难以意识到选择的错误。这些惨痛的教训是我们成长的宝贵财富。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1224.5K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
快速学习COSMIC方法之九:如何识别兴趣对象?
兴趣对象是COSMIC方法中一个关键的概念。它影响了我们识别的功能点的多少。兴趣对象是描述中在功能需求中的、功能用户感兴趣的事物,它可以是一个具体的东西,也可以是一个抽象的概念,系统一定要对它执行输入、输出、读或写的动作。 在COSMIC中对兴趣对象有明确的定义,识别兴趣对象的规则也有定义。结合度量手册与其他指南,结合我的实践经验,总结了如下的实用性规则,供大家参考:1兴趣对象一定是来自于功能需求
三轮自动代码评审,质量持续收敛
本文复盘了一个智能文档评审工具的Bug修复与质量提升过程。项目采用前后端分离架构,在修复Word预览失败等表面Bug时,发现深层架构问题——文档解析应迁移至前端。通过三轮"后置四区评审"(聚焦变更单元的四个维度),团队逐步解决严重问题:首轮发现公共模块缺失、CDN无降级等3个严重缺陷;次轮修复后仍暴露null处理等新问题;第三轮最终收敛到零缺陷。核心启示包括:1)多轮评审才能层层深入;2)修复常会引入次生问题;3)结构化评审方法比工具更重要。
估算项目工作量的方法:定额法
定额法的优点是可以进行快速估算,并容易和客户达成一致。缺点是需要对定额进行校对后使用。
需求交付周期的分析
需求交付周期的分析
我说CMMI2.0之:II点睛
II(implementation infrastructure)可以翻译为:实施基础设施。基础设施包括了资源、资金、培训、流程定义、经验教训总结等方面的实践,总之,就是要建立进行持续过程改进的能力。实践列表: 1.1 Perform processes that address the intent of the Level 1 practices. ...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线