如何处理客户需求——实施经验漫谈.doc

处理客户需求需要知道的三件事 客户提出的需求很少有不合理的，往往是客户提出的实现办法并不能真正解决问题而已；客户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和服务而已；客户提出的需求往往有简单的解决方法，如果你的答案很复杂，往往不是正解。如何分析客户的需求做实施没有一帆风顺的，对于现有产品，客户提出不满，提出这样那样的问题是常有的事。 如果客户提出一个需求，往往表现为强烈需要一个功能，这个时候很多实施人员可能开始考虑这个功能是否合理，是否容易实现，并以此为基础和用户展开谈判。一个有经验的实施人员这个时候首先应该思考客户为什么有这个需求，不要光看需求的功能描述。 首先应该考虑的是客户这个需求的本来面目是什么，有时客户的需求也是客户自己加工过的，比如客户认为在某个表单加个字段就可以实现这样一种业务，但实际上可能不是那么简单。也就是从需求出发把客户要解决的业务还原，然后再站在全局业务的高度考虑我们到底要解决的是什么问题。这个时候我们可能就会发现很多时候用户提出的需求往往是管理上的漏洞造成的，技术手段并不能解决业务问题，属于不合理的需求。 这个时候我们并不能轻易拒绝用户的需求，而是要和用户一起推导直到他们发现自己的方案并不能根本上解决问题，然后探讨真正解决问题的办法，这样用户不但会收回自己的想法，还会建立对你分析能力的认可。如果客户需求是很合理的，首先应该考虑系统是否有现成的解决方案？很多软件在长期发展中还是积累了很强的能力，而实施人员未必能够了解全面，这个时候要抱定一个原则： 把现有产品功能用尽！ 要想把现有产品用尽往往需要创造性发挥，调动一切可以利用的工具和自己产品整合，包括操作业务的变动。 如果想到可以解决问题的思路，要立即与客户即时交流，验证。 很多时候用户是非常通情达理，只要你能给他一条路，他就会用。即使这条路现在很麻烦，用户的忍受能力也会超出我们的想象。 如果我们能够在未来版本中持续改善，还有可能获得极好的口碑。 但是很多时候用户提出的需求非常到位的指出我们系统中的不足，也是我们产品的软肋，也就是通过功能绕不过去，或者勉强能绕过去，但终究是不能长久的。这个时候还要记住另一个原则： 关键问题不要绕，一定要及早主动去协调公司资源去解决！ 对于一些关键性需求，往往它对提升用户的业务是非常有价值的，有时彻底解决才是正确的方法，变通实现可谓治标不治本，难免以后面对更复杂的问题。 实施人员往往都能意识到这个问题，但在公司内部解决和协调问题可能需要大量精力和投入，因而产生畏惧心理，结果耽误了项目，也影响了自己的绩效。还有很多人觉得项目现在有时间，等到了实施到这块业务的时候再解决，一拖就把解决问题的时机给耽误了。我们做信息化项目，对于客户的需求应该是一个负责任的态度，既不是一味听从客户，也不是一切都以软件不能修改为借口，这样是无法建立客户对你个人和公司的信任的，没有信任也不能指望会有一个好的沟通，好的团队来完成项目实施。有的时候，客户的需求清晰，而且也是很关键的问题，但是客户在项目中的投入远远不足以支撑相关需求的开发。 这个时候还要记住第三个原则：要解决的合理且关键问题，如果用户支付金额并不合理的情况下立即了解公司意见，并按公司意见和用户反复沟通。 很多时候公司考虑到市场影响，用户后续追加潜力，版本主动规划符合度等多方面的因素，会在项目中承诺解决问题，这个时候实施人员是幸运的，但还是要花费大量时间和用户沟通，确定需求实现的时间可以在双方的承诺能力范围内。 对于客户的需求，如果已经决定进行解决，那么在进行解决的时候，一定要搞清楚客户的需求。这部分的需求，不仅包括客户提出的需求，还包括客户潜在的需求以及客户自己尚未发现的需求。虽然这样会造成一定程度的项目范围蔓延，但是同时会未将来的实施带来的很大的收益，避免问题解决得不彻底不但不能得到用户的认同，还会怀疑我们的能力。更重要的是实施团队会获取客户的信任。 也有的时候公司根本无法承受过多的开发需求（很多管理软件公司的产品离成熟还有很长的路要走），这个时候我们不得不面临最痛苦的事情，去拒绝用户的合理需求，因为我们的公司资源还不能承受。 如果公司随意承诺实现，最终并不能实现，结果并不比不承诺实现好，至少后者是讲真话的人。 对于客户的需求，如果不能满足的时候，一定要清楚的告诉客户基于什么样的原因，不能解决或者拖后解决。 不要利用信息的不对称来蒙混客户。因为在很多的时候，你所认为的掌握的信息，客户很快就会掌握或者他已经掌握。如果采用蒙混的方式，可能会使得自己处于一个很尴尬的处境。 对于客户的需求，如果需要在商务上需要进行谈判，可以委婉的告诉客户。注意：在小的问题上尽可能不要动用商务谈判，如果客户总是被告知需要进行商务谈判，他可能会感到厌烦，在他们看来你是在不停的向他们伸手要钱。 应该