本文來自《現(xiàn)代企業(yè)應(yīng)用設(shè)計指南》一書的試讀章節(jié)：第三章《理解扒秸，分析和表達(dá)用戶需求》。

歡迎閱讀并提供改進意見嗽元，在知乎上關(guān)注我阴孟。作者郵箱 phil.ren@mingdao.com

文/明道創(chuàng)始人任向暉

3.3 產(chǎn)品需求文檔

3.3.1 開始撰寫產(chǎn)品需求文檔前的準(zhǔn)備

在軟件產(chǎn)品設(shè)計領(lǐng)域，PRD（產(chǎn)品需求文檔）是最重要的文書昼榛。很多產(chǎn)品設(shè)計人員在接到設(shè)計任務(wù)后會急于開始撰寫境肾，同時非常在意PRD形式的完整性。在互聯(lián)網(wǎng)上，也有大量的公開PRD模版可以獲得奥喻，感覺可以按照填表格的方式來完成它偶宫。但是，不要過于著急环鲤。在開始撰寫PRD之前纯趋，我們需要通過和需求方的溝通和確認(rèn)，事先對以下內(nèi)容達(dá)成了共識：

1）明確了產(chǎn)品設(shè)計的目標(biāo)是為了解決哪些用戶的哪些問題冷离，它對企業(yè)的商業(yè)目的實現(xiàn)起到了什么作用吵冒？（要做什么）

2）開發(fā)項目的投入資源怎樣？可以有多少產(chǎn)品研發(fā)人員西剥？給出了多長的時間窗口痹栖？（能有多少資源）

3）我們要交付的最小化產(chǎn)品要達(dá)到什么標(biāo)準(zhǔn)？是否有對標(biāo)的競爭對手或者其他產(chǎn)品可以幫助衡量瞭空？（要做到怎么樣）

3.3.2 PRD的常見誤區(qū)

1）混合而不分層次地陳述需求结耀，缺失由總到分，由高到低匙铡，由粗到細(xì)的層次結(jié)構(gòu)。這個問題通常是因為在PRD起草之前的討論和總結(jié)不夠有條理造成碍粥。結(jié)構(gòu)化腦圖可以幫助團隊在動筆之前先建立好這個層次結(jié)構(gòu)鳖眼，將該腦圖作為PRD文檔的一部分也可以。

2）缺乏經(jīng)驗的設(shè)計者因為擔(dān)心遺漏嚼摩，追求一個過度完整的PRD钦讳，不僅事無巨細(xì)，而且把遠(yuǎn)期和非必要的需求羅列得過多枕面，從而模糊了交付標(biāo)準(zhǔn)的界限愿卒。實際上，沒有軟件產(chǎn)品是依靠第一個版本的PRD管得太久的潮秘。要么PRD需要持續(xù)迭代琼开，要么需要建立后續(xù)升級版本的PRD，設(shè)計者無需追求PRD的絕對完整枕荞。

3）設(shè)計者越俎代庖柜候，不是描述需求，而是描述了解決方案躏精。這個看似是全面能力的體現(xiàn)渣刷，但卻對高產(chǎn)出的協(xié)作帶來障礙。按照專業(yè)分工的要求矗烛，產(chǎn)品設(shè)計者應(yīng)該著眼于需求和實現(xiàn)目標(biāo)的描述辅柴，而不是替代架構(gòu)師和工程師來設(shè)計具體的數(shù)據(jù)表結(jié)構(gòu)和邏輯實現(xiàn)方法。

4）過度使用視覺輔助，而忽略對需求實質(zhì)的描述碌嘀。產(chǎn)品設(shè)計人員喜歡大量使用腦圖等圖表來表達(dá)邏輯結(jié)構(gòu)涣旨，卻對需求的實質(zhì)缺乏自然的描寫。雖說一圖勝千言筏餐，但在需求文檔中开泽，除了參數(shù)和標(biāo)準(zhǔn)等具體的表格信息，其他視覺內(nèi)容起到的主要是輔助表達(dá)作用魁瞪。當(dāng)然穆律，另外一個極端也是PRD文檔容易出現(xiàn)的問題，那就是對于復(fù)雜的需求缺失視覺輔助呈現(xiàn)导俘，導(dǎo)致管理層和開發(fā)人員需要花很長的時間來閱讀和理解峦耘。在義、文旅薄、圖之間辅髓，產(chǎn)品設(shè)計者需要按照實際表達(dá)的需要組合使用。

3.3.3 PRD的基本構(gòu)成和擴展

我們做了大量的討論少梁、分析和總結(jié)洛口，接下來就是真的要動手寫出第一份產(chǎn)品需求文檔了。優(yōu)秀的PRD絕對不是來自它的模版結(jié)構(gòu)凯沪，也不依賴它的篇幅長短第焰，而是用最小的篇幅讓開發(fā)者準(zhǔn)確理解了產(chǎn)品開發(fā)意圖。一份相對規(guī)范的PRD總會包含一些不可或缺的內(nèi)容妨马，根據(jù)應(yīng)用產(chǎn)品的性質(zhì)挺举，它可能還需要更加豐富的擴展內(nèi)容，完整和詳簡程度取決于設(shè)計開發(fā)團隊的成熟度烘跺、應(yīng)用產(chǎn)品本身的重要度和質(zhì)量風(fēng)險等多個因素湘纵。

以下列出了一份完整的PRD可能包含的所有模塊，其中有一部分是根據(jù)需要可選擴展的滤淳。為了讓你更清晰地理解每部分內(nèi)容的性質(zhì)和作用梧喷，我們?nèi)淌褂昧艘粋€慈善業(yè)募款管理軟件的例子。

1）開發(fā)目的

用最自然通俗的語言說明為什么要開發(fā)這個企業(yè)應(yīng)用脖咐，它能夠給用戶企業(yè)帶來什么價值伤柄。這是看似簡單，但很容易被忽略的部分文搂。我們在之前介紹了“三層次需求分析”的方法适刀，那么在“開發(fā)目的”的章節(jié)就是要將其中的“整體商業(yè)目標(biāo)”通俗易懂地準(zhǔn)確表達(dá)出來。

如果你要為本企業(yè)開發(fā)一個定制應(yīng)用煤蹭，那么你需要闡述對本公司的商業(yè)意義笔喉；如果你是一家軟件公司取视，要開發(fā)一個軟件產(chǎn)品，要描述它對目標(biāo)服務(wù)客戶企業(yè)的價值常挚。對于軟件產(chǎn)品開發(fā)企業(yè)作谭，說明開發(fā)一款產(chǎn)品的目的是為了進入某某市場，獲得客戶和收入不是PRD應(yīng)該描寫的開發(fā)目的奄毡。

我們舉一個軟件產(chǎn)品開發(fā)目的的例子折欠。比如一款面向慈善組織的募款管理軟件，它可以用以下簡明扼要的文字闡明開發(fā)目的吼过。

幫助慈善組織管理好募款過程锐秦，捐款人資料和援助項目的預(yù)算和實際開支信息，從而為該慈善機構(gòu)提高核心工作流程的準(zhǔn)確度和效率盗忱，增加用款信息的透明度酱床，提高捐款人的滿意度和忠誠度。

2）服務(wù)受眾

在這個章節(jié)趟佃，產(chǎn)品設(shè)計者要列出產(chǎn)品所服務(wù)的多層次角色扇谣。他們是誰，各自有什么樣的工作目標(biāo)闲昭，這個產(chǎn)品將幫助到他們解決哪些問題罐寨。在列舉服務(wù)受眾的角色時，要窮舉所有的可能序矩，而且不能含糊交叉衩茸，不要用“管理人員”、“普通用戶”這樣的概括性角色名稱贮泞。

繼續(xù)上面慈善行業(yè)軟件的例子，這個產(chǎn)品可能要服務(wù)的對象有：

公關(guān)市場經(jīng)理：使用捐款人管理模塊管理捐款人信息幔烛，定向和按照自動規(guī)則發(fā)送營銷Email啃擦。

募資項目經(jīng)理：通過捐款人和募款管理模塊記錄募款記錄，發(fā)放收款憑證饿悬。

慈善項目經(jīng)理：通過善款項目管理模塊令蛉，管理支出，生成項目財務(wù)報表狡恬。

財務(wù)經(jīng)理：復(fù)核和經(jīng)辦善款支出珠叔，記錄和核對募款記錄，建立相關(guān)財務(wù)憑證弟劲。

負(fù)責(zé)人：通過統(tǒng)計模塊了解善款使用分布祷安、捐款人分布和行為分析，完成項目開支審批兔乞。

管理員：配置產(chǎn)品使用必要的參數(shù)汇鞭，創(chuàng)建用戶凉唐，分配權(quán)限。通常由負(fù)責(zé)人兼任霍骄。

通過服務(wù)對象的羅列台囱，可以幫助我們繼續(xù)樹立產(chǎn)品需求，遍歷可能的用戶故事读整，設(shè)計必要的產(chǎn)品特性簿训。同時，也對整個產(chǎn)品的開發(fā)規(guī)模有更加精確的預(yù)計米间。

3）命名約定

命名是所有的產(chǎn)品技術(shù)文檔的核心强品，它的質(zhì)量甚至?xí)绊懙介_發(fā)編碼的環(huán)節(jié)。缺少命名約定的文檔無論是書寫還是閱讀都會很困難车伞。在PRD中择懂，要對涉及的主要數(shù)據(jù)對象、參數(shù)另玖、概念困曙、功能和用戶動作進行規(guī)范命名和釋義。這個命名一旦確定后谦去，就需要連貫使用慷丽，在PRD文檔全文、后期拓展的原型設(shè)計鳄哭、研發(fā)溝通過程和未來的用戶幫助文檔撰寫中統(tǒng)一使用要糊，不能隨意變更。

在企業(yè)軟件中妆丘，用戶引導(dǎo)和教育是一個非常艱巨的過程锄俄，而命名是維系和加強這個過程的重要基礎(chǔ)，否則在未來寫用戶幫助文檔的時候就會混亂不堪勺拣。

當(dāng)然奶赠，PRD的命名不需要面面俱到，只要針對應(yīng)用中獨特的對象進行命名約定即可药有。對于通用領(lǐng)域的一般概念，我們只需要在設(shè)計范式中約定即可愤惰。比如“募款”是產(chǎn)品PRD需要定義的功能模塊苇经，但是“刪除”、“導(dǎo)出”這些概念是不需要在命名約定中出現(xiàn)的宦言。

4）用戶故事

用戶故事扇单，也可以稱為“用戶場景描述”，是產(chǎn)品PRD在進入功能需求描述之前奠旺，用非產(chǎn)品視角來表達(dá)用戶需求的一種方法令花。它完全站在用戶的角度阻桅，描述他們將來使用這個產(chǎn)品來完成一項重要工作的全過程。如果有必要兼都，也可以對比說明不使用這個軟件產(chǎn)品的對應(yīng)解決方案嫂沉，從而讓產(chǎn)品設(shè)計者對這個軟件產(chǎn)品將要解決的問題有更加清晰的描述。

用戶故事也不需要覆蓋所有的用戶場景扮碧，只需要選擇那些比較核心的用戶問題趟章，尤其是那些占用戶80%時間的20%用戶場景。

我們繼續(xù)舉一個募款管理軟件的用戶故事：

用戶故事：募款項目經(jīng)理錄入一個批次的捐款信息

募款項目經(jīng)理通過和公關(guān)市場部的協(xié)作獲得了數(shù)百位捐款人通過公眾號微信支付的5萬元善款慎王。微信支付后臺導(dǎo)出了所有捐款人的訂單和付款信息蚓土。捐款人的個人資料和聯(lián)系方法已經(jīng)合并到了一個Excel文件，每個獨立的捐款記錄一行赖淤，其中已經(jīng)標(biāo)記了付款完成狀況蜀漆。

現(xiàn)在募款項目經(jīng)理需要通過軟件直接導(dǎo)入這些捐款記錄。通過募款管理的導(dǎo)入募款記錄功能咱旱，他直接上傳Excel文件确丢，系統(tǒng)會提示創(chuàng)建一個募款項目批次，上傳完成后顯示有多少條符合條件的記錄吐限，Review一致后鲜侥，所有的捐款記錄都被導(dǎo)入，新的捐款人（根據(jù)身份證號字段識別）被創(chuàng)建為新的捐款人記錄诸典。在導(dǎo)入的捐款記錄中描函，已經(jīng)被標(biāo)記上對應(yīng)的募款項目ID。導(dǎo)入完成后狐粱，系統(tǒng)提示總計成功導(dǎo)入條數(shù)舀寓、創(chuàng)建捐款人記錄數(shù)和捐款總金額。通過和原始數(shù)據(jù)的對比肌蜻，募款項目經(jīng)理確認(rèn)完成了導(dǎo)入工作互墓。

通過這個例子，我們會發(fā)現(xiàn)用戶故事的描述和產(chǎn)品功能描述有類似的地方宋欺，但著眼于不同的角度和細(xì)節(jié)。好用的功能特性設(shè)計來源其實就是這些用戶故事場景的還原胰伍。很多PRD容易忽略用戶故事的描述齿诞，而直接進入了功能特性的設(shè)計描述，就容易產(chǎn)生用戶體驗的重大斷層骂租。比如上例中祷杈，為什么要創(chuàng)建募款項目批次，在批次下導(dǎo)入具體的捐款數(shù)據(jù)渗饮，這個和用戶在實際工作中的場景是密不可分的但汞。如果設(shè)計者把這個功能設(shè)計為在線輸入單條的捐款記錄宿刮，或者無批次地直接導(dǎo)入多行的捐款記錄，就會讓未來用戶陷入使用的痛苦之中私蕾。

撰寫出的用戶故事本身看起來并不復(fù)雜僵缺，相反，它可能是整個PRD文檔部分最富有人性的部分踩叭。如果拿著PRD文檔給普通用戶閱讀磕潮，這可能是他們最喜歡閱讀，也最容易理解的部分容贝。但是自脯，用戶故事的撰寫并不依賴好文筆，它來自細(xì)致入微的用戶觀察和調(diào)研斤富。在上例中膏潮，如果不和多位慈善機構(gòu)的募款項目經(jīng)理交談，是不可能了解他們工作中的準(zhǔn)確痛點的满力。而且焕参，在實踐中，大多數(shù)企業(yè)用戶在主動描述自己需求的時候脚囊，并不會很完整龟糕，有些對他們未來使用很關(guān)鍵的細(xì)節(jié)特性，他們自己卻在需求表達(dá)時容易忽略悔耘。

有些產(chǎn)品設(shè)計者非常信賴自己的直覺讲岁，尤其是那些有消費者應(yīng)用設(shè)計經(jīng)驗的人。他們力圖跳過繁復(fù)冗長的用戶調(diào)研衬以，直接進入設(shè)計階段缓艳，但是在企業(yè)軟件世界，這是絕對不可能允許發(fā)生的看峻。如果你不調(diào)研醫(yī)院員工和管理層的工作阶淘，絕無可能設(shè)計出醫(yī)療服務(wù)管理應(yīng)用；如果你不去拜訪工程項目經(jīng)理互妓，也絕對不可能設(shè)計出工程項目管理軟件溪窒。直覺在企業(yè)應(yīng)用需求管理中的價值要遠(yuǎn)比在其他領(lǐng)域低。

5）特性組合

特性組合是PRD文檔中的主體內(nèi)容冯勉。在陳述清楚了開發(fā)目的澈蚌、服務(wù)受眾，建立了命名約定灼狰，描述了用戶核心需求場景后宛瞄，我們需要通過特性組合完整詳盡地列出產(chǎn)品開發(fā)需求。

在撰寫此部分之前交胚，需要再次明確份汗，產(chǎn)品需求的文檔的主要讀者是軟件開發(fā)人員盈电，因此，一定要牢記通過特性組合陳述需求杯活，而不是給出解決方案匆帚。過于簡單的特性描述沒有完整傳遞需求，但是過度詳細(xì)的特性描述也會容易制約開發(fā)者解決問題的靈活性轩猩。

用特性地圖（Feature Map）開始

為了有序地講述一個復(fù)雜企業(yè)產(chǎn)品的需求卷扮，首先需要通過一個綱要或者視覺列出所有特性的邏輯結(jié)構(gòu)。表格和腦圖都是很好的表達(dá)工具均践，它從整體上先勾勒出特性組合的全局分布晤锹。這和我們之前講到的產(chǎn)品需求三層次是同一個道理。越是復(fù)雜的事物彤委，越需要從簡單的大局開始鞭铆。

結(jié)合上文提到的慈善項目管理軟件的例子，下圖給出了這個應(yīng)用一個簡化的特性組合視覺表達(dá)焦影。通過腦圖來繪制這樣的圖形會很有條理车遂。腦圖還能夠表達(dá)出用戶在一個產(chǎn)品上的基本使用路徑、功能特性之間的聯(lián)系斯辰。

如果開發(fā)的是一個Web應(yīng)用舶担，這個特性地圖基本就等同于未來的站點地圖（sitemap）了。設(shè)計特性地圖并沒有絕對的格式要求彬呻，只要能夠表達(dá)清楚各個功能特性之間的邏輯包含關(guān)系即可衣陶，然后將其作為特性組合部分的指導(dǎo)目錄。開發(fā)人員將會很樂意將這個地圖打印出來貼在案頭闸氮，在產(chǎn)品開發(fā)的整個周期內(nèi)頻繁使用它剪况，無論是后端還是前端開發(fā)者都需要這么一個序列來評估開發(fā)工作的工時和進度，如果能夠?qū)⑦@個地圖條目編上1蒲跨，2译断，2.1，2.2這樣的數(shù)字編號或悲，溝通的有序性會進一步提高孙咪。

頁面要素?（Page Component）

因為現(xiàn)在的絕大多數(shù)企業(yè)應(yīng)用都是基于Web的了，即使是移動應(yīng)用巡语，也可以被稱為頁面或者屏幕翎蹈，所以我們可以用“頁面要素”來指軟件界面中的組成部分。

在特性組合部分捌臊，頁面要素是核心內(nèi)容杨蛋。它的性質(zhì)可以用兩句話來概括：

1）用戶在頁面上能看到什么兜材？

2）用戶在頁面上能夠做什么理澎？

簡化的頁面要素表達(dá)可以用章節(jié)結(jié)構(gòu)逞力，把前面列出的特性地圖中的頁面詳細(xì)展開說明。例如例子中的募款管理頁面糠爬，需要包括以下內(nèi)容：

現(xiàn)有募款項目列表寇荧，可以點擊進入募款項目詳情列出項目名稱，開始日期执隧，負(fù)責(zé)人揩抡，累計募款額，完成比例镀琉，狀態(tài)

關(guān)鍵詞搜索募款項目

按照組合條件篩選募款項目

募款項目統(tǒng)計的儀表板列出當(dāng)前募款項目數(shù)峦嗤，累計項目數(shù)，累計募款額屋摔，本月募款額點擊任何一個數(shù)值烁设，進入募款統(tǒng)計首頁

新建募款項目的按鈕

用戶使用流程?（User Flow）

對于復(fù)雜的軟件產(chǎn)品，僅僅依賴特性地圖和頁面要素可能還不夠钓试。不同的用戶角色可能有多樣的任務(wù)要完成装黑，如果只是羅列出有哪些頁面或者窗口依然不能說明清楚用戶的使用流程和期望。這時候弓熏，可以選擇加入“用戶使用流程”的專門章節(jié)恋谭，對于核心的用戶任務(wù)進行詳細(xì)說明。

用戶使用流程的表達(dá)有文本和圖形兩種方式挽鞠，設(shè)計者可以根據(jù)需要選擇疚颊。文本模式的用戶使用流程用用戶任務(wù)的名稱開始，然后用1滞谢，2串稀，3這樣順序的步驟說明用戶期望的交互路徑。

例如：

流程1: 創(chuàng)建募款項目

首頁點擊募款管理

點擊“創(chuàng)建”狮杨，進入新募款項目創(chuàng)建頁面

完成填寫后提交

添加募款項目成員母截，指定更多管理員

選擇或添加對應(yīng)的財務(wù)科目

提示是否需要導(dǎo)入募款記錄？

Yes- 進入募款記錄導(dǎo)入

No - 進入下一步

7. 提示項目創(chuàng)建成功

當(dāng)然橄教，文本的流程說明也很容易用對應(yīng)的流程圖來表達(dá)清寇。在這樣的用戶使用流程圖中，可以約定用矩形框表達(dá)對應(yīng)的頁面或者窗口名稱护蝶，這樣用戶使用流程的描述就能夠和前面的特性地圖华烟、頁面要素中的命名對應(yīng)起來。

在復(fù)雜的企業(yè)軟件中持灰，有時候完整的用戶使用流程是非常復(fù)雜和漫長的盔夜。這時候，就需要按照一定的階段將流程切分，分板塊來表達(dá)喂链，否則讀者將很難使用返十。下圖的用戶使用流程來自一個復(fù)雜的企業(yè)工作流軟件，如此復(fù)雜的表達(dá)也僅僅呈現(xiàn)了整個使用路徑的一個局部椭微。

原型設(shè)計（Prototype）

我們終于進入了原型設(shè)計部分洞坑，這是構(gòu)成特性組合板塊的最后一部分。對于很多產(chǎn)品設(shè)計人員來說蝇率，這部分是特別熟悉的迟杂。不少軟件產(chǎn)品設(shè)計者終日都在Adobe的設(shè)計工具上，產(chǎn)出的大多數(shù)是原型設(shè)計圖稿本慕。但是排拷，我們在進入原型設(shè)計之前，居然花費這么多筆墨在視覺之外的內(nèi)容上锅尘。

為什么企業(yè)應(yīng)用不能直接從視覺化的原型設(shè)計開始呢攻泼？和消費者應(yīng)用相比，企業(yè)應(yīng)用很難依靠單純的視覺原型來說明清楚軟件開發(fā)需求鉴象，因為交互與視覺原型很難說明清楚背后的邏輯忙菠，因為不同的數(shù)據(jù)狀態(tài)要進行的容錯處理也要比個人應(yīng)用復(fù)雜得多。更重要的是纺弊，企業(yè)應(yīng)用質(zhì)量的核心的確在于它的可靠性和精確性牛欢。界面的美觀和易用當(dāng)然是我們追求的重要目標(biāo)，但它如果離開了可靠和精確后淆游，一文不值傍睹，因為它無法幫助用戶完成任務(wù)。

雖然我們不能僅僅依賴視覺原型來說明清楚需求犹菱，但是如果有直觀的原型設(shè)計拾稳，的確能夠幫助說明過程。有了它腊脱，也能夠幫助節(jié)省PRD的文字篇幅访得，開發(fā)團隊可以更加精準(zhǔn)地理解設(shè)計意圖。

在這個行業(yè)中陕凹，產(chǎn)品架構(gòu)師悍抑、界面設(shè)計師和交互設(shè)計師都可能需要進行原型繪制。而且杜耙，就連客戶和老板都會喜歡用原型來表達(dá)或確認(rèn)需求搜骡，但他們提供視覺設(shè)計的完成度是完全不同的。在分工完整的團隊中佑女，完整的原型和交互設(shè)計最好由專業(yè)的交互設(shè)計師來主導(dǎo)记靡。在產(chǎn)品需求的邏輯面完整以后谈竿，專業(yè)的視覺設(shè)計師可以保證交互界面的勻稱、一致和加入情感元素摸吠。

現(xiàn)在榕订，因為交互設(shè)計的范式庫建設(shè)（我們在后面的章節(jié)會專門介紹設(shè)計范式），交互設(shè)計工具的發(fā)展蜕便，更多的設(shè)計成員都可以更容易地提供高保真的設(shè)計原型。高保真原型不僅能夠用像素級標(biāo)準(zhǔn)來固化需求贩幻，還能夠提供用戶操作的模擬反饋轿腺，甚至包括動效。但是丛楚，對絕大多數(shù)的企業(yè)應(yīng)用來說族壳，高保真原型的主要價值并非去提供一個嚴(yán)絲密縫的需求規(guī)范，而是給客戶方提供一個可以預(yù)見和感知的效果趣些。過于強調(diào)高保真的實現(xiàn)會限制開發(fā)者靈活運用解決方案仿荆，做出合理取舍的可能。從團隊協(xié)作產(chǎn)出最大化的角度而言坏平，框線圖和高保真圖都是可以接受的原型繪制方案拢操。

有些團隊還發(fā)展出把用戶使用流程和原型圖結(jié)合在一起的模式。通過原型中的UI元素之間的連接線或者索引編號舶替，把用戶使用產(chǎn)品的流程直接疊加在原型圖上令境。只要團隊能夠溝通和磨合好，也不失為一種提高協(xié)作成效的方式顾瞪。如下圖就是一個完成度比較高的視覺和文字結(jié)合的原型圖舔庶。

從特性地圖、界面要素陈醒、用戶使用流程到最終的原型圖惕橙，包括它們之間的組合使用方式都是為了清晰完整地表達(dá)一個軟件實現(xiàn)的具體需求。一個企業(yè)應(yīng)用到底要用怎樣的表達(dá)方式組合則完全取決于項目內(nèi)在的需要钉跷。一般而言弥鹦，復(fù)雜和高風(fēng)險的產(chǎn)品會要求更加完整的表達(dá)，產(chǎn)品和開發(fā)協(xié)作困難（比如是兩個企業(yè)之間）的也會要求高完成度的需求描述爷辙。反之惶凝，如果是比較小型的產(chǎn)品，非敏感和關(guān)鍵的系統(tǒng)犬钢，協(xié)作配合度很高的團隊則可以有選擇地使用這些表達(dá)工具苍鲜，不必面面俱到。

但不管產(chǎn)品文檔有多完整玷犹，產(chǎn)品設(shè)計者永遠(yuǎn)需要和開發(fā)者與客戶之間建立高頻度的面對面溝通混滔。需求溝通得越完整洒疚，越準(zhǔn)確，產(chǎn)品實現(xiàn)的質(zhì)量就越高坯屿，這一點是毋庸置疑的油湖。

接下來PRD還有兩個可選的模塊，可以幫助進一步說明應(yīng)用開發(fā)需求领跛，它們都是為了更清楚地說明我們要把產(chǎn)品做得有多好乏德。

6）競爭標(biāo)桿

顧名思義臣咖，競爭標(biāo)桿部分需要列出應(yīng)用所對標(biāo)的產(chǎn)品哑子，指明它們可參照的產(chǎn)品特性和實現(xiàn)標(biāo)準(zhǔn)。對于產(chǎn)品型公司來說窃页，這一點至關(guān)重要矢棚，因為我們不僅希望設(shè)計一款需求明確的產(chǎn)品郑什，還希望設(shè)計能夠超越競爭對手的產(chǎn)品。

當(dāng)然蒲肋，每個企業(yè)都有自己的獨特優(yōu)勢蘑拯，所以競爭標(biāo)桿也不是列出一堆競爭對手的產(chǎn)品名字，而是要指出每個特性所對標(biāo)的產(chǎn)品兜粘。比如在“用戶管理”方面超越或達(dá)到A申窘，在“活動管理”方面超越或達(dá)到B。競爭標(biāo)桿的樹立也可以幫助我們在需求說明當(dāng)中減少篇幅孔轴，因為有的時候偶洋，競品的存在事實上提供了可參照的原型。

但是距糖，在每個特性上都建立一個標(biāo)桿在商業(yè)上未必合理玄窝。任何一個軟件產(chǎn)品，首先都還是要有自己的獨特性悍引，在某些優(yōu)勢特性上出類拔萃恩脂。而對一般特性、支持性模塊或者難以差異化的部分趣斤，通過其他優(yōu)秀產(chǎn)品的定標(biāo)是完全應(yīng)該的俩块。尤其是企業(yè)應(yīng)用產(chǎn)品如果能夠選擇好某個消費者應(yīng)用產(chǎn)品的優(yōu)異體驗作為標(biāo)桿，對于提高用戶交互體驗度是很有幫助的浓领。

7）發(fā)布標(biāo)準(zhǔn)和時間要求

在實踐中玉凯，設(shè)計階段很有可能對應(yīng)用產(chǎn)品的最小交付標(biāo)準(zhǔn)還無法確定。同時联贩，為了方便開發(fā)人員規(guī)劃完整的架構(gòu)漫仆，需求說明可能會包含需要漸進實現(xiàn)的特性列表。所以泪幌，在PRD的最后或者使用獨立的文檔來規(guī)范應(yīng)用發(fā)布時的最小化要求盲厌。如果規(guī)劃多個版本連續(xù)發(fā)布署照，也可以配套上對應(yīng)的時間要求。

經(jīng)常有團隊對一個產(chǎn)品的最小化交付標(biāo)準(zhǔn)爭執(zhí)不下吗浩。有時候是需求方認(rèn)為最小化標(biāo)準(zhǔn)過于簡單建芙，需要增加功能特性，有時候是設(shè)計方認(rèn)為我們不應(yīng)該在第一個版本塞進這么多功能懂扼。這種爭執(zhí)可能是企業(yè)應(yīng)用設(shè)計過程中最廣泛存在的團隊分歧禁荸。

這些爭執(zhí)似乎很難有一個客觀的標(biāo)準(zhǔn)，但是出現(xiàn)這些爭執(zhí)的主要原因來自于團隊對本章開頭部分所要求明晰的產(chǎn)品目標(biāo)未能達(dá)成足夠的共識阀湿。我們可以再回顧一下赶熟。在動手寫作PRD之前，團隊需要厘清：

1）明確了產(chǎn)品設(shè)計的目標(biāo)是為了解決哪些用戶的哪些問題炕倘，它對企業(yè)的商業(yè)目的實現(xiàn)起到了什么作用？（要做什么）

2）開發(fā)項目的投入資源怎樣翰撑？可以有多少產(chǎn)品研發(fā)人員罩旋？給出了多長的時間窗口？（能有多少資源）

3）我們要交付的最小化產(chǎn)品要達(dá)到什么標(biāo)準(zhǔn)眶诈？是否有對標(biāo)的競爭對手或者其他產(chǎn)品可以幫助衡量涨醋？（要做到怎么樣）

理想的工作方式要求我們在項目定義的時候就盡力達(dá)成一致，而不是在開發(fā)的晚期再去爭執(zhí)這些問題逝撬。項目未展開之前浴骂，團隊成員和管理層尚能保持清醒的頭腦來溝通和決策這些目標(biāo)和交付標(biāo)準(zhǔn)。一旦項目展開宪潮，需求開始被成更加具體的表達(dá)溯警，就會有增加和變更需求的沖動。公說公有理狡相，婆說婆有理的事情就多了梯轻。這就是為什么我們要早起確定和文檔化以上三點的原因【∽兀控制項目邊界的任務(wù)在很多情況下是落在產(chǎn)品設(shè)計人員身上的喳挑。

任何的交付標(biāo)準(zhǔn)都和配套的資源相關(guān)，對于軟件開發(fā)來說滔悉，資源就是指人力和時間伊诵。所以，設(shè)計人員需要對開發(fā)團隊的人力分布和資源情況有清晰的認(rèn)知才能控制一個項目的邊界回官。

也有人認(rèn)為軟件產(chǎn)品就是應(yīng)該敏捷迭代曹宴，不要拘泥于項目定義。這個觀點混淆了新產(chǎn)品研發(fā)項目和產(chǎn)品長期改進的差別歉提。對于任何一個企業(yè)浙炼，一個IT系統(tǒng)能否投入銷售或使用份氧，直接影響到它對業(yè)務(wù)產(chǎn)出的影響，需要配合的營銷和銷售投入弯屈，運營系統(tǒng)的建立等協(xié)同事務(wù)蜗帜，它初次交付的標(biāo)準(zhǔn)和時間要求是沒有太多寬容度的。但是资厉，應(yīng)用上線以后厅缺，基于初始版本和事實的使用反饋，不斷迭代改進則是完全另外一個邏輯宴偿，所謂的SCRUM敏捷開發(fā)模式主要指的是后者湘捎，而不是一個新軟件產(chǎn)品的初始打造過程。

3.4 有關(guān)產(chǎn)品需求設(shè)定的檢查清單

我們花了不少篇幅來專門講“需求”窄刘，它是制約一個企業(yè)應(yīng)用開發(fā)和交付質(zhì)量的源頭窥妇。大多數(shù)失敗的軟件開發(fā)都可以溯源到需求分析和表達(dá)階段的重要瑕疵。因此娩践，作為本章的小結(jié)活翩，我提供了一個9點的檢查清單，幫助設(shè)計者在最終評定需求階段工作質(zhì)量的一個工具翻伺。

明確的目標(biāo)服務(wù)的受眾是誰材泄？

明確了要解決他們的哪些問題？

明確了應(yīng)用給用戶企業(yè)的成本和收益帶來的影響吨岭？

明確了可以投入在應(yīng)用開發(fā)上的人手拉宗？

明確了初次版本要交付的時間？

提供了導(dǎo)航性質(zhì)的特性地圖辣辫？

提供了關(guān)鍵用戶流程的描述旦事？

特性地圖上的每個特性提供了頁面列表、元素列表和視覺原型急灭，并方便開發(fā)者找到族檬？

項目資源滿足最小化的發(fā)布標(biāo)準(zhǔn)和時間要求？