跟客户谈需求时，应注意什么

跟客户谈需求时，应注意什么
在做项⽬时，经常会碰到这样的事情.
客户向我们反映在和你们的⼯程师谈论需求时，他们总是满⼝答应没问题。

可是，当他们做好以后，拿过来⼀看，根本就不是这么回事。

⽽开发⼈员也在诉苦：⽤户什么都不懂，⽽且他们的需求⽼是变动，时间⼜这么紧,你让我们怎么办？
我觉得如果开发⼈员在做需求分析时,如果注意以下⼏点,也许可以避免被动的局⾯.
1、掌握相关的⾏业知识
在和客户沟通之前，最好了解⼀下相关的⾏业知识。

有⼀个项⽬管理⼈员说：⾏业知识可有可⽆，作为需求⼈员，最重要的是和客户沟通。

最好把客户讲的东西都记下来。

然后，由项⽬组决定后，再把意见反馈给⽤户。

这种沟通⽅式，既不能有效的发现问题，也容易延误项⽬时间。

案例：⼩A某名牌⼤学毕业，公司为了锻炼他，特意安排他和⼀个⽐较重要的客户进⾏⼀次沟通。

⼩A和客户电话联系，商定了见⾯的时间和地点。

西装⾰履的⼩A提前⼗分钟来到了见⾯的地点。

⼀番客套之后，⼩A和客户就开始进⼊话题。

客户开始谈他的需求，从项⽬背景到项⽬⽬的，从业务流程到相关部门和⼈员。

客户兴致勃勃地说着，⼩A⼿忙脚乱的记着。

客户停下来，问⼩A你觉得我的观点有什么需要补充吗？⼩A⽼实地回答说，我对业务还不是很熟悉。

客户⼀下兴致全⽆，对⼩A说，等你对业务熟悉了，再来找我把。

2、重在沟通
沟通的⽅式可以是访谈和调研、会议、电话、电⼦邮件、⼩组讨论、模拟演⽰等不同形式。

我的意见是最好是与客户⾯对⾯的沟通。

⾦庸武侠⼩说中的⾼⼿过招，都是⾯带微笑，不露声⾊，⽐拼的是内⼒。

⾯对⾯的沟通，就是⽐拼内⼒。

所以，⼀定要把准备⼯作都做好了。

沟通其实也是在相互妥协。

对⽤户合理的要求，要尽量满⾜。

⽤户的⼀些不合理的要求，要想办法避免。

要委婉地提醒⽤户，如果这样做，可能要增加项⽬时间，或者对运⾏环境有更⾼的要求。

沟通⼀定要有记录，对于交流的结果还可以进⾏分类，便于后续的分析活动。

3、深究细节
不要等到项⽬做好后，才让客户发现问题。

客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项⽬承担⽅没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的.这时，在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。

既然是需求的更改,那么就需要增加项⽬成本(资源)或延长项⽬时间。

我看过⼀篇⽂章,说要要想项⽬成功,就得和⽤户建⽴亲密的伙伴关系.可是,这种以需求的更改为理由让⽤户从⼝袋⾥掏钱,亲兄弟也不⼲阿.
所以,需求分析不仅仅是拿到客户的需求，更重要的是还需进⾏分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

需求是最重要的⼯作，也是最⿇烦的。

客户是不懂需求的，他们的脑海⾥⾯没有这个概念，他们只希望你做出能⽤的系统，⽤着顺⼿就好我认为做需求有⼏个地⽅是⽐较关键的 1.⼈际交往能⼒。

这是最根本的不⽤多说
2.了解需求后及时做出demo让客户确认，确认后要签字。

这⼀点⾮常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨⼤浪费；签字是为了让客户认真对待这个demo
3.能⽤就好，不要过多追求。

程序员往往追求完美，想⼀下⼦把⼯作做到位；⽽最有效率的⽅法是尽快看到结果然后再慢慢完善。

在项⽬初期需求会经常改变，这样的⽬的也是避免把过多时间耗在⽆⽤的需求上。

做过软件的⼈都听过这样的抱怨：变化太快，软件系统经常要修改，都连续加班⼏个星期了......
通常⾯对这样的问题，要如何解决呢?
⾸先，问题的根源是：需求不断变化。

很多⼈都有这样的经历，在捕获需求时，根据客户的阐述，做了记录，然后开发出了软件，客户却说很多地⽅不符合他们的意思，⼜要求修改。

我们分析⼀下捕获需求过程中存在的问题。

客户很可能对软件⽅⾯的知识知之甚少，他并不知道你需要知道什么。

⽐如说，⼀个业务流程，从业务逻辑到能转化成软件实现很可能会有问题。

这就是所说的信息化过程中需要进⾏的业务改造，因为能输⼊计算机，并输出结果的⼀定是能进⾏形式化处理的内容，这也是很多企业员⼯抵制信息化的原因之⼀，因为信息化会导致⼈的因素会被相对削弱，他们的⼯作过程也会完全被透明化。

这样，我们就⼀定要让客户知道你要知道的是什么。

如何做到呢?
对于产品类的项⽬，你的客户不是⼀个，那么就要⼴泛的去征求意见，需求调查问卷通常对全⾯了解客户需求有⼀定的作⽤。

对于特定客户，需要和他们直接沟通交流。

和客户交流要注意⽅式⽅法，不能盲⽬约见，下⾯是⼀些⾏之有效的⽅法。

⼀、会⾯前做充分的准备
通常会⾯前的问题列表准备时间要远远多于会⾯的时间。

通常客户在连续和你交谈2个⼩时之后，就会失去热情和耐⼼，这是⼤部分⼈的共同特点。

所以充分的准备⼯作很重要。

如果你去客户那捕获需求，通常客户会说，我需要做⼀个什么样的系统，然后我可以⽤它来做这个，那个，还有那个......，然后就不知道该说什么了。

这时，你⼀定要拿出事先准备的问题列表，针对每个⼤的功能的每⼀个功能点进⾏提问，⼀个都不能放过。

对⾮功能的需求也同样不能放过，如客户需要的系统⾄少连续运⾏多少⼩时不出问题，系统在若⼲数量的访问者访问时的响应时间范围等。

如果你在会⾯前没有对客户提供的资料，表格等进⾏全⾯研究，对客户需求就不可能调查全⾯，你可能需要反复去约见他，这样你会给
客户留下⼯作效率低的印象，他对你会逐渐的感到厌烦，对你未来的⼯作表现会失去信⼼。

⼆、让客户打开话匣⼦
对客户进⾏提问，引导客户说出他们的需求，是⾮常关键的，这⾥⾯的学问也是很⼤的。

有⼀些⼈通常会问这样的问题：“你们的⼯作流程是什么样的?”，这种问题是⾮常经典的⽆效问题。

当你向客户提出问题的时候，你可以先进⾏换位思考，如果有⼈问你这个问题你该怎么回答呢?是不是很好回答呢?如果连你也觉得这个问题并不好回答时，就需要考虑换个问法了。

通常⼈们在谈论⾃⼰很熟悉的东西时，都会有说不完的话，对于客户⾃⼰每天做的⼯作，他为什么没办法对你谈呢?
问恰当的问题，问能让客户打开话匣⼦的问题，你就胜利了。

这时你会⾯前的准备⼯作就显得尤为重要了，你要针对他们要做的软件的功能，⼀部分⼀部分的问，不能着急，要深⼊，并细致，对于他们如何处理这些事情的操作习惯等都要重视，因为要改变他们的习惯，让他们适应你的软件的⼀种新的操作⽅法通常是会降低客户满意度的，甚⾄他们会要求你进⾏修改。

对于你对某些功能的猜想和假设，也⼀定要问客户，是不是根本就不需要，客户有时会碍于情⾯不好意思说出你的想法是没有必要的或是错误的，这时你⼀定要⾜够敏感，并勇于否定⾃⼰，这样会减少不必要的开发⼯作，也会给客户留下你很尊重事实的良好印象。

三、千万不要浪费客户的时间
和客户⾯谈时特别要注意⼀点，就是千万不能浪费客户的时间，让他觉得⾮常⽆聊，这是捕获需求最⼤的忌讳。

⼀旦你犯了这样的错误，你再想约见他就难了，他很可能不愿意再和你会⾯了。

尤其是企业中的领导，他们通常是⽇理万机，能抽出时间和你会⾯，你应该感到很荣幸，因此要格外珍惜会⾯的时间。

这也是很多作需求的⼈员常常抱怨的问题，“客户经常没时间见我，我有什么办法”，如果你遇到了这类问题，你⼀定要反省⼀下⾃⼰，是不是曾经犯过这样的错误，下次⼀定不要再犯了。

四、搞清能正确回答问题的⼈
不同的问题需要问不同的⼈，需求中有很多是细⼩的操作级别的问题，也有很多是关乎全局的问题，这就要求⼀定要搞清楚什么问题去问什么⼈。

很多捕获需求的⼈员抱怨说，“客户答不上这些问题，他们⾃⼰都不知道要怎么做”，如果你碰到了这种事情，就要反省⼀下，你问对⼈了吗?
客户中有⼀些是⼤⼲部，有些是中层管理⼈员，还有操作⼈员。

对于操作细节上的问题，⼀定要去问那些负责操作的⼈员，他们会更清楚每个步骤需要怎么去操作，如果你去问⼤⼲部这些问题，你通常会被搪塞，或者以⼯作太忙，还有其他得事等原因被打发掉。

对于关乎全局的问题，操作级别的⼈员给出的答案通常是不权威的，即便他们回答了你，你也⼀定要去⼤⼲部那⾥确认⼀下，再开始开发⼯作，否则你会后悔的。

五、发挥原型的效⼒
原型对于提⾼客户对软件的认知程度有很好的效果，他能使客户对软件有⼀个直观的认识，⾯对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。

对原型的修改，再确认，最后得到稳定的原型，这些⼯作会让需求更稳定，减少很多实施⼯作中的反复修改⼯作或者返⼯。

六、充分利⽤需求确认会议
需求确认会议通常由全体涉众(利益相关⼈)参加，这可是个确认需求的难得的机会，⼤家能聚在⼀起，这样的机会其实很难得，所以⼀定要珍惜。

在这种会议上，⼀定要先针对全局性的问题(与⼤家都相关的问题)进⾏交流，千万不要针对部分⼈感兴趣的问题讨论个没完没了，那样的话，不感兴趣的⼈会⾛开的，那样你再想征求与他们相关问题的意见时就找不到⼈了。

对于只跟个别部门或⼈员有关系的问题你可以单独找时间根他们讨论。