Our work, their stories
當MIUI每天有十多萬用戶都在論壇提交需求時，如何排序這些海量需求的優先級?
我們內部面對產品需求有長期、中期和短期的定義。長期開發方向雷總每1~2個月會和團隊溝通約定，中期和短期基本就是在和用戶互動中，碎片化產生，這個過程也會反過來修正我們設定的長期目標。
處理碎片化的需求，我們的方法有三個：
1.先處理浮出水面的需求。
在論壇做恰當的帖子輔助功能，主要幫助用戶盡量格式化提交需求，另外在碰到同樣需求的時候，能直接跟著表達“我也需要這個功能”。這樣，每周下來，你會發現緊急的功能開發需求自然會按熱度排到帖子前面。
2.第一時間公示需求改進計劃。
“橙色星期五”的每周更新，論壇會有完整的更新公告帖，列清楚更新了哪些功能，哪些是推薦的。另外對于閃單點的需求討論，討論結果往往是投票結果，都會公示在論壇;團隊也會定期把未來一個月的更新計劃做個說明。
3.讓團隊結構也“碎片化”。
就是說2~3人組成一個小組，長期改進一個功能模塊。給他們自主權，在和用戶交流中，有30%的模塊自己就定義開發了。過去也確實出現過，有用戶天天圍著某個工程師，后來開發了看起來并不是很急需的功能。但我們整個項目都是每周更新，迭代很快，出錯了的方案也不要緊，過兩周就改對了。
做產品，我和團隊舉例說：就好比一輛車在路上，只要大方向選清楚了，哪怕偶爾偏離路線或偶爾減速都不怕，其實最怕就是經常180度調頭并且反復，或者停下來不動了。
有些項目不適合立刻對外發布測試，如何找需求反饋?
創業起步階段，怎么有效就怎么來，那就動員內部來測試。小米加步槍干革命，說一個我們“大賣部”的小故事。
2010年7月，我們決定自己做電商，4個工程師僅用1個月就開發出電商后臺的第一個版本。為了測試，我們在電商平臺做了面對內部員工的“1折賣可樂”，這就是我們的“大賣部”。真正的訂單，真正的收費，真正的配送簽收(我們的工程師都跑去“送貨”)，每天進貨，每天盤點，這樣就提前發現并解決了電商系統的很多問題。等到8月29日系統真正上線時，一切都很順利。
