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

如何做好一份高質量的產品需求，作者從完整、具體、準確、友好四個方面出發，分析做好產品需求所需要具備的要點，希望通過閱讀本篇文章，能對你有所幫助。

交付高質量的產品需求：

一份高質量的產品需求，應該是具備以下重要特性：完整、具體、準確、友好。

一、完整

產品需求的完整性，包括標配需求，分支流程、異常流程的閉環；包括功能邏輯的齊全；包括不同的業務場景；包括上下游關聯影響的說明；包括附件資料；包括非功能性需求…

1. 分支、異常流程

業務流程中涉及有分支流程，需說明每種分支流程的走向、流程節點的具體規則、不應出現有去無回、斷頭路的情況；涉及有異常流程，同樣需需說明異常流程的觸發條件、走向、異常流程節點的具體業務規則。

比如在常見的OA審批流程中，就存在以下容易被忽略的流程狀況：

• 提交OA申請后，沒有撤銷申請的步驟，以及撤銷申請后是否可修改再次提交申請。
• 審批人超時未審批 流程該怎么走，超24小時未審、超48小時未審 流程如何處理。
• 審批人駁回OA申請，是否可以直接修改原申請內容 再次提交申請。
• 申請人職級不同，審批層級不同的情況，這種多級審批流程如何定義和說明。
• 審批流程結束后，是否有需要 回寫的數據、或需要更新的狀態。

2. 列舉完整的業務場景

對于業務場景眾多、且復雜的需求，需列舉出所有相關的業務場景，以及每種情況對應的業務規則和邏輯、或處理方案。

這點上，就比較考驗產品同學的業務熟悉程度、以及業務分析能力了。

在以下購物車的示例中，在提交訂單時，就需考慮各種業務場景下的邏輯處理：

• 商品已下架。
• 商品無庫存。
• 商品被刪除。
• 商品不在配送區域內。
• 商品屬于不同的商家（涉及需拆單）。
• 商品屬于不同的倉庫（涉及需拆單）。
• 包含需冷鏈運輸的商品（涉及需拆單）。
• …

3. 上下游相關聯的邏輯

修改某項功能點（尤其涉及到基礎數據變更的情況），需列舉出上下游相關的修改點，或通知下游系統變更的影響以及可能需要做哪些修改；包括相關模塊的功能點、對外接口、權限規則、數據報表、數據的導入導出等。

• 比如：客戶信息中 客戶類型的枚舉值由5個變成了3個，在統計報表中原來根據5個客戶類型統計數據的邏輯，就需要做同步的變更。
• 再比如：客戶信息中 渠道類型由1個字段拆成了2個字段，對外接口中讀取渠道類型的邏輯，需要指明是否需要調整。

4. 原有的規則和邏輯

涉及需要描述原有功能邏輯的需求，產品同學普遍的會寫：與原有邏輯保持一致、或翻看原有邏輯，同時又不指明原有邏輯是怎樣的，或在哪個地方以查看。如果是新同學遇到這種情況，就不知所措，要開始懟人了。

對于業務邏輯復雜的中后臺系統，并且是經歷1-100的迭代過程，更需要注意描述清楚原功能的邏輯和規則，或者指明在哪個文檔、文檔的哪個部分可以查看現。如原有邏輯已找不到有文檔記錄，可能就需要提前找技術同學翻查代碼，以核驗原有邏輯的正確性。

5. 提供關聯的附件資料

• 導入、導出模板文件：涉及導入、導出數據的系統功能，需提供導入、導出數據的模板文件。
• 初始化的數據：功能上線后需立即展示初始數據的需求，應提供初始化的數據源文件。
• 消息、短信模板：如需發送短信，需提供短信模板，包括短信簽名。如需給用戶發送即時消息，需提供消息模板文件，包括發送人、消息模板內容。 同時指明，短信或消息模板中的變量，以及變量的取值規則。
• 產品提示文案：固定的提示文案，如有變量，需指明變量如何取值。

6. 非功能性需求

• 權限需求：所有功能權限、數據權限點的權限分配規則，涉及數據接口的，還需說明接口范圍的權限要求。
• 安全需求：說明哪些字段或數據需配置為監控字段，即默認展示位***，點擊再查看明文。對于業務復雜的后臺系統，可能還需再深入一步，指明哪些級別或類型的用戶可直接看明文、哪些需點擊再看明文、哪些只能看到***。 安全類與權限類的需求，關聯度比較高，有時需結合在一起，尤其是重業務、重流程的B端產品，需單獨列為一份產品需求來對待。

如以下示例：

• 數據需求：如果涉及存量數據的處理(比如加字段），需描述存量數據的處理方案；描述哪些功能項需做數據埋點。
• 兼容性需求： 不同移動端系統（Android、iOS等）及其版本、手機及其型號的兼容性；新老數據接口的兼容性等；不同瀏覽器及其版本的兼容性。
• 性能需求：系統并發量的要求；頁面打開速度、響應速度的要求。

二、具體

交付給技術、測試同學的需求，一定是具體可編碼的、可執行測試驗證的。

很多時候產品同學以為是清楚的描述了，實際上會包括潛在的多個選項指明不清、或與且的關系、多個操作入口該修改哪些地方、以及邊界性的問題等。

在曾經團隊中出現過如此產品需求：

滿足狀態在跟進中、最后跟進時間在7天內的客戶需由銷售管理層手動分配銷售經理。

在該需求描述中就存在不夠清晰，具體的問題：

• 滿足的2個條件是且、還是或的關系。
• 跟進中的客戶有跟進中-未拜訪、跟進中-已拜訪2個狀態，那 跟進中 該如何判定，只包括其中一個狀態，還是2個狀態都包括。
• 最后跟進時間在7天內，是否包括7天。

再比如以下需求：

替換銷售經理時，不能填寫自己的姓名。

實際上替換銷售經理的操作入口有N個，并且有的特殊地方其邏輯是不同的，最好把替換的入口列舉出來的，不然技術同學容易做漏、測試同學容易測漏、上線后也便于自己驗收。

另外不能填寫自的姓名該怎么判斷，可編碼的具體描述應該是不能填寫當前操作用戶的姓名。

三、準確

同樣的文字描述加上標點符號、或斷句不同，其表達出來的意思就可能有多種。需求的準確性主要指需求的描述應該是唯一確定、理解上沒有歧義的。

類似時間/日期相關的描述，應具體說明是哪個時間段，精確到日期還是時分秒；涉及連續多個且、或的邏輯判斷，需明確描述“或者”， “并且”的判斷規則。對于理解可能有歧義，又很難文字描述邏輯需求，加以釋義說明、或示例說明。

團隊曾經做過一個增值服務相關的費用：不加時效費。

從字面上腦回路不同的人就有不同的理解：

• 不加 “時效費”，不加上? 貨物運輸時效的費用，即是要減去相應的費用。
• “不加時效” 費，不加 貨物運輸時效? 的一種費用。

比如以下產品需求：

營業額均值取值規則：取當前時間前3個月客戶的營業額之和的均值

當前時間前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個月營業額之和均值的理解：

假如3個月中有1個月的營業額為0，則取均值時除以2、還是除以3？或者是再往前多取一個月的營業額？

四、友好

產品需求描述清楚、準確了，最后展示給用戶（技術、測試同學）時，也需漂亮的顏值，友好的展示形式。

需求文檔需設置好文檔結構圖，標明清晰文檔的結構、層次，難易理解的邏輯給予示例說明，大段文字的空行、格式、間隔等，也都是需要考慮的因素。能用圖形、表格的盡量使用圖表展示，避免大坨的文字堆積。

比如以下示例中的格式、符號問題：

在申請信息頁面要增加 結算方式、客戶分值2個新的字段，以下團隊成員給出的文字描述，就沒太注意文字的格式、標點符號等展示細節：

更友好的展示應該是：

• 結算方式：取客戶后臺->財務信息->結算信息中的結算方式字段。
• 客戶分值：取客戶后臺->基礎信息->基本信息中的客戶分值字段。

再比如以下的文檔結構圖示例，設置了文檔結構圖的文檔就更便于閱讀：

五、另外

清晰明了的產品需求， 能有效提高產研的效率，節省團隊的溝通成本，也能體現出產品同學的專業度，贏取團隊的信任。

但也并無意味著溝通的減少，產研整個過程的產品、技術、測試同學之間積極、及時性、無障礙的溝通始終是不可缺少的，在項目跟進過程中，產品同學大部分的時間其實都會花在溝通上。

溝通是門大學問，也是一生的學問。