| 文檔的撰寫與合格交付一直是困擾在許多產(chǎn)品經(jīng)理心中的一個難題。為了解決這個難題，筆者收集了開發(fā)、測試、設(shè)計人員多方意見，總結(jié)出這一份文檔交付原則。眾所周知，需求文檔的撰寫與交付是每位產(chǎn)品經(jīng)理工作中必備的技能，而在筆者寫下這套文檔交付原則之前，筆者所在的產(chǎn)品團隊正面臨著需求文檔混亂、格式不統(tǒng)一、不具備參考性等眾多問題。筆者在收集了多位開發(fā)、測試、設(shè)計人員的意見后，綜合了一些較為優(yōu)秀的PRD需求文檔，最終寫下了這篇文檔交付原則。目前也已經(jīng)成功投入使用，它不僅僅能告訴你如何寫一份需求文檔，也能告訴你文檔在進入設(shè)計、開發(fā)流程前你需要做哪些準備工作，衷心的希望這篇原則能給讀者們以啟迪！一、文檔交付流程文檔從最開始的需求分析到真正以文本格式投入使用往往需要經(jīng)歷以下幾個階段——即：需求分析→原型設(shè)計→文檔撰寫→內(nèi)部評審→外部評審。這也是當今主流互聯(lián)網(wǎng)公司大多采用的流程，筆者在本文中會主要介紹：原型設(shè)計、文檔撰寫、內(nèi)部評審三個方面。二、原型設(shè)計原型繪畫是產(chǎn)品經(jīng)理的基礎(chǔ)技能，但現(xiàn)在許多產(chǎn)品經(jīng)理都認為繪畫原型沒那么重要，所以草草了事。但實際上，一份好的原型不僅能幫助設(shè)計和后端開發(fā)較好的理解你的意圖，也能增進團隊之間的和諧。在筆者的產(chǎn)品工作中，設(shè)計人員不止一次因為拿到一些不規(guī)范的原型設(shè)計向筆者抱怨。那么，一份讓大家都滿意的原型應(yīng)該滿足哪些要求呢？筆者認為主要是以下四點：· 可點擊的頁面跳轉(zhuǎn)或頁面流程圖 · 清晰且與文檔對應(yīng)的框架結(jié)構(gòu) · 美觀且較易于理解的設(shè)計草圖 · 簡單、規(guī)范、統(tǒng)一的必要文字說明 “可點擊的頁面跳轉(zhuǎn)或頁面流程圖”：能夠幫開發(fā)更好的理解功能流程，也更利于產(chǎn)品經(jīng)理在內(nèi)審時對自己做的功能進行介紹，而且這通過Axure的“屏幕快照”功能可以非常輕松的實現(xiàn)?！扒逦遗c文檔對應(yīng)的框架結(jié)構(gòu)”：要求PRD需求文檔功能模塊的名稱要與原型文檔里的名稱對應(yīng)?！懊烙^且較易于理解的設(shè)計草圖”：要求產(chǎn)品經(jīng)理繪畫的原型要至少保證可用性——即有原型且原型交互符合規(guī)范。筆者曾遇到過有產(chǎn)品經(jīng)理在原型設(shè)計中將Web端交互放到了移動端，甚至直接給設(shè)計人員Web端原型，讓設(shè)計人員做一份移動端設(shè)計稿的情況。(移動端原型錯誤的交互設(shè)計) 此時的設(shè)計人員：“到底你是產(chǎn)品，還是我是產(chǎn)品？？？”“簡單、規(guī)范、統(tǒng)一的必要文字說明”：因為有些功能點描述在文本中表現(xiàn)可能不夠清晰，所以直接在原型上給予標注，這部分要盡量克制。三、文檔撰寫1. 我們?yōu)槭裁匆獙懳臋n？文檔的撰寫目的，筆者認為主要有以下四點：· 幫助產(chǎn)品經(jīng)理梳理思路、流程及細節(jié)，完善產(chǎn)品。 · 減少設(shè)計、開發(fā)、測試過程中反復(fù)溝通造成的時間浪費和進度延誤。 · 增強用戶意識及程序思維。 · 反向通過完整的PRD、原型對產(chǎn)品進行驗收及質(zhì)量評價。 以上的一、三、四點都比較好理解，主要是為了完善產(chǎn)品經(jīng)理的產(chǎn)品思維、減少出錯。而第二點可能有很多人會疑惑，做產(chǎn)品本來就需要我們反復(fù)的去跟開發(fā)、設(shè)計、測試進行溝通，為什么還要減少呢？這主要是因為：產(chǎn)品經(jīng)理與他們之間的許多溝通本來是可以不發(fā)生的。例如：一個Butoon的字段，你在文檔里沒有描述清晰，那么開發(fā)就會過來找你問，如果沒有問你直接照著他的想法做了。最后方向和你想的不一樣，那就悲劇了，要接著溝通怎么改了。所以，對于一個產(chǎn)品經(jīng)理，最好的狀態(tài)是當你完成了某個項目的V1.0版本時，你就應(yīng)該立刻著手準備V1.1版本的迭代與更新了，而不是接著和團隊的其他成員在V1.0版本上扯皮。請務(wù)必記?。骸爱a(chǎn)品經(jīng)理是帶著團隊跑，不是和團隊一起跑?！?. 優(yōu)秀文檔應(yīng)具有哪些特性？筆者認為，優(yōu)秀的文檔主要具有以下特性：· 邏輯性：內(nèi)容有層次，描述可遞進，文檔中的結(jié)論要有客觀事實來說明。 · 敏捷性：文檔的內(nèi)容要盡可能精簡，切勿長篇大論。 · 完整性：在保證文檔內(nèi)容精簡的同時，也不能缺三少四，重要的模塊不能丟。 · 可讀性：盡量避免使用二義性的語句，這容易造成使用人員曲解你的想法。 · 規(guī)范性：每份文檔盡量保證格式相同或類似，減少使用人員的適應(yīng)成本。 · 一致性：在需求分析模塊的劃分和命名上與原型文檔保持一致。 3. 優(yōu)秀文檔應(yīng)該包含哪些模塊？上文提到：一個好的需求文檔應(yīng)該做到完整性——即包含所有的重要模塊，不能缺三少四。那么又有哪些模塊是重要的呢？筆者在仔細分析了團隊正在做的產(chǎn)品業(yè)務(wù)后，總結(jié)了優(yōu)秀文檔所需要包含的23個重要模塊，其中有11個模塊是必備的。筆者相信，這也同樣適用于大部分其他產(chǎn)品的業(yè)務(wù)。 筆者簡單解釋一下，上圖中各個模塊應(yīng)包含的內(nèi)容和存在意義。（1）版本修訂記錄(必備)：主要包含現(xiàn)有版本的版本號、主要更改內(nèi)容、更改原因等，它在產(chǎn)品出現(xiàn)問題，追根溯源時可以起到巨大作用。同時，也便于使用人員梳理邏輯。（2）產(chǎn)品目標（必備）：可以是功能或者產(chǎn)品上線后想要達到的效果。（4）需求方及背景（必備）：簡述需求產(chǎn)生背景以及原因，需求面向哪些人群？一定要有事實或者數(shù)據(jù)作為佐證，開發(fā)吐槽產(chǎn)品經(jīng)理亂提需求也不是一天兩天了。（5）預(yù)估收益（必備）：最好能用數(shù)字量化產(chǎn)品或功能開發(fā)產(chǎn)生的收益，也就是ROI，對收益的正確評判也是產(chǎn)品經(jīng)理的一項重要能力。這里舉個例子，如“優(yōu)化公司內(nèi)部系統(tǒng)某流程，預(yù)計耗時13人天，完成后預(yù)計可以為公司其他部門每年節(jié)省35人天”。這樣的描述，清晰且可信。（6）風(fēng)險描述：簡要概述產(chǎn)品或功能開發(fā)過程中可能會遇到的內(nèi)部風(fēng)險和外部風(fēng)險，例如：新項目遷移可能遇到未知問題，這就是內(nèi)部風(fēng)險。前端開發(fā)缺人，項目撞車，這就屬于外部風(fēng)險。（7）目標用戶（必備）：簡要描述一下產(chǎn)品或功能上線后服務(wù)的人群，有群體特征的最好也寫上。（8）使用場景：簡要描述一下產(chǎn)品或功能上線后使用的場景。（9）參與人員（必備）：記錄產(chǎn)品或功能從孵化到上線過程中負責(zé)的工作人員，這樣的好處是某個環(huán)節(jié)一旦出了問題，可以快速的定位到相關(guān)的負責(zé)人，提高效率，特別是翻看歷史記錄的時候。（10）項目周期：主要是方便使用人員進行時間規(guī)劃，同時可用于進行項目管理，如果所在團隊項目的時間管理已經(jīng)足夠好，那么這個模塊可以不寫。（11）名詞解釋：對使用人員可能不了解的名詞進行注釋。（12）功能流程（必備）：這是PRD需求文檔里最重要的一個模塊，所以在保持簡潔的同時要做到盡可能的詳細。流程圖的作用不必多說，邏輯清晰的流程圖可以幫助使用者快速的理清業(yè)務(wù)邏輯，提高效率，減少出錯。而在“交互流程”中，我建議產(chǎn)品經(jīng)理可以直接用Axure生成的HTML網(wǎng)址進行表示，方便且快捷。接下來是“頁面及彈窗”，這部分對前端開發(fā)意義很大，能有效的避免漏掉某些重要頁面。最后便是“功能及說明”，這部分主要對產(chǎn)品的每個功能進行詳盡的描述。以Web端的一個頁面舉例，我們需要介紹這個頁面的操作路徑，頁面上的操作形式，數(shù)據(jù)的來源，額外的說明等。具體的示例，筆者在下面用圖片展示：（13）權(quán)限&角色：簡要描述一下使用這個產(chǎn)品或功能的不同特征人群的權(quán)限，舉個例子，企業(yè)做一個自己的日報系統(tǒng)，老板和員工的使用權(quán)限肯定是不一樣的。（14）性能需求：簡要描述一下產(chǎn)品對性能的要求，如QPS、請求訪問時長等。（15）營銷&運營需求：這部分主要是面向C端產(chǎn)品，寫出方向性就可以，是與運營聯(lián)動的一個模塊。（16）安全需求：不同產(chǎn)品或功能對于安全的要求往往不盡相同，例如“支付功能”的安全需求比大多其他功能都要高，這個模塊建議寫上產(chǎn)品或功能安全等級的高低，應(yīng)該做好哪些預(yù)防。（17）法務(wù)需求：主要是專利著作權(quán)、版權(quán)等可能遇到的法務(wù)風(fēng)險，大多產(chǎn)品或功能不存在這個問題。（18）異常情況（必備）：簡要描述一下用戶使用產(chǎn)品或功能時可能碰到的異常情況，例如突然斷網(wǎng)等。（19）測試要點（必備）：這部分非常重要，產(chǎn)品經(jīng)理需要在這個模塊介紹產(chǎn)品或功能在上線前有哪些重點功能是需要反復(fù)測試的，有哪些異常邏輯是需要注意的。因為測試人員在一些細節(jié)的把控上可能沒有產(chǎn)品經(jīng)理來的仔細，如果一些重要的點沒能被測試到就直接Pass，在后續(xù)的開發(fā)中就可能會惹上大麻煩（回爐重造等），從而導(dǎo)致項目延期。（20）數(shù)據(jù)埋點及統(tǒng)計需求：寫清楚應(yīng)該在產(chǎn)品中的哪些維度進行數(shù)據(jù)埋點，和與之對應(yīng)的統(tǒng)計需求。（21）上線前準備（必備）：分點敘述上線前需要完成那些事件，例如把Bug狀態(tài)都變?yōu)椤耙呀鉀Q”。（22）上線后工作（必備）：大多數(shù)產(chǎn)品或功能不是上線就結(jié)束了，往往需要后續(xù)的跟進，例如進行回歸測試，對用戶進行意見調(diào)研、實際收益評估等。（23）設(shè)計規(guī)范：針對有交互原則的團隊。（24）補充說明：其他不屬于以上22個模塊的解釋描述。四、需求評審1. 評審的主要流程· 自評清單，自評通過再內(nèi)審。 · 內(nèi)審評價，內(nèi)審?fù)ㄟ^再外審。 · 外審評價，外審?fù)ㄟ^進入開發(fā)。 2. 如何做好內(nèi)審？內(nèi)審是評審的第一步，如果沒有卡好內(nèi)審這門關(guān)卡，隨意的讓項目通過，會導(dǎo)致外審時項目出現(xiàn)諸多紕漏，浪費團隊其他人員的時間，所以內(nèi)審一定要足夠謹慎。針對內(nèi)審，筆者總結(jié)了六條原則：· 至少應(yīng)有3人參與內(nèi)審； · 內(nèi)審必須邀請項目管理者參與； · 要提前給定好內(nèi)審預(yù)計所需要的時間； · 基礎(chǔ)測試一旦沒有通過，內(nèi)審必須當即中斷； · 評審結(jié)束后，相關(guān)人員應(yīng)該在幕后形成相關(guān)的結(jié)論； · 每次內(nèi)審需做內(nèi)審會議紀要，紀要包括內(nèi)審的結(jié)論和問題。 這六條原則應(yīng)該都是比較通俗易懂的，但關(guān)于基礎(chǔ)測試，筆者要額外解釋一下：所謂基礎(chǔ)測試其實就是需求或功能流程，如果在內(nèi)審當中，因為產(chǎn)品經(jīng)理個人的靈光乍現(xiàn)或者是他人異議發(fā)現(xiàn)原定流程中有一段已經(jīng)完全行不通了，那此時的內(nèi)審也就沒有意義了。產(chǎn)品經(jīng)理應(yīng)立刻停止內(nèi)審，回去重新思考并修改流程，但如果僅僅是某一個節(jié)點需要修改，影響較小，則可以繼續(xù)進行。3. 評審需要符合那些標準？· 合理性：成本、收益、用戶、痛點、風(fēng)險等評估要合理。 · 完整性：角色是否完整、狀態(tài)是否完整、功能是否完整。 · 可行性：技術(shù)的可行性，是否觸碰到已知邊界。 · 一致性：保持相同的視覺風(fēng)格、交互方式和情感傳達。 · 邏輯性：流程是否清晰便于其他人理解。 · 準確性：字段、數(shù)據(jù)源、數(shù)據(jù)計算方式、異常狀態(tài)等。 · 易用性：用戶使用成本是否足夠低，路徑足夠簡潔。 · 復(fù)用性：是否考慮復(fù)用已有產(chǎn)品、框架、設(shè)計。 · 創(chuàng)新性：是否能夠盡可能發(fā)揮創(chuàng)新的能力。 以上標準既適用于內(nèi)審，也適用于外審?？偨Y(jié)文檔的撰寫與合格交付一直是困擾在許多產(chǎn)品經(jīng)理心中的一個難題?，F(xiàn)在許多的人都建議直接用Axure來同時進行原型與PRD文檔的制作，這種方式的確非常節(jié)省時間，但要注意這個時間只是節(jié)省了寫文檔的時間，在接下來的設(shè)計、開發(fā)、測試過程中，由于前期文檔內(nèi)容不夠詳盡，耗費的時間實際上是大幅度增加了。在筆者寫下這篇原則之前，所在團隊也是采取Axure原型和文檔一起做的模式，但實行起來效果并不好——前端、測試、設(shè)計飽受這種不規(guī)范文檔之苦。所以，依舊建議大家用文字表達。這套原則因為是第一版，且筆者作為一個實習(xí)生還沒有太多的產(chǎn)品工作經(jīng)歷，所以在部分模塊細節(jié)上可能仍然有許多疏漏。特別的，可能因為從事的業(yè)務(wù)相關(guān)，這套原則不能完全的適用于其他團隊產(chǎn)品的工作模式，不過筆者相信它依舊能給你們以啟發(fā)。至于這套原則的下一步，筆者目前所考慮的是協(xié)同文檔，WIKI、石墨等等，如果大家有好的建議或者是看法，也歡迎在評論中提出，筆者都會認真聆聽并虛心接受，謝謝！ |
|
|
