中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

最近和一些初入剛入門的產品或者想要進入產品崗位的人交流。發現很多人都是在自學Axure、去練習軟件的使用和交互的設計。

昨晚有個朋友把他的原型發給我，想讓我幫忙看下問題。

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

產品經理有一個工作內容叫做需求分析，去看業務上有哪些不合適的地方，并且提出方案去完善。

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

01

這是這位同學的需求文檔，我簡單截2張圖：

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

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

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

那請問當賬號和密碼都沒有填寫的時候是可點擊還是不可點擊呢？

如果可以點擊，那點擊后的提示是提示賬號不能為空還是密碼不能為空呢？

2）圖中3是指密碼錯誤時候給予提示：密碼錯誤請重新輸入?？雌饋磉壿嬍钦_的，但業務場景上是有問題的。

這樣表述代表著你已經默認賬號是正確的。

那是否會存在A用戶的賬號是ningshu，B用戶的賬戶是ninshu。當A在賬戶上填寫的是B用戶的賬戶，那密碼不可能正確。

因為錯誤其實不在密碼上，而是在賬戶上。所以更準確的說法應該是：賬號或密碼可能有誤，請重新輸入。

3）圖中4部分是指賬號不存在的時候，輸入框下方會進行提示：無此賬號，請重新輸入。

第一，沒有觸發條件，是需要研發監控輸入框，每輸入一個字符就去數據庫查詢是否有這個賬戶嗎？顯然不合適。

第二，哪怕你的觸發條件是在光標離開輸入框之后也不合適。因為判斷賬號信息應該在登錄按鈕時一起來判斷，原本在一個操作上完整判斷的事情不合適分開來處理。

4）圖中5部分只講了自動登錄，那什么時候自動登錄會被取消呢？

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

5）整個文檔從邏輯上就有問題，在講某一個頁面組件，比如“賬號輸入框”的時候會出現其他組件的邏輯判斷（輸入框提示賬號不能為空）。

你在和研發溝通的時候，研發的思維是跳躍著來，并且本身是登錄按鈕的邏輯被打散拆到了賬號輸入框、密碼輸入框等不同地方，對于單個組件的邏輯是不連續的。

6）登錄按鈕在頁面上講過有很多錯誤提示的情況。那請問這些錯誤提示的優先級是什么？

就像我們上面剛剛提到過的，既有賬號不能為空，也有密碼不能為空。那當賬號密碼都為空的情況下應該給予什么樣的錯誤提示呢？

……

其實這里面還有很多問題，就不一一詳細來說了。

02

需求文檔到底應該怎么寫？

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

PRD是給誰看的？PRD評審其實根據不同業務或者重要程度參與的人每次都可能不一樣。

參與者會是以下11個崗位的其中1個或多個。

當有這么多人參與進行PRD評審的時候，第一件事情不是講具體的功能點事什么。

而是要和大家溝通為什么做這件事情，做這件事情對我們的業務有什么樣的好處？也就是常說的需求目標是什么？

只有大家達成共識的時候，在接下來的PRD評審過程里，才能讓研發和其他部門的人和你是在一個頻道上思考的。

03

PRD文檔是用于給研發進行開發所使用的，所以這里就有一個非常關鍵的原則——沒有任何歧義的部分。

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

就像我們剛剛上面聊到的，登錄按鈕的錯誤提醒是有優先級的，你可以這樣寫：

當賬戶和密碼兩者有一個沒有輸入的情況下，點擊登錄按鈕時，在下方提示：賬號或密碼不能為空。

當賬戶和密碼輸入后，點擊登錄按鈕時，系統按以下順序進行判斷：

1.賬戶是否存在

存在：進行第2條規則判斷

不存在：下方提示文案：“該賬號不存在”

2.判斷密碼是否正確

不正確：下方提示文案：“賬號或密碼錯誤,請重新輸入”

正確：toast提示：“登錄成功”并跳轉頁面進入管理后臺首頁

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

User Case 是拿來干嘛的？是用來描述什么角色通過某某系統能做什么事情的流程體現，User Case 的書寫也是產品經理對用戶需求深刻理解的體現。

04

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

如果涉及到系統安全性部分還需要有安全性需求，比如接口的加密、賬戶的單點登錄、單位時間內多次接口訪問時需要進行人機交驗、用戶輸入不能注入SQL、代碼等。

如果涉及到一些法律上的部分，需要法務進行協助的需求。比如用戶隱私、用戶所輸入的安全性交驗，是否涉黃涉暴涉政等。

詳細的內容一篇文章說不完，我們后面再慢慢詳細說。

本文由 @寧叔愛思考 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Pexels，基于CC0協議。