扫码阅读
手机扫码阅读
结论简单,教训深刻:一个大型项目关于需求工程的反思
44 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
文章来源:
麦哲思科技任甲林
扫码关注公众号
项目回顾摘要
某公司在开展一个新行业的大型软件项目时,面临了多个挑战。项目计划工期为2年,实际用时2.5年,投入了近100人年的工作量,但浪费了约25人年,主要因需求返工所致。项目结束后,作为外部咨询顾问,我参与了项目的回顾过程,并总结了以下经验教训。
保持的做法:
- 小范围的需求沟通与交流更有效,有助于清晰透彻地理解需求。
- 每日召开例会来准备和总结需求调研,确保调研的方向和重点。
- 多轮面对面沟通和现场调研,以深刻理解客户需求。
放弃的做法:
- 避免没有领域专家参与需求调研与分析,以免理解不透彻。
- 不依赖中间人传递的需求,减少误解和返工。
- 制定销售人员作业规范,避免过多不实际的客户承诺。
- 确保需求决策者直接参与项目,防止需求确认延误。
- 及时让客户确认需求,避免大规模返工。
- 对参与需求调研的人员进行专业培训,提高需求质量。
新增或加大投入的做法:
- 在需求描述中明确系统能做和不能做的事项。
- 设立组织级需求规范,指导需求分析。
- 需求访谈前准备问题清单。
- 了解客户背景和企业文化。
- 让测试人员参与需求调研,评价需求的可测试性。
- 在开发前确认需求原型。
- 项目结束后总结领域经验,构建知识库。
- 对紧急需求修改采取结对设计、结对修改模式。
项目管理铁律:
- 项目中一定要有领域专家参与。
- 让客户进行阶段性验收,以三个月为最长周期。
- 采用迭代或增量模型开发,而非瀑布模型。
- 在开发前使用原型法确认需求。
- 保证项目参与者对项目真正负责。
总结上述经验,我们认识到大项目的失败往往在于宏观的项目管理策略,且在项目进行中难以意识到选择的错误。这些惨痛的教训是我们成长的宝贵财富。
想要了解更多内容?
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
420 篇文章
浏览 72.3K
麦哲思科技任甲林的其他文章
如何学习设计模式?
1 先理解概念,再学习原则先理解OO的基本概念,比如:封装、继承、多态、组合/聚合、依赖等,理解各概念的内涵,弄清楚这些概念的具体实现方式及各实现方式的优缺点。2 先学习原则,再学习模式设计原则是蕴含在设计模式后最根本的思想,掌握了基本的设计原则可以做到不拘泥于某个具体的设计模式,可以更容易的理解设计模式,知道在何种情况下应该采用某种模式,可以自己创造合理的设计模式。设计原则可以参考的2本书籍是《
我说CMMI 2.0 之 配置管理
和CMMI1.3相比,CMMI2.0中配置管理的实践基本没有变化。CMMI DEV 2.0 的20个PA中,CM是唯一一个没有3级实践的PA。基本概念这个PA涉及到的基本概念比较多,我们挑选部分基本概念,做通俗解释:配置管理:通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性。配置项:配置管理的对象,包括各种文档资料,代码等工作产品。包括:给客户的交付...
代码评审的速度与缺陷密度是啥关系?
某企业采集了8个项目的代码评审数据,虽然样本数量不多,但是仍然可以发现一些规律原始的度量数据如下,包括了代码评审发现的缺陷密度与代码评审的速度。这2者是什么关系呢? 表一:8个项目的代码评审缺陷密度与评审速度 ...
同行评审培训练习点评结果
2008年3月3日做同行评审的培训,讲解同行评审方法花费了3小时,练习时间为1小时,点评时间为45分钟。参加培训的人员为20人,19人参与了练习,划分成了3个小组练习。3个小组对同一个需求进行了同行评审,该需求为一个实际项目需求的一部分,仅有1页纸,但是质量比较差。 这3个小组的练习结果如下表所示: 第1组 第2组 第3组
CMMI2级的难点在哪里
其实这个问题本没有答案,因为不同的企业难点是不同的。对于某些企业来讲,可能没有什么难点,譬如:某企业只想拿到一个评估证书,而不考虑改进效果。尽管CMMI 2级是最基本的等级,如果真想将CMMI2级做好,其实还是不容易的,通常情况下的难点为:(1) 做一个切实可行的计划。任务要识别的比较全面,估算的工作量比较合理,人员的安排不能超负荷、不能窝工,、进度安排紧凑而不失弹性。(2) 实时
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线