需求文檔是以一種文檔記錄的方式，Excel需求文檔的優(yōu)勢(shì)在于能夠幫助更好地查閱信息。如何編寫Excel格式的需求文檔？作者根據(jù)自身經(jīng)驗(yàn)，并結(jié)合案例分享了相關(guān)經(jīng)驗(yàn)，希望對(duì)你有用。

之前參加枯葉講師的公開課，提到了Excel需求文檔的優(yōu)勢(shì)，剛好目前工作中也是通過Excel來編寫需求文檔，于是總結(jié)如下通過Excel來編寫需求文檔的經(jīng)驗(yàn)和技巧。

一、需求文檔的常見問題

產(chǎn)品經(jīng)理的日常工作中，編寫需求文檔是一項(xiàng)必備的技能。

需求文檔的重要性是不言而喻的，對(duì)團(tuán)隊(duì)的研發(fā)和測(cè)試人員，他們需要產(chǎn)品經(jīng)理提供詳情的需求文檔，以便以此為依據(jù)，開展開發(fā)和系統(tǒng)測(cè)試的工作。

但是往往由于時(shí)間緊迫、產(chǎn)品經(jīng)驗(yàn)不足等原因，提供的需求文檔，常常出現(xiàn)需求描述不清楚、邏輯不通、需求遺漏等問題，這些問題很容易在研發(fā)和測(cè)試工作中發(fā)現(xiàn)，例如：

研發(fā)抱怨需求文檔中沒有描述清楚：比如：文檔中寫到：點(diǎn)擊新增按鈕，打開新增頁(yè)面。前端就會(huì)跑過來疑問：這里新增頁(yè)面是新開頁(yè)面，還是當(dāng)前頁(yè)面打開。

研發(fā)在開發(fā)過程中，發(fā)現(xiàn)需求邏輯不通，找產(chǎn)品經(jīng)理反饋，產(chǎn)品經(jīng)理發(fā)現(xiàn)確實(shí)如此，趕緊補(bǔ)救。從而導(dǎo)致在研發(fā)過程中產(chǎn)生需求變更，引起眾怒，還是引起研發(fā)人員質(zhì)疑產(chǎn)品經(jīng)理的能力。

需求有遺漏，不完整。產(chǎn)品在驗(yàn)收的時(shí)候，發(fā)現(xiàn)某個(gè)功能的排序規(guī)則不對(duì)，然后讓研發(fā)修改。結(jié)果研發(fā)抱怨你的需求文檔中，沒有定義這個(gè)列表的排序規(guī)則，從而會(huì)產(chǎn)生團(tuán)隊(duì)矛盾。

那么，我們?nèi)绾尾拍馨研枨笳f明清楚，盡量減少需求不清、需求遺漏、需求質(zhì)量問題呢？

二、Excel需求文檔

需求文檔是以一種文檔記錄的方式，進(jìn)行信息的溝通和傳遞。以便有跡可循，有理可依。

前面出現(xiàn)的：需求不清、需求遺漏、需求質(zhì)量問題，我們可以通過編寫Excel形式的需求文檔，逐漸減少此類情況的發(fā)生，從而提升需求文檔質(zhì)量。

需求文檔也是一個(gè)迭代的過程中，通過多次的迭代過程，一方面我們可以形成思考的方式，然后查漏補(bǔ)缺，進(jìn)而逐漸可以完成出完整的需求文檔。另一方面我們可以積累出需求文檔庫(kù)，便于后期的復(fù)用。

1. 歷史迭代可追溯

首先Excel的需求文檔，可以很清楚每個(gè)版本迭代的功能有哪些。產(chǎn)品不斷的迭代更新，或是人員的交接，經(jīng)常需要回溯之前的線上邏輯，需求文檔的缺失或不完善，會(huì)導(dǎo)致線上邏輯不明確，甚至后續(xù)的產(chǎn)品需求設(shè)計(jì)的邏輯與線上矛盾或沖突，為項(xiàng)目的開發(fā)帶來麻煩。

Excel需求文檔中，可以通過sheet保留每一個(gè)迭代版本的需求內(nèi)容。方便進(jìn)行信息的查閱！

2. 需求顆粒度細(xì)

我們經(jīng)常會(huì)很糾結(jié)，需求到底要寫到多細(xì)，常常以為寫的很詳細(xì)了，結(jié)果研發(fā)還是有很多疑問。通過Excel的需求文檔，對(duì)每一個(gè)元素進(jìn)行描述，這樣細(xì)化之后的需求，可以防止遺漏，思考就更加清楚，方便檢查，查漏補(bǔ)缺，從而提升需求文檔的質(zhì)量。

例如：后臺(tái)系統(tǒng)都有導(dǎo)出某個(gè)頁(yè)面上的數(shù)據(jù)的功能，比如導(dǎo)出用戶列表的數(shù)據(jù)。有些產(chǎn)品經(jīng)理在寫這個(gè)導(dǎo)出需求時(shí)只有一句話的描述：點(diǎn)擊『導(dǎo)出』按鈕后，將表格中的數(shù)據(jù)導(dǎo)出為excel文檔。

但是我們經(jīng)過一步一步拆解到不能再細(xì)的程度，這樣再來審視這句話，會(huì)發(fā)現(xiàn)有很多不明確的點(diǎn)：

• 導(dǎo)出的文件格式是什么？xlsx？xls？還是csv？（這三種格式都很常見）
• 導(dǎo)出的表格是否區(qū)分sheet？sheet名稱是什么？
• 導(dǎo)出的表格包含哪些字段？
• 如果還有圖片（頭像）等信息，怎么處理？
• 導(dǎo)出列表數(shù)據(jù)的最大上限值是多少？
• 導(dǎo)出的文件如何命名？

上述這些問題，如果在需求文檔中不明確，在需求開發(fā)過程中通常會(huì)出現(xiàn)兩種情況：要么是技術(shù)同學(xué)過來問產(chǎn)品經(jīng)理如何定義（可能不止一次的溝通），要么是技術(shù)同學(xué)按自己的想法實(shí)現(xiàn)。前者增加了溝通成本，后續(xù)還是要花費(fèi)時(shí)間完善文檔或是再給測(cè)試同學(xué)講需求，后者如果實(shí)現(xiàn)的方案在測(cè)試環(huán)節(jié)發(fā)現(xiàn)與產(chǎn)品或測(cè)試的想法不同，就需要返工再調(diào)整，兩種情況無論怎樣，都會(huì)浪費(fèi)時(shí)間。

3. 迭代更新，沉淀需求庫(kù)

需求傳遞到研發(fā)和測(cè)試人員之后，通過團(tuán)隊(duì)后續(xù)反饋，產(chǎn)品經(jīng)理可以及時(shí)補(bǔ)充遺漏的地方，完善需求文檔，并且總結(jié)遺漏的原因，避免后期再出現(xiàn)同樣的問題，從而最終能夠完成一個(gè)高質(zhì)量的需求文檔。

通過這樣迭代，可以形成一個(gè)通用的需求庫(kù)。其實(shí)在需求中，發(fā)現(xiàn)不同需求所用到的功能很多都是類似的，那么后面如果再碰到這樣的需求，我們可以在這個(gè)基礎(chǔ)上面進(jìn)行復(fù)用，從積累的需求庫(kù)中，提取出相應(yīng)的功能即可。

三、Excel需求文檔的模板介紹

下面來介紹Excel形式的需求文檔的模板，定義好模板結(jié)構(gòu)之后，可以快速編寫。

1. 文檔命名規(guī)范

文檔的編號(hào)和命名很關(guān)鍵，每個(gè)產(chǎn)品都是經(jīng)過若干個(gè)迭代才完成的，而每個(gè)迭代所完成的產(chǎn)品功能或者升級(jí)的需求都可能是不一樣的，因此需要定義清楚該文件屬于產(chǎn)品的哪個(gè)迭代，修改了幾個(gè)版本。

文件命名的方法一般是通過版本號(hào)定義，比如簡(jiǎn)單的方法是：XX產(chǎn)品V1.0PRD_V2,前面的V1.0是產(chǎn)品迭代的編號(hào)，后面的V2 PRD的版本號(hào)。

2. 文檔基本信息介紹

需求文檔的封面基本信息，需要注明產(chǎn)品名稱、需求文檔的狀態(tài)、當(dāng)前版本、編寫需求文檔的人員和完成的時(shí)間。

3. 文檔修改記錄

產(chǎn)品是分多個(gè)版本迭代的，關(guān)于需求文檔修改的記錄頁(yè)需要記錄下面，包括：版本號(hào)、修訂日期、模塊、修訂說明、修訂人、備注。文檔版本號(hào)顯示的當(dāng)前修改的內(nèi)容屬于文檔的第幾個(gè)版本(當(dāng)前系統(tǒng)的版本XX產(chǎn)品V1.0+修改的版本V1)，模板是具體到修改內(nèi)容屬于的功能模塊，以便閱讀人及時(shí)找到修改后的內(nèi)容，修改原因說明為什么要修改該需求，讓閱讀者直觀的了解原因。日期是指需求文檔修改的時(shí)間，修改人是指需求內(nèi)容的修改者。

4. 模板說明

需求文檔的模板參考上圖，需求文檔的關(guān)鍵屬性說明如下：

• 編號(hào)：編號(hào)就是功能的順序號(hào)，主要是需求的唯一性標(biāo)識(shí)。
• 模塊：把需求劃分到系統(tǒng)的某個(gè)功能模塊，一般只需要?jiǎng)澐值较到y(tǒng)的一級(jí)菜單。
• 功能名稱：系統(tǒng)化到系統(tǒng)的功能菜單，比如注冊(cè)、個(gè)人中心、活動(dòng)管理。
• 功能點(diǎn)：這個(gè)功能菜單中具體的功能點(diǎn)，比如修改個(gè)人信息、查詢訂單。
• 需求類型：需求類型一般包括：新增功能、功能改進(jìn)、需求變更、界面優(yōu)化、Bug修復(fù)、刪除功能、接口需求等。
• 功能詳細(xì)描述：功能詳情是描述這個(gè)功能點(diǎn)的頁(yè)面展示、業(yè)務(wù)規(guī)則內(nèi)容。是需求文檔的核心內(nèi)容。
• 參數(shù)：對(duì)輸入的參數(shù)信息描述。提示信息的描述。
• 備注：其它任何信息，如：與哪個(gè)信息相關(guān)。

示例：如何以正確的姿勢(shì)編寫需求？

在編寫需求文檔的過程中，往往因進(jìn)度緊而來不接寫的完整，這就需要技巧性的簡(jiǎn)化文檔，不妨先出一個(gè)系統(tǒng)框架，然后再補(bǔ)充每個(gè)欄目中的內(nèi)容，最后再來扣細(xì)節(jié)，這樣在檢查的時(shí)候，能夠及時(shí)發(fā)現(xiàn)需要是否有遺漏。沒有任何文檔是一次能寫好的，所以在初期版本不要一上來就追求完美，有瑕疵是很正常的，在考慮到不影響開發(fā)設(shè)計(jì)工作的前提下，將后期迭代的思考加入其中就好了。

• 搭建需求框架，細(xì)化了每個(gè)功能點(diǎn)上。
• 針對(duì)每個(gè)功能點(diǎn)，結(jié)構(gòu)化描述詳情功能。
• 最后整體檢查，補(bǔ)充遺漏、摳細(xì)節(jié)，完善需求文檔。

例如：一個(gè)活動(dòng)管理頁(yè)面如下，那我們要如何編寫活動(dòng)管理模板的功能說明。

1. 搭建框架

在寫需求文檔前，需要先搭建框架，首先會(huì)把這個(gè)模塊盡可能細(xì)化到功能點(diǎn)，其實(shí)就是先寫目錄。結(jié)合產(chǎn)品功能的操作，涉及到多個(gè)頁(yè)面或多個(gè)系統(tǒng)的狀態(tài)變化；另一個(gè)是大框架下的內(nèi)容是不是有遺漏，有沒有遺漏描述某一項(xiàng)功能邏輯。

2. 結(jié)構(gòu)化描述

通常完成了目錄框架，自己對(duì)整個(gè)需求就很清晰明朗了，一種一切盡在掌控的感覺，接下來就是挨個(gè)補(bǔ)齊具體的需求的功能描述。功能是有邏輯的。而不是只講功能點(diǎn)羅列出來。通過結(jié)構(gòu)化的梳理，也是自己對(duì)系統(tǒng)的進(jìn)一步深入思考。

所以，產(chǎn)品交付給研發(fā)的，是詳細(xì)的系統(tǒng)功能說明。研發(fā)是實(shí)現(xiàn)功能，按照功能清單來，此時(shí)產(chǎn)品提供的就是簡(jiǎn)明扼要的功能說明。

3. 摳細(xì)節(jié)

工作中我經(jīng)常建議產(chǎn)品同學(xué)寫完需求文檔后自己再讀一遍，自己讀一遍就能發(fā)現(xiàn)很多問題和漏洞。更重要的是，要能代入看需求文檔的人的角色中，以他們的視角來審閱需求。最簡(jiǎn)單的，我習(xí)慣于將文檔中我認(rèn)為重要的，擔(dān)心他人閱讀時(shí)會(huì)忽視的段落文字加下劃線或背景色標(biāo)識(shí)，或是特別注明（此處設(shè)計(jì)師請(qǐng)注意有多個(gè)狀態(tài)）等。代入測(cè)試的角色，試想自己看著這份需求文檔在寫測(cè)試用例，通常會(huì)發(fā)現(xiàn)很多漏洞。

總結(jié)

需求文檔不僅僅是為了交付給研發(fā)測(cè)試而編寫的，是為了降低需求遺漏的風(fēng)險(xiǎn)，降低團(tuán)隊(duì)的矛盾，確保研發(fā)理解的功能與產(chǎn)品想要的功能一致，從而有效避免了團(tuán)隊(duì)甩鍋。

通過編寫需求文檔，產(chǎn)品經(jīng)理也可以再次梳理一遍需求?；蛘咴谘邪l(fā)過程中，根據(jù)溝通發(fā)現(xiàn)問題，繼續(xù)查漏補(bǔ)缺需求文檔。最終反哺于自己，發(fā)現(xiàn)自己的遺漏，提升需求質(zhì)量。這樣長(zhǎng)期積累下面的需求文檔，就是一個(gè)功能庫(kù)，一方面可以引導(dǎo)我們把需求思考的更加清晰，一方面當(dāng)做功能庫(kù)，便于后期的需求復(fù)用，幫助我們更快的完成需求文檔，提升效率。

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

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