要像管理咨询一样去做软件需求调研

转：http://www.cnblogs.com/tyonly/archive/2011/05/23/2054141.html

有感于做软件的辛苦，特撰一文。

      一般软件公司接到了软件实施案子，第一步是急吼吼的去做需求调研。首先集中要使用软件的一帮人在一起开座谈会，有使用部门的，有间接使用的部门，有计算机管理部门，有大老板，有二老板，甚至有的时候连前台也来了。好几个部门的人集中在一起，每个人角度不同、层次不同，关注的重点不同。大家从自己的角度唧唧喳喳的说了一通，然后需求调研人员将这些都记录下来，形成需求文档，拿回去开发软件。经过一段时间的努力，终于可以给相关使用人员演示了。一演示，问题来了：某某部门的说刚才我突然发现我这里有个东西你这软件没做，某某部门说我这里还有个流程你还没做进去，某某又说有个关键的报表你做的跟我们实际要的不同。。。。软件公司的人傻了，赶紧又重新记下来，继续修改软件。好容易都修改完了，拿给客户看。客户一看，又提出一堆问题。接下来，又继续修改。往来反复，几轮之后，好容易大家都满足了，进入试用了。运气好的话，皆大欢喜，部门使用的很顺畅，软件公司也不用在返工修改，客户也满意，最终结帐，大家都好。但是很多时候，这个时候还会有事情发生，比如：某个以前没关注的部门突然又提出需求，我也要用这个软件，新软件上我不能使用。软件公司项目开发人员把这个部门人员请来一聊，最终发现这个部门确实有使用这个软件的理由，再一翻以前的调研，这个部门给漏掉了。没办法，把这个部门的需求在加上，继续进入开发中。。。  过程如此反复。到最后，项目实施期越拉越长。软件开发公司一评估，认为没什么利润可赚，而客户的需求似乎永远很多，利益冲突纠葛在一起，就放弃该项目了。

      最终的原因是什么呐？

     软件公司需求调研没做好吗？调研确实做了，而且相关人员都请到了，做的需求报告各部门都确认过了。

     客户不配合吗？也不对，客户相当的配合，每个相关部门都说出了需求，所需要的报表他们都很热情的给你。

     客户领导不重视吗？那怎么会，不重视的话，还请你做软件干什么？

     那为什么是这个结果呢？两方都挺受伤的。

     表面看，没有任何一个单独的问题会导致困难，每个问题都能被解决，但是当他们纠结在一起的时候，事情就变得难以被解决。面对这种问题，我们很难看到问题本质所在。不过，如果我们要解决问题，必须试图先去了解问题。

    那么问题是什么？

    回到本源，我们要思考一个问题：客户为什么要实施软件？客户实施软件，显然是要解决问题的。要解决问题，需要软件。所以他们要开发软件。但是仅仅凭借客户所提出的愿望去帮他们实施软件，一般很难一次性的知道客户真正的需求是什么。我们必须自己去把握这个需求，了解客户越多，我们作出来的软件越是客户想要的。

   OK，那我们开始了解。

   第一、我们需要了解项目相关方。比如有谁在用，谁起主导作用，为什么要实施软件，实施软件的背景是什么。

   第二、理流程。一个部门一个部门去了解，现场去看，去研究，和实际使用者一起去工作，了解业务流程，弄懂相关业务报表，对产生的报表的重要度进行分析，理顺与其他报表的勾结关系等。

   第三、理思路。了解了流程以后，我们需要这对调研资料，画出流程图、整理业务报表，列出哪些是关键业务流程、哪些是次要业务流程、哪些流程之间有矛盾、哪些可以优化的、哪些有空白、哪些有漏洞等信息，做出一份报告。

  第四、确认数据流之间的关系。比如数据是从哪里进入、到哪里出来。输入是怎么个要求、输出是什么样的。

  第五、确认特殊流程和特殊需求，如：每个岗位每个人需要解决什么、特殊事件是如何发生的，怎么解决。

  第六、补充建议。到这一步，基本客户整个业务流程我们非常清晰了，针对某些流程我们可写出自己的优化建议，以利于软件更好的实施。

  最后，我们整理报告，告诉客户，我们了解了什么。未来软件会解决什么。我相信，当你把这些详细的报告丢到客户面前的时候，客户还有什么理由不认可你所做的软件呢。

    有人说：天啦，你这不是在做软件管理咨询么？我说：对的，你不这样做，你就没法了解客户，不了解客户，你就没法做出合适的软件。要做软件，就要专业些，只有专业了，你才能做出合适的软件。