程序员客栈3.2今晚即将上线，随着使用人数的越来越多，我们也累积了越来越多的用户反馈。我们的开发猿已经日以继夜了，可需要解决的问题依然越来越多。当然，这是好事，因为这意味着我们的用户和活跃度的确越来越高了，哥们儿要火了你知道吗？

　　客栈最近浏览趋势

　　另外一个方面，这也意味着，我们必须要从各类碎片化的反馈中，识别真正的需求，排列出优先级别并实现。要做到第一步，是识别真正的需求。

　　看到过两种截然不同的对待用户反馈的态度：

　　1-只听用户的反馈，只要用户反馈就记录下来大会讨论想办法满足。

　　2-不听用户反馈的需求，只听bug反馈。觉得用户不懂需求。

　　前者自不可取：，用户需要一匹千里马的时候，你去满足他；于是他又提出需要一匹万里马呢？后者也过于武断：用户在使用过程中即使没碰到任何bug，但就是用得不顺呢？我这么看：

　　用户提出的反馈，一般是基于使用过程中触发的问题（这是一个存在的事实）。他在和我们沟通的时候，很可能就忽略了告诉我们这个问题（事实）是什么，直接提出要求（经过自己的经验判断给出的方案）。

　　我们要做的，是先追问一句：为什么你会有这样的反馈？你碰到什么问题了么？

　　还原问题之后，我们再来判断什么样的解决方案更合适。也许用户的确牛逼，按照他的建议去做比我们自己的方案更好，那就改呗；也许用户的方案比较不完善，没问题，我们知道关键问题是什么了，只要我们能够更好地解决这一点，用户只会惊喜不会有意见。

　　以下为亲身经历的案例：

　　案例1：客户在发布项目的页面直接进入与客服对话的状态（恩，是的，目前我兼任客服:D)

　　客户A:我提交审核之后，你们还没有审核完成之前，应该要增加一个功能，我应该还可以修改项目呀，否则不方便。

　　客服喵：谢谢，您的建议我们已经收到。请问为什么需要增加这个功能呢？

　　客户A: 如果这个时候我的主意突然变了怎么办？

　　客服喵：&……&……%）￥#@￥#（平静一会儿） （然后再回复）为了避免我们审核通过和报价的项目，和您最终提交的项目不是同一个项目，由此产生更多不必要的纠纷耽误您的时间，提交审核之后请不要再修改了哦。如果的确需要修改，请直接联系客服，我们和您确认之后会先拒绝您的第一次申请，您可以在原有申请基础上修改好再次提交，然后我们再审核。

　　案例2：业务汪很着急地跑过来，要求增加一个新功能。

　　业务汪：后台管理增加一个功能吧，用户提交项目后我们可以帮他们修改。

　　产品喵：啥？我们修改用户的项目？为什么？

　　业务汪：客户第一次填，很多内容没有填写好，我们的填写引导页写得不够，我请他们重新填；第二次又填错了，他们自己也懒得改，让我直接帮他们改了，否则他们都懒得发布项目了。。。

　　产品喵：如果我们帮他们修改项目，意味着修改完之后还要得到他们的确认，这在整个项目流程上便增加了两步，况且，很少能够做到一次修改完成的，我们的流程会变得很重，之后多少个人都服务不过来。

　　业务汪：也是，可这个问题很紧急，我如果不在后台帮他们修改了他们也不愿意做了呀。

　　产品喵：这个问题，对于你而言，有两种解决办法：

　　1）通过远程桌面控制工具，控制他的桌面帮他填写完然后让他检查，提交；

　　2）让他临时修改自己密码，再把账号密码给你，你修改好了之后还给他，让他核查没问题后提交，然后修改回自己的密码。对于产品本身而言，我们要做的是加强产品的引导，尽量减少用户犯错的机会。你看（喵调出已经好几个屏幕长度的待优化列表），我们上线前已经列下来了，只等完成这次的支持，马上开始网站的优化。

　　案例x: 又一位客户上线进入对话框。“我觉得你们需要增加一个功能。。。”