闲话需求调研（一） 没有用户就没有需求

马上就年底了，今年的两个新开发的的项目都进入了验收阶段，一年的忙碌马上要有个收尾。因为公司和项目性质的原因，有大半年都在外地出差，泡在项目现场。正巧这时得到了新的消息，负责我们区域的销售签下了一个大单子，其中软件项目由我们项目组来开发，看来明年出差也躲不了了。

 

由着这个项目，大家很自然的讨论起如何明年该如何开展进行这个项目，让项目可以顺利的进行，并且对比了今年的两个项目，也算是总结一年的工作，于是，种种想法，有正面的，有负面的，有牢骚，有不满，有自得，全都冒了出来。针对之前出现的问题，到底是什么原因造成的，如何在新的项目中避免，大家各抒己见，争论不休。

 

说起来今年的两个项目进行的还算是顺利，但是期间也有不少很闹心的小问题。就是这些小问题，导致了一个项目在上线后，几个比较重要的功能出现了比较大的改动，还有两个功能理解错误，直接废弃功能，重新开发。虽然多年的开发经验，还是有惊无险的应付过去了，但是谁也不想重蹈覆辙，很快争论的焦点就集中在了需求调研分析上了。

 

确实如此，软件开发，是否成功，最重要的衡量标准就是得到客户的认可，特别是定制项目。

 

这么多年的开发经验，根据需求，进行功能设计，直至开发实现，这个流程不会出错，这点自信还是有的。但是需求获取以及分析的结果，一旦出错，就是根源出问题，即使代码写的再漂亮，界面再华丽，易用性再好，用户也不会买账。

 

争来争去，其实大致的方向，道理都差不多，但是如何动手去做，去实现这些理想化的流程，还是任重道远。

 

于是想把这些讨论的问题和一些想法记下来，也算是这一年工作的一个总结，给明年的工作开一个好头，先有了想法，在想办法去动作做，不怕晚，就怕不做。

 

 ****************************************************************************************************************************************************************************

 

写出用户认可的正确的软件，需要有正确的设计，正确的设计，来源于正确的需求，那么需求来自于哪？自然是软件系统的用户。

 

一个软件系统的用户，有很多种。从系统的具体使用方式来说，有具体的操作用户，负责基础业务数据的录入维护；有数据审核用户，负责业务数据的审核处理；最后还有决策层的领导用户，系统需要提供这类用户合乎规格的数据报表。如果从他们的文化背景，行事风格，个人性格等等来说，更是五花八门。

 

做定制项目软件，用户无法回避，无论什么样的用户，都得硬着头皮上。不和客户打交道，和他们去交流沟通，就不会有项目中不可或缺的需求调研结果。

 

没有用户，就没有需求，那么有了用户（废话，合同签了，项目组都进驻现场了，能没有用户么），需求在哪里？这是个问题。

 

用户就在那里，看得见摸（这个容后再论）得着，那么需求呢，在用户的脑子里，用户的办公桌上，用户的办公室里，用户的工作车间？进驻项目现场，需求哪里都是，但是看不见摸不着，就得我们想办法从我们能获得所有渠道去搜集，调研，整理，总结。

 

很多时候想当然的想法就是，问用户呗，给他们做软件，他们还不知道想要什么么？按照他们的思路，要求，不就一切ok了？

 

但是很现实的是，很多用户也不清楚他们到底想要一个什么样子的软件，有哪些操作。有的时候是根本没有想法，毕竟他们平时接触的软件系统就很少，对这方面认知不多，有的也许是还有些想法，但是表达上又会出现问题，说不清楚，没有一个能动手操作的东东，光是让凭空去说，换个角度考虑，也确实是难为他们了，这个时候就非常让人郁闷了。

 

这还是比较配合的用户呢，起码他们在为软件系统最后的成型在努力。遇到哪些不配合的用户，特别是心里有着自己小九九的，对软件系统上线排斥的，更是让人想发飙。但是用户是不能得罪的。你得想办法，找到突破口。

 

怎么让用户配合，这个就没有一个放之四海皆准的办法了。比如有的情况是，整个项目里面利益关系错综复杂，也许是这个领导力推的项目，但是另一个领导偏偏两人不对付，在项目上也有发言权。有的是部门之间的博弈，想要在项目上为本部门争取更大的利益。有的基层的工作人员认为这个项目平白无故的增加了他们的工作量，心里不痛快。等等。就需要好好分析原因，只要是我们的力量能够解决的，哪怕是能得到缓解的，都要去努力，找到解决办法。

 

比如，认为增加了他们的工作量，就得好好的去解释了，项目上线后的种种远景展望，获得用户的理解，让他明白，现在配合项目工作，增加了工作量，都是暂时的。之前的项目就是这样，一开始很排斥，想办法解释后，将信将疑，在部分功能上线后，终于开窍，之后工作的配合就很积极了。

 

领导之间的矛盾。我们干涉不了，如果不是根本性的，项目主管，销售就需要努努力，而我们，就是要把工作完成的尽量漂亮，起码让销售领导说话有底气。

 

部门之间的博弈，从负面角度来说，确实会带来不可预知的风险，但换个角度，起码这些部门为了自己的利益，特别是部门领导，都会比较积极的关注和参与项目工作，这也算是“因祸得福”。我们需要做的是好好分析业务，搞清楚他们争论背后真正的关注点在哪，如何在系统中去做权衡，避免出现重大影响的风险。

 

项目里面，人是最复杂的因素。开发过程中，项目成员是，项目需求调研，项目验收测试，用户更是。