程序員：少聽些用戶抱怨吧

如果一直以來你都是在一個封閉的小屋子寫程序，從來沒有接觸過用戶，收集過反饋，那麼我建議看看劉老師的“程序員：多聽聽用戶抱怨吧 ”，如果你發現自己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％即可。
    UPDATE：本文原標題是：程序員：慎重對待用戶意見吧
                        因覺得太中庸，故改爲“程序員：少聽些用戶抱怨吧”