这个需求的目的是什么？

程序员每天最不希望见到的是什么，除了BUG，估计就是需求了。每当见到新需求，大部分程序员的内心是挣扎的。并不是因为不希望做，而是怕因为需求导致一连串的问题。小编深有体会。

下面是一个实际的案例：

某知名互联网公司，在早期开发了一款音频播放器，在每一次用户关掉播放器，第二次打开的时候，播放器会在上一次关掉的播放位置开始播放。产品上线后，引发了很多用户的投诉。不认可这种方式。 后续通过了解，发现这一批用户是音乐发烧友，都是听歌曲的。这样不难理解用户的痛苦了，你一打开播放器，就从歌曲的中间高潮开始，那谁不爽？ 于是，新的需求来了，每一次播放器被关闭后，下一次都从关闭的那个音频源的最开始进行播放。 本以为平息了，可以新功能上线后，没过多久，产品又引发了大批量的用户投诉。不认可修改后的这种方式，甚至抗议更大。 后续对这一些用户也进行了沟通了解，发现这一批用户是听评书的。这下啥都不说了，人家不烦才怪。 紧接着，团队彻底的分析了下，针对音频源，时长，做了不同的判断，针对不同的类型做不同的处理。这样，问题才得以解决。

从上面的案例中，在第一次提出产品要进行修改的时候，相信产品人员提出的需求是：请把播放器的逻辑进行调整，播放器被关闭后，下一次都从关闭的那个音频源的最开始进行播放。可能当程序员接到这个需求时，自己也是想不到，这个需求是白做的，做了后面还是要改。这确实是很多程序员郁闷的地方。

但是程序员能否自己把关需求，减少无谓的工作和返工呢？答案一定是能。关键是是否足够的换位思考，找到根本原因。

我们再看一个案例。

某团队给一个知名酒店做了一个酒店的管理系统，提供给酒店的工作人员进行管理操作。有一天，团队收到了酒店方的一个需求：希望后台管理系统有一个新的模块，其中会展示酒店每一层的平面图，清晰的标识出每一间房间，并且用不同的颜色区分该房间当前是否有人入住。 这个需求涉及到的工作量是不小的，首先要用工具画好平面图，以及做上后台交互，也要区分颜色，前端也要做校验。这时团队成员开始和酒店方咨询需求的细节，很多人问了一些问题: 1. 除了这些还需要有什么功能么？ 2. 颜色有什么限制呢？最好提供下你们觉得喜欢的颜色 3. 每一层一个页面，还是所有楼层都在一个页面？ 酒店方一一给出了解答，这时，团队一个刚毕业的同事，唐突的问了一个问题：这个需求的目的是什么，为了解决什么问题？ 团队很多“老司机”开始苦笑，不过酒店方还是给出了解答：因为我们想知道有哪些空的房间是相邻的，这样就可以满足一些想入住的人员的需求，他们希望住到相邻的房间。 这个时候团队有人开始沉默了。 因为大家都逐步意识到现在酒店方人员说的才是原始需求，而之前提出的不过是他们认为的解决方案。而这个原始需求是很好满足的，只要在后台查询SQL稍作调整，就能很轻松的查出相邻的房间。这个需求两个小时之内就可以完成了，也根本就不用搞什么平面图来实现。

为什么我们的需求经常会改，原因有很多。但是很重要的一点，就是因为提出需求的同事，很多时候提出的并不是原始的需求，而是他们认为的解决方案。很多时候程序员就会被绕进去，从一个错误或者并不完善的解决方案中越走越远。

这个需求的目的是什么？这句话看似简单，但是至关重要。找出客户心中的原始想法，然后针对原始需求，定制一个完整的解决方案，可以极大的减少反复的工作，并且通常能增加客户满意度。程序员的工作也会慢慢“舒适”起来。

说白了，也就是换位思考，多理解客户的想法。其实这种情况在工作中出现的几率是很大的。为什么会这样，原因也有多种：

1. 有时候客户会有“不给产品人员添麻烦”这种心理，就在原始想法出来后，自己想一个解决方案，觉得这样需求就显得简单了。而产品人员同样会有这样的心理，不给程序员添麻烦，想把需求简单化。但是其实效果是适得其反的。

2. 人性本质。人越大，越是包装自己的原始想法，这很正常。一个3岁的孩子，口渴了会说：妈妈我要喝水。但是一个30岁的男人去到丈母娘家，口渴了，恐怕就不敢这么直接，可能会说：妈，我听说您这买了上好的茶叶，可以品尝下么？

3. 也不排除一些强势的客户或者产品经理，认为我说的方案就是对的，原始需求只要我知道，我的下游就是给我完成任务的。

4. 小编没想到的种种原因。

程序员并不是流水线工人，更多的是系统的主导者。每天的工作“常规”化，是程序员的大忌。要清晰的知道解决方案和原始需求的区别，当接到需求的时候，搞清楚到底是原始需求还是解决方案，多思考，多沟通，这样一定能规避一些常见的问题。 

———————————————————