我对IT项目需求发掘的一些思考

需求是IT项目开始阶段重要的环节，准确的发掘客户真实的需求（Requirement Discovery）是项目成功的关键。IDG 的调查显示60% 的项目失败原因是需求阶段的失误，或者是需求阶段产生连锁效果造成的。但是我们看到，很多IT项目时没有需求发掘这一个步骤的。需求是业务部门提出的，IT部门作为接收方，只是做到需求分析设计。

 

需求发掘（Requirement Discovery）的基本过程大家都很了解，下面只做简单的介绍。需求发掘的步骤有：

·        制定需求管理发掘计划

·        需求采集

·        需求分析

·        需求验证、审核

·        需求验收

·        需求变更管理

 

项目开始前，我们都会有一个项目范围，之后基于这个范围开展工作。很多人认为这个项目范围会是固定的，需要严格遵守的。但是因为需求发掘这一工作流程的加入，项目的最初范围会因为需求发掘的成果而发生修正，改变。要知道传统的项目需求管理方式普遍存在需求不断增加，项目范围不断扩大的情况。而通过需求挖掘可以有效的避免这一点。

 

项目范围与需求挖掘是一个交互影响的关系，而不是一个waterfall流程一样的单项流动过程。项目范围提供指导，需求挖掘发现需求再反过来影响范围。最终通过项目发掘的整个流程，需求得到了全面的优化，整理。

 

整个需求挖掘流程中，需求采集涉及的部门多，牵扯的关键人物（stakeholder）多，处理起来有很多障碍，在这里提出一些我认为有帮助的方法，希望帮助大家的工作。

1.      需求采集会议是需求采集中被广泛使用的方式，作为需求分析师，自己建立一套自己的控制需求采集会议的方法。这样的方法有很多，之后我会仔细介绍。但是重要的一点是这些方法一定要保证一个有纪律性的，有规律的需求采集会议。

2.      采集需求是，使用可视化，容易理解的方式描述需求，这样可以提高交流效率。我建议直接使用use case的建模方式，文字描述作为辅助。

3.      之所以采用可视化建模，因为它直观，易理解，所以在会议上就可以快速达成意见共识。于是我们就可以直接在会议上进行预审，会后也可以快速产生文档，进行分析，审核工作。

4.      采集的需求一定要让业务部门验收签字，这样可以防止随意的变更，也可以让业务部门对需求采集有责任感，从而认真对待。

 

不少人认为需求挖掘是一个可有可无的步骤，而且这个步骤会产生很大的费用。对这个问题，IAG做个详细的调查，他们的研究大量的客户和超过1000个项目, 已经发现需求质量的提高大大降低系统开发和实施的时间和成本。这是因为没有需求挖掘的项目往往伴随着项目进行中的大量的需求变更，每个人都知道这是的需求变更会产生大量的费用。IAG的调查报告显示，IT项目的平均返工率达到30%。伴随着成本的提高，很多隐性的负面因素所产生的消极后果更是无法衡量的，比如项目的延期、甚至失败，客户满意度的降低，用户的反馈不佳等。综合考虑需求挖掘的费用远远低于没有这个过程的情况。