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

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

本文的思路是：

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

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

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

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

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

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

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

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

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

• 以用戶為核心；
• 角色場(chǎng)景任務(wù)三要素。

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

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

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

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

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

如何解決這個(gè)缺陷呢？

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

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

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

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

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

這樣做的好處是：

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

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

首先我想讓大家思考2個(gè)問題：

1. 需求的詳細(xì)分析分解一定要PM來承擔(dān)嗎？

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

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

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

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

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

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

除了硅谷的合作模式的思考外，還有倆個(gè)新的理念也非常值得學(xué)習(xí)，它們也驗(yàn)證了上面說的配合模式是值得學(xué)習(xí)和探索的。

• 一個(gè)是設(shè)計(jì)界的設(shè)計(jì)沖刺：強(qiáng)調(diào)PM、設(shè)計(jì)和開發(fā)一起集中幾天來快速完成設(shè)計(jì)定稿，規(guī)避反復(fù)冗長的溝通確認(rèn)；
• 一個(gè)是敏捷界的持續(xù)交付：持續(xù)交付的核心是一開始團(tuán)隊(duì)就要思考完整的服務(wù)流程，而不是各自思考自己的單點(diǎn)功能，而后期集成測(cè)試的時(shí)候，發(fā)現(xiàn)很多接口都缺失或?qū)硬簧稀?/li>

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

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

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