作为开发人员,难免会需要直接接触客户，那么这就导致了需要能理解客户说的需求，能挖掘出客户描述中，真正需要的功能，在这么多年与客户的沟通中，有些客户会整理出需求的简单文档给你，有些就只能是口头说明，而且如果经过产品经理的转述之后，如果产品经理没办法整理明白，就会发觉了一个很奇妙的事情，那就是：你看到需求≠产品经理心里理解的需求≠客户口头说的需求≠客户心里实际的需求，当然我这里没有任何贬低产品经理的意思。
（案例会不定时补充）
案例一：
某客户说要做一个ERP，说了特高大上，听着就觉得大型系统， 后来按进销存等系统的功能规划参考用户给过来的文字整理了一份需求给到客户，客户说太复杂，，后来我跟客户实际微信在线语音了一次之后，发觉，客户只是想要一个类似于项目进度管理的功能+一点点的库存管理就行，连个进货单跟销售单都省了。。与一开始看到的功能差了不是一星半点
大部分客户只能是有一个朦胧的概念说要一个XX东西，当实际到开发阶段的时候，朦胧的需求就会使得开发周期完全没办法确定，而且客户也会边想边改，这就痛苦了，因此，整理出了几条经验:
1、首先要问客户三个问题：是否客户有正在用的系统？这套系统主要想解决什么样的问题？是否有心目中可以参考的第三方系统？
问这三个问题，第一如果客户已有系统了，那么重点就在于客户对现有系统哪里不满意，还需要增加什么东西，这样一来，可以节省很多力气，第二，客户有时候只是一个朦胧的需求，但是他们为什么需要一套系统，以及想用这套系统解决目前哪种问题，这个大部分客户是可以说出来的，比如：想规范审批流程啊、想让财务报表和库存能准一点啊、想对目前公司的流程进行电子化省的员工随意走流程啊、又或者是想搭建自己的商城对外销售啊等等，有了这个前提，那么后面才可以聊的下去了，并且功能的大体范围可以确定下来。
2、不管完整的系统功能有多复杂，，一定要跟客户谈分期上线，否则就跟自己搬石头砸自己的脚一样，第一期尽量外部功能少，因为第一期还需要预留时间做系统的一些基础架构的设计啊，数据库表单的设计啊，还有初期上线的调整期，这些都是需要时间的。
3、别老是觉得客户甲方是傻X，，换个思路想想，人家都能搞清楚了，还要你干嘛？你的价值不就是替客户解决问题。
4、如果是做的商业系统的，一般可以有两条线可以串起整套系统的流程：
一条钱流，一条物流。
钱流是指整套系统中有多少个流程口是进钱的，比如：商城的客户订单、进销存系统的销售单等等；
物流是指整套系统中，商品的库存是怎么流动的，哪个节点扣，哪个节点增加，比如商城的客户订单或发货单，进销存系统的进货入库单或销售出库单等等。
一般来说绝大部分商业系统都是要解决钱跟库存的管理，一般来说，这两条线，如果跟客户确认，，客户是可以明确告诉你的，因为客户原本就是按着这样去运行的，把确认的流程画出来或者整理成UE图，，基本上就成功了20%
5、要客户提供目前现有在有的所有表单（纸质的或者电子版的）的给你，并且单据上需要有模拟的数据，从客户给出来的单据上，大体可以看出这套系统中，需要为客户开发哪些单据，这部分也是客户可以明确提供出来的
6、通过上述几个阶段之后，大体上就可以整理出一份客户的工作流，并且这套系统的大框架的功能就可以确定下来了，再来就是一些细节的地方需要不断地跟客户核对，比如：商品信息是否有什么特殊的字段，不同的表单上的字段会不会有什么特别的字段需要注意的，权限要怎么管理（不是所有客户都需要权限功能，客户不需要就不要硬塞，没加钱的），在不断地与客户交流中，修正你手中的思维导图或者文档
7、一般如果客户公司比较正规的话，除了跟对接人确认需求的同时，还需要注意去跟财务部确认他们的真实需求，因为经验下来，财务部是最难搞定的，财务搞定了，其他部门就相对好解决一点，因为作为老板，一般最终就关心钱的事情而已，只要钱对了，其他都好说，而财务部通常是一分都不能差。
8、如果出现需求经常变动的话，一般有两种可能：
一是客户自己的经营模式经常变动（这个比较少，毕竟系统这东西不像设计图，是确定的，可以逆推的，跟各人审美无关）,这个亲身经历一个刚创业期的客户，模式三天两天变一次。；
二是初期整理出来的需求不是客户心理真正的需求（这个可能性比较大），一般文档是给公司内部人员自己看的，其实不要指望客户能看得懂UE或者思维导图实际要表达的事情。
因此，如果边开发，客户经常要求修改功能的话，频率比较高的情况下，最好停止开发，把需求从头开始跟客户再过一遍，否则就是越努力越凄凉，产品经理累，客户也累，开发更累
9、如果客户有打算通过系统管理生产流程的话，必须跟客户建议，初期先对仓库的生产出入库数量进行管理，等仓库人员对系统更熟悉了之后，再开始讨论怎么样管理或优化生成环节，因为：大部分生产环境的工人也好，操作人员也好，对IT是不熟悉的，并且最致命的一个问题是，国内的情况是，几乎没有多少家工厂的生产流程是特别标准的，大部分都是自己玩自己一套，因此，如果要做生产方便管理的话，优先确保仓库对生产的收发两端数量的准确，只有出入的数量准确了，当开始推进到生产环节的时候，至少前后两端的数量是准确的，那么出了问题，就查中间的操作流程，相对而言会比较容易查出问题。
如果一开始就整套上线，会出现的问题就是，生产环节的操作员，由于习惯问题，要么做错单，要么先记录纸质后录入系统，最终导致数量永远对不齐。
最后的最后，以上只是针对中小型客户，大型客户未接触过，不一定可用。然后对新入行做后端开发的同学一个建议就是，最好能多接触一点比如说ERP系统，进销存系统，因为这类系统，属于长流程，并且流程之间的衔接比较缜密，可以培养一些逻辑的思维以及跟客户的沟通能力，大部分互联网的系统都不会有太长的流程。