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