凡是搞软件开发的都得和用户面对面交流，了解需求。运气好的时候用户比较有水准，一开始就能给你个很详细的文档。不过一般来说没有那么理想的情况。就算有，还是得对着文档和用户好好交流一下。项目开始之前，先从其他角度，通过文档或者类似的系统了解一下大概的业务和工作流程，是无可厚非的。根据自己的理解进行整理，可以作为需求调研时的辅助，可以事半功倍。按理来说，了解需求的时候，我们都是听众，用户是讲师，可总有些实际情况不是这样。

      有那么一种人，总是在嘴上挂着“从用户角度出发考虑问题”，总以为自己是业务领域的专家（有时嘴上不一定这么说），凡是都要我们先假设一下用户的流程。当然我不是说假设一下用户的流程有什么问题。有时候，适当分析，假设一下用户的业务流程，能方便我们需求调研时引导、帮助用户更加清晰地表达出自己的意向。本来了解需求嘛，让用户多说说，把他的想法和疑惑都表达出来，不就结了。可是就有那么些人喜欢和用户比口才，只要能插得上嘴的地方都要出来添油加醋一番，那架势比参加演讲比赛还精神。

      总有些项目领导做了一番假设之后，自信满满地来到用户面前，在用户介绍业务的时候不断打岔，时不时跳出来“wait，这里我补充一下”，“**，你要注意一下，这个地方很重要和你负责的模块很有关”，“这个术语容易造成误解，我们改叫**吧”……个人觉得，这种做法其实也算一种不尊重用户的表现，频繁打断别人的说话增加自己的补充或是理解，并不见得能让同行的开发人员对需求有更深的理解，甚至有时还会误导用户。个人认为，最好的方式是耐心听完用户的介绍后，项目组成员进行讨论，然后各个开发人员有针对性地去了解自己的问题。如果项目负责人真的有那么深入的理解，也应该在小组讨论时，引导具体的开发人员，去提出自己的问题。这样既可以让用户觉得心理舒坦，也可以让开发人员更充分了解了用户的思路。

      还有一种人，虽然知道自己不是业务专家，但还是要按照自己的既定思路，和用户狂侃，似乎抱着一种“如果我说不出点什么，用户就会觉得我没有用心做事”的想法，一定要从这里引申到那里，从现在说到将来。当然，我不是说这种引申有什么不好，还是那么说，得有个度。做企业信息化，有些团队可能已经有了自己的积累，除了拥有领域专家外还有一定的技术沉淀，所以一听到用户的需求，就可以告诉用户“您所说的问题我们已经有了一个很好的解决方案，而且如果您……会带来……好处”。对于刚起步的团队，一开始就好高鹜远，一心想着借此机会一仗成名，生怕漏了什么没说显得自己技不如人。用户可能很开心，因为他很开心“物超所值啊，我就给了这么点钱，也有人愿意做这么多工作。”不过呢，言多必失，不了解业务的情况下，指不准原形毕露，用户的心立马凉半截“完了”。作企业级的东西，再小也不可能一步到位，一次成型。可怜的开发人员，本来就面临严峻的挑战，突然间被引申出去不少，更加郁闷。到了交货时间，继续拖吧，告诉用户“由于……所以……开发过程中有很多困难，希望再延期一下”。于是乎，恶性循环开始。在原定时间内，增加了一些新的任务，时间更紧了；某些用户被误导或是被灌输后的临时想法，发现和实际业务不一致，需要修改；项目延期，赶工使bug增加。

      最可恶的就是之前说的那种喜欢臆测用户需求的人（这种人其实心里老觉得说不出点啥就会让用户觉得没用功或做不好事情）。这种人当上领导，项目组肯定遭殃。有事没事就喜欢召集项目组成员“我们现在来讨论一下。”然后就开始他的长篇大论，虽然图文并茂，说得头头是道，但就是没有经过考证。你想和他提点意见，说这个东西可能不用这样，他还会说肯定是这样。最有意思的是他嘴上还会说“我们都不是专家，先假设一下”，那还不如直接去和用户交流来得快呢。再碰到糟糕点的项目组负责人，根本不管什么用户了，按照领导的假想满头大汗狂写了一阵，还不三不四，直到过了n久以后要验收了还有很多流程还没有真正由业务人员使用过或者有些一经使用就被咔嚓了。但是往往越是这种情况下，一边开发，一边还能加近些领导自己的想法。试想这种项目要到什么时候才是个尽头啊。我接触的最典型的是，开发组在抱怨，用户也在抱怨；开发组希望早点验收，摆脱这个包袱；用户希望早点验收，然后把这个破烂玩意丢到一边去。（当然这个可能是我说得严重了些）

     软件开发是一个迭代的过程，不论多小的项目都不应该抱着一次成型、一步到位的心理。用土一些的话说：如果能一次就把软件做好，还赚什么钱啊，有些功能可以日后升级时候再加，小改不要钱，大改收点升级费。说得动听些的就是：即使是用户本身，他也不一定就是领域专家，他也在信息化的过程中逐步完善自己的理解，不可能一次就提出所有正确的需求；开发人员同样不是领域专家，即使是，也不可能将一个企业的业务套到另一个企业上；开发人员和用户在开发过程中都不断补充自己，提高自己的认识。

     软件开发所要做的事情其实很简单：1、跑到用户那里认真当听众，不要怕用户怎么看，不懂就问。2、完全按照用户的需求先实现原型（不管做出来的东西是不是很简陋）。3、带着原型再到用户那里当听众，让用户来批斗。4、修改。5、重复3和4，直到项目结束。

     最后声明：本文纯属发发牢骚，最近做得真有些郁闷了。希望偶的牢骚可以给大家提个醒，不要在自己去了解需求时也去显示自己的口才。文中有什么不妥之处望大家指正。

来自：莫把需求调研当作演讲比赛

分类： 软件工程 项目管理 系统架构 软件测试