在开发中经常会遇到这样的问题，就是一些需求方在对一些点进行描述的时候，会说：这个应该很简单吧，就跟xxx那种一样。在这种“很简单”逻辑上，需求方会在时间和金钱上进行压榨，让开发者很不爽。那么问题来了，为什么很多需求提出时对方会说“这个很简单”？

答案是：他就是个bitch! 文章完。

wuli吐槽之后，我们还是郑重其事的来谈一谈这个问题吧。这是一个严肃且值得深挖的问题，在普通人和开发者之间的鸿沟，通过这个现象可以表现的极其突出。

在程序员眼里，有些东西很简单，但是普通用户会“哇”的大叫出来；有些东西程序员眼里会很复杂，而普通用户会不屑一顾。这是什么逻辑，他们的简单和困难的价值观在什么维度上发生了逆向的判断？

1. 知识鸿沟

在普通人觉得很简单，而程序员嗷嗷叫苦的问题上，一定存在一个知识的坎，程序员会从具体的实现过程去考虑这些需求。比如一个很简单的功能，选择某个电影院可以被预订的位置。普通用户会掏出美团或猫眼，告诉程序员，就是这样，这样。但在程序员眼里，没一个动作都需要逻辑代码去实现，把这些实现组合在一起，可能就需要一到两天的时间，所以会觉得并不是那么简单。普通用户的脑海里没有这些知识结构，无法评估代码量和难易程度，因此和程序员得到的结果不同。

2. 注重结果与注重过程

普通用户更加注重结果，而程序员可能思考更多的是开发过程中可能遇到的问题。普通用户在想到一个功能点的时候，对它对难易程度的评价，往往是把对它的操作时间换算为难易度。比如一个划动效果，如果用户在多款产品中使用该效果都可以在1秒内完成，就会认为这个效果应该比较简单。而如果他们在使用一个很花哨，界面酷炫的应用，没一个渐变效果都要用到一两秒，那肯定会觉得这个应用会特别难。

普通用户在知识结构上无法理解编码过程，因此只能将难易标准转移到产品的体验感上。

3. 面向产品还是面向编程

说的更直接一点，用户面对的是成形产品，而程序员是生产这些产品。在用户的脑海里，其实已经有产品的形态，但是可能限于语言，无法表达出来。而程序员，实际上并没有产品的完整形态，而是有产品的组件，况且这些组件还要自己去编程。程序员在遇到不懂解码的用户时，必须去把用户提出来的需求解码为自己可以理解的编程目标，但是为了和用户沟通，程序员又使用了编码的逻辑，向用户求证自己的理解是否正确，用户接收到到信息难以处理，所以就会用错误的方法解码，导致沟通失败。

在普通用户和程序员之间需要一个角色，作为编译器，对用户的需求进行编译，使得程序员可以很好的理解，同时把程序员的报错信息翻译为用户可以理解的说明。这个角色，从很大程度上讲，就是产品经理。

互联网界都在捧产品经理，认为他们是“改变世界的人”。可实际上，他们就是下水道，来来去去都要从他们这里过。对于和用户直接接触的程序员，最大的建议，就是要待人宽厚，和用户逐个解释，把他当作朋友，如此而已。