需求沟通与挖掘的原则
简介：需求是功能实现的起点（个人观点）。系统实现后的功能能否被客户承认，并能有效的推广使用，对需求的理解和把握绝对是最重要的一个环节。集团项目的工作经历，让自己对需求沟通与挖掘有了一些想法，在此分享，以供探讨。
1、需求沟通不要过多考虑实现难度 需求沟通的主要目的是去理解客户的需求，而不是去引导客户。即使意图引导也需要首先理解。开发人员或实施人员，容易犯的一个毛病，就是在需求沟通时，就开始思考如何实现。这样的沟通就不能理解到客户的需求，最终导致实现的功能不能满足需求，而需要再次改造甚至重新开发，产生了不必要的工作量。所以，需求沟通时，除了去理解和体会客户想要表达的意思，不应考虑其他。
需求沟通必然是个反复的过程，设计实现时的难度问题，完全可以在沟通后，需求理解和分析时考虑，然后在下次沟通时提出困难。 需求沟通是一个为了理解需求而进行交流的过程，沟通时以理解为目的，所有的思考都应该是为了去理解需求。
2、理解客户真正要解决的问题，客户提出的需求不一定是解决问题的最好方案 客户提出的需求往往是解决方案，而不是问题或业务规则。沟通时，如不加思考，后期实现了，客户虽然会接受，但也许会因为客户需求自身的漏洞，而导致很多需求变更。所以，沟通时不仅要理解客户要表达的意思，更要去挖掘需求背后的问题。 挖掘客户的问题，站在客户的角度去思考。沟通的结果，不仅是要知道客户想要什么，还要理解客户为什么要这些。一起讨论解决方案，达到共识，这样对双方都是最有利的。
3、先考虑解决实际问题，后考虑规划业务的实现 理解到客户需求背后的问题后，还需要考虑，这背后的问题是实际业务进行时的问题，还是为了实现业务规划而产生的问题。从实际的经验来看，仅仅只为了实现业务规划而进行功能改造，而后的结果是，功能设计得很好，却不适用于实际操作，导致功能不能广泛使用；甚至为了方便使用，又再次将功能进行适用性改造，最后，功能既不满足业务规划的需求，又不能完全的适合应用，不伦不类。
出现这种情况的原因，分析下便知，主要是客户是依赖改造后的系统，来推广规划好的业务。在下认为，这个过程应该是反向的。即客户规划好的业务，在自己的管理体系范围内普遍推广了以后，发现支持他们的系统有些不能完全适用了，此时便是改造系统的时机。过去规划中的业务，这时已经成为实际操作的业务。考虑实际业务进行时的问题，进行功能改造，系统的应用性将最大化。
总结：
目前自己负责的薪资模块，在这种理念下进行了积极的开发改造，经过培训，客户基本能接受系统的功能流程。在实际应用中，功能使用广泛，并且出现的问题较少，客户给与了积极的肯定。 集团项目有其特殊性，需求实现上采取的是尽量满足的态度，而且功能实现和后期维护都是由自己团队来担任。所以充分理解需求，并真正解决实际问题，最终才能客户满意，自己也便于维护，即达到双赢。
