今天仍然是3.3節(jié)聂抢、“關(guān)鍵的青春期，又見需求”辩尊，主要講的是需求開發(fā)涛浙，俗稱寫文檔。上一篇辨析了各種文檔的區(qū)別和聯(lián)系摄欲，下面作者就PRD進(jìn)行了詳細(xì)的說明轿亮，內(nèi)容還是蠻多的，我看了兩遍才慢慢有感覺了~
產(chǎn)品需求文檔胸墙，PRD
通常一個(gè)項(xiàng)目會(huì)有一到多份PRD我注，每一個(gè)PRD會(huì)包含邏輯相關(guān)的若干功能點(diǎn)，這些相關(guān)的需求在“需求打包”的環(huán)節(jié)已經(jīng)被識(shí)別出來迟隅，也就是產(chǎn)品需求列表里的若干行但骨。PRD的結(jié)構(gòu)如下圖：
總體說明
（1）修訂歷史：寫清楚每次修訂的日期、版本號(hào)智袭、說明和作者奔缠，便于以后追溯。
（2）項(xiàng)目概述：簡單描述項(xiàng)目的背景吼野、意義校哎、目的、目標(biāo)等瞳步，描述業(yè)務(wù)領(lǐng)域知識(shí)闷哆，讓讀者明白項(xiàng)目是為什么而做，這部分內(nèi)容可以參考Kick Off會(huì)議所用PPT里面的內(nèi)容单起。如果此PRD沒有包含項(xiàng)目全部需求的話抱怔，也應(yīng)做相應(yīng)說明這部分需求是什么，其他需求在哪里等嘀倒。
（3）功能范圍：給出業(yè)務(wù)邏輯圖屈留，重點(diǎn)描述系統(tǒng)中角色的職責(zé)、與周邊系統(tǒng)的關(guān)系测蘑、全局的商業(yè)規(guī)則等绕沈。
（4）用戶范圍：對(duì)本PRD涉及的角色、系統(tǒng)做出簡單的說明帮寻。
（5）詞匯表：對(duì)本PRD涉及的專有詞匯乍狐、術(shù)語、縮寫等做出說明固逗。
（6）非功能需求：如性能需求浅蚪、數(shù)據(jù)監(jiān)控的需求等。
（7）其他說明：其他任何需要說明的內(nèi)容都可以寫在這里烫罩。
用例文檔部分
（1）整體說明：首先需要對(duì)這個(gè)PRD中所有的用例來個(gè)說明惜傲，給出用例的可視化表示，說明各個(gè)用例之間的關(guān)系贝攒，一般有類圖盗誊、用例圖、狀態(tài)圖幾種表示方法（下面一部分會(huì)詳述），其中用例圖最為關(guān)鍵哈踱，下節(jié)里即將給出幾個(gè)例子說明荒适。
（2）接下來是用例的正文，由一個(gè)個(gè)的用例組成开镣，這部分也就是我們常說的——用例文檔刀诬。
（3）最后一部分“對(duì)單個(gè)UC的說明”是一些注釋，常用的PRD模板里有如下內(nèi)容：
? ? 注1：視覺層面的描述通常直接通過Demo表達(dá)（如頁面大小邪财、顏色陕壹、字體、字號(hào)等）树埠；
? ? 注2：界面細(xì)節(jié)糠馆，引用界面規(guī)范文檔（如表格中的文字對(duì)齊方式等）；
? ? 注3：交互細(xì)節(jié)怎憋，引用交互規(guī)范文檔（如出錯(cuò)提示的方式等）又碌；
? ? 注4：文案細(xì)節(jié)，引用文案規(guī)范文檔（如各種提示文案等）盛霎。
接下來赠橙，作者詳細(xì)介紹了用例文檔部分，這部分大家比較陌生而且前面也沒有提及愤炸。
學(xué)一點(diǎn)UML：類圖期揪、用例圖、狀態(tài)圖
先解釋下UML：統(tǒng)一建模語言规个，unified modeling language凤薛，它試圖將軟件工程的過程規(guī)范化。
公司一般會(huì)經(jīng)歷“人治→法治→德治”的三個(gè)階段：人治是“由外而內(nèi)”的被治诞仓，靠的是領(lǐng)袖魅力缤苫，更適合小公司；法治靠的是“硬法律 + 軟倫理 + 執(zhí)行者的以身作則”墅拭；而德治是“由內(nèi)而外”的自治活玲，靠的是企業(yè)文化，更適合大公司谍婉。很多小公司停留在第一階段舒憾，很多大公司停留在第二階段，只有少數(shù)公司才可能進(jìn)入第三階段穗熬。第三階段和第一階段表面上很像镀迂，但區(qū)別在于第一階段根本無法，而第三階段的法在每個(gè)人的心中而非紙上唤蔗。
這也是產(chǎn)品和團(tuán)隊(duì)發(fā)展的必經(jīng)階段探遵。一開始我們非常推崇個(gè)人英雄主義窟赏，或者在老板的帶領(lǐng)下，或者自己帶領(lǐng)幾個(gè)菜鳥箱季，沒有章法地怎么快怎么做涯穷。慢慢地，產(chǎn)品越來越復(fù)雜规哪，團(tuán)隊(duì)的新人也越來越多求豫，于是我們開始在文檔上做起了規(guī)范化的事情塌衰，從第一階段走向第二階段诉稍。在這個(gè)過程中，大家開始學(xué)起了UML最疆，從產(chǎn)品設(shè)計(jì)的角度杯巨，作者把它對(duì)PD的價(jià)值簡單理解成，提供了一系列的標(biāo)準(zhǔn)圖形化的表達(dá)方式努酸，把需求開發(fā)的過程串起來服爷，充分體現(xiàn)了“字不如表，表不如圖”的原則获诈。
類圖：Class Diagram
描述系統(tǒng)中出現(xiàn)的各個(gè)對(duì)象之間的關(guān)系仍源，以及和外部系統(tǒng)的關(guān)系，這是對(duì)業(yè)務(wù)領(lǐng)域的描述舔涎，一個(gè)外行看了以后就應(yīng)該了解此系統(tǒng)是做哪方面事情的笼踩。
用例圖：Use Case Diagram
描述各個(gè)用例之間的關(guān)系，比如“include”或“extend”亡嫌，用例包（將一組相關(guān)用例打包而成的模塊）嚎于、用例和行為者（Actor）之間的關(guān)系。
狀態(tài)圖：State Diagram
表達(dá)系統(tǒng)里實(shí)體的狀態(tài)轉(zhuǎn)換挟冠，同樣也是貫穿多個(gè)用例的于购。
上述幾種圖也可以看作是由整個(gè)產(chǎn)品最頂級(jí)的業(yè)務(wù)邏輯圖細(xì)化而來，而對(duì)于商業(yè)演示場(chǎng)景所用的業(yè)務(wù)邏輯圖的畫法知染，團(tuán)隊(duì)內(nèi)沒有統(tǒng)一的意見肋僧，但一定要簡潔清楚，因?yàn)槭鼙姸际谴罄习蹇氐麄儧]那么多時(shí)間看細(xì)節(jié)嫌吠，所以這也意味著業(yè)務(wù)邏輯圖最難畫。
用例文檔逸寓，UC
用例整體說明部分結(jié)束居兆，就要進(jìn)入單個(gè)UC的寫作了。UC是需求人員寫給開發(fā)人員看的一種最基本的文檔竹伸，查了一下資料泥栖，早期的需求人員是通過對(duì)應(yīng)用場(chǎng)景（Scenario）的分析來細(xì)化需求的簇宽，20世紀(jì)初，一些牛人們才將這種方法正式歸納為用例法吧享。之后在互聯(lián)網(wǎng)和軟件行業(yè)魏割，又繼續(xù)發(fā)展，逐步形成了今天的用例文檔钢颂，或者說“任務(wù)分解”等描述需求的方法钞它。理想狀態(tài)下，一個(gè)UC代表了產(chǎn)品需求列表里的一行殊鞭，但實(shí)際上并不絕對(duì)遭垛，也可能多個(gè)UC滿足一個(gè)產(chǎn)品需求，或者一個(gè)UC涉及多個(gè)產(chǎn)品需求操灿。
UC里要寫哪些內(nèi)容
首先是UC概述：
（1）用例的唯一標(biāo)識(shí)：這項(xiàng)經(jīng)常偷懶不寫锯仪，關(guān)系并不大；
（2）用例名稱：用一個(gè)短語講清楚這個(gè)UC是做什么的趾盐。一個(gè)UC寫一個(gè)任務(wù)庶喜，任務(wù)的粒度可以自行把握，比如同樣是“增加救鲤、刪除久窟、修改訂單”，在新人本缠、新業(yè)務(wù)的情況下斥扛，就最好分為三個(gè)用例詳細(xì)描述；如果是“老人”搓茬、老業(yè)務(wù)犹赖，也許用一個(gè)“管理訂單”的用例描述就足夠了。
（3）業(yè)務(wù)描述：商業(yè)目標(biāo)卷仑、用戶目的等業(yè)務(wù)內(nèi)容峻村，說明為什么要做這個(gè)UC？
（4）需求描述：產(chǎn)品需求锡凝，需要實(shí)現(xiàn)哪些功能點(diǎn)粘昨，這個(gè)UC要做什么？
（5）行為者：該用例的Actor窜锯；
（6）前置條件：觸發(fā)這個(gè)用例的前提是什么张肾？
（7）后置條件：用例完成，后續(xù)動(dòng)作是什么锚扎？
（8）其他說明：任何其他信息吞瞪，針對(duì)這個(gè)UC的特殊說明，沒有就空著驾孔。
然后是UC主體：
（1）界面描述：通成指眩互聯(lián)網(wǎng)惯疙、軟件產(chǎn)品中界面描述會(huì)占很大的篇幅，給出截圖妖啥，界面上各種元素的說明霉颠，并且會(huì)和Demo關(guān)聯(lián)起來，當(dāng)然還有一種做法是單獨(dú)寫界面文檔荆虱，然后與UC文檔互相引用蒿偎。
（2）業(yè)務(wù)規(guī)則：整個(gè)用例的通用規(guī)則，比如限制條件怀读、诉位。而界面元素或流程中的私有規(guī)則則不適合寫在這里；
（3）流程描述：分主干愿吹、分支和異常三種不从，描述在這個(gè)用例發(fā)生的過程中惜姐，由什么事件觸發(fā)犁跪，系統(tǒng)與用戶之間產(chǎn)生何種交互步驟，這里盡量用時(shí)序圖和活動(dòng)圖來替代文字描述歹袁，具體的例子下一節(jié)給出坷衍。
現(xiàn)實(shí)中的UC會(huì)做得比較美觀，這也是為了防止大家看久了白底黑字太無聊条舔。從下表可以看到對(duì)于界面描述枫耳、業(yè)務(wù)規(guī)則、流程描述的寫作孟抗，我們都有一些模板式的總結(jié)迁杨，這些都是特定的產(chǎn)品、特定的團(tuán)隊(duì)通過不斷優(yōu)化得到的結(jié)果凄硼，并且會(huì)繼續(xù)優(yōu)化下去铅协。經(jīng)常有網(wǎng)友問作者要文檔模板，但作者認(rèn)為其用的非常個(gè)性化摊沉，拿過去直接用會(huì)有很多的地方不適合狐史，甚至產(chǎn)生負(fù)作用，所以建議大家按照本節(jié)講述的內(nèi)容做一個(gè)最簡單的模板说墨，把現(xiàn)在你覺得沒用的內(nèi)容都刪掉骏全。然后在實(shí)踐中慢慢優(yōu)化，切身體會(huì)到缺什么了時(shí)再添加內(nèi)容尼斧。
UC一般只用來描述功能需求姜贡，它不便于描述諸如產(chǎn)品擴(kuò)展性、系統(tǒng)容量棺棵、人員培訓(xùn)等非功能需求楼咳，所以我們把非功能需求部分寫在PRD的總體說明里潘悼。
【注】：UC里對(duì)語言的要求比較高，需要做到：無歧義爬橡、完整治唤、一致、可測(cè)試等糙申，相信為此吃過苦頭的同學(xué)都有體會(huì)宾添，舉幾個(gè)簡單的例子。
無歧義：比如“小明和兩個(gè)部門的同事一起去餐館”柜裸，就不知道“兩個(gè)”是形容“部門”還是“同事”缕陕。
完整：比如“小明預(yù)算不超過100 元”，其實(shí)是不完整的疙挺，應(yīng)該是“小明的人均預(yù)算不超過100元”扛邑，如果他和大毛一起來，則預(yù)算是200元铐然。
一致：比如“小明非工作日去餐館吃飯”與“小明周末去餐館吃飯”就不一致蔬崩，國慶節(jié)、春節(jié)怎么算搀暑？
可測(cè)試：比如“點(diǎn)菜時(shí)要考慮到金額限制”沥阳，就沒有辦法驗(yàn)證，應(yīng)該說“如果金額大于100元自点，則需要修改點(diǎn)菜單”桐罕。
再學(xué)一點(diǎn)UML：時(shí)序圖、活動(dòng)圖及其他
剛才提到了UC里的流程描述桂敛，我們?cè)賹W(xué)幾種UML的圖功炮，它們描述的是用例的內(nèi)部事務(wù)。當(dāng)然术唬，用例內(nèi)部不一定是“單個(gè)用例”內(nèi)部薪伏，也可能有用例之間的關(guān)系。這些圖在描述業(yè)務(wù)規(guī)則和流程的時(shí)候非常有用碴开。
時(shí)序圖：Sequence Diagram
也叫順序圖毅该，描述事物變化在時(shí)間維度上的先后順序，善于表達(dá)對(duì)象的交互潦牛，比如多個(gè)頁面之間眶掌、多個(gè)角色之間。
活動(dòng)圖：Activity Diagram
比較接近我們常說的流程圖巴碗，描述各種動(dòng)作如何引起系統(tǒng)變化朴爬，善于表達(dá)泳道較多、分支較多的情況橡淆。
協(xié)作圖：Collaboration Diagram
表達(dá)不同對(duì)象之間是如何互相影響的召噩。這幅圖在日常的項(xiàng)目中用得不多母赵。理論上它和時(shí)序圖是可以等價(jià)轉(zhuǎn)換的，只不過時(shí)序圖關(guān)注交互在時(shí)間上的步驟具滴，而協(xié)作圖關(guān)注交互過程中各個(gè)對(duì)象間的關(guān)系凹嘲。
很多時(shí)候多種圖都可以描述同一件事情，只是視角不同而已构韵，選用哪個(gè)關(guān)鍵是看針對(duì)特定的系統(tǒng)周蹭，從哪個(gè)角度來描述更容易讓受眾理解。另外還有表述軟件實(shí)施的構(gòu)件圖疲恢、描述硬件結(jié)構(gòu)的部署圖凶朗，這些圖更偏向技術(shù)一些，對(duì)PD的用處不大显拳。
【工具】：上述這些UML圖都是用Visio畫的棚愤。再次強(qiáng)調(diào)，工具是為人服務(wù)的杂数，如果團(tuán)隊(duì)里其他成員都看不懂UML圖宛畦，且學(xué)習(xí)成本太高，那一定不要強(qiáng)推UML耍休，尋找合適自己的工具吧刃永。描述需求的原則很簡單：把要做的事情跟受眾說清楚！
產(chǎn)品Demo
PRD寫完了羊精，工程師拿著它就可以開發(fā)了么？不是囚玫。還缺了很重要的一塊喧锦，產(chǎn)品Demo，也經(jīng)常被說成是產(chǎn)品原型抓督、演示版燃少。
【Demo與用例文檔的關(guān)系】
對(duì)于某個(gè)產(chǎn)品功能的用例是否包含界面的描述，每個(gè)團(tuán)隊(duì)有自己的做法铃在，好壞難以評(píng)估阵具，這取決于產(chǎn)品的特點(diǎn)、團(tuán)隊(duì)的習(xí)慣等定铜，我的建議是不妨再次應(yīng)用做產(chǎn)品的思路阳液，去問問這些文檔的用戶，即團(tuán)隊(duì)里的開發(fā)工程師揣炕、測(cè)試工程師帘皿，按照他們喜歡的方式寫就好了。但用例里最多只能放Demo的截圖畸陡，所以如果要表現(xiàn)更多交互和視覺的細(xì)節(jié)鹰溜，Demo是必須獨(dú)立存在的∷涮睿現(xiàn)在應(yīng)該有一些可以嵌入富媒體內(nèi)容的文檔方式，可以直接把Demo嵌入用例曹动，不過作者沒有嘗試過斋日，說周圍也尚未看到有人用。
【主導(dǎo)與參與】
作者認(rèn)為Demo最好是由用戶體驗(yàn)部門的同學(xué)主導(dǎo)墓陈，即使團(tuán)隊(duì)中可能并沒有這樣一個(gè)叫User Experience桑驱，簡稱UE的部門，那么做這個(gè)事情的人也許叫用戶體驗(yàn)師跛蛋、交互設(shè)計(jì)師熬的、視覺設(shè)計(jì)師，甚至是比較過時(shí)的稱呼——美工赊级。但產(chǎn)品經(jīng)理也必須參與Demo制作的過程押框。Demo的制作在產(chǎn)品會(huì)議之前就可以開始了，有可能的話在BRD中展示出來理逊，很可能成為爭(zhēng)取資源的加分因素橡伞。最關(guān)鍵是要保證Demo的設(shè)計(jì)師們充分理解商業(yè)目的和用戶目標(biāo)等，讓大家在方向正確的前提下再自由發(fā)揮晋被。
【Demo的發(fā)展過程】
Demo也會(huì)經(jīng)歷從低保真到高保真兑徘，從抽象到具體，從全局到細(xì)節(jié)的漸變過程羡洛。
一般來說挂脑，最開始會(huì)有一個(gè)紙面Demo，鉛筆加A4紙的組合欲侮，或者是馬克筆加白板再用手機(jī)拍個(gè)照崭闲，有了這樣的東西，大家就可以開始溝通了威蕉。其實(shí)這些線下的工具刁俭，紙、筆韧涨、白板牍戚，加上口頭交流，可以幫助我們進(jìn)入很高效的工作狀態(tài)虑粥。
接下來會(huì)有一個(gè)線框圖如孝，只關(guān)注界面框架而不考慮細(xì)節(jié)，使用的工具可以是Visio舀奶、PPT暑竟、Word，甚至Windows操作系統(tǒng)自帶的畫圖板。
進(jìn)一步但荤，我們要關(guān)注視覺效果罗岖，也許會(huì)用PhotoShop做幾張典型頁面的效果圖。然后腹躁，表達(dá)交互細(xì)節(jié)桑包，使用Axure、Dreamweaver制作頁面纺非，這頁面很可能就是將來產(chǎn)品里真實(shí)可用的網(wǎng)頁了哑了。
產(chǎn)品不同，用到的Demo工具會(huì)不同烧颖，或者各個(gè)階段也會(huì)不同弱左，但最重要的不是工具，而是內(nèi)心的想法炕淮。實(shí)際工作中拆火，PD肯定會(huì)對(duì)Demo給出一些自己的想法，甚至經(jīng)常自己做涂圆，越是低保真的Demo我們做得越多们镜。
團(tuán)隊(duì)分工的形成總有各種各樣的原因，凡事向好的方向看吧润歉，如果要我們做Demo模狭，那么就更加全面地鍛煉了能力，如果有UE的同事踩衩，我傾向于信任專業(yè)人員嚼鹉，只提建議而不做決定，讓專業(yè)的人做專業(yè)的事九妈，這樣產(chǎn)品才更完善反砌。
概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)
作者發(fā)現(xiàn)，在寫UC的時(shí)候萌朱，經(jīng)常寫著寫著就覺得是在越俎代庖地做概要設(shè)計(jì)，甚至是詳細(xì)設(shè)計(jì)的事情了策菜。比如晶疼，對(duì)于網(wǎng)頁上簡單的一個(gè)“公司名稱”字段，就有很多細(xì)節(jié)的設(shè)計(jì)使人糾結(jié)又憨，詢問工程師后也常常會(huì)得到相反的答案：有人希望你寫得越詳細(xì)越好翠霍，而有人希望你交給他決定。后來漸漸總結(jié)出兩種做法蠢莺。
第一寒匙，不以寫的東西是需求還是設(shè)計(jì)區(qū)分職責(zé)，而以“業(yè)務(wù)”或“技術(shù)”區(qū)分。比如上例锄弱，在業(yè)務(wù)上需要對(duì)“公司名稱”的長度做何限制由PD確定考蕾，而“公司名稱”的數(shù)據(jù)在數(shù)據(jù)庫里如何存儲(chǔ)，由工程師決定会宪。
第二肖卧，細(xì)枝末節(jié)的設(shè)計(jì)經(jīng)常重復(fù)，PD應(yīng)該和開發(fā)工程師一起協(xié)商掸鹅，漸漸沉淀出產(chǎn)品規(guī)范塞帐。比如上例，通過幾次協(xié)商巍沙，我們確定了以后產(chǎn)品中出現(xiàn)的各種字段的各種限制規(guī)范葵姥，下次再寫UC的時(shí)候，只要引用規(guī)范即可句携，省去了很多重復(fù)勞動(dòng)榔幸。
