產品經理需求分析報告
打從接觸產品管理至今已有8年了，中間也換過一次行業(yè)，深覺一旦掌握基本技能加之恰當的方法，行業(yè)壁壘沒有想像中那么大，畢竟都是IT產品相關的工作，還是大同小異的。我是一直在產品管理的路上亂闖亂跳，工作經驗積累的已經不少，但總是覺著沒有任何提升，沒有自信就容易否定自己。所以，痛定思痛，還是沉淀一下，仔細總結總結歷往遇到的問題和那些沒能完美跨過的坑。沒有總結的人生，永遠都是瞎混。所以，先從需求入手，聊一聊需求分析那些事兒。
需求分析可以分這幾個階段：需求收集-需求調研-需求梳理-需求評審。每個階段都有不同的思路，也有對應不同的輸出物。
一、需求收集
在這一點上，通信、傳統(tǒng)IT項目可能有別于傳統(tǒng)互聯(lián)網，需求的產生和提出，通常會有其發(fā)起的業(yè)務部門，即業(yè)務Owner。業(yè)務Owner需要深度參與到項目中來，要對需求負責，要協(xié)調業(yè)務流程梳理，要進行業(yè)務測試，并決定是否上線。運營商行業(yè)的業(yè)務Owner我接觸比較
多是信息化部、業(yè)務支撐部。原則上講，業(yè)務Owner需要提交一份業(yè)務需求，但有時也只是口頭傳達有個什么樣的需求，具體調研時候再來談。
1、需求的接收
業(yè)務Owner會有哪些需求通常都是提前預知的。打個招呼，會有個什么類的需求要找你做。可能暫時無法接收，可能業(yè)務Owner還沒能想好，那么可以約定相關需求的提交時間。大家都比較忙，作為接收人，要提前排好接收時間，同時到約定時間前也提前提醒一下對方。
對于項目背景、建設目標、需求提出部門、業(yè)務負責人、用戶群及使用量，可以提前做些功課，收集信息，收集的途徑可以多方，適當時候也可以收集一下類似的需求/產品。
如下信息盡量在需求分析前先搞清楚：組織架構、職責、角色、使用人員的梳理。
2、需求的主動收集
互聯(lián)網產品往往沒有業(yè)務Owner，產品做成什么樣子，需要產品經理主動去了解。基于此
背景，需求的收集可以有用戶訪談、意見收集、問卷調查等等。這里我經驗有限，就不展開來講了。日常用的最多的就是各種競品分析，哈哈
二、需求調研
向客戶和相關部門開展調研工作：了解業(yè)務、現狀、痛點、角色責任人等；
1、需求調研需要覆蓋如下人員：業(yè)務負責人（主要負責整個系統(tǒng)的建設）以及關鍵人群（日后使用者，可能包含多部門的多人）；
2、對于業(yè)務需求，要發(fā)揚刨根問底的精神，了解業(yè)務到底要干什么，這么做到底為什么。
3、如果是系統(tǒng)改造或新建系統(tǒng)與其他系統(tǒng)有關聯(lián)，以下事項不可或缺：對本系統(tǒng)或其他系統(tǒng)的影響評估；本系統(tǒng)或其他業(yè)務系統(tǒng)的痛點問題分析；
4、不能忽略異常流程、人員組織機構變動的實際情況；
這里重點再說一下第二點，發(fā)揚刨根問底的精神。這一點說起來容易做起來可不容易，跟我們打交道的人都是IT出身，這些技術愛好者們最喜歡干的事兒就是跳過業(yè)務需求，直接
告訴你怎么實現，頭疼不已，一定不要讓他們牽著鼻子走。可以探討技術實現，但是一定記住這不是主要目的，業(yè)務部門的人立足于當前的自身需求，考慮的實現一定不是全面的、合理的、滿足產品規(guī)劃的。如果讓業(yè)務部門的人直接決定，那要需求分析人員干嘛呢，是不是這個道理？所以，需求調研時，秉承一個原則，技術實現問題，下階段再討論，我們專注于業(yè)務。
至此，本階段結束時，輸出物應該有初版的業(yè)務需求書。
三、需求梳理
根據客戶需求輸出系統(tǒng)方案，包括：業(yè)務流程、業(yè)務規(guī)則的確定、系統(tǒng)功能架構、功能描述，以及與外圍系統(tǒng)間關系。這一階段，是思考和創(chuàng)作的階段了。說幾個重要的輸出物：
1、完整的業(yè)務流程圖，需要表示出正常和異常流程；
2、需求說明書，功能點業(yè)務邏輯寫的盡量詳細，要保證文檔的質量，check一下原來討論的結論；
3、頁面原型DEMO，提供給業(yè)務部門確認，為業(yè)務UI的設計提供依據，對于前臺的要求可體現在原型中；
4、列表數據的展現順序，盡早確認，以免后續(xù)頻繁調整頻繁復測；
5、狀態(tài)轉換圖，可幫助設計人員更好的考慮異常，也方便指導開發(fā)；
此階段可提前與業(yè)務部門約定，對于業(yè)務不清晰、職責不明確的需求，考慮后續(xù)迭代
四、需求評審
完成需求內部評審及用戶最終確認，這一階段需要進行需求收斂，切忌發(fā)散。
1、召集內部評審，根據評審的結果進行調整；
對于重大變化提前與相關人員確認，預料到的問題不要等到需求確認時再提。評審之前一定要內部達成一致，一定要內部達成一致，一定要內部達成一致，重要的事情說三遍，不要問我怎么知道的。
對于需求/DEMO版本的迭代，內部評審時因為版本太多大家看的不仔細，每版都要描述一下有哪些重點變化。
2、與用戶進行最終確認，確定上線要求及是否需要分階段；
郵件確認的話，時間要預留一周；往往復復的，需要幾輪。對于需要分階段的，不急著給出下階段時間，因為有些需求，等下階段再評估的時候很可能已經不合理了。
