編輯導(dǎo)語：產(chǎn)品經(jīng)理有一個(gè)工作內(nèi)容叫做需求分析（PRD），主要是看業(yè)務(wù)上有哪些不合適的地方，并且提出方案去完善。在這篇文章里，作者便通過分析一個(gè)實(shí)際例子中存在的問題，像我們分享了如何寫好需求文檔，需要注意什么，一起來看一下吧。

最近和一些初入剛?cè)腴T的產(chǎn)品或者想要進(jìn)入產(chǎn)品崗位的人交流。發(fā)現(xiàn)很多人都是在自學(xué)Axure、去練習(xí)軟件的使用和交互的設(shè)計(jì)。

昨晚有個(gè)朋友把他的原型發(fā)給我，想讓我?guī)兔聪聠栴}。

其實(shí)這里第一個(gè)問題就是他不知道自己的問題在哪里，這本身就是一個(gè)比較致命的問題。

產(chǎn)品經(jīng)理有一個(gè)工作內(nèi)容叫做需求分析，去看業(yè)務(wù)上有哪些不合適的地方，并且提出方案去完善。

暫且拋開這些，我們今天先來看下PRD到底應(yīng)該怎么寫。

01

這是這位同學(xué)的需求文檔，我簡(jiǎn)單截2張圖：

乍一看挺像那么回事的，但其實(shí)不管是邏輯上、還是原型交互上，仔細(xì)看都會(huì)有問題。

以登錄頁面的需求描述為例：

1）圖中1、2兩部分的邏輯是有沖突的。1講的是賬號(hào)沒有填寫的時(shí)候，點(diǎn)擊登錄按鈕會(huì)給予提示“賬號(hào)不能為空”；而2講的是登錄按鈕在賬號(hào)密碼未填寫時(shí)是不可點(diǎn)擊的。

那請(qǐng)問當(dāng)賬號(hào)和密碼都沒有填寫的時(shí)候是可點(diǎn)擊還是不可點(diǎn)擊呢？

如果可以點(diǎn)擊，那點(diǎn)擊后的提示是提示賬號(hào)不能為空還是密碼不能為空呢？

2）圖中3是指密碼錯(cuò)誤時(shí)候給予提示：密碼錯(cuò)誤請(qǐng)重新輸入?？雌饋磉壿嬍钦_的，但業(yè)務(wù)場(chǎng)景上是有問題的。

這樣表述代表著你已經(jīng)默認(rèn)賬號(hào)是正確的。

那是否會(huì)存在A用戶的賬號(hào)是ningshu，B用戶的賬戶是ninshu。當(dāng)A在賬戶上填寫的是B用戶的賬戶，那密碼不可能正確。

因?yàn)殄e(cuò)誤其實(shí)不在密碼上，而是在賬戶上。所以更準(zhǔn)確的說法應(yīng)該是：賬號(hào)或密碼可能有誤，請(qǐng)重新輸入。

3）圖中4部分是指賬號(hào)不存在的時(shí)候，輸入框下方會(huì)進(jìn)行提示：無此賬號(hào)，請(qǐng)重新輸入。

第一，沒有觸發(fā)條件，是需要研發(fā)監(jiān)控輸入框，每輸入一個(gè)字符就去數(shù)據(jù)庫查詢是否有這個(gè)賬戶嗎？顯然不合適。

第二，哪怕你的觸發(fā)條件是在光標(biāo)離開輸入框之后也不合適。因?yàn)榕袛噘~號(hào)信息應(yīng)該在登錄按鈕時(shí)一起來判斷，原本在一個(gè)操作上完整判斷的事情不合適分開來處理。

4）圖中5部分只講了自動(dòng)登錄，那什么時(shí)候自動(dòng)登錄會(huì)被取消呢？

是保持7個(gè)自然日的自動(dòng)登錄，如果用戶登錄后會(huì)重新更新7自然日的token記錄，超出7個(gè)自然日不登錄會(huì)被取消自動(dòng)登錄？還是其他的一些條件？

5）整個(gè)文檔從邏輯上就有問題，在講某一個(gè)頁面組件，比如“賬號(hào)輸入框”的時(shí)候會(huì)出現(xiàn)其他組件的邏輯判斷（輸入框提示賬號(hào)不能為空）。

你在和研發(fā)溝通的時(shí)候，研發(fā)的思維是跳躍著來，并且本身是登錄按鈕的邏輯被打散拆到了賬號(hào)輸入框、密碼輸入框等不同地方，對(duì)于單個(gè)組件的邏輯是不連續(xù)的。

6）登錄按鈕在頁面上講過有很多錯(cuò)誤提示的情況。那請(qǐng)問這些錯(cuò)誤提示的優(yōu)先級(jí)是什么？

就像我們上面剛剛提到過的，既有賬號(hào)不能為空，也有密碼不能為空。那當(dāng)賬號(hào)密碼都為空的情況下應(yīng)該給予什么樣的錯(cuò)誤提示呢？

……

其實(shí)這里面還有很多問題，就不一一詳細(xì)來說了。

02

需求文檔到底應(yīng)該怎么寫？

首先我們得理解原型是原型，需求文檔（下面簡(jiǎn)稱為PRD）是需求文檔。像這種原型邊上做標(biāo)注的方式是可以的，但標(biāo)注完也不是完整的PRD。

PRD是給誰看的？PRD評(píng)審其實(shí)根據(jù)不同業(yè)務(wù)或者重要程度參與的人每次都可能不一樣。

參與者會(huì)是以下11個(gè)崗位的其中1個(gè)或多個(gè)。

當(dāng)有這么多人參與進(jìn)行PRD評(píng)審的時(shí)候，第一件事情不是講具體的功能點(diǎn)事什么。

而是要和大家溝通為什么做這件事情，做這件事情對(duì)我們的業(yè)務(wù)有什么樣的好處？也就是常說的需求目標(biāo)是什么？

只有大家達(dá)成共識(shí)的時(shí)候，在接下來的PRD評(píng)審過程里，才能讓研發(fā)和其他部門的人和你是在一個(gè)頻道上思考的。

03

PRD文檔是用于給研發(fā)進(jìn)行開發(fā)所使用的，所以這里就有一個(gè)非常關(guān)鍵的原則——沒有任何歧義的部分。

1就是1，2就是2，不能模凌兩可，這樣研發(fā)才能很好地把代碼寫出來，千萬不能讓研發(fā)去猜。

就像我們剛剛上面聊到的，登錄按鈕的錯(cuò)誤提醒是有優(yōu)先級(jí)的，你可以這樣寫：

當(dāng)賬戶和密碼兩者有一個(gè)沒有輸入的情況下，點(diǎn)擊登錄按鈕時(shí)，在下方提示：賬號(hào)或密碼不能為空。

當(dāng)賬戶和密碼輸入后，點(diǎn)擊登錄按鈕時(shí)，系統(tǒng)按以下順序進(jìn)行判斷：

1.賬戶是否存在

存在：進(jìn)行第2條規(guī)則判斷

不存在：下方提示文案：“該賬號(hào)不存在”

2.判斷密碼是否正確

不正確：下方提示文案：“賬號(hào)或密碼錯(cuò)誤,請(qǐng)重新輸入”

正確：toast提示：“登錄成功”并跳轉(zhuǎn)頁面進(jìn)入管理后臺(tái)首頁

把所有的情況都寫出來，這樣研發(fā)看起來是沒有爭(zhēng)議的。當(dāng)然，更好的做法是寫User Case，如下：

User Case 是拿來干嘛的？是用來描述什么角色通過某某系統(tǒng)能做什么事情的流程體現(xiàn)，User Case 的書寫也是產(chǎn)品經(jīng)理對(duì)用戶需求深刻理解的體現(xiàn)。

04

需求文檔的書寫上還有很多需要寫的，比如你需求中的完整業(yè)務(wù)流程圖、分角色甬道圖、詳細(xì)需求清單等。

如果涉及到系統(tǒng)安全性部分還需要有安全性需求，比如接口的加密、賬戶的單點(diǎn)登錄、單位時(shí)間內(nèi)多次接口訪問時(shí)需要進(jìn)行人機(jī)交驗(yàn)、用戶輸入不能注入SQL、代碼等。

如果涉及到一些法律上的部分，需要法務(wù)進(jìn)行協(xié)助的需求。比如用戶隱私、用戶所輸入的安全性交驗(yàn)，是否涉黃涉暴涉政等。

詳細(xì)的內(nèi)容一篇文章說不完，我們后面再慢慢詳細(xì)說。

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

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