如何交付高質(zhì)量的產(chǎn)品需求(二)
如何做好一份高質(zhì)量的產(chǎn)品需求,作者從完整、具體、準確、友好四個方面出發(fā),分析做好產(chǎn)品需求所需要具備的要點,希望通過閱讀本篇文章,能對你有所幫助。
交付高質(zhì)量的產(chǎn)品需求:
一份高質(zhì)量的產(chǎn)品需求,應(yīng)該是具備以下重要特性:完整、具體、準確、友好。
一、完整
產(chǎn)品需求的完整性,包括標配需求,分支流程、異常流程的閉環(huán);包括功能邏輯的齊全;包括不同的業(yè)務(wù)場景;包括上下游關(guān)聯(lián)影響的說明;包括附件資料;包括非功能性需求…
1. 分支、異常流程
業(yè)務(wù)流程中涉及有分支流程,需說明每種分支流程的走向、流程節(jié)點的具體規(guī)則、不應(yīng)出現(xiàn)有去無回、斷頭路的情況;涉及有異常流程,同樣需需說明異常流程的觸發(fā)條件、走向、異常流程節(jié)點的具體業(yè)務(wù)規(guī)則。
比如在常見的OA審批流程中,就存在以下容易被忽略的流程狀況:
- 提交OA申請后,沒有撤銷申請的步驟,以及撤銷申請后是否可修改再次提交申請。
- 審批人超時未審批 流程該怎么走,超24小時未審、超48小時未審 流程如何處理。
- 審批人駁回OA申請,是否可以直接修改原申請內(nèi)容 再次提交申請。
- 申請人職級不同,審批層級不同的情況,這種多級審批流程如何定義和說明。
- 審批流程結(jié)束后,是否有需要 回寫的數(shù)據(jù)、或需要更新的狀態(tài)。
2. 列舉完整的業(yè)務(wù)場景
對于業(yè)務(wù)場景眾多、且復雜的需求,需列舉出所有相關(guān)的業(yè)務(wù)場景,以及每種情況對應(yīng)的業(yè)務(wù)規(guī)則和邏輯、或處理方案。
這點上,就比較考驗產(chǎn)品同學的業(yè)務(wù)熟悉程度、以及業(yè)務(wù)分析能力了。
在以下購物車的示例中,在提交訂單時,就需考慮各種業(yè)務(wù)場景下的邏輯處理:
- 商品已下架。
- 商品無庫存。
- 商品被刪除。
- 商品不在配送區(qū)域內(nèi)。
- 商品屬于不同的商家(涉及需拆單)。
- 商品屬于不同的倉庫(涉及需拆單)。
- 包含需冷鏈運輸?shù)纳唐罚ㄉ婕靶璨饐危?/li>
- …
3. 上下游相關(guān)聯(lián)的邏輯
修改某項功能點(尤其涉及到基礎(chǔ)數(shù)據(jù)變更的情況),需列舉出上下游相關(guān)的修改點,或通知下游系統(tǒng)變更的影響以及可能需要做哪些修改;包括相關(guān)模塊的功能點、對外接口、權(quán)限規(guī)則、數(shù)據(jù)報表、數(shù)據(jù)的導入導出等。
- 比如:客戶信息中 客戶類型的枚舉值由5個變成了3個,在統(tǒng)計報表中原來根據(jù)5個客戶類型統(tǒng)計數(shù)據(jù)的邏輯,就需要做同步的變更。
- 再比如:客戶信息中 渠道類型由1個字段拆成了2個字段,對外接口中讀取渠道類型的邏輯,需要指明是否需要調(diào)整。
4. 原有的規(guī)則和邏輯
涉及需要描述原有功能邏輯的需求,產(chǎn)品同學普遍的會寫:與原有邏輯保持一致、或翻看原有邏輯,同時又不指明原有邏輯是怎樣的,或在哪個地方以查看。如果是新同學遇到這種情況,就不知所措,要開始懟人了。
對于業(yè)務(wù)邏輯復雜的中后臺系統(tǒng),并且是經(jīng)歷1-100的迭代過程,更需要注意描述清楚原功能的邏輯和規(guī)則,或者指明在哪個文檔、文檔的哪個部分可以查看現(xiàn)。如原有邏輯已找不到有文檔記錄,可能就需要提前找技術(shù)同學翻查代碼,以核驗原有邏輯的正確性。
5. 提供關(guān)聯(lián)的附件資料
- 導入、導出模板文件:涉及導入、導出數(shù)據(jù)的系統(tǒng)功能,需提供導入、導出數(shù)據(jù)的模板文件。
- 初始化的數(shù)據(jù):功能上線后需立即展示初始數(shù)據(jù)的需求,應(yīng)提供初始化的數(shù)據(jù)源文件。
- 消息、短信模板:如需發(fā)送短信,需提供短信模板,包括短信簽名。如需給用戶發(fā)送即時消息,需提供消息模板文件,包括發(fā)送人、消息模板內(nèi)容。 同時指明,短信或消息模板中的變量,以及變量的取值規(guī)則。
- 產(chǎn)品提示文案:固定的提示文案,如有變量,需指明變量如何取值。
6. 非功能性需求
- 權(quán)限需求:所有功能權(quán)限、數(shù)據(jù)權(quán)限點的權(quán)限分配規(guī)則,涉及數(shù)據(jù)接口的,還需說明接口范圍的權(quán)限要求。
- 安全需求:說明哪些字段或數(shù)據(jù)需配置為監(jiān)控字段,即默認展示位***,點擊再查看明文。對于業(yè)務(wù)復雜的后臺系統(tǒng),可能還需再深入一步,指明哪些級別或類型的用戶可直接看明文、哪些需點擊再看明文、哪些只能看到***。 安全類與權(quán)限類的需求,關(guān)聯(lián)度比較高,有時需結(jié)合在一起,尤其是重業(yè)務(wù)、重流程的B端產(chǎn)品,需單獨列為一份產(chǎn)品需求來對待。
如以下示例:
- 數(shù)據(jù)需求:如果涉及存量數(shù)據(jù)的處理(比如加字段),需描述存量數(shù)據(jù)的處理方案;描述哪些功能項需做數(shù)據(jù)埋點。
- 兼容性需求: 不同移動端系統(tǒng)(Android、iOS等)及其版本、手機及其型號的兼容性;新老數(shù)據(jù)接口的兼容性等;不同瀏覽器及其版本的兼容性。
- 性能需求:系統(tǒng)并發(fā)量的要求;頁面打開速度、響應(yīng)速度的要求。
二、具體
交付給技術(shù)、測試同學的需求,一定是具體可編碼的、可執(zhí)行測試驗證的。
很多時候產(chǎn)品同學以為是清楚的描述了,實際上會包括潛在的多個選項指明不清、或與且的關(guān)系、多個操作入口該修改哪些地方、以及邊界性的問題等。
在曾經(jīng)團隊中出現(xiàn)過如此產(chǎn)品需求:
滿足狀態(tài)在跟進中、最后跟進時間在7天內(nèi)的客戶需由銷售管理層手動分配銷售經(jīng)理。
在該需求描述中就存在不夠清晰,具體的問題:
- 滿足的2個條件是且、還是或的關(guān)系。
- 跟進中的客戶有跟進中-未拜訪、跟進中-已拜訪2個狀態(tài),那 跟進中 該如何判定,只包括其中一個狀態(tài),還是2個狀態(tài)都包括。
- 最后跟進時間在7天內(nèi),是否包括7天。
再比如以下需求:
替換銷售經(jīng)理時,不能填寫自己的姓名。
實際上替換銷售經(jīng)理的操作入口有N個,并且有的特殊地方其邏輯是不同的,最好把替換的入口列舉出來的,不然技術(shù)同學容易做漏、測試同學容易測漏、上線后也便于自己驗收。
另外不能填寫自的姓名該怎么判斷,可編碼的具體描述應(yīng)該是不能填寫當前操作用戶的姓名。
三、準確
同樣的文字描述加上標點符號、或斷句不同,其表達出來的意思就可能有多種。需求的準確性主要指需求的描述應(yīng)該是唯一確定、理解上沒有歧義的。
類似時間/日期相關(guān)的描述,應(yīng)具體說明是哪個時間段,精確到日期還是時分秒;涉及連續(xù)多個且、或的邏輯判斷,需明確描述“或者”, “并且”的判斷規(guī)則。對于理解可能有歧義,又很難文字描述邏輯需求,加以釋義說明、或示例說明。
團隊曾經(jīng)做過一個增值服務(wù)相關(guān)的費用:不加時效費。
從字面上腦回路不同的人就有不同的理解:
- 不加 “時效費”,不加上? 貨物運輸時效的費用,即是要減去相應(yīng)的費用。
- “不加時效” 費,不加 貨物運輸時效? 的一種費用。
比如以下產(chǎn)品需求:
營業(yè)額均值取值規(guī)則:取當前時間前3個月客戶的營業(yè)額之和的均值
當前時間前3個月的理解:
假如當前時間為2020-10-10 10:00,則當前時間前三個月含義可能有2種:
- 自然月份: 2020-07-01 00:00:00 到 2020-09-30 23:59:59?
- 非自然月份:2020-07-10 00:00:00 到 2020-10-09 23:59:59?
前3個月營業(yè)額之和均值的理解:
假如3個月中有1個月的營業(yè)額為0,則取均值時除以2、還是除以3?或者是再往前多取一個月的營業(yè)額?
四、友好
產(chǎn)品需求描述清楚、準確了,最后展示給用戶(技術(shù)、測試同學)時,也需漂亮的顏值,友好的展示形式。
需求文檔需設(shè)置好文檔結(jié)構(gòu)圖,標明清晰文檔的結(jié)構(gòu)、層次,難易理解的邏輯給予示例說明,大段文字的空行、格式、間隔等,也都是需要考慮的因素。能用圖形、表格的盡量使用圖表展示,避免大坨的文字堆積。
比如以下示例中的格式、符號問題:
在申請信息頁面要增加 結(jié)算方式、客戶分值2個新的字段,以下團隊成員給出的文字描述,就沒太注意文字的格式、標點符號等展示細節(jié):
更友好的展示應(yīng)該是:
- 結(jié)算方式:取客戶后臺->財務(wù)信息->結(jié)算信息中的結(jié)算方式字段。
- 客戶分值:取客戶后臺->基礎(chǔ)信息->基本信息中的客戶分值字段。
再比如以下的文檔結(jié)構(gòu)圖示例,設(shè)置了文檔結(jié)構(gòu)圖的文檔就更便于閱讀:
五、另外
清晰明了的產(chǎn)品需求, 能有效提高產(chǎn)研的效率,節(jié)省團隊的溝通成本,也能體現(xiàn)出產(chǎn)品同學的專業(yè)度,贏取團隊的信任。
但也并無意味著溝通的減少,產(chǎn)研整個過程的產(chǎn)品、技術(shù)、測試同學之間積極、及時性、無障礙的溝通始終是不可缺少的,在項目跟進過程中,產(chǎn)品同學大部分的時間其實都會花在溝通上。
溝通是門大學問,也是一生的學問。
本文由 @天晴一把刀 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
- 目前還沒評論,等你發(fā)揮!