軟件產品經理該如何滿足用戶的需求
轉朋友博客的一篇新文章，講產品經理分析需求的，有興趣的可以多去朋友博客逛逛，幫宣傳下：飯窩，http://finewo.net/
產品經理在產品設計前，最頭疼的問題多是需求的滿足度，該如何保障在滿足當前需求的前提下還能順應產品的未來擴展性，往往使產品經理抓耳撓腮。本文先簡單介紹幾種筆者常用的需求分析法，再與大家探討下需求該如何采納。
一、需求分析方法
1 公司級服務型產品
公司級服務型產品是指由公司發起，以大眾服務為目的，用戶對象為互聯網大眾的產品。這類產品最終的需求的定拍方為公司方，需求調研對象為大眾，調研方法也很多，本文不多述，可以使用調研問卷、面對面交談、根據歷史積累訂立初級需求等。
在對各種用戶角色進行需求調研后，通常我們的做法是按用戶的優先級排序，將各級用戶的需求按用戶分組整理，取各級用戶的需求交集，整理進需求報告中作為第一批需求，然后按優先級高的用戶需求依次放入需求報告中，最終結合設計團隊前期預見的需求集形成出版的需求列表，進行討論會，可以通過頭腦風暴或delphi法，定出中版的需求列表，值得注意的是討論會的討論方法是非常占用人力成本，所以會議主持人要非常清晰本次會議的討論內容，避免問題擴展太多偏離太大，導致會議遲遲不能結束。討論出的中版需求列表后，是需要進行更高層次的會議討論，至少要有一位產品總監或項目高管參與，用來定拍，否則所有的之前的討論基本都是不算數的，對未來預期的風險如發生后是沒有援軍的。
2 客戶級定制型產品
客戶級定制型產品是指由客戶發起，以方便客戶使用解決客戶某種現存問題為目的，使用對象為專有客戶群體的產品。這種產品最終的需求定拍方為專有客戶群體，可以是一個人或多個人，需求調研對象也為客戶方，調研方法同樣也有很多，如召開項目啟動會，要求客戶代表和產品團隊代表進行需求討論，或也可以根據歷史積累做出初版原型后，使用原型法進行多輪調研得出最終定拍版原型后則為需求列表。注意，以上所說為通常情況，特殊情況則需特殊處理，比如大型產品則需要采用螺旋模型，多次螺旋后得出最終產品，小型項目則可以直接采用較敏捷方法通過原型法直接定拍，中型的可以采用瀑布等，依實際情況而論。
筆者比較喜歡召開項目啟動會的方式，因為這種比較直接也是最效率的，一輪不夠可以開兩場，直到沒有異議為止，然后做出產品原型。項目啟動會的產品團隊成員在條件允許的情況下，筆者通常會安排以下幾種角色參與：UI、開發經理、一個高級開發工程師。為什么安排這幾種角色？通常這樣的產品團隊，是不具備交互設計師的，UI和產品經理就擔當了此角色。叫上開發經理為什么還要再叫上一個高級開發工程師？從經驗上來講，產品團隊里的高級開發工程師是長期駐留在產品團隊里的，對產品的開發細節很了解，方便在關鍵需求做出強硬判斷，可以及時給用戶反饋避免“浮夸風”和“冷場”的情況出現；開發經理有可能是經常流動的，雖然對公司大部分的產品很是了解，但對細節的了解程度沒有高工更有深度，但產品經理對整體產品開發的框架有全局觀，如一個需求需要哪些硬件資源配合等，可以很快做出大方面的技術把控，所以這兩個角色是都需要的，但如果有那么一種全能的開發經理就不需多此一舉了。為什么沒有見到項目經理？這個問題就很奇妙了，通常來講，這種類型的產品團隊中，產品經理即項目經理，項目經理即產品經理了，呵呵！
二、需求如何滿足
1 公司級服務型產品
服務型產品在確定出最終的需求列表后，產品經理可以叫上交互設計師、開發經理三個人，找間小會議室，用思維導圖工具以產品為核心將產品的需求列表畫出來，并標出各類需求的優先級。確立優先級的原則是以大部分用戶的一般需求為主，確保最高優先級的需求為最基礎的需求，即用戶最需要的需求，比如你要設計一個電風扇，一級需求應該包括扇葉、電源開關，有了這兩個功能就可以保障電風扇的最基本運轉，二級需要可以考慮設計風速控制、外觀裝飾等。我們的產品也是如此，將大部分用戶最需要的一般需求設立為一級需求，作為1.0版本發布，包含基礎需求，一些個性化的需求或一些亮點需求可以逐步擴展，放到2.0、3.0中，這樣可以很好的控制產品經理的發散思維，因為通常產品經理在產品進入到執行開發階段時，總是會突然的冒出一些很奇怪的想法，就迫不及待的在晨會或小組會時提出，希望開發經理給加到產品功能里，在1.0時發布，有了這樣的方式，產品經理可以將突發奇想的好想法放到思維導圖里，標出優先級，作為2.0需求集里發布。
2 客戶級定制型產品
可能做過此類項目的產品經理或項目經理都會有這樣的經歷，客戶提出的需求較多的時候，需求比較亂，雖然最終定拍了，但結合產品的合同額度、時間、人力成本做出初版project后，才恍然發現超期了很多，這時就要祭出我們的寶劍“砍需求”了，這個“砍”就比較難了，砍大了產品不能驗收，砍少了到了期限做不完還是不能驗收。這時該怎么辦？
保持冷靜的思考是很重要的，切忌不能急躁，容易做出沖動的決定，比如沖動的去和公司提出加人，瘋狂的讓開發人員加班，這些都是不理智的，最理智的是多翻幾遍需求列表和討論會的會議紀要，仔細分析里面的細節，這里面的需求其實并不全是客戶最需要的，在項目啟動會時，客戶一口氣全提出來，多半都是產品經理引導的，說道一個功能時，客戶就跟著順下去了，順著順著就出來了更多的需求。客戶也和我們一樣，是可以商量的，仔細分析過這些需求后，找出一些你認為可以暫緩甚至留到后期再做的整理出來，可以單獨找客戶方可以定拍的代表，在一起屢一遍，只要你的理由充足，客戶多半都是會同意的，如果實在不同意的可以變通一下，用另一種容易實現的方式來滿足用戶。
以上一些是筆者在實際運作時遇到過的一些情況和應對方法，時間比較晚了可能有些沒有寫清楚，后面我會整理一些具體的內容寫寫，像需求調研的細節和需要注意的地方，風險的預測，做計劃時的一些技巧等。
原文鏈接：http://www.cnblogs.com/saisky/archive/2011/10/04/2198929.html
【編輯推薦】
