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

需求文檔的重要性，相信大多數(shù)產(chǎn)品經(jīng)理都有所感知了，一份好的需求文檔，更是能提高效率，減少重復(fù)溝通所花費(fèi)的時(shí)間。那么，好的需求文檔，到底長啥樣？

去年入職新公司后，研發(fā)團(tuán)隊(duì)人員均不在base地，且都是通過外協(xié)的形式進(jìn)行項(xiàng)目開發(fā)（問就是初創(chuàng)團(tuán)隊(duì)的難），這對導(dǎo)致了產(chǎn)研團(tuán)隊(duì)溝通成本很高。另一方面，對于產(chǎn)品工作的最后一公里、產(chǎn)品經(jīng)理的重要交付物——需求文檔的要求也極其的高，因?yàn)楫惖貐f(xié)作溝通成本高的問題，一份好的需求文檔可以有效降低重復(fù)溝通的時(shí)間，以便有更多的時(shí)間去摸魚（bushi）。

那么，就讓我來聊一聊需求文檔（prd/產(chǎn)品需求規(guī)格書）的結(jié)構(gòu)和一些需要注意的點(diǎn)。

一、好的需求文檔，到底長啥樣？

在說我的結(jié)論之前，我們先來看看市面上的文檔管理工具所提供的需求文檔的模板格式，下圖分為飛書、語雀和云效：

以這三家為例，我們來看看對應(yīng)的需求文檔的結(jié)構(gòu)：

• 飛書：版本信息、變更日志、文檔說明（名詞解釋）、需求背景（產(chǎn)品/數(shù)據(jù)現(xiàn)狀、用戶調(diào)研、競品分析）、需求范圍、功能詳細(xì)說明（產(chǎn)品流程圖、交互原型圖、功能說明）、非功能需求、埋點(diǎn)、項(xiàng)目規(guī)劃、附錄。
• 語雀：變更記錄、背景介紹（業(yè)務(wù)背景、業(yè)務(wù)場景）、產(chǎn)品概述（產(chǎn)品定位、服務(wù)對象、產(chǎn)品邏輯、信息架構(gòu)、角色術(shù)語）、需求說明（需求列表、需求明細(xì)、非功能需求）、人員&排期。
• 云效：基本信息（項(xiàng)目成員）、需求背景、產(chǎn)品目標(biāo)、衡量指標(biāo)、產(chǎn)品需求、功能及界面設(shè)計(jì)、問題、暫不支持、附錄。

是不是很相似？

互聯(lián)網(wǎng)隨著這些年的發(fā)展，需求文檔也慢慢的標(biāo)準(zhǔn)化，只需在對應(yīng)的模板稍許改造就能得出符合自己團(tuán)隊(duì)的模板。在前司中，因在線文檔管理工具使用的是語雀，其中不乏有同事直接使用語雀的需求文檔模板。

而我的需求文檔，隨著工作這幾年的迭代和與不同團(tuán)隊(duì)的適配，自認(rèn)為還是比較好的模板（叉腰），讓我們來看下文檔結(jié)構(gòu)，如下圖：

其中我認(rèn)為版本記錄、需求說明、名詞解釋、需求列表、詳細(xì)需求說明和問題為需求文檔的必要性內(nèi)容，而暫不支持、性能需求、數(shù)據(jù)需求及其他均為選擇性內(nèi)容。

1. 版本記錄

版本記錄是需求文檔非常重要的一部分，因?yàn)楹芏嘈枨蠖际菚a(chǎn)生變更的，特別是在一些比較大的需求上…這就導(dǎo)致了版本記錄的必要性，這樣在用戶（研發(fā)/測試/自己…）閱讀文檔時(shí)就能大體上知道這個(gè)需求的迭代情況。

版本記錄包含日期、版本號、修訂人和修訂描述，其中需格外注意的是修訂描述。在修訂描述中需求描述修訂原因和具體內(nèi)容，當(dāng)然修訂原因也可單獨(dú)拆分出一個(gè)字段進(jìn)行管理，原因需說明該版本的‘增刪改’情況。具體內(nèi)容則需說明修改的‘場景+結(jié)果’，例如后臺管理端新增用戶時(shí)剔除手機(jī)號的必填校驗(yàn)，則可將具體內(nèi)容描述為用戶在管理端「用戶管理」中新增/修改用戶時(shí)，提交時(shí)去除手機(jī)號的必填校驗(yàn)。

言簡意賅的內(nèi)容描述，可以降低理解成本。

2. 需求說明

需求說明包含需求來源、需求背景和需求目標(biāo)。

需求來源主要記錄需求的所屬項(xiàng)目、需求提出人和主要的負(fù)責(zé)人（需求負(fù)責(zé)人/研發(fā)負(fù)責(zé)人/測試負(fù)責(zé)人…）。在一個(gè)公司中有多個(gè)項(xiàng)目在開發(fā)屬于正?，F(xiàn)象，因此需記錄需求的所屬項(xiàng)目；需求提出人則可以是老板、對應(yīng)的業(yè)務(wù)同事或者是自己，若后續(xù)需求提出人出現(xiàn)離崗交接時(shí)，也可跟進(jìn)對應(yīng)的提出人；主要負(fù)責(zé)人則按照公司規(guī)模進(jìn)行實(shí)際填寫，我前司人員較多，還會涉及到系統(tǒng)支持、排版等相關(guān)人員。

需求背景主要描述需求產(chǎn)生的背景，即為什么要做這個(gè)需求。需求背景的書寫切不可流于形式，深入的理解需求背景可以更好的理解當(dāng)前公司的戰(zhàn)略方向，因?yàn)槊恳粋€(gè)需求都是公司戰(zhàn)略執(zhí)行層的具體表現(xiàn)。

需求目標(biāo)則是描述需求實(shí)現(xiàn)的目標(biāo)，即要做什么。需求目標(biāo)可大可小，小至功能目標(biāo)，大至業(yè)務(wù)目標(biāo)，需把握好需求目標(biāo)的尺度。

3. 名詞解釋

名詞解釋主要解釋該需求的專業(yè)名詞，讓用戶更好的理解需求。例如在票據(jù)行業(yè)中的背書、貼現(xiàn)、前手等專有名詞，是有必要在對應(yīng)的需求中進(jìn)行闡述說明的。

4. 需求列表

需求列表（feature list）記錄了需求的具體需求，即怎么做。對于歷史項(xiàng)目/需求的更新，需求列表則尤為重要，在需求列表中描述本次需求的變更點(diǎn)，可以讓研發(fā)/測試更好理解本次的需求內(nèi)容，起到了‘總’的概覽作用。

5. 詳細(xì)需求說明

詳細(xì)需求說明需包含UML圖、原型圖和詳細(xì)邏輯說明。UML圖在正常的需求中起碼要包含活動圖/時(shí)序圖+狀態(tài)機(jī)圖（UML這么畫請看這篇文章），一個(gè)邏輯清晰的圖可以勝過千言萬語；原型圖和詳細(xì)邏輯說明相輔相成，構(gòu)成了需求文檔篇幅最大的部分，是對「怎么做」的更加詳細(xì)的描述，詳細(xì)到頁面如何跳轉(zhuǎn)、按鈕的交互邏輯、字段的展示邏輯等。

6. 問題

問題主要記錄需求評審過程中參會人員提出了相關(guān)問題，其中若未能當(dāng)場給出解答的部分，則需對問題和結(jié)論進(jìn)行記錄。

7. 暫不支持

暫不支持記錄當(dāng)前需求無法實(shí)現(xiàn)的部分。正常情況下，需求評審之前應(yīng)對需求的可實(shí)現(xiàn)方案進(jìn)行初步溝通，即和研發(fā)通通氣，這樣可以避免評審過程針對不可實(shí)現(xiàn)的打斷問題。

8. 性能需求

性能需求包含并發(fā)量、響應(yīng)速度等一系列系統(tǒng)性能相關(guān)的需求。性能需求相關(guān)的內(nèi)容偏向于技術(shù)層面，我在當(dāng)前基本不寫（寫了也沒啥用）。

9. 數(shù)據(jù)需求

數(shù)據(jù)需求包含數(shù)據(jù)量、存儲時(shí)間等，這與單獨(dú)的報(bào)表需求不同，因此我也不寫。

二、一些tips

說完我當(dāng)前的需求文檔構(gòu)成之后，我再來補(bǔ)充幾點(diǎn)我認(rèn)為比較重要的tips。

1. 善用目錄導(dǎo)航

對于動輒幾千字的需求文檔，要善用目錄導(dǎo)航，這樣在閱讀時(shí)可快速定位需求內(nèi)容，結(jié)構(gòu)性會更強(qiáng)。

關(guān)于管理端來說，我一般目錄導(dǎo)航中會根據(jù)頁面的從上到下的邏輯進(jìn)行描述，例如按照查詢條件、列表和操作進(jìn)行說明。

2. 文檔拆分

如果是一個(gè)大需求，涉及到系統(tǒng)的多個(gè)模塊的變更改造，最好對文檔進(jìn)行拆分，再利用文件夾對其規(guī)整，這樣在團(tuán)隊(duì)人員閱讀起來會降低一定門檻，對于后續(xù)的任務(wù)分配的工作也有一定幫助。

3. 需求顆粒度

需求的顆粒度是一個(gè)很難把控的事情。

比如，是否要涉及到表的相關(guān)字段。這個(gè)非?？简?yàn)產(chǎn)品經(jīng)理對于表的理解和系統(tǒng)的熟悉程度，因?yàn)楹芏嗲闆r下用戶端的字段和數(shù)據(jù)庫的字段并不是一一對應(yīng)的。于我而言，若是比較陌生的系統(tǒng)，則是按照‘取值路徑+截圖’的形式進(jìn)行描述，這樣能有效避免二義性。

另外，B端產(chǎn)品很多情況下會涉及到與外部對接，那么對方系統(tǒng)和本司系統(tǒng)避免不了要交互，那么在這種情況下，盡量保證詳細(xì)到對接文檔中的每個(gè)字段，這樣能最大程度降低溝通成本。

4. 舉個(gè)例子

很多時(shí)候，研發(fā)和測試對于需求的描述會感到非?；逎y懂，這樣「舉個(gè)例子」就不可避免。我一般是會在比較難懂的部分后面增加一個(gè)實(shí)際例子，就比如：

1 + 1 = 2

通過一個(gè)具體的例子來對需求點(diǎn)進(jìn)行闡釋，可以有效增強(qiáng)需求的可讀性。

5. 需求重點(diǎn)的標(biāo)注

需求文檔作為產(chǎn)品經(jīng)理的輸出物，產(chǎn)品經(jīng)理對于需求可謂是了然于胸，那么在文檔中就可以著重標(biāo)注出需求的重點(diǎn)（例如用紅色字體進(jìn)行突出），以此突出某個(gè)重要需求點(diǎn)，要求研發(fā)和測試著重關(guān)注。

三、總結(jié)

需求文檔對于我來說主要作用還是傳達(dá)和記錄，讓團(tuán)隊(duì)成員對于需求達(dá)成相同的認(rèn)知，以及讓后人對某個(gè)需求有跡可循，不至于系統(tǒng)‘口口相傳’。因此，需求文檔并不是所謂產(chǎn)品經(jīng)理一言堂的一個(gè)文檔，而是團(tuán)隊(duì)對需求的共同認(rèn)知，所以適合團(tuán)隊(duì)的就是一份好的需求文檔。

如果需要我對好的文檔下一份定義，那就是——問題的答案都在文檔中。