程序员：少听些用户抱怨吧
如果一直以来你都是在一个封闭的小屋子写程序，从来没有接触过用户，收集过反馈，那么我建议看看刘老师的“程序员：多听听用户抱怨吧 ”，如果你发现自己80％以上的时间都在满足个别用户的一些看似大众化的BT需求的时候，并因此极其痛苦而无法推动具有建设性和战略性的的工作时。我建议不妨这么来看待这个问题。
1， 用户是只想自己，不想全局的
2， 用户自己也不知道自己想要什么
3， 用户提出要的并不是他真正需要，也不一定是他会去使用的
4， 性价比是需要考虑的
5， 商业意识是需要考虑的
6， 可发展空间是需要保留的
7， 适当的功能应该在适当的用户量级别和用户生态结构和用户活跃度下提供
8， 听取用户意见的心态是一定要的，听取的渠道一定是要广泛的，但是，满足任何一个需求一
定是要慎重的。
9， 系统健壮是第一位，因此而牺牲某些东西和功能是正确的
10， 用户确实能提出非常有价值的建议，但是
11， 我们是做游戏平台和制定游戏规则的。首先关注你的目标和核心用户
12， 你满足不了所有用户
13， 应该撰写开发者日志，管理员日志，产品简史日志，但是这些日志开发匿名或公开发言的时
候一定要慎重。一个可随意公开发言的论坛群体极其容易放大一些微小的抱怨，并且形成不
良的和不真实的反馈，可能你看到的意见大多说是抱怨的，或者抱怨的意见总是容易被放大
然而，这并不是真正的整体用户对产品的态度。说你好的用户总是习惯性地保持沉默，说你
不好地总是在习惯性地表达
13， 因为，群体的智力水平是低于群体平均智力。流言蜚语和错误总是在无声无息中被夸大了。
如果A用户提交了一个Bug（甚至可能不是，或者极其微小），B用户提交了另外一个Bug，C
用户提交了另外一个Bug，当D用户来了之后，看到，A，B，C提交的Bug，可能会迅速被误
导，并并放大这种抱怨。
14， 你应该有长远计划
15， 区分最重要的和最急迫的
有耐心和技巧去拒绝那些虚妄的非理性的需求,有决心和勇气积极迅速地去满足那些急迫的
关系生死的Bug与需求,有智慧去区分以上两种
16， 所以，应该与专门的人去面对用户，安抚用户，收集反馈，去粗取精，去除虚妄想法，然后
反馈给程序员，慎重讨论，改进之，此频度可一周或一月一次，取决于产品的发展阶段和成
熟度。
所以综上，我认为：程序员应该远离你的用户，设定专员链接程序员和用户。
正确对待销售的意见
17， 积极对待销售的意见，他们最终帮你兑现产品的商业价值
18， 但要清楚，销售的意见90％是不利于你产品长远发展的，销售的意见是超前的（用户还没到
哪个地步和生态呢）
19， 销售需求是BT的。你永远无法满足他们
10， 满足他们所有的意见中的1％即可。
程序员：少听些用户抱怨吧
如果一直以来你都是在一个封闭的小屋子写程序，从来没有接触过用户，收集过反馈，那么我建议看看刘老师的“程序员：多听听用户抱怨吧 ”，如果你发现自己80％以上的时间都在满足个别用户的一些看似大众化的BT需求的时候，并因此极其痛苦而无法推动具有建设性和战略性的的工作时。我建议不妨这么来看待这个问题。
1， 用户是只想自己，不想全局的
2， 用户自己也不知道自己想要什么
3， 用户提出要的并不是他真正需要，也不一定是他会去使用的
4， 性价比是需要考虑的
5， 商业意识是需要考虑的
6， 可发展空间是需要保留的
7， 适当的功能应该在适当的用户量级别和用户生态结构和用户活跃度下提供
8， 听取用户意见的心态是一定要的，听取的渠道一定是要广泛的，但是，满足任何一个需求一
定是要慎重的。
9， 系统健壮是第一位，因此而牺牲某些东西和功能是正确的
10， 用户确实能提出非常有价值的建议，但是
11， 我们是做游戏平台和制定游戏规则的。首先关注你的目标和核心用户
12， 你满足不了所有用户
13， 应该撰写开发者日志，管理员日志，产品简史日志，但是这些日志开发匿名或公开发言的时
候一定要慎重。一个可随意公开发言的论坛群体极其容易放大一些微小的抱怨，并且形成不
良的和不真实的反馈，可能你看到的意见大多说是抱怨的，或者抱怨的意见总是容易被放大
然而，这并不是真正的整体用户对产品的态度。说你好的用户总是习惯性地保持沉默，说你
不好地总是在习惯性地表达
13， 因为，群体的智力水平是低于群体平均智力。流言蜚语和错误总是在无声无息中被夸大了。
如果A用户提交了一个Bug（甚至可能不是，或者极其微小），B用户提交了另外一个Bug，C
用户提交了另外一个Bug，当D用户来了之后，看到，A，B，C提交的Bug，可能会迅速被误
导，并并放大这种抱怨。
14， 你应该有长远计划
15， 区分最重要的和最急迫的
有耐心和技巧去拒绝那些虚妄的非理性的需求,有决心和勇气积极迅速地去满足那些急迫的
关系生死的Bug与需求,有智慧去区分以上两种
16， 所以，应该与专门的人去面对用户，安抚用户，收集反馈，去粗取精，去除虚妄想法，然后
反馈给程序员，慎重讨论，改进之，此频度可一周或一月一次，取决于产品的发展阶段和成
熟度。
所以综上，我认为：程序员应该远离你的用户，设定专员链接程序员和用户。
正确对待销售的意见
17， 积极对待销售的意见，他们最终帮你兑现产品的商业价值
18， 但要清楚，销售的意见90％是不利于你产品长远发展的，销售的意见是超前的（用户还没到
哪个地步和生态呢）
19， 销售需求是BT的。你永远无法满足他们
10， 满足他们所有的意见中的1％即可。