優先處理浮出水麵的需求

當MIUI每天有十多萬用戶都在論壇提交需求時，如何排序這些海量需求的優先級？

我們內部麵對產品需求有長期、中期和短期的定義。長期開發方向雷總每1～2個月會和團隊溝通約定，中期和短期基本就是在和用戶互動中，碎片化產生，這個過程也會反過來修正我們設定的長期目標。

處理碎片化的需求，我們的方法有三個：

1.先處理浮出水麵的需求。

在論壇做恰當的帖子輔助功能，主要幫助用戶盡量格式化提交需求，另外在碰到同樣需求的時候，能直接跟著表達“我也需要這個功能”。這樣，每周下來，你會發現緊急的功能開發需求自然會按熱度排到帖子前麵。

2.第一時間公示需求改進計劃。

“橙色星期五”的每周更新，論壇會有完整的更新公告帖，列清楚更新了哪些功能，哪些是推薦的。另外對於單點的需求討論，討論結果往往是投票結果，都會公示在論壇；團隊也會定期把未來一個月的更新計劃做個說明。

3.讓團隊結構也“碎片化”。

就是說2~3人組成一個小組，長期改進一個功能模塊。給他們自主權，在和用戶交流中，有30%的模塊自己就定義開發了。過去也確實出現過，有用戶天天圍著某個工程師，後來開發了看起來並不是很急需的功能。但我們整個項目都是每周更新，迭代很快，出錯了的方案也不要緊，過兩周就改對了。

做產品，我和團隊舉例說：就好比一輛車在路上，隻要大方向選清楚了，哪怕偶爾偏離路線或偶爾減速都不怕，其實最怕就是經常180度調頭並且反複，或者停下來不動了。

有些項目不適合立刻對外發布測試，如何找需求反饋？

創業起步階段，怎麽有效就怎麽來，那就動員內部來測試。小米加步槍幹革命，說一個我們“大賣部”的小故事。

2010年7月，我們決定自己做電商，4個工程師僅用1個月就開發出電商後台的第一個版本。為了測試，我們在電商平台做了麵對內部員工的“1折賣可樂”，這就是我們的“大賣部”。真正的訂單，真正的收費，真正的配送簽收（我們的工程師都跑去“送貨”），每天進貨，每天盤點，這樣就提前發現並解決了電商係統的很多問題。等到8月29日係統真正上線時，一切都很順利。