大家都知道，有一個Idea之后，一般就要進行需求分析和拆解來落地，每個公司每個人可能都會有不同的拆解方法論，本文主要從底層來系統(tǒng)跟大家聊下為什么要做，如何做需求分析。

先統(tǒng)一下大家對詞匯的認知，對于需求分析，有很多不同叫法：需求分析、需求分解、需求拆解、User Case分解、User Story分解等等，本質說的都是一個事，就是對需求進行進一步詳細分析，來確保整個團隊正確理解。

本文的思路是：

1. 需求分析的本質是什么？為什么要做需求分析？（Why）
2. 目前常見的需求分析的方法論有哪些？（How）
3. 如何更系統(tǒng)高效的分析需求？（How）
4. 給大家一些啟發(fā)來串聯(lián)本文的知識。

一、為什么要做需求分析？

一個產(chǎn)品從0到1，一般的必經(jīng)流程是：

1. 產(chǎn)品戰(zhàn)略（到底要解決什么問題）；
2. 需求分析，輸出Roadmap、需求文檔PRD或User Story等；
3. 設計團隊：硬件、軟件的UX和UI設計；
4. 開發(fā)、QA、TA、運維團隊：開發(fā)，測試，上線；
5. 迭代。

我們今天要探討的是上面的#2，那么我們來思考下，很多人可能立刻就想到思維導圖工具、麥肯斯MECE分解法則等，我想跟大家一起思考的是Why，就是分析需求的目的和原因，下面四點逐層深入：

1. 理清具體有哪些需求和它們的優(yōu)先級（考慮的是一個點：需求）；
2. 讓團隊能具體執(zhí)行下去，團隊包含設計、開發(fā)、QA、TA、運維等（考慮到的是一個線的局部：整個團隊）；
3. 團隊一起給客戶高效地、持續(xù)地交付有價值的服務（考慮到的是一個完整的線：考慮到了外部的客戶）；
4. 團隊一起實現(xiàn)自我價值，獲得成就感和物質獎勵，內(nèi)心充實（思考回歸到人和自己）。

二、目前常見的需求分析的方法論有哪些？

國內(nèi)開始出現(xiàn)PM這個職位還要感謝喬布斯、BAT的引領，大概是在2010年左右，近3到5年是PM從業(yè)的高潮期，所以國內(nèi)PM的發(fā)展歷史大概也不到10年，加上每個公司的情況不同職責就不同。

所以也一直沒有特別萬能的套路給PM們使用，只有一些high-level的Guideline，比如：

• 以用戶為核心；
• 角色場景任務三要素。

基于此，常見的幾類需求分析的框架輸出有：

1. 基于界面：每個界面是一個獨立的case，然后基于此再拓展出頁面上的button、邏輯等；比如：App分析，下面的四五個Tab就是四五個主case。
2. 基于功能模塊：每個產(chǎn)品功能模塊就是一個主case。
3. 基于用戶流程：用戶使用一個功能的流程，比如：微信，簡單的核心主case可分解為注冊登錄、加好友、跟好友聊天等等。

下圖就是網(wǎng)上看到的一個1和2的混合版：

以上三個分解方法理論來說，是不斷有改進的，他們的好處是：模塊清晰了、case遍歷窮舉了、也有條理了。但是他們都有一個明顯的缺陷：各個分支case是孤立的，你看不到全局這個大系統(tǒng)，看不到各個分支之間的相互關系。

三、如何更系統(tǒng)高效的分析需求？

如何解決這個缺陷呢？

此時要引入敏捷理念下的一個方法：User Story Mapping（用戶故事地圖）

這個地圖的層級也有很多不同的形式，我個人經(jīng)過實踐輸出了一個感覺比較好落地和理解的形式，舉一個實際的例子Task，也就是大家在用的to-do任務管理工具的功能：

從上圖例子中大家可以看到，其思路是：

1. 先列出所有跟這個服務相關的用戶角色（Persona），如果是從0到1的產(chǎn)品強烈建議列出自己公司的不同團隊、合作伙伴、客戶的不同角色等，要全面，因為漏掉一個角色可能會導致你的業(yè)務跑不通或者不順暢。
2. 再列出你這個需求的目標，讓你思考過程有個原則，不至于YY到跑偏。
3. General Activity，我解讀為High level的端到端任務流程。
4. Epic：就是模塊化需求。
5. User Story：就是每一個子case。

另外，值得一提的是這個方法可以跟“服務設計”以及騰訊內(nèi)部據(jù)說不提“產(chǎn)品”只提“服務”是完美匹配的，這也就再次驗證了此方法的科學性。

這樣做的好處是：

• 你看到并看清了整個系統(tǒng)；
• 利用Persona連接了各個孤立的分支；
• 優(yōu)先級通過任務流程更容易看清晰，更容易找出MVP；
• 不同意遺漏重要的User Case。

四、給大家一些啟發(fā)來串聯(lián)本文的知識

首先我想讓大家思考2個問題：

1. 需求的詳細分析分解一定要PM來承擔嗎？

之前看到了一篇關于硅谷和中國的PM與工程師之間的差異的文章，本人剛好在兩類公司都工作過，我對那篇文章說的有深刻體會：

硅谷有工程師文化，工程師懂技術也懂產(chǎn)品，PM懂產(chǎn)品也懂技術，目前我們公司當提出一個需求的時候，PM會思考需求并且會考慮技術實現(xiàn)，然后你要自己去Drive不同開發(fā)團隊的人來組隊來實現(xiàn)你的需求，如果你不懂技術基本就無法完成工作（PM和開發(fā)配合很順暢）。

而國內(nèi)的PM是承包了所有產(chǎn)品需求的部分，不怎么考慮開發(fā)的實現(xiàn)，開發(fā)只考慮實現(xiàn)不去深入理解或思考需求，這就導致了PM越來越不懂技術，開發(fā)越來越不關系需求的價值，也就導致了雙方經(jīng)常相愛相殺（配合不太順暢）。

2. 是否要按照開發(fā)喜歡或者某個固定的模式去拆分呢？

啟發(fā)：敏捷理念有一個3C原則（Card一句話的卡片式需求、Communications密切雙向溝通、Confirmation確認達成共識），這個我覺得特別適合PM與Team之間的合作分工。

簡單概括來說，可以講目前是同步串聯(lián)模式（PM交付需求給設計，設計畫UX和UI給開發(fā)和QA，開發(fā)和QA實現(xiàn)給運維），完全可以革新轉換為異步并行模式（PM、開發(fā)、QA、TA、Ops打破各自邊界，前期一起來介入需求的分析，避免了后期反復的溝通，也提升了團隊對目標的一致性認可，自然可達到齊心協(xié)力的效果）。

除了硅谷的合作模式的思考外，還有倆個新的理念也非常值得學習，它們也驗證了上面說的配合模式是值得學習和探索的。

• 一個是設計界的設計沖刺：強調PM、設計和開發(fā)一起集中幾天來快速完成設計定稿，規(guī)避反復冗長的溝通確認；
• 一個是敏捷界的持續(xù)交付：持續(xù)交付的核心是一開始團隊就要思考完整的服務流程，而不是各自思考自己的單點功能，而后期集成測試的時候，發(fā)現(xiàn)很多接口都缺失或對接不上。

感謝你讀完此篇，希望對你有所啟發(fā)，本人會持續(xù)分享此類思考的結果。

本文由 @小麥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議

愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導、進階學習的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關注微信公眾號運營小咖秀（ID: yunyingshow）