本文由作者 嘮呵?于社區(qū)發(fā)布

前段時(shí)間，由于項(xiàng)目的開發(fā)周期卡得非常緊，在極端的高壓下，我一個(gè)多月內(nèi)連續(xù)設(shè)計(jì)了三款B端產(chǎn)品，累積寫了好幾萬字的需求文檔，畫了數(shù)百個(gè)頁面，每個(gè)B端產(chǎn)品都涉及多方角色和系統(tǒng)的交互，業(yè)務(wù)邏輯非常復(fù)雜，回顧那段時(shí)間過的，真是生不如死，差點(diǎn)就憋出抑郁癥。

但是好在我熬過來了，苦盡甜來，也算是學(xué)到很多的東西。

以前做產(chǎn)品的時(shí)候，沒有那么嚴(yán)格的上線時(shí)間點(diǎn)，有充裕的時(shí)間思考，哪怕有很多思考得不周全的地方，也可以花很長的時(shí)間去彌補(bǔ)，所以問題都被悄無聲息地掩蓋了，但是，經(jīng)過前段時(shí)間高強(qiáng)度的壓迫輸出，需要在極短的時(shí)間內(nèi)做出高質(zhì)量的方案，問題便展露無疑。

比如，

明明老早就已經(jīng)想好的功能，后面寫需求的時(shí)候卻忘記了，直到測試的時(shí)候才想起來。需求都已經(jīng)寫好了，正打算好好休息，跟朋友happy一下，卻突然想到還有一些異常流程沒有考慮到，導(dǎo)致前面已經(jīng)梳理好的所有流程和頁面都需要重新改動(dòng)，那一刻我的心是崩潰的。需求評(píng)審時(shí)，程序員直接指出了一堆異常場景，而這些場景此前自己完全沒考慮到，頓時(shí)一陣語塞，好不尷尬。有些功能想得太粗，只是簡單帶過，導(dǎo)致開發(fā)還需要來主動(dòng)問具體的實(shí)現(xiàn)邏輯是什么，產(chǎn)品經(jīng)理的專業(yè)性受到了嚴(yán)重的質(zhì)疑。

之所以會(huì)出現(xiàn)上面出現(xiàn)的各種窘境，最主要的原因還是在于自己寫需求的方式不對(duì)，都是想到啥寫啥，沒有遵循一定的流程和步驟。

寫需求過于隨意，則容易過早地陷入細(xì)節(jié)中，沒有做好頂層設(shè)計(jì)，后面自然會(huì)漏洞百出，在開發(fā)面前百般出糗，長此以往，一定會(huì)讓研發(fā)同事或者其他團(tuán)隊(duì)成員認(rèn)為你不專業(yè)，后續(xù)推進(jìn)必然會(huì)存在障礙。

于是，我花了很大一部分時(shí)間對(duì)此前做的項(xiàng)目進(jìn)行全面的總結(jié)回顧，也找了很多書和文章來看，總算形成了一種行之有效的需求寫作方法論，以這套方法論寫需求會(huì)感覺非常順，指哪打哪，不會(huì)像以前一樣寫著寫著突然感嘆自己從哪里來，到底往哪里去的迷茫感。

我打算把這套需求寫作方法共享出來，如果大家有遇到跟我一樣的問題，希望這個(gè)方法能幫助到你們。

為了讓這套方法更容易被吸收，我以一個(gè)簡單的點(diǎn)餐小產(chǎn)品作為案例在全文中穿插著進(jìn)行講解。

01

系統(tǒng)用例圖

系統(tǒng)用例圖是指由參與者，用例以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的視圖。

它是我們寫需求的第一步，是根據(jù)業(yè)務(wù)用例圖分析得到的，針對(duì)于業(yè)務(wù)用例圖的用戶行為分析后，從系統(tǒng)側(cè)去建立對(duì)應(yīng)的模塊。

業(yè)務(wù)用例圖在這里就不細(xì)說了，它是我們在調(diào)研用戶需求的階段輸出的產(chǎn)物，展現(xiàn)形式跟系統(tǒng)用例圖基本一樣，不同之處只是在于它更注重用戶的需求是什么，是從使用場景去考慮的，而系統(tǒng)用例圖也更加注重需求對(duì)應(yīng)的系統(tǒng)功能是什么，用戶能通過這個(gè)系統(tǒng)做些什么。

系統(tǒng)用例圖是產(chǎn)品最頂層的設(shè)計(jì)，它構(gòu)畫出了產(chǎn)品整體的架構(gòu)，后續(xù)所有的流程和頁面設(shè)計(jì)都需要圍繞它進(jìn)行展開，所以應(yīng)該非常地重視它。

它的目的簡單來說就是這么兩點(diǎn):

1.系統(tǒng)有哪些用戶角色

2.每類用戶角色能使用這個(gè)系統(tǒng)做些什么

你可以把系統(tǒng)用例圖理解成我們熟知的功能清單，它相當(dāng)于形象化地展示出每種角色享有哪些功能，并將功能與角色一一對(duì)應(yīng)起來。

比如我們要講解的點(diǎn)餐小產(chǎn)品，它有兩類角色:

1.顧客

2.廚師

顧客可以用產(chǎn)品做什么？他可以用來點(diǎn)餐，以及查看已點(diǎn)餐品的狀態(tài)。

而廚師可以做什么？他可以查看顧客已點(diǎn)的餐品以及餐品的桌號(hào)，還可以操作餐品的狀態(tài)，操作餐品的狀態(tài)又可以往下細(xì)分，包括開始做餐，餐品售罄，餐品出餐。

那么，我們的系統(tǒng)用例圖大概可以畫成這樣:

用例的層級(jí)需要分清楚，比如顧客需先查看已點(diǎn)的餐品，才可以往下查看餐品的狀態(tài)，廚師需要先查看已點(diǎn)的餐品，才可以往下繼續(xù)查看餐品的桌號(hào)以及查看餐品的狀態(tài)，不同的用例是有先后順序的，這一點(diǎn)需要注意。

在這一步，相當(dāng)于把整個(gè)小產(chǎn)品的骨架給搭建起來了，這一步一定要考慮得非常周全，當(dāng)然，細(xì)小的骨頭暫時(shí)可以缺失，后面在畫細(xì)節(jié)的時(shí)候能發(fā)現(xiàn)并彌補(bǔ)回來就可以了，不會(huì)影響大局，但是千萬不能缺了撐起整個(gè)骨架的關(guān)鍵骨頭，不然后面的流程圖也會(huì)跟著缺失，流程圖一旦出問題，則導(dǎo)致整個(gè)產(chǎn)品都會(huì)接連出問題，后面改起來一定會(huì)非常痛苦，這一點(diǎn)我可深有體會(huì)。

當(dāng)然，很多時(shí)候用例圖和流程圖的思考順序是相互交叉的，沒有絕對(duì)的先后順序，因?yàn)槟阍谒伎加美龍D的時(shí)候其實(shí)就已經(jīng)把流程熟稔于心了，如果腦里沒有流程，你也無法把用例圖很全面地畫出來，而畫流程的時(shí)候，又經(jīng)常會(huì)回過頭來補(bǔ)充之前用例圖沒有考慮到的部分，所以，寫需求的過程，不是線性的，而是折線型的，需要來回地進(jìn)行修補(bǔ)。

02

普通流程圖

普通流程圖是我們最常見的流程圖，每個(gè)人在工作中或多或少都會(huì)接觸一點(diǎn)，這里的“普通”主要是為了區(qū)別于后面要講的跨角色或系統(tǒng)流程圖來說的，它讓你更側(cè)重于業(yè)務(wù)的流程與步驟，而不要分散精力去關(guān)注哪一步是誰做的(這一點(diǎn)是跨角色或系統(tǒng)流程圖最為關(guān)注的)

比如點(diǎn)餐小產(chǎn)品，它的業(yè)務(wù)流程是這樣的:

1.顧客點(diǎn)餐

2.廚師看到餐品

3.廚師將餐品狀態(tài)改為開始做餐

4.廚師開始做餐

5.廚師將餐品狀態(tài)改為餐品出餐，然后把餐品貼上桌號(hào)

6.送菜員拿餐

7.送餐品上桌

流程圖可以這么畫:

? ? ? ? ? ? ? ? ? ? ? ? ??

流程圖中，雖然不同的步驟是由不同的角色做的，但是并沒有明確地在圖中標(biāo)注出來，只是文字一筆帶過，這一步不需要關(guān)注到具體的角色，只需要關(guān)注業(yè)務(wù)流程，從大體上去描述業(yè)務(wù)是如何運(yùn)轉(zhuǎn)的，如果過早地陷入細(xì)節(jié)中，反而會(huì)讓你考慮得不夠周全，導(dǎo)致漏掉一些關(guān)鍵的節(jié)點(diǎn)，也會(huì)讓開發(fā)人員看得云里霧里，無法清晰地看出業(yè)務(wù)的全貌。

由于我舉的例子只是一個(gè)小產(chǎn)品，所以流程比較簡單，如果你設(shè)計(jì)的是一個(gè)復(fù)雜的產(chǎn)品，那么，流程的鏈條則會(huì)長很多，而且可能需要畫多個(gè)流程，包括主流程和子流程，最好把流程的層級(jí)關(guān)系也標(biāo)記出來，這樣才便于自己或者開發(fā)更加理解業(yè)務(wù)的邏輯。

03

跨角色或系統(tǒng)流程圖

跨角色或系統(tǒng)流程圖，主要是梳理清楚角色或系統(tǒng)各自的分工和模塊相互之間的串聯(lián)，它是我們畫完普通流程圖之后第一步要做的事情，相當(dāng)于是對(duì)普通流程圖的進(jìn)一步地解釋。

很多做C端產(chǎn)品的朋友很少接觸到這種流程圖，因?yàn)楹唵蔚臉I(yè)務(wù)邏輯其實(shí)只要普通流程圖就足以描述清楚，不需要特意區(qū)分角色就能看得明白，但是一旦涉及到N多角色多系統(tǒng)之間的交互，如果沒有用合適的圖形語言來思考和表達(dá)，則很容易導(dǎo)致邏輯混亂，不但自己拎不清，則會(huì)讓看的人摸不著頭腦。

對(duì)于跨角色的流程，我們一般用泳道圖來表現(xiàn)，就拿上面的點(diǎn)餐流程來說，可以畫成這樣:

上面表現(xiàn)的主要是不同角色之間的交互流程，它更注重的是不同角色之間交互的邏輯，而對(duì)于那些比較復(fù)雜的產(chǎn)品，還可能涉及到不同系統(tǒng)之間的交互，我們需要關(guān)注它們在哪些地方需要產(chǎn)生交互，交互的數(shù)據(jù)是什么，這個(gè)直接影響開發(fā)人員對(duì)接口的設(shè)計(jì)。

比如互聯(lián)網(wǎng)金融產(chǎn)品的授信流程，我們需要體現(xiàn)出我方產(chǎn)品是如何與第三方征信機(jī)構(gòu)進(jìn)行交互的:

用戶提交的信息會(huì)通過接口傳到第三方的征信機(jī)構(gòu)，第三方的征信機(jī)構(gòu)返回征信的結(jié)果。

這種圖叫做時(shí)序圖，通過描述對(duì)象之間發(fā)送消息的時(shí)間順序顯示多個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作。它可以表示用例的行為順序，當(dāng)執(zhí)行一個(gè)用例行為時(shí)，其中的每條消息對(duì)應(yīng)一個(gè)類操作或狀態(tài)機(jī)中引起轉(zhuǎn)換的觸發(fā)事件。

簡單來說，就是展示不同系統(tǒng)之間哪些地方需要對(duì)話，是如何對(duì)話的，對(duì)話的順序是什么。

跨角色或部門流程圖展示不同角色或部門之間的交互邏輯，時(shí)序圖展示不同系統(tǒng)之間的數(shù)據(jù)傳遞，根據(jù)產(chǎn)品形態(tài)的不同，我們可以互相搭配著用。

04

異常流程圖

上面所涉及到的流程，考慮的是作為一個(gè)用戶最主流的場景，通常不會(huì)涵蓋其他異常的場景。

比如，一個(gè)用戶在登陸時(shí)，一般來說都會(huì)輸入正確的手機(jī)號(hào)，輸入正確的圖形驗(yàn)證碼，獲取短信驗(yàn)證碼，然后輸入并登錄，這是一個(gè)最主流的場景，而對(duì)于一個(gè)產(chǎn)品設(shè)計(jì)者考慮的則不僅僅是這些，還需要考慮到一些非主流的場景，比如驗(yàn)證碼輸錯(cuò)，手機(jī)號(hào)格式不對(duì)，沒有輸入圖形驗(yàn)證碼等各種情況。

比如上面的點(diǎn)餐流程，主流的場景就是，用戶點(diǎn)餐，廚師看到餐品，開始做餐，出餐，然后服務(wù)員拿餐，最后送餐上桌，但是，異常場景也有可能會(huì)出現(xiàn)，用戶點(diǎn)餐的時(shí)候，這個(gè)菜品沒有了，或者用戶點(diǎn)餐后，廚師在做菜過程中發(fā)現(xiàn)原材料不足了等等。

當(dāng)然，我所講的異常流程圖跟異常場景還不是一回事，異常流程圖更加關(guān)注的是足以形成流程的場景，比如像上面所說的登錄的這種，一般不需要?jiǎng)佑玫搅鞒虉D去解決，只需要后續(xù)在寫需求文檔的時(shí)候，在具體的頁面原型上把邏輯說清楚就行。

那什么才是異常流程呢，通常指的是邏輯比較復(fù)雜，需要?jiǎng)佑玫搅鞒虉D表現(xiàn)出來的異常場景。

就拿現(xiàn)在很火的視頻會(huì)議來舉例。

比如，某視頻會(huì)議產(chǎn)品有兩種付費(fèi)模式，購買會(huì)議次數(shù)或者購買包月或包年服務(wù)，某用戶此前已經(jīng)購買了2次會(huì)議，但是他又不小心去點(diǎn)了購買包月服務(wù)，那么，此時(shí)系統(tǒng)則需判斷該用戶是否已經(jīng)購買過包月或包年服務(wù)，即判斷他的會(huì)議有效期是否已經(jīng)結(jié)束，如果還未結(jié)束，則需提示他無需重復(fù)購買，如果已經(jīng)結(jié)束，系統(tǒng)還得繼續(xù)判斷他是否還剩沒有用完的會(huì)議，如果有，需提示他用完才可以繼續(xù)購買。

?

這種異常場景相對(duì)于上面所提到的登陸會(huì)復(fù)雜許多，通常需要用流程圖表現(xiàn)出來，才不容易出現(xiàn)差錯(cuò)。

我們作為產(chǎn)品設(shè)計(jì)者，一定不要想當(dāng)然地覺得用戶不會(huì)這么去操作就不考慮它，而是需要把所有可能會(huì)出現(xiàn)的場景都要考慮到，把體驗(yàn)做到最好，減少用戶的損失。

05

頁面流程圖

上面的流程都想清楚之后，接下來就要進(jìn)入到具體頁面的設(shè)計(jì)了。

但是，現(xiàn)在還不是畫原型圖的時(shí)候，一定不要一開始就陷入到頁面具體的元素中去，比如頁面有哪些字段，有哪些按鈕等等，而是應(yīng)該從整體上去考慮。

比如點(diǎn)餐小產(chǎn)品，它的頁面流程圖可以這么畫:

當(dāng)然，這里還沒有把所有的頁面都列舉出來，只是展示了個(gè)大概，方便大家理解即可。

在這一步，我們思考的是，產(chǎn)品總的有多少個(gè)頁面，頁面之間的關(guān)系是怎么樣的，它們是如何進(jìn)行交互的，這樣我們可以從高處俯瞰整個(gè)產(chǎn)品的頁面架構(gòu)以及頁面之間的關(guān)聯(lián)關(guān)系。

這個(gè)過程跟我們寫文章很類似，要先列好大綱，然后再針對(duì)具體某個(gè)論點(diǎn)展開論述，頁面架構(gòu)其實(shí)就相當(dāng)于文章的大綱，后面原型的設(shè)計(jì)則相當(dāng)于論點(diǎn)的詳述，只有通過這種從宏觀到微觀，從抽象到具象的思考方法，才能緊跟產(chǎn)品的脈絡(luò)，不至于迷失方向，出現(xiàn)遺漏或差錯(cuò)。

06

原型圖和需求文檔

當(dāng)把上面的所有流程圖畫完后，接下來就是我們最熟悉的一步了:畫原型和寫文檔。

所謂畫原型，無非就是把頁面流程圖中所涉及到的每一個(gè)頁面，以及每個(gè)頁面里所有的元素，包括字段，按鈕，菜單等等，全部都畫出來而已。

而需求文檔簡單來說就是看圖寫字，把上面所畫的流程圖和原型圖一一進(jìn)行文字說明，把自己腦里面的圖形思考付諸于文字，讓別人看得更加明白。

文檔中需要把流程圖的邏輯，以及每一個(gè)頁面上的元素，操作和跳轉(zhuǎn)邏輯講清楚，文檔的架構(gòu)可以是這個(gè)樣子:

說到頁面上的操作和跳轉(zhuǎn)邏輯，除了一些頁面級(jí)的特別細(xì)微的點(diǎn)，大部分在上方的幾個(gè)流程圖中都已經(jīng)說清楚了，在這里只要把邏輯對(duì)到頁面上的某個(gè)具體的元素上就可以了。

比如在異常流程圖中所提到的，如果這個(gè)人已經(jīng)購買了會(huì)議次數(shù)，那么他在購買包月服務(wù)的時(shí)候就應(yīng)該提醒他已經(jīng)購買過了，而在原型圖中，就要讓開發(fā)知道，這個(gè)判斷是出現(xiàn)在哪個(gè)頁面的元素上。

比如，它是用戶在付費(fèi)頁面上點(diǎn)擊付費(fèi)按鈕的時(shí)候進(jìn)行判斷？判斷后會(huì)出現(xiàn)提示嗎？提示是彈框還是只需要旁邊出現(xiàn)文字說明？這都需要一一說清楚。

07

用戶權(quán)限表

在文檔的結(jié)尾或者文檔的開頭，還需要附上各角色的權(quán)限說明，包括功能權(quán)限和數(shù)據(jù)權(quán)限。

功能權(quán)限：

數(shù)據(jù)權(quán)限：

總結(jié)

到這里，一整套寫需求的方法就講完了，這些都是我在做產(chǎn)品的過程中踩了無數(shù)的坑之后總結(jié)出來的，我自己感覺非常有用，當(dāng)然，這套方法不一定適合所有人，它也不是一成不變的，我們可以把它看做一款產(chǎn)品，需要不斷地對(duì)它進(jìn)行迭代優(yōu)化，最終沉淀出最適合自己，最行之有效的方法論。

作者：嘮呵，就職于某大廠的B端產(chǎn)品經(jīng)理，喜歡跟各類喜歡深度思考的人交流，歡迎勾搭探討，微信nxn123_

↘好文推薦：

王慧文清華產(chǎn)品課

產(chǎn)品經(jīng)理跳槽面試大揭秘……

作為產(chǎn)品經(jīng)理，你目前薪資多少呢？

點(diǎn)個(gè)“在看”吧

總結(jié)

以上是生活随笔為你收集整理的血泪总结！5000字产品需求写作方法论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。