从需求方面谈谈项目为何失败〔转载〕

一、需求采集与分析

  1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。

   之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。

  2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。

二、需求定义与确认

   需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。

三、需求变更

  需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。

  1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。

  2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。

  我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。