结论简单,教训深刻:一个大型项目关于需求工程的反思
发布于 2024-10-01
1187
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
项目回顾摘要
某公司在开展一个新行业的大型软件项目时,面临了多个挑战。项目计划工期为2年,实际用时2.5年,投入了近100人年的工作量,但浪费了约25人年,主要因需求返工所致。项目结束后,作为外部咨询顾问,我参与了项目的回顾过程,并总结了以下经验教训。
保持的做法:
- 小范围的需求沟通与交流更有效,有助于清晰透彻地理解需求。
- 每日召开例会来准备和总结需求调研,确保调研的方向和重点。
- 多轮面对面沟通和现场调研,以深刻理解客户需求。
放弃的做法:
- 避免没有领域专家参与需求调研与分析,以免理解不透彻。
- 不依赖中间人传递的需求,减少误解和返工。
- 制定销售人员作业规范,避免过多不实际的客户承诺。
- 确保需求决策者直接参与项目,防止需求确认延误。
- 及时让客户确认需求,避免大规模返工。
- 对参与需求调研的人员进行专业培训,提高需求质量。
新增或加大投入的做法:
- 在需求描述中明确系统能做和不能做的事项。
- 设立组织级需求规范,指导需求分析。
- 需求访谈前准备问题清单。
- 了解客户背景和企业文化。
- 让测试人员参与需求调研,评价需求的可测试性。
- 在开发前确认需求原型。
- 项目结束后总结领域经验,构建知识库。
- 对紧急需求修改采取结对设计、结对修改模式。
项目管理铁律:
- 项目中一定要有领域专家参与。
- 让客户进行阶段性验收,以三个月为最长周期。
- 采用迭代或增量模型开发,而非瀑布模型。
- 在开发前使用原型法确认需求。
- 保证项目参与者对项目真正负责。
总结上述经验,我们认识到大项目的失败往往在于宏观的项目管理策略,且在项目进行中难以意识到选择的错误。这些惨痛的教训是我们成长的宝贵财富。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 642.9K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
最有效的5条改进措施
有朋友问我在咨询过程中发现对客户最有效的5条改进措施有哪些,细细反思后总结如下: 1、分类管理项目 通过区分企业中不同类型的项目制定不同的管理策略、裁剪策略,保证了质量体系的实用性、灵活性,即减少了开发投入又保证了项目的质量,平衡了敏捷方法与规范方法。 有的企业区分了新产品研发、订单项目开发、系统维护等3类项目,又区分了大中小规模的不同,针对不同类不同规模的项目定义了管理的流程、文档模板。 2、用
对需求变更的定量分析
很多公司头疼需求变更,如果我们采用定量的技术该如何分析需求的变更呢?首先定义什么叫需求变更?在客户方与开发方共同认可需求之后的需求修改、增加、删除都是需求变更。需求变更对象可以从多个维度划分: 维度一: 功能需求、非功能性需求、接口需求、界面需求、技术约束等; 维度二:业务逻辑、数据对象、控制逻辑等;其次,可以从3个层次分析需求变更:层次1: 需求变更率分析。需求变更率有多种定义方法。 方法一:需求变更率=需求变更的个数/交付的需求个数;...
敏捷实践大全
对常见的敏捷实践整理归纳如下: 序号 类别 敏捷实践/技术 1 1过程 价值流映射 2 1过程 WIP上限 3 1过程 发布火车 ...
CMMI:收获的欣慰
晚上客户为我送行,今天是我最后一次现场咨询,12月底的正式评估我回避了。去年底我和他们一起努力,使他们公司通过了CMMI2级的评估,今年底将进行CMMI3级的正式评估。2年的时间,见证了他们的软件管理体系从无到有,从2级到3级的历程,回顾2年来的变化,甚感欣慰:Ø 项目经理能够编写比较详细的项目计划,进行比较完备的WBS分解;Ø 项目组每周都有例会,每个阶段都会里程碑评审,
我说CMMI2.0之技术解决方案
TS:技术解决方案,映射到实际工程活动中包含了技术路线选择、概要设计、详细设计、实现、技术文档编写等活动。 实践列表 TS 1.1 Build solution to meet requirements. 创建满足需求的解决方案 TS 2.1 Des...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线