理清需求

當了十幾年的敏捷團隊的產品經理，我覺得這些年積累最多的經驗就是把握客戶需求。產品經理作為和客戶接觸最緊密的人，對客戶需求最瞭解，在敏捷迭代開始之前，就要先將客戶的需求整理出來。然而，不是每個客戶都會交給你一份整理好的需求文件，也許客戶的需求只是一個idea，具體需要什麼自己也沒想好。這時，如果產品經理拿著這個idea去給開發交代任務，我敢肯定會被湊回來的。

那麼，該怎麼做呢？重要的兩點：溝通和整理。首先，儘量多的和客戶溝通，蒐集各個渠道客戶的需求資訊，並理清需求優先順序和價值，記錄下來。使用一款好的工具有事半功倍的作用，我推薦使用腦圖的方式記錄需求，MindManager和Xmind都還不錯，我一直在使用華為軟體開發雲(http://t.cn/RohXAxI)的scrum流程中的“專案規劃”，這個服務在腦圖的基礎上為產品需求分了層次，更有助於整理。

我經歷過的故事

講個我們團隊一個web平臺的研發案例吧，有一家規模比較大的家居公司，由於銷售量下滑，想把主戰場轉戰到線上，老闆找到我們說“給我做一個賣家居的網站吧”，其它的就沒了，不是老闆對網站沒要求，而是他還沒想出來。

我帶著公司幾個人去家居店裡轉了一圈，記錄了一下銷售的產品和品牌，和店員諮詢了一下店裡的活動，就回公司開始整理需求了，下圖是我整理出來的產品backlog，我在開發雲平臺上直接把工作項匯出excel，發給了客戶。客戶很快就有反饋了，說增加一個“樣品特賣”的功能，將實體店裡擺放超過三個月的產品定期更新到網上，低價處理。

此外，預約到店的客戶要給折扣優惠。客戶在我的分類篩選上也給了詳細的建議，按照家居風格，家居實材，房間型別等。

總之，客戶根據我的初稿，有了真正的需求。

拆分需求

敏捷開發過程中,透過進行Story拆分,將客戶的需求對接給開發人員，幫助開發人員發現問題，識別交付風險，這就要求Story必需要是驗收的。

對於一個pizza開發團隊（7到8人），一個迭代我們建議完成5-10個story，所以story的大小應該符合這個團隊速率。

拆分前應考慮的點：

1．Story之間的依賴，一個story的完成是否依賴另一個；

2． 從簡單到複雜，不要追求一次把事情做完，用貝塔版響應客戶需求

3.先使能功能，再完善效能

拆分後應考慮的點：

1.優先順序，哪個story先交付會提高客戶認同感或降低開發風險——提高它的優先順序

2.拆丟了，哪個客戶關注的點沒有story對應——增加

澄清需求

Story拆分之後，最重要的是讓開發人員充分的理解需求。在迭代開始前的計劃會議上，對需求講解之後，一般會讓開發人員進行反串講，這樣一個回合之後，基本不會上有理解的偏差，工作量也直接評估出來了。

以上只是淺談了產品經理的一些工作內容，對於新手產品經理，由於缺乏經驗，迷茫和困惑是不可避免的，但只要端正從客戶角度出發，對開發團隊負責的態度，不怕苦不怕累，離成功只是時間的問題。

華為軟體開發雲：http://t.cn/RohXAxI

大抵上就是這個過程，我注意到你們會安排開發反串講，這個很有意思，對人要求也高，我想知道你們怎麼把握的，另外產品經理和研發關於需求具體怎麼實現有爭議的話你們怎麼解決的？