至此，我們完成了app的定位、系統(tǒng)架構(gòu)、產(chǎn)品結(jié)構(gòu)、重要的2大流程圖（業(yè)務(wù)、頁面流程圖）以及所有頁面的原型稿、交互稿、視覺設(shè)計稿。最后將他們組合在一起，是否就得到PRD了呢？不完全是，本文將圍繞PRD的3大目的來拆解如何寫PRD。

本系列是筆者拆解從0到1設(shè)計「職得App」，這個作品幫助我拿了好幾個offer，因此特別展開分享給大家。之前的文章，可以在筆者的個人中心閱讀，歡迎訂閱～

一、市場分析篇：市場分析（上）；市場分析（下）

二、競品分析篇：競品分析

三、用戶調(diào)研篇：用戶調(diào)研（上）；用戶調(diào)研（下）

四、需求管理篇：需求管理

五、架構(gòu)流程篇：產(chǎn)品定位（上）；系統(tǒng)架構(gòu)/產(chǎn)品結(jié)構(gòu)（中）；業(yè)務(wù)、頁面流程圖（下）

六、原型設(shè)計篇：原型&交互設(shè)計

七、UI設(shè)計篇：視覺概念設(shè)計

八、PRD文檔篇：（本文最終篇）

在此聲明：本系列的產(chǎn)品內(nèi)容原創(chuàng)且非商用，如有雷同，你抄我的！

一、前言

在之前的文章中，我們做過背景分析（市場調(diào)研、用戶調(diào)研、競品調(diào)研）、需求管理、產(chǎn)品定位（功能目標(biāo)）、流程圖、原型圖、交互稿、UI稿。

如果你還沒看過之前的文章，建議先行閱讀，以免產(chǎn)生知識的詛咒，讀不懂下文。

實際上，在做這些事的過程，就相當(dāng)于在寫PRD。PRD的全稱是：Product Requirement Document，核心是圍繞「需求」來寫的一份文檔罷了。鑒于我們是從0設(shè)計App，相對來說就是N個需求的集合，甚至還涉及到了需求排期和產(chǎn)品演進藍(lán)圖，因此我們職得的PRD會非常大。

二、Why：為什么要PRD？

我們反過來想，如果沒有一份PRD會怎么樣？

• 溝通全靠想象力；
• 跟不同部門的同事用不同文檔溝通；
• 開發(fā)完了沒有“憑據(jù)”；
• idea太好，記不住了……

如果沒有一份完備的PRD，就會導(dǎo)致需求無法落地成軟件。如同借錢不打借條，沒門。如果不寫PRD，相當(dāng)于程序員天天不敲代碼。

三、PRD是什么？

不用多說，PRD重要性不言而喻。

實際上，在各公司里，對PRD都有各自的規(guī)范，其實你可以理解為各公司規(guī)定的一份「解決需求」說明書，PRD也好，需求稿也罷只是一個名頭而已。不要被名詞所拘束。

在不同公司里，要靈活運營，達(dá)到以下3個目的即可：

1. 清晰地傳遞需求——>評審、溝通用；
2. 詳細(xì)地拆解需求——>設(shè)計、開發(fā)用；
3. 認(rèn)真地驗證需求——>驗收、測試用。

很肯定地說，不用拘泥于需要什么模塊、也不用拘泥于用什么工具開發(fā)，朝著這3個目標(biāo)去寫就可以了。

一份優(yōu)質(zhì)有效的PRD關(guān)鍵點是什么？

1. 把背景、共識交代清楚了。好的prd是放置1年，新入職的產(chǎn)品同學(xué)也能看得懂。
2. 邏輯明確，沒有廢話。好的prd是字?jǐn)?shù)不多，邏輯清晰、全是有用的信息。
3. 簡約清晰，該有的都有。好的prd是顧及到本次需求涉及的同事，如服務(wù)端開發(fā)、測試工程師。

只要你能夠做到這3點，大概就是一份好的prd了。從來沒有人定義好的prd是字多。

四、怎么寫PRD？

問：PRD用什么寫？

答：Word、Axure、共享協(xié)作軟件都可以。

主要看公司統(tǒng)一用什么，你就跟著用就對了。個人比較喜歡用共享協(xié)作軟件，因為prd的一個目的是溝通用，而在溝通中一定會出現(xiàn)其他人的不同意見，或者其他人才有的知識，可以讓別人直接更改，很高效。我在公司里用過。

當(dāng)然，我也推薦用Axure，小需求小改動或者是多個需求集合的時候，可以使用，比較適用于小團隊，我在公司里也用過，各有優(yōu)劣。

問：PRD怎么寫？包含什么模塊？

答：不要固化思維，正如上文，重點在于圍繞「需求」的三個目的。

按照上文一份PRD的3個目的即可，結(jié)合「職得app」來拆解每一個模塊。

目的1：清晰地傳遞需求

關(guān)鍵詞：清晰、傳遞。

為了清晰地向其他同事（如開發(fā)、設(shè)計師、測試、運營、市場等）、上級領(lǐng)導(dǎo)、boss、未來新入職的產(chǎn)品講清楚需求。

必須說清楚的有：

• prd版本迭代：因為一份prd并不是一個人來寫的，比如常見的UI稿就來自UI設(shè)計師，因此prd是一步一步寫出來的，特別需要在prd開頭寫明白；
• 交代背景：場景、遇到的困難、為什么要做這個需求；
• 定義詞匯：對于陌生詞、專有詞、跨領(lǐng)域詞用文字在prd開頭定義清楚；
• 交代目的：想解決什么問題、想提高什么數(shù)據(jù)到多少；
• 描述解決方案：根據(jù)背景/現(xiàn)狀、以及目的去描述可能的解決方案；
• 附屬鏈接：貼上與本需求相關(guān)的其他內(nèi)容。

回到我們「職得App」中，我們一一拆解來看。

PRD版本迭代：做成表格，每次記錄迭代順便記錄即可。包括時間節(jié)點、負(fù)責(zé)人、內(nèi)容、進度。

需求的背景：對于從0設(shè)計的APP來說，無疑是市場分析、用戶調(diào)研、競品分析。關(guān)于調(diào)研內(nèi)容我在本系列頭幾篇文章已經(jīng)詳細(xì)分析過，還沒閱讀的小伙伴可以認(rèn)真看一下。

定義詞匯：因為涉及的業(yè)務(wù)比較簡單也沒有什么專有名詞，跳過這個模塊。

交代目的：做一款A(yù)pp解決市場上發(fā)現(xiàn)的未被滿足的需求。

大致解決方案：之前在產(chǎn)品定位有提及，包含產(chǎn)品定位和v1.0.0版本功能需求Feature List、系統(tǒng)框架、以及產(chǎn)品演進藍(lán)圖，就不一一贅述了。

名稱：職得App

定位：大牛培伴式互聯(lián)網(wǎng)職場技能學(xué)習(xí)平臺；

slogan：陪練十遍，技能自現(xiàn)；

目標(biāo)用戶：非一線互聯(lián)網(wǎng)職場新人；

用戶痛點：在中小型公司得不到業(yè)界大牛指點崗位技能的機會。

附屬鏈接：無

目的2：詳細(xì)地拆解需求

關(guān)鍵詞：詳細(xì)，拆解

需求最終還是要給到設(shè)計師、程序員、測試工程師來進行設(shè)計和開發(fā)。因此在prd里必須包含了本次需求所涉及的實現(xiàn)路徑。

視情況而定，不同需求拆解的程度不同。

• 比常規(guī)少：有的需求不涉及前端的頁面，就不涉及UE/UI設(shè)計，有的需求開發(fā)自測，不需要測試工程師來進行質(zhì)量把控。
• 比常規(guī)多：有的需求涉及跨部門協(xié)作，需要運營、市場的人后期參與，或有的需求涉及數(shù)據(jù)分析師、公司中臺的協(xié)助。

簡而言之，幾方參與就寫幾方內(nèi)容，一般包括但不限于：

• 給開發(fā)看：業(yè)務(wù)流程圖、頁面流程圖、原型交互稿、UI稿、數(shù)據(jù)庫調(diào)整規(guī)范、埋點修改規(guī)范、版本迭代、接口規(guī)范
• 給UE看：需求目標(biāo)、解決方案、線框稿
• 給UI看：需求目標(biāo)、解決方案、原型交互稿、
• 給測試看：需求解決方案、業(yè)務(wù)流程圖、頁面流程圖、原型交互稿、測試用例、埋點修改規(guī)范
• 給運營看：運營推廣計劃、a/b實驗方案、產(chǎn)品培訓(xùn)方案
• 給數(shù)據(jù)分析師看：需求目標(biāo)、解決方案、a/b實驗方案

再次強調(diào)It depends，情況而定的思想。需求目標(biāo)會影響到在prd中需要拆解出哪些內(nèi)容。

回到我們「職得App」中，因為是從0設(shè)計App，因此幾乎會覆蓋到所有人。但由于是模擬項目，并非真實上線投入到市場中，無法驗證，所以不包含運營計劃和ab實驗方案。

因此「職得App」PRD中包含業(yè)務(wù)流程圖、頁面流程圖、原型交互稿、UI稿。而這些在之前的文章中一一詳細(xì)分析過了。

在實際工作中，還應(yīng)當(dāng)包含：埋點規(guī)范文檔（給開發(fā)和測試看）、測試用例（和測試協(xié)商）、運營推廣計劃（和運營協(xié)商）、ab實驗方案（和數(shù)據(jù)分析師協(xié)商）、產(chǎn)品培訓(xùn)方案（和運營/商務(wù)協(xié)商）

目的3：認(rèn)真地驗證需求

關(guān)鍵詞：認(rèn)真、驗證

互聯(lián)網(wǎng)人喜歡說「閉環(huán)思維」，這一步就是閉環(huán)。

當(dāng)一個需求被開發(fā)完之后，還沒有結(jié)束?？梢哉f才完成了一半，最重要的是檢驗是否達(dá)成了目標(biāo)，怎么檢驗，如果達(dá)成改怎么辦，如果沒達(dá)成又該怎么辦？

例如：

1. 在開始中時，臨時調(diào)整需求；
2. 在測試環(huán)節(jié)出現(xiàn)了問題，需要代碼回滾；
3. 一個簡單的需求上線后出現(xiàn)了bug，需要fix；
4. 上線后數(shù)據(jù)效果不佳，遠(yuǎn)不如預(yù)期；
5. ……

這些情況都可以算在驗證需求環(huán)節(jié)出了問題。即目標(biāo)和現(xiàn)實情況出現(xiàn)不匹配。

如何實現(xiàn)「閉環(huán)」，去驗證需求？實際上并不局限于prd，一般有如下幾點要注意：

• 質(zhì)量保障：多方驗收與測試。
• 數(shù)據(jù)分析：無論是否有a/b實驗，有數(shù)據(jù)變化的話都要進行事后分析。
• 目標(biāo)完成度：記錄下未完成/超額完成的原因是什么？
• 下期規(guī)劃：是否要做下期需求來彌補/持續(xù)優(yōu)化。
• 郵件通知：盡可能發(fā)郵件通知到本次需求的所有參與方。

關(guān)于這一目的，由于「職得App」無法真正上線，不能夠形成真正的閉環(huán)。因此就不展開舉例。以上5點是我個人在實際工作中總結(jié)出來的，同樣地，并非針對每個需求都要如此，需要是情況而定。

所謂產(chǎn)品經(jīng)理要靠譜，如果能夠?qū)π枨笮纬伞搁]環(huán)思維」，就是真正的事事有著落。這，特別需要在實際公司、業(yè)務(wù)中磨練，培養(yǎng)出這種思維意識。

總之，PRD只是一種承載形式，它完成它的3個目的即可，核心關(guān)鍵還是在于內(nèi)容是否想明白，如流程是否解決用戶需求、交互是否合理，這才是產(chǎn)品經(jīng)理的本質(zhì)工作。

五、感謝和總結(jié)

這是「從0設(shè)計App」系列的最后一篇內(nèi)容，感謝大家的關(guān)注和支持～

相關(guān)閱讀：

產(chǎn)品人深思（7）：互聯(lián)網(wǎng)群面的1個通關(guān)原則：horsekeeper

產(chǎn)品人深思（5）：產(chǎn)品經(jīng)理如何寫有用的簡歷？

產(chǎn)品人深思（3）：大學(xué)生如何拿到產(chǎn)品offer？

作者：朱魯斌，公眾號：字字朱心。每周深度思考一個問題，不穩(wěn)定的世界里找到一份篤定。

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

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