Article source: Official Account-Intelligent IT System.
What programmers don't want to see every day, except for bugs, it is estimated that it is the demand. Whenever new requirements are encountered, most programmers struggle in their hearts. It's not because you don't want to do it, but because you're afraid of causing a series of problems because of demand. I have a deep experience.
Here is an actual case:
A well-known Internet company developed an audio player in the early days. Every time the user turns off the player and turns it on for the second time, the player will start playing at the playback position that was turned off last time. After the product was launched, many users complained. This method is not approved. Through follow-up understanding, it was found that this group of users are music enthusiasts, and they all listen to songs. In this way, it is not difficult to understand the pain of users. As soon as you open the player, it starts from the middle climax of the song, so who is not happy? Therefore, a new requirement comes. Every time the player is turned off, the audio source will be played from the beginning of the turned-off audio source next time. I thought it subsided, but after the new function was launched, it didn't take long for the product to trigger a large number of user complaints. Disapproval of this revised method is even bigger. We also communicated with these users in the follow-up, and found that this group of users listened to storytelling. Don't say anything now, it's strange that people don't bother. Then, the team thoroughly analyzed the audio source and duration, made different judgments, and made different treatments for different types. In this way, the problem is solved. |
From the above case, when the product was first proposed to be modified, I believe that the demand put forward by the product personnel is: please adjust the logic of the player. After the player is turned off, the audio source will be turned off next time. at the beginning of playback. Maybe when the programmer received this requirement, he didn't even think that this requirement was made for nothing, and it still needs to be changed later. This is indeed where many programmers are depressed.
But can programmers manage their own needs and reduce unnecessary work and rework? The answer must be yes. The key is whether there is enough empathy to find the root cause.
Let's look at another case.
A team made a hotel management system for a well-known hotel and provided it to the hotel staff for management operations. One day, the team received a request from the hotel: I hope that the background management system has a new module, which will display the floor plan of each floor of the hotel, clearly identify each room, and use different colors to distinguish the current room. Is anyone staying. 这个需求涉及到的工作量是不小的，首先要用工具画好平面图，以及做上后台交互，也要区分颜色，前端也要做校验。这时团队成员开始和酒店方咨询需求的细节，很多人问了一些问题: 1. 除了这些还需要有什么功能么？ 2. 颜色有什么限制呢？最好提供下你们觉得喜欢的颜色 3. 每一层一个页面，还是所有楼层都在一个页面？ 酒店方一一给出了解答，这时，团队一个刚毕业的同事，唐突的问了一个问题：这个需求的目的是什么，为了解决什么问题？ 团队很多“老司机”开始苦笑，不过酒店方还是给出了解答：因为我们想知道有哪些空的房间是相邻的，这样就可以满足一些想入住的人员的需求，他们希望住到相邻的房间。 这个时候团队有人开始沉默了。 因为大家都逐步意识到现在酒店方人员说的才是原始需求，而之前提出的不过是他们认为的解决方案。而这个原始需求是很好满足的，只要在后台查询SQL稍作调整，就能很轻松的查出相邻的房间。这个需求两个小时之内就可以完成了，也根本就不用搞什么平面图来实现。 |
为什么我们的需求经常会改，原因有很多。但是很重要的一点，就是因为提出需求的同事，很多时候提出的并不是原始的需求，而是他们认为的解决方案。很多时候程序员就会被绕进去，从一个错误或者并不完善的解决方案中越走越远。
这个需求的目的是什么？这句话看似简单，但是至关重要。找出客户心中的原始想法，然后针对原始需求，定制一个完整的解决方案，可以极大的减少反复的工作，并且通常能增加客户满意度。程序员的工作也会慢慢“舒适”起来。
说白了，也就是换位思考，多理解客户的想法。其实这种情况在工作中出现的几率是很大的。为什么会这样，原因也有多种：
1. 有时候客户会有“不给产品人员添麻烦”这种心理，就在原始想法出来后，自己想一个解决方案，觉得这样需求就显得简单了。而产品人员同样会有这样的心理，不给程序员添麻烦，想把需求简单化。但是其实效果是适得其反的。
2. 人性本质。人越大，越是包装自己的原始想法，这很正常。一个3岁的孩子，口渴了会说：妈妈我要喝水。但是一个30岁的男人去到丈母娘家，口渴了，恐怕就不敢这么直接，可能会说：妈，我听说您这买了上好的茶叶，可以品尝下么？
3. 也不排除一些强势的客户或者产品经理，认为我说的方案就是对的，原始需求只要我知道，我的下游就是给我完成任务的。
4. 小编没想到的种种原因。
程序员并不是流水线工人，更多的是系统的主导者。每天的工作“常规”化，是程序员的大忌。要清晰的知道解决方案和原始需求的区别，当接到需求的时候，搞清楚到底是原始需求还是解决方案，多思考，多沟通，这样一定能规避一些常见的问题。
———————————————————
公众号-智能化IT系统。每周都有技术文章推送，包括原创技术干货，以及技术工作的心得分享。扫描下方关注。
