產品經理在日常工作當中，由于其崗位的職責范圍廣，所需要具備的能力也較多，事情也相對較“雜”。

往往在有限的腦容量當中，要完美地做好每一件事，是極其有難度的。

不知道朋友們是否在產品工作當中有沒有遇到這類問題：

1、產品文檔寫完，自己審視后沒問題（自認為沒問題），評審的時候“舌戰(zhàn)群儒”，搞得心力交瘁！

2、產品文檔寫完，評審也順利通過，但實際開發(fā)當中，還是遇到了需求變更！

3、產品文檔寫完，需求也順利開發(fā)了，但推向市場，卻發(fā)現用戶不買賬？

4、產品文檔寫完，需求順利開發(fā)，用戶也用了一段時間，數據分析的時候發(fā)現，效果極差！

看完上述四點，相信每一個產品朋友都會有或多或少這類的問題。（是讀心高手阿境了）

所以就需要有個規(guī)范，在做產品當中，也需要有份自查表，能夠清楚每一篇文檔每一個需求是否清晰準確。

做好每一個需求，不管大小，都是非常重要的。而每一點需求也都是每一個產品人最初接觸產品崗的工作內容之一，但也是極其重要。

（有一說一，有蠻大部分產品人沒辦法面面俱到地寫好一個需求）

阿境在這篇文章當中所說的產品自查表，主要指的是需求文檔的產品自查。深感需求的重要性，于是乎整理了這份產品自查表，望能夠給到各位產品朋友一點啟發(fā)（強烈建議收藏+分享?。?/p>

簡單來說，文章適用于以下幾類朋友：

1、還不明白產品自查的重要性，目前在“野生”地寫文檔。

2、意識到目前產品需求文檔不完善而造成的問題后果，但沒有行動，想要有規(guī)范的產品自查流程。

3、已經在逐步搭建自身的產品自查表，但卻并不完善，想了解其他人的產品自查。

當然，產品自查表并不局限于產品需求自查，還包括產品項目流程自查，產品調研自查等等，阿境對于這些，會簡單先概括下，這部分更詳細的內容，后續(xù)阿境會持續(xù)整理，再分享給朋友們。

阿境會以兩個方面來闡述產品自查表，第一個是宏觀角度的自查，主要指產品整體全局；一個是微觀角度的自查，主要針對產品需求文檔（這個是重點?。?。

另：

①附上本文導圖框架，節(jié)約時間。若您感興趣，可繼續(xù)深入閱讀；若不感興趣，感謝光臨。

②老規(guī)矩，本文的產品自查表阿境導成了pdf版，需要的公眾號回復“產品自查表”即可；

③若朋友們想拷貝這份自查表，自己修改成適合自身的自查表，可關注（公眾號：夢想家阿境），分享or在看文章后，找阿境拿自查表源文件。

一、什么是產品自查表？

什么是產品自查表？顧名思義，自查表也就是checklist文檔，是一份給到產品崗的朋友來驗證自身產品的規(guī)劃是否合適、妥當的表格。

當然，格式并不局限于表格，僅僅是以表格的形式來展示。

二 、產品自查表的作用

講作用之前，給大家講個故事：

沒錯，這真是比悲傷更悲傷的故事，當中的小B就是曾經的阿境。（不堪回首）

許多人自認為自己做產品的合格及細心，僅僅局限于“自認為”而已。

產品經理是一個比較吃經驗的崗位（當然，也并不是年限越多越厲害，因人而異）；這里所指的經驗主要是針對于產品的定義及對細節(jié)的執(zhí)行程度。

年輕的產品經理往往拿到一個需求洋洋灑灑地敲打鍵盤，毫無考慮；而有經驗的產品經理則是經過深思熟慮之后再開始進展。

什么是差距，這就是差距！

話說回來，產品自查表表面上是一張表，一個導圖，但實際上是一名產品經理對于細節(jié)的把控程度，一名好的產品經理腦子里面已經有一份自身的產品自查表。

在產品想法還沒完成之前，它能夠幫助產品經理思考需求的可行性及必要性；在產品正在規(guī)劃當中，它能夠幫助產品經理梳理清楚產品業(yè)務及細節(jié)；在產品規(guī)劃后正在落地，它能夠幫助產品經理規(guī)范進行查缺補漏，復盤思考。

那么，產品自查表有用嗎？阿境認為對于大部分產品經理都是有用的，減少與開發(fā)的撕X，與老板的爭論，思考清楚產品及需求的細節(jié)。

認清產品，寫好需求實在是太太太太太重要了?。ㄊ÷訬個太）

噢對，一份適合自身的產品自查表能夠讓你瞬間變專業(yè)，工作瞬間變輕松！

所以，阿境姑且稱為這份產品自查表為“讓你瞬間變專業(yè)工作瞬間變輕松的產品自查表”。（別問，問就是標題瞎取的）

三、產品自查表內容

在產品自查表內容部分，阿境分為兩部分，一是產品整體自查，是站在宏觀角度來思考產品，主要適用在產品想法的階段；二是產品需求文檔自查，是站在微觀角度上，思考一份文檔是否嚴謹、細節(jié)流程是否得當，主要適用在產品規(guī)劃中及規(guī)劃后。

1、產品整體自查

對于產品整體自查，主要考慮的是產品的市場可行性、需求可拓展性等因素。是以一個宏觀的角度來思考產品本身。

由于本文著重描述的是產品需求文檔的自查，故該部分僅簡單講述下。

（1）產品的受眾人群是誰？

（2）產品的定位是什么？

（3）產品的核心功能是什么？

（4）產品與其他競品的核心競爭點？

（5）產品是否滿足了各個場景下用戶的需求？

（6）在做需求之前，是否有進行需求調研（包括競品分析）？

（7）在做需求之前，是否了解需求包含功能所涉及的業(yè)務？

（8）在做需求之前，是否了解需求包含功能所涉及的歷史邏輯？

（9）產品要完成的目標是什么？

......

整體自查更多的是在產品想法誕生的時候來進行自查，只有想清楚了大方向是否正確，才不會造成“南轅北轍”。

2、產品需求文檔自查

產品需求文檔的自查部分，從第1點到10點更多的也是站在文檔的宏觀部分，而第11到第23點則是針對于需求當中的細節(jié)規(guī)范自查，涉及到產品的功能模塊，例如文案、數據、彈窗、輪播圖、圖片等等。

1）需求階段

在需求階段，通常會出現的問題是“你認為你想清楚了需求的場景、對用戶側的作用、對產品的影響等”，但其實沒有深入全面，最后導致需求做出來了，沒人用亦或者是用了效果不好的情況發(fā)生，由此可見，深入思考需求是極其重要的。

a. 是誰在什么樣的場景下產生的什么訴求，希望用什么方法解決什么問題？

b. 是否需要進一步調研相關用戶/需求提出方，是否需要數據佐證？

c. 是否符合當前核心業(yè)務場景、是否符合用戶畫像和用戶故事？

d. 是否存在類似競品，是否完成競品分析？

e. 當前方案是否是同類場景下的共性訴求？

f. 對核心用戶的影響程度，盡可能量化。

g. 對核心業(yè)務的貢獻程度，盡可能量化。

h. 當前技術是否可以支持

i. 當前業(yè)務是否可以支持

j. 是否存在關聯功能的改造點？

k. 是否完整梳理當前規(guī)劃內容下線后的影響點？

l. 是否已預估業(yè)務高峰數據爆發(fā)量級，及其處理措施？

m. 是否已計劃好功能上線后的驗證方法？

n. 是否引發(fā)諸如騷擾、欺詐等安全隱患？

o. 是否存在負面輿情風險？

p. 是否存在法律及合規(guī)風險？

q. 用戶覆蓋度

r. 使用頻率

s. 對核心場景的影響

t. 實際收益的高低

u. 對KPI的影響

v. 實現難度的高低

w. 產品成長時機

2）整體框架設計階段

在整體框架設計的階段，更多的是站在一個全局的角度，可以理解為樹木的枝干，通過這些用戶能夠清晰地感知到產品的清晰度及易用性。

a. 設計時是否結合了用戶畫像、用戶習慣、業(yè)務場景等因素。

b. 架構層次是否清晰，是否足夠扁平，是否容易能使用戶理解。

c. 所有信息均需要進行重要級評定，以決定在界面和功能中的重要程度。

d. 信息分類是否合理，一定要“高內聚，低耦合”。

e. 架構拓展性是否足夠大，后續(xù)對信息模塊進行增刪改查時，是否容易施行。

3）流程設計階段

產品流程主要指的是業(yè)務流程部分，整體產品業(yè)務是重中之重，了解業(yè)務后再了解產品。拆分現有業(yè)務流程，持續(xù)優(yōu)化它，排除不合理的流程走向，同時通過業(yè)務流程也能夠探索現有問題。

a. 流程設計是否結合了用戶畫像、用戶習慣、業(yè)務場景、競品等因素。

b. 主干流程是否最簡化，是否覆蓋了足夠多的場景。

c. 是否有特殊流程（分支流程、逆向流程）

d. 是否有異常流程

e. 是否歸納出所有的操作節(jié)點、數據交互點。

f. 操作節(jié)點是否足夠精簡易理解。

g. 是否考慮了操作節(jié)點的容錯性（二次確認、撤銷操作）

h. 數據交互點是否依賴其它系統(tǒng)。

i. 特殊、異常流程是否需要增加切換流程的引導，避免流程斷頭。

j. 相關流程的用戶體驗路徑是否一致

k. 各圖形形狀/字號統(tǒng)一。重點內容可特殊標識，關鍵節(jié)點增加注釋說明

l. 流程均以開始框開始，以結束框結束，避免斷頭風險。

m. 流程圖從左到右、從上到下排列。

n. 流程圖從左到右、從上到下排列。

o. 流程完成后是否進行了場景驗證，是否符合用戶預期。 

4）需求文檔設計階段

需求文檔設計階段時，是整體文檔的自查，關于流程、文檔文案、名詞、場景、信息等大方向進行的把控。

a. 完整流程是否可形成閉環(huán)？

b. 逆向功能流程是否可逆，如果逆向操作，是否考慮對應的機制：比如退款、退貨操作

c. 各個步驟可能出現預期外的情況。

d. 歧義需求文檔的語法、功能文案、名詞是否易懂，是否存在歧義。

e. 兼容是否存在兼容問題：不同業(yè)務人員對功能都能接受嗎？各個系統(tǒng)之間兼容嗎？新舊功能的兼容嗎（比如歷史數據要不要初始化）？

f. 備用是否有備用方案，次級選項。比如當正常流程無法傳輸的時候，是否可以用導入的機制救急。業(yè)務高峰的系統(tǒng)，是否有降級處理邏輯。

g. 窮盡業(yè)務場景和可能原因是否窮舉完畢。

h. 脫敏是否存在敏感信息，是否有脫敏機制。

i. 文案描述切記要精確，“可能”、“也許”、“大概”等模糊性詞語避免出現。

j. 不是本需求的功能避免加入文檔中，給開發(fā)、測試人員造成干擾

5）特殊因素

特殊因素主要列舉的是一些客觀因素（例如手機系統(tǒng)、賬號、網絡等外在情況）的問題，由于其大部分脫離產品本身功能，是一個輔助的作用，容易被產品朋友忽略。

a. 是否存在不同登錄狀態(tài)下展示內容或操作有不同（登錄、未登錄、帳號異常狀態(tài)）

b. 是否存在不同用戶狀態(tài)下展示內容或操作有不同（非會員、不同等級的會員，特殊付費會員等）

c. 是否考慮多賬號切換，切換時，本地緩存數據是否需要同步清空。

d. 是否允許多終端同時登錄一帳號，若允許，操作同一數據時是否產生沖突。

e. WiFi網絡、移動網絡（4G）

f. 集團局域網、公共網絡

g. 連接超時，多久為超時

h. 網絡顯示什么內容？是否給予用戶友好引導檢查網絡或重試按鈕。

i. 網絡變化從WiFi到4G網絡環(huán)境時是否需要提示

j. 服務器出問題返回數據失敗時，是否給予用戶友好提示或重試按鈕

k. 橫豎屏是否有橫屏展示的需要，如不需要需要鎖定豎屏

l. 分辨率高低：分辨率情況下是否會有適配問題，是否備注清楚。

m. SD卡Android手機，沒有SD卡、SD卡存儲已滿、存儲位置等情況是否考慮并備注。

n. 硬件不同，手機物理按鍵的不同衍生不同操作。

o. 系統(tǒng)版本的不同是否同步支持，iOS、Android、Windows及其不同版本

p. 定位提示是否打開定位

q. 相機提示是否打開相機

r. 閃光燈提示是否調用閃光燈

s. 藍牙提示是否打開藍牙

t. 設備數據是否需要調用，步數、心率等，主要在iOS設備中。

u. 夜間\日間模式是否考慮光線較暗的場景。

v. 編輯模式下出現意外情況是否提示保存或自動保存已填信息。

w. 無痕模式：不記錄用戶所有操作信息（實際是否記錄根據數據需求來看）

x. 無圖模式：節(jié)約用戶流量，加快頁面加載速度。

6）賬號狀態(tài)及用戶權限自查

a. 不同賬號狀態(tài)說明：登錄狀態(tài)、非登錄狀態(tài)不同情況是否說明完整？

b. 不同用戶等級和權限說明，不同等級用戶有哪些權限？在頁面展示上有什么不同？

c. 不同賬號狀態(tài)切換時是否有特殊展示？

d. 不同賬號狀態(tài)切換時是否有特殊展示？

e. 是否考慮多賬號切換問題？

f. 是否支持第三方賬號登錄？

7）設備相關

a. 是否支持橫豎屏操作；檢查不同屏幕效果

b. 不同分辨率下的適配問題，是否有空白溢出變形

c. 操作過程是否有卡頓

8）特殊場景

a. 網絡加載慢情況下無圖顯示效果

b. 考慮夜間模式下的展示效果

c. 區(qū)分編輯模式下可變更內容的權限

9）全局

a. 修改頁面時，考慮在系統(tǒng)中其余地方是否也有相同的業(yè)務，是否需要修改？

b. 全局控件樣式是否具有一致性

c. 全局控件交互行為是否具有一致性

d. 是否周全地考慮了所有操作成功的反饋。

e. 是否周全地考慮了所有操作失敗的反饋。

f. 控件觸發(fā)的提示類型是否恰當（小紅點、Toast、彈窗）

10）版本發(fā)布自查

a. 確認完需求之后，要告知運營同事們有哪些新功能，何時能交付版本，這樣方便運營童鞋們也好對應的落實相關的運營工作。如果運營的部分/全部工作也是PM干的話，那么自己心里要有數；

b. 該版本開始就要落實是否要做新的應用商店圖、新的歡迎頁、新的功能引導頁，并且相應的安排人手。在上線前3天最好再確認一下，萬一有漏，也有時間能再補；注意：針對這三個東西，都有相應的文案要出；

c. 確認這個項目中沒有完成的需求或者中途協(xié)商修改的需求，都已經被記錄下來，并且最好開始確認沒有解決的需求怎么辦，修改的需求怎么辦的問題；

d. 確認該新功能的埋點列表是否給出；

e. 確認新功能帶來的相關新數據的查看地方以及方法，這里會涉及一些常用的統(tǒng)計平臺；

f. 確認新功能帶來的后臺新的管理模塊使用或者從某個地方切換到另一個地方的使用方法的切換，培訓過相關人員，并且已經正確掌握；

g. 確認提交給應用商店的新功能文案是否有出；

h. 確認最終提交給應用商店的應用商店圖、新功能介紹更新了；

i. 確認各個渠道中的最新版確實為最新版本；

j. 每個版本都要觀察上個版本的埋點數據是否正常，及時發(fā)現是否打錯點，進行及時修正，避免數據浪費；

11）按鈕

a. 按鈕文字是寫死還是服務端配置

b. 是否有默認的按鈕文案

c. 按鈕文字的字數超過了怎么辦

d. 按鈕的樣式是否有特殊樣式？若有，什么情況下會觸發(fā)特殊樣式（例如帶icon情況與不帶icon情況）

e. 考慮點擊按鈕后的情況（頁面不變/跳轉到其他頁面.....）

f. 點擊按鈕后出現的情況是否會與頁面其他情況沖突，如何處理（例如點擊按鈕出現浮窗，與其他浮窗重疊，則需要考慮浮窗優(yōu)先級）

12）內容型文案

a. 內容是靜態(tài)的or動態(tài)調用

b. 內容描述是否完整？頂部標題，按鈕里的文字等

c. 內容加載方式描述是否完整？本地緩存or加載網絡刷新內容等

d. 輸入型內容是否完整？是否有初始內容？

e. 內容違禁如何處理？敏感詞，違禁內容等如何處理？

f. 數據內容為空時如何處理

g. 內容長度是否有限制

h. 數據內容過期or刪除or違禁后如何展示？

i. 用戶內容輸入是否描述完整？

13）描述型文案

a. 必填or非必填

b. 若為非必填，則界面樣式如何

c. 定義文案的行數or字數

d. 文案的截斷策略是否考慮？超過字數or行數如何展示處理（例如超過兩行，超出部分“...”展示）

e. 出現同一場景時，提示文案是否保持一致？

f. 文案由服務端控制還是客戶端？

g. 是否有默認文案？

h. 是否易理解？是否有歧義？是否有錯別字？

14）輸入型文字

a. 輸入文字前是否有默認值，   是否有輸入提示。

b. 輸入框內容為空時如何顯示？

c. 輸入框獲得焦點時，默認文字是消失（即僅作為提示文字或占位符）還是保留（即作為可編輯的默認文案）？

d. 獲得焦點后，調取的鍵盤類型（數字鍵盤、英文鍵盤等）

e. 輸入焦點丟失和存在時是否有展示內容的差異。

f. 輸入文字是否存在極限長度或最低長度。

g. 輸入文字是否可存在特殊字符，若用戶輸入如何處理。

h. 輸入文字是否存在對敏感詞（密碼、存款金額等）、違禁詞的禁用或過濾展示。

i. 輸入文字后是否需要一鍵清空操作。（加個一鍵清空的按鈕等）

j. 輸入文字后是否顯示輔助結果（輔助詞），輔助詞的搜索規(guī)則。

k. 輸入文字后遇到流程打斷的情況是否保留輸入記錄（斷網、離開當前頁面或關閉瀏覽器等）

l. 是否說明了鍵盤喚起后需要頁面的滾動來避免輸入框的遮擋（移動端）

15）輸入型圖片

a. 是否強制要求上傳圖片的必須參數（尺寸、格式、大小等）

b. 是否設置了不符合尺寸的提示，圖片過大或過小，格式錯誤等。

c. 是否提供上傳完成圖片的預覽。

d. 是否提供了再次編輯操作，引導是否明顯。

e. 上傳失敗的情況是否給予用戶提示，引導再次上傳。

f. 上傳完成后遇到流程打斷的情況是否保留已上傳的記錄（斷網、離開當前頁面或關閉瀏覽器等）

16）頁面跳轉

a. 頁面跳轉流程是否完整順暢，流程中間是否有頁面缺失

b. 頁面跳轉是否有提示和引導說明

c. 頁面跳轉加載的loading展示是否友好

d. 頁面跳轉動作是否有跳轉特效

e. 頁面跳轉的方式是什么，點擊？滑動？等

f. 頁面加載不出來或者報錯時展示什么內容

g. 頁面點擊過程中是否包含權限限制，如果有如何提示

h. 頁面跳轉盡量要減少跳轉次數，縮短用戶操作流程，盡可能在一個頁面內完成

i. 一個頁面內是否有功能冗余的內容

j. 頁面跳轉時是否需要進行輔助性說明

17）標簽

a. 標簽是系統(tǒng)做的還是用戶標記上傳的

b. 標簽下的列表展示（回歸到列表的問題即可）

c. 用戶是否可自定義上傳標簽

d. 用戶上傳標簽后是否可修改、刪除

e. 用戶上傳的標簽，考慮敏感詞庫

f. 標簽是寫死還是服務端配置

g. 是否必填

h. 是否有默認的標簽

i. 標簽的內容是文字還是圖片？

j. 標簽的文字是否有字數限制？

k. 標簽的個數是單個還是多個，多個的話考慮優(yōu)先級排序

l. 標簽個數多個的情況，是否會遮擋住頁面其他元素（例如，多個可以收納起來處理）  

m. 多種類型的標簽，對類型進行排序

n. 多種類型的標簽，出現重復的情況（一般做去重處理）

o. 后臺：是否必填、標簽名（是否限制字數）、標簽內容（文字/圖片）、排序（是否有默認值，越大排越前）、是否顯示、標簽個數、快捷的標簽配置

18）列表

a. 列表的排序如何？

b. 列表中的元素是否都定義清楚？

c. 列表中涉及的數據來源定義

d. 列表數據為空時的展現形式

e. 若部分元素為后臺配置，則配置前后的情況定義

f. 列表的數據是否分頁展示？還是一次性加載？單頁展示的數量是否有限制

19）數據

a. 數據的來源（具體后臺的哪個地方）

b. 展示數據是否使用的是服務器數據，或使用的是本地緩存（客戶端）數據？

c. 展示數據是否是初次加載讀取的靜態(tài)數據，或實時、定時展示的動態(tài)數據。

d. 數據未加載出來前展示什么？

e. 是否規(guī)劃數據為空時的展示效果

f. 數據的極值情況（為0的情況，最大值的情況）

g. 數據長度是否有限制？是否規(guī)劃數據字數超長展示效果（幾位小數點，超出如何展示）

h. 若為多個數據，則數據的排序如何？

i. 是否選取全部數據or部分數據？（數據根據什么搜索規(guī)則篩選出來的）

j. 對過期的緩存數據是否需要告知用戶刷新（活動過期）

k. 前置場景的不同是否對當前展示數據產生影響，不同場景是否需要展示不同數據。

l. 移動端從后臺喚醒應用時，是否需要刷新當前頁面數據。

m. 數據在什么條件下進行展示？

n. 數據是否分頁展示？

o. 數據去重策略如何？

p. 什么時候開始請求數據？

q. 什么情況下觸發(fā)更新數據？

r. 數據更新頻次？是定時更新還是實時更新？

s. 是否有部分數據需要過濾掉不展示？是否對特殊內容進行過濾、標記（敏感、違禁的詞語）

t. 當數據被刪除后，展示的狀態(tài)如何？

u. 過期的緩存數據如何處理（定時清理還是繼續(xù)保存）？

20）彈窗

a. 什么時候觸發(fā)彈窗？

b. 什么時候彈窗消失？（關閉按鈕、返回按鈕、手機系統(tǒng)返回按鈕、點擊頁面空白處等）

c. 彈窗內的元素（文案、跳轉等）是否都定義清楚

d. 是否每次滿足條件都觸發(fā)彈窗？還是只彈一次？

e. 若該彈窗與其他彈窗同時滿足條件觸發(fā)，則優(yōu)先級如何？

21）輪播圖

a. 圖片數據為后臺配置or客戶端寫死？

b. 圖片排序如何？

c. 點擊是否有跳轉？跳轉頁面為內部鏈接or外部鏈接？

d. 輪播的頻次如何？

22）圖片上傳

a. 是否有圖片尺寸、像素、格式的要求

b. 是否有上傳張數的限制及張數限制的提示

c. 是否提供上傳的圖片預覽

d. 是否有上傳成功后可以再次編輯上傳

e. 上傳失敗如何處理及引導提示如何展示

f. 上傳過程遇到突然中斷情況是否保存上傳記錄

23）數據埋點

a. 數據埋點的字段內容及展示類型是否完整

b. 數據埋點的時間范圍和時間段是什么

c. 上線后驗證的數據是否都進行了埋點記錄

d. 是否需要進行數據漏斗模型分析報表生成

e. 埋點數據后續(xù)如何提取出來

f. 是否有自動通知機制，通知形式是什么

g. 據埋點不成功是否有報警機制

04 如何來做產品自查？

當我們擁有了產品自查表之后，要做的就是在遇到每一個需求，撰寫每一份產品文檔的時候，將自查表運用到當中去。

敲黑板，說重點了！打瞌睡的同學醒醒，這段聽完再睡~

阿境總結了一句話：先總后分，模塊劃分，按序核查，勿忘更新。

“阿境你又說出這么抽（zhe）象（li）的東西了，說人話行不行？”

不說點大家覺得高（ting）大（bu）上（dong）的話，能是廈門吳彥祖嗎？

（沒錯，第一厚臉皮也是阿境本境）

好了，不廢話，啥意思？簡單來說，分成四步：

1、先總后分

先按照宏觀的角度來審視整篇文檔，查看文檔的整體方向是否正確，文檔的結構是否無誤，暫時先不考慮細節(jié)。等到總體方向沒問題了之后，再去查看查看文檔的分支細節(jié)。

2、模塊劃分

根據模塊來進行文檔的撰寫，有個大忌就是在A模塊寫到了B模塊的內容定義，文檔容易造成不易閱讀，冗長，劃分好文檔的模塊并且對文檔進行相應的模塊定義，一個清晰的模塊就好比是樹木的枝干，能夠提升文檔的可讀性。

3、按序核查

當進行第二步模塊劃分之后，為的便是更好地進行順序的核查，例如產品需求、業(yè)務流程、功能主次關系、功能布局、模塊狀態(tài)等等順序進行一一校對。

4、勿忘更新

有了這份文檔，并不是一蹴而就的，時代在更新，產品在更新，自然，產品自查表也需要不斷更新。這份自查表是阿境在自身實踐當中總結而出，可以看出，產品的理論大多源于實踐，脫離實踐則無從談起。所以，朋友們可實踐當中，不斷完善這份產品自查表，一句話：沒有最完美的，只有適合自己的。

寫在最后

做產品是一個并不那么容易的活，寫一份合格的需求文檔也不是那么輕松的事情。為了確保產品能夠“活下來”，確保需求文檔能夠嚴謹、詳盡、完善，這份產品自查表希望能夠幫助到各位朋友。

但有一點要記住，產品自查表起到的作用是錦上添花，并不是雪中送炭。它是建立在有一定產品思考方向的前提之下。

同時阿境也想拋磚引玉，以這份產品自查表來提醒各位朋友，需要有核查、糾錯、校對的意識，對產品對需求保持敬畏之心，才能夠做好產品。

最后，愿天下沒有難寫的需求文檔。

-END-