起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識 人手必備的產(chǎn)品自查表（建議收藏+打?。?/h2>
編輯導(dǎo)讀：對于產(chǎn)品經(jīng)理來說，由于平時的工作比較繁瑣，在產(chǎn)品工作中容易對一些細節(jié)有所遺漏，這樣會導(dǎo)致需求反復(fù)和研發(fā)資源的浪費。本文作者從自身工作實踐出發(fā)，對產(chǎn)品各階段需要自查的問題進行了梳理總結(jié)，制作了一份產(chǎn)品自查表，供大家一同參考學習。
產(chǎn)品經(jīng)理在日常工作當中，由于其崗位的職責范圍廣，所需要具備的能力也較多，事情也相對較“雜”。
往往在有限的腦容量當中，要完美地做好每一件事，是極其有難度的。
不知道朋友們是否在產(chǎn)品工作當中有沒有遇到這類問題：
- 產(chǎn)品文檔寫完，自己審視后沒問題（自認為沒問題），評審的時候“舌戰(zhàn)群儒”，搞得心力交瘁！
- 產(chǎn)品文檔寫完，評審也順利通過，但實際開發(fā)當中，還是遇到了需求變更！
- 產(chǎn)品文檔寫完，需求也順利開發(fā)了，但推向市場，卻發(fā)現(xiàn)用戶不買賬？
- 產(chǎn)品文檔寫完，需求順利開發(fā)，用戶也用了一段時間，數(shù)據(jù)分析的時候發(fā)現(xiàn)，效果極差！
看完上述四點，相信每一個產(chǎn)品朋友都會有或多或少這類的問題。（是讀心高手阿境了）
所以就需要有個規(guī)范，在做產(chǎn)品當中，也需要有份自查表，能夠清楚每一篇文檔每一個需求是否清晰準確。
做好每一個需求，不管大小，都是非常重要的。而每一點需求也都是每一個產(chǎn)品人最初接觸產(chǎn)品崗的工作內(nèi)容之一，但也是極其重要。
（有一說一，有蠻大部分產(chǎn)品人沒辦法面面俱到地寫好一個需求）
阿境在這篇文章當中所說的產(chǎn)品自查表，主要指的是需求文檔的產(chǎn)品自查。深感需求的重要性，于是乎整理了這份產(chǎn)品自查表，望能夠給到各位產(chǎn)品朋友一點啟發(fā)（強烈建議收藏！）
簡單來說，文章適用于以下幾類朋友：
- 還不明白產(chǎn)品自查的重要性，目前在“野生”地寫文檔。
- 意識到目前產(chǎn)品需求文檔不完善而造成的問題后果，但沒有行動，想要有規(guī)范的產(chǎn)品自查流程。
- 已經(jīng)在逐步搭建自身的產(chǎn)品自查表，但卻并不完善，想了解其他人的產(chǎn)品自查。
當然，產(chǎn)品自查表并不局限于產(chǎn)品需求自查，還包括產(chǎn)品項目流程自查，產(chǎn)品調(diào)研自查等等，阿境對于這些，會簡單先概括下，這部分更詳細的內(nèi)容，后續(xù)阿境會持續(xù)整理，再分享給朋友們。
阿境會以兩個方面來闡述產(chǎn)品自查表，第一個是宏觀角度的自查，主要指產(chǎn)品整體全局；一個是微觀角度的自查，主要針對產(chǎn)品需求文檔（這個是重點！）。
另附上本文導(dǎo)圖框架，節(jié)約時間。若您感興趣，可繼續(xù)深入閱讀；若不感興趣，感謝光臨。
一、什么是產(chǎn)品自查表？
什么是產(chǎn)品自查表？顧名思義，自查表也就是checklist文檔，是一份給到產(chǎn)品崗的朋友來驗證自身產(chǎn)品的規(guī)劃是否合適、妥當?shù)谋砀瘛?/p>
當然，格式并不局限于表格，僅僅是以表格的形式來展示。
二、產(chǎn)品自查表的作用
講作用之前，給大家講個故事：
A：“你細心嗎？”
B：“超細心好吧！人送外號[心細如塵廈門吳彥祖]”
A：“好的，寫一份需求文檔看看”
n分鐘，寫完后小A審閱…..
A：“你這叫哪門子細心？”
沒錯，這真是比悲傷更悲傷的故事，當中的小B就是曾經(jīng)的阿境。（不堪回首）
許多人自認為自己做產(chǎn)品的合格及細心，僅僅局限于“自認為”而已。
產(chǎn)品經(jīng)理是一個比較吃經(jīng)驗的崗位（當然，也并不是年限越多越厲害，因人而異）；這里所指的經(jīng)驗主要是針對于產(chǎn)品的定義及對細節(jié)的執(zhí)行程度。
年輕的產(chǎn)品經(jīng)理往往拿到一個需求洋洋灑灑地敲打鍵盤，毫無考慮；而有經(jīng)驗的產(chǎn)品經(jīng)理則是經(jīng)過深思熟慮之后再開始進展。
什么是差距，這就是差距！
話說回來，產(chǎn)品自查表表面上是一張表，一個導(dǎo)圖，但實際上是一名產(chǎn)品經(jīng)理對于細節(jié)的把控程度，一名好的產(chǎn)品經(jīng)理腦子里面已經(jīng)有一份自身的產(chǎn)品自查表。
在產(chǎn)品想法還沒完成之前，它能夠幫助產(chǎn)品經(jīng)理思考需求的可行性及必要性；在產(chǎn)品正在規(guī)劃當中，它能夠幫助產(chǎn)品經(jīng)理梳理清楚產(chǎn)品業(yè)務(wù)及細節(jié)；在產(chǎn)品規(guī)劃后正在落地，它能夠幫助產(chǎn)品經(jīng)理規(guī)范進行查缺補漏，復(fù)盤思考。
那么，產(chǎn)品自查表有用嗎？阿境認為對于大部分產(chǎn)品經(jīng)理都是有用的，減少與開發(fā)的撕X，與老板的爭論，思考清楚產(chǎn)品及需求的細節(jié)。
認清產(chǎn)品，寫好需求實在是太太太太太重要了?。ㄊ÷訬個太）
噢對，一份適合自身的產(chǎn)品自查表能夠讓你瞬間變專業(yè)，工作瞬間變輕松！
所以，阿境姑且稱為這份產(chǎn)品自查表為“讓你瞬間變專業(yè)工作瞬間變輕松的產(chǎn)品自查表”。（別問，問就是標題瞎取的）
三、產(chǎn)品自查表內(nèi)容
在產(chǎn)品自查表內(nèi)容部分，阿境分為兩部分，一是產(chǎn)品整體自查，是站在宏觀角度來思考產(chǎn)品，主要適用在產(chǎn)品想法的階段；二是產(chǎn)品需求文檔自查，是站在微觀角度上，思考一份文檔是否嚴謹、細節(jié)流程是否得當，主要適用在產(chǎn)品規(guī)劃中及規(guī)劃后。
1. 產(chǎn)品整體自查
對于產(chǎn)品整體自查，主要考慮的是產(chǎn)品的市場可行性、需求可拓展性等因素。是以一個宏觀的角度來思考產(chǎn)品本身。
由于本文著重描述的是產(chǎn)品需求文檔的自查，故該部分僅簡單講述下。
- 產(chǎn)品的受眾人群是誰？
- 產(chǎn)品的定位是什么？
- 產(chǎn)品的核心功能是什么？
- 產(chǎn)品與其他競品的核心競爭點？
- 產(chǎn)品是否滿足了各個場景下用戶的需求？
- 在做需求之前，是否有進行需求調(diào)研（包括競品分析）？
- 在做需求之前，是否了解需求包含功能所涉及的業(yè)務(wù)？
- 在做需求之前，是否了解需求包含功能所涉及的歷史邏輯？
- 產(chǎn)品要完成的目標是什么？
- ……
整體自查更多的是在產(chǎn)品想法誕生的時候來進行自查，只有想清楚了大方向是否正確，才不會造成“南轅北轍”。
2. 產(chǎn)品需求文檔自查
產(chǎn)品需求文檔的自查部分，從第1點到10點更多的也是站在文檔的宏觀部分，而第11到第23點則是針對于需求當中的細節(jié)規(guī)范自查，涉及到產(chǎn)品的功能模塊，例如文案、數(shù)據(jù)、彈窗、輪播圖、圖片等等。
（1）需求階段
在需求階段，通常會出現(xiàn)的問題是“你認為你想清楚了需求的場景、對用戶側(cè)的作用、對產(chǎn)品的影響等”，但其實沒有深入全面，最后導(dǎo)致需求做出來了，沒人用亦或者是用了效果不好的情況發(fā)生，由此可見，深入思考需求是極其重要的。
- 是誰在什么樣的場景下產(chǎn)生的什么訴求，希望用什么方法解決什么問題？
- 是否需要進一步調(diào)研相關(guān)用戶/需求提出方，是否需要數(shù)據(jù)佐證？
- 是否符合當前核心業(yè)務(wù)場景、是否符合用戶畫像和用戶故事？
- 是否存在類似競品，是否完成競品分析？
- 當前方案是否是同類場景下的共性訴求？
- 對核心用戶的影響程度，盡可能量化。
- 對核心業(yè)務(wù)的貢獻程度，盡可能量化。
- 當前技術(shù)是否可以支持
- 當前業(yè)務(wù)是否可以支持
- 是否存在關(guān)聯(lián)功能的改造點？
- 是否完整梳理當前規(guī)劃內(nèi)容下線后的影響點？
- 是否已預(yù)估業(yè)務(wù)高峰數(shù)據(jù)爆發(fā)量級，及其處理措施？
- 是否已計劃好功能上線后的驗證方法？
- 是否引發(fā)諸如騷擾、欺詐等安全隱患？
- 是否存在負面輿情風險？
- 是否存在法律及合規(guī)風險？
- 用戶覆蓋度
- 使用頻率
- 對核心場景的影響
- 實際收益的高低
- 對KPI的影響
- 實現(xiàn)難度的高低
- 產(chǎn)品成長時機
（2）整體框架設(shè)計階段
在整體框架設(shè)計的階段，更多的是站在一個全局的角度，可以理解為樹木的枝干，通過這些用戶能夠清晰地感知到產(chǎn)品的清晰度及易用性。
- 設(shè)計時是否結(jié)合了用戶畫像、用戶習慣、業(yè)務(wù)場景等因素。
- 架構(gòu)層次是否清晰，是否足夠扁平，是否容易能使用戶理解。
- 所有信息均需要進行重要級評定，以決定在界面和功能中的重要程度。
- 信息分類是否合理，一定要“高內(nèi)聚，低耦合”。
- 架構(gòu)拓展性是否足夠大，后續(xù)對信息模塊進行增刪改查時，是否容易施行。
（3）流程設(shè)計階段
產(chǎn)品流程主要指的是業(yè)務(wù)流程部分，整體產(chǎn)品業(yè)務(wù)是重中之重，了解業(yè)務(wù)后再了解產(chǎn)品。拆分現(xiàn)有業(yè)務(wù)流程，持續(xù)優(yōu)化它，排除不合理的流程走向，同時通過業(yè)務(wù)流程也能夠探索現(xiàn)有問題。
- 流程設(shè)計是否結(jié)合了用戶畫像、用戶習慣、業(yè)務(wù)場景、競品等因素。
- 主干流程是否最簡化，是否覆蓋了足夠多的場景。
- 是否有特殊流程（分支流程、逆向流程）
- 是否有異常流程
- 是否歸納出所有的操作節(jié)點、數(shù)據(jù)交互點。
- 操作節(jié)點是否足夠精簡易理解。
- 是否考慮了操作節(jié)點的容錯性（二次確認、撤銷操作）
- 數(shù)據(jù)交互點是否依賴其它系統(tǒng)。
- 特殊、異常流程是否需要增加切換流程的引導(dǎo)，避免流程斷頭。
- 相關(guān)流程的用戶體驗路徑是否一致
- 各圖形形狀/字號統(tǒng)一。重點內(nèi)容可特殊標識，關(guān)鍵節(jié)點增加注釋說明
- 流程均以開始框開始，以結(jié)束框結(jié)束，避免斷頭風險。
- 流程圖從左到右、從上到下排列。
- 流程圖從左到右、從上到下排列。
- 流程完成后是否進行了場景驗證，是否符合用戶預(yù)期。
（4）需求文檔設(shè)計階段
需求文檔設(shè)計階段時，是整體文檔的自查，關(guān)于流程、文檔文案、名詞、場景、信息等大方向進行的把控。
- 完整流程是否可形成閉環(huán)？
- 逆向功能流程是否可逆，如果逆向操作，是否考慮對應(yīng)的機制：比如退款、退貨操作
- 各個步驟可能出現(xiàn)預(yù)期外的情況。
- 歧義需求文檔的語法、功能文案、名詞是否易懂，是否存在歧義。
- 兼容是否存在兼容問題：不同業(yè)務(wù)人員對功能都能接受嗎？各個系統(tǒng)之間兼容嗎？新舊功能的兼容嗎（比如歷史數(shù)據(jù)要不要初始化）？
- 備用是否有備用方案，次級選項。比如當正常流程無法傳輸?shù)臅r候，是否可以用導(dǎo)入的機制救急。業(yè)務(wù)高峰的系統(tǒng)，是否有降級處理邏輯。
- 窮盡業(yè)務(wù)場景和可能原因是否窮舉完畢。
- 脫敏是否存在敏感信息，是否有脫敏機制。
- 文案描述切記要精確，“可能”、“也許”、“大概”等模糊性詞語避免出現(xiàn)。
- 不是本需求的功能避免加入文檔中，給開發(fā)、測試人員造成干擾
（5）特殊因素
特殊因素主要列舉的是一些客觀因素（例如手機系統(tǒng)、賬號、網(wǎng)絡(luò)等外在情況）的問題，由于其大部分脫離產(chǎn)品本身功能，是一個輔助的作用，容易被產(chǎn)品朋友忽略。
- 是否存在不同登錄狀態(tài)下展示內(nèi)容或操作有不同（登錄、未登錄、帳號異常狀態(tài)）
- 是否存在不同用戶狀態(tài)下展示內(nèi)容或操作有不同（非會員、不同等級的會員，特殊付費會員等）
- 是否考慮多賬號切換，切換時，本地緩存數(shù)據(jù)是否需要同步清空。
- 是否允許多終端同時登錄一帳號，若允許，操作同一數(shù)據(jù)時是否產(chǎn)生沖突。
- WiFi網(wǎng)絡(luò)、移動網(wǎng)絡(luò)（4G）
- 集團局域網(wǎng)、公共網(wǎng)絡(luò)
- 連接超時，多久為超時
- 網(wǎng)絡(luò)顯示什么內(nèi)容？是否給予用戶友好引導(dǎo)檢查網(wǎng)絡(luò)或重試按鈕。
- 網(wǎng)絡(luò)變化從WiFi到4G網(wǎng)絡(luò)環(huán)境時是否需要提示
- 服務(wù)器出問題返回數(shù)據(jù)失敗時，是否給予用戶友好提示或重試按鈕
- 橫豎屏是否有橫屏展示的需要，如不需要需要鎖定豎屏
- 分辨率高低：分辨率情況下是否會有適配問題，是否備注清楚。
- SD卡Android手機，沒有SD卡、SD卡存儲已滿、存儲位置等情況是否考慮并備注。
- 硬件不同，手機物理按鍵的不同衍生不同操作。
- 系統(tǒng)版本的不同是否同步支持，iOS、Android、Windows及其不同版本
- 定位提示是否打開定位
- 相機提示是否打開相機
- 閃光燈提示是否調(diào)用閃光燈
- 藍牙提示是否打開藍牙
- 設(shè)備數(shù)據(jù)是否需要調(diào)用，步數(shù)、心率等，主要在iOS設(shè)備中。
- 夜間日間模式是否考慮光線較暗的場景。
- 編輯模式下出現(xiàn)意外情況是否提示保存或自動保存已填信息。
- 無痕模式：不記錄用戶所有操作信息（實際是否記錄根據(jù)數(shù)據(jù)需求來看）
- 無圖模式：節(jié)約用戶流量，加快頁面加載速度。
（6）賬號狀態(tài)及用戶權(quán)限自查
- 不同賬號狀態(tài)說明：登錄狀態(tài)、非登錄狀態(tài)不同情況是否說明完整？
- 不同用戶等級和權(quán)限說明，不同等級用戶有哪些權(quán)限？在頁面展示上有什么不同？
- 不同賬號狀態(tài)切換時是否有特殊展示？
- 不同賬號狀態(tài)切換時是否有特殊展示？
- 是否考慮多賬號切換問題？
- 是否支持第三方賬號登錄？
（7）設(shè)備相關(guān)
- 是否支持橫豎屏操作；檢查不同屏幕效果
- 不同分辨率下的適配問題，是否有空白溢出變形
- 操作過程是否有卡頓
（8）特殊場景
- 網(wǎng)絡(luò)加載慢情況下無圖顯示效果
- 考慮夜間模式下的展示效果
- 區(qū)分編輯模式下可變更內(nèi)容的權(quán)限
（9）全局
- 修改頁面時，考慮在系統(tǒng)中其余地方是否也有相同的業(yè)務(wù)，是否需要修改？
- 全局控件樣式是否具有一致性
- 全局控件交互行為是否具有一致性
- 是否周全地考慮了所有操作成功的反饋。
- 是否周全地考慮了所有操作失敗的反饋。
- 控件觸發(fā)的提示類型是否恰當（小紅點、Toast、彈窗）
（10）版本發(fā)布自查
- 確認完需求之后，要告知運營同事們有哪些新功能，何時能交付版本，這樣方便運營童鞋們也好對應(yīng)的落實相關(guān)的運營工作。如果運營的部分/全部工作也是PM干的話，那么自己心里要有數(shù)；
- 該版本開始就要落實是否要做新的應(yīng)用商店圖、新的歡迎頁、新的功能引導(dǎo)頁，并且相應(yīng)的安排人手。在上線前3天最好再確認一下，萬一有漏，也有時間能再補；注意：針對這三個東西，都有相應(yīng)的文案要出；
- 確認這個項目中沒有完成的需求或者中途協(xié)商修改的需求，都已經(jīng)被記錄下來，并且最好開始確認沒有解決的需求怎么辦，修改的需求怎么辦的問題；
- 確認該新功能的埋點列表是否給出；
- 確認新功能帶來的相關(guān)新數(shù)據(jù)的查看地方以及方法，這里會涉及一些常用的統(tǒng)計平臺；
- 確認新功能帶來的后臺新的管理模塊使用或者從某個地方切換到另一個地方的使用方法的切換，培訓過相關(guān)人員，并且已經(jīng)正確掌握；
- 確認提交給應(yīng)用商店的新功能文案是否有出；
- 確認最終提交給應(yīng)用商店的應(yīng)用商店圖、新功能介紹更新了；
- 確認各個渠道中的最新版確實為最新版本；
- 每個版本都要觀察上個版本的埋點數(shù)據(jù)是否正常，及時發(fā)現(xiàn)是否打錯點，進行及時修正，避免數(shù)據(jù)浪費；
（11）按鈕
- 按鈕文字是寫死還是服務(wù)端配置
- 是否有默認的按鈕文案
- 按鈕文字的字數(shù)超過了怎么辦
- 按鈕的樣式是否有特殊樣式？若有，什么情況下會觸發(fā)特殊樣式（例如帶icon情況與不帶icon情況）
- 考慮點擊按鈕后的情況（頁面不變/跳轉(zhuǎn)到其他頁面…..）
- 點擊按鈕后出現(xiàn)的情況是否會與頁面其他情況沖突，如何處理（例如點擊按鈕出現(xiàn)浮窗，與其他浮窗重疊，則需要考慮浮窗優(yōu)先級）
（12）內(nèi)容型文案
- 內(nèi)容是靜態(tài)的or動態(tài)調(diào)用
- 內(nèi)容描述是否完整？頂部標題，按鈕里的文字等
- 內(nèi)容加載方式描述是否完整？本地緩存or加載網(wǎng)絡(luò)刷新內(nèi)容等
- 輸入型內(nèi)容是否完整？是否有初始內(nèi)容？
- 內(nèi)容違禁如何處理？敏感詞，違禁內(nèi)容等如何處理？
- 數(shù)據(jù)內(nèi)容為空時如何處理
- 內(nèi)容長度是否有限制
- 數(shù)據(jù)內(nèi)容過期or刪除or違禁后如何展示？
- 用戶內(nèi)容輸入是否描述完整？
（13）描述型文案
- 必填or非必填
- 若為非必填，則界面樣式如何
- 定義文案的行數(shù)or字數(shù)
- 文案的截斷策略是否考慮？超過字數(shù)or行數(shù)如何展示處理（例如超過兩行，超出部分“…”展示）
- 出現(xiàn)同一場景時，提示文案是否保持一致？
- 文案由服務(wù)端控制還是客戶端？
- 是否有默認文案？
- 是否易理解？是否有歧義？是否有錯別字？
（14）輸入型文字
- 輸入文字前是否有默認值， 是否有輸入提示。
- 輸入框內(nèi)容為空時如何顯示？
- 輸入框獲得焦點時，默認文字是消失（即僅作為提示文字或占位符）還是保留（即作為可編輯的默認文案）？
- 獲得焦點后，調(diào)取的鍵盤類型（數(shù)字鍵盤、英文鍵盤等）
- 輸入焦點丟失和存在時是否有展示內(nèi)容的差異。
- 輸入文字是否存在極限長度或最低長度。
- 輸入文字是否可存在特殊字符，若用戶輸入如何處理。
- 輸入文字是否存在對敏感詞（密碼、存款金額等）、違禁詞的禁用或過濾展示。
- 輸入文字后是否需要一鍵清空操作。（加個一鍵清空的按鈕等）
- 輸入文字后是否顯示輔助結(jié)果（輔助詞），輔助詞的搜索規(guī)則。
- 輸入文字后遇到流程打斷的情況是否保留輸入記錄（斷網(wǎng)、離開當前頁面或關(guān)閉瀏覽器等）
- 是否說明了鍵盤喚起后需要頁面的滾動來避免輸入框的遮擋（移動端）
（15）輸入型圖片
- 是否強制要求上傳圖片的必須參數(shù)（尺寸、格式、大小等）
- 是否設(shè)置了不符合尺寸的提示，圖片過大或過小，格式錯誤等。
- 是否提供上傳完成圖片的預(yù)覽。
- 是否提供了再次編輯操作，引導(dǎo)是否明顯。
- 上傳失敗的情況是否給予用戶提示，引導(dǎo)再次上傳。
- 上傳完成后遇到流程打斷的情況是否保留已上傳的記錄（斷網(wǎng)、離開當前頁面或關(guān)閉瀏覽器等）
（16）頁面跳轉(zhuǎn)
- 頁面跳轉(zhuǎn)流程是否完整順暢，流程中間是否有頁面缺失
- 頁面跳轉(zhuǎn)是否有提示和引導(dǎo)說明
- 頁面跳轉(zhuǎn)加載的loading展示是否友好
- 頁面跳轉(zhuǎn)動作是否有跳轉(zhuǎn)特效
- 頁面跳轉(zhuǎn)的方式是什么，點擊？滑動？等
- 頁面加載不出來或者報錯時展示什么內(nèi)容
- 頁面點擊過程中是否包含權(quán)限限制，如果有如何提示
- 頁面跳轉(zhuǎn)盡量要減少跳轉(zhuǎn)次數(shù)，縮短用戶操作流程，盡可能在一個頁面內(nèi)完成
- 一個頁面內(nèi)是否有功能冗余的內(nèi)容
- 頁面跳轉(zhuǎn)時是否需要進行輔助性說明
（17）標簽
- 標簽是系統(tǒng)做的還是用戶標記上傳的
- 標簽下的列表展示（回歸到列表的問題即可）
- 用戶是否可自定義上傳標簽
- 用戶上傳標簽后是否可修改、刪除
- 用戶上傳的標簽，考慮敏感詞庫
- 標簽是寫死還是服務(wù)端配置
- 是否必填
- 是否有默認的標簽
- 標簽的內(nèi)容是文字還是圖片？
- 標簽的文字是否有字數(shù)限制？
- 標簽的個數(shù)是單個還是多個，多個的話考慮優(yōu)先級排序
- 標簽個數(shù)多個的情況，是否會遮擋住頁面其他元素（例如，多個可以收納起來處理）
- 多種類型的標簽，對類型進行排序
- 多種類型的標簽，出現(xiàn)重復(fù)的情況（一般做去重處理）
- 后臺：是否必填、標簽名（是否限制字數(shù)）、標簽內(nèi)容（文字/圖片）、排序（是否有默認值，越大排越前）、是否顯示、標簽個數(shù)、快捷的標簽配置
（18）列表
- 列表的排序如何？
- 列表中的元素是否都定義清楚？
- 列表中涉及的數(shù)據(jù)來源定義
- 列表數(shù)據(jù)為空時的展現(xiàn)形式
- 若部分元素為后臺配置，則配置前后的情況定義
- 列表的數(shù)據(jù)是否分頁展示？還是一次性加載？單頁展示的數(shù)量是否有限制
（19）數(shù)據(jù)
- 數(shù)據(jù)的來源（具體后臺的哪個地方）
- 展示數(shù)據(jù)是否使用的是服務(wù)器數(shù)據(jù)，或使用的是本地緩存（客戶端）數(shù)據(jù)？
- 展示數(shù)據(jù)是否是初次加載讀取的靜態(tài)數(shù)據(jù)，或?qū)崟r、定時展示的動態(tài)數(shù)據(jù)。
- 數(shù)據(jù)未加載出來前展示什么？
- 是否規(guī)劃數(shù)據(jù)為空時的展示效果
- 數(shù)據(jù)的極值情況（為0的情況，最大值的情況）
- 數(shù)據(jù)長度是否有限制？是否規(guī)劃數(shù)據(jù)字數(shù)超長展示效果（幾位小數(shù)點，超出如何展示）
- 若為多個數(shù)據(jù)，則數(shù)據(jù)的排序如何？
- 是否選取全部數(shù)據(jù)or部分數(shù)據(jù)？（數(shù)據(jù)根據(jù)什么搜索規(guī)則篩選出來的）
- 對過期的緩存數(shù)據(jù)是否需要告知用戶刷新（活動過期）
- 前置場景的不同是否對當前展示數(shù)據(jù)產(chǎn)生影響，不同場景是否需要展示不同數(shù)據(jù)。
- 移動端從后臺喚醒應(yīng)用時，是否需要刷新當前頁面數(shù)據(jù)。
- 數(shù)據(jù)在什么條件下進行展示？
- 數(shù)據(jù)是否分頁展示？
- 數(shù)據(jù)去重策略如何？
- 什么時候開始請求數(shù)據(jù)？
- 什么情況下觸發(fā)更新數(shù)據(jù)？
- 數(shù)據(jù)更新頻次？是定時更新還是實時更新？
- 是否有部分數(shù)據(jù)需要過濾掉不展示？是否對特殊內(nèi)容進行過濾、標記（敏感、違禁的詞語）
- 當數(shù)據(jù)被刪除后，展示的狀態(tài)如何？
- 過期的緩存數(shù)據(jù)如何處理（定時清理還是繼續(xù)保存）？
（20）彈窗
- 什么時候觸發(fā)彈窗？
- 什么時候彈窗消失？（關(guān)閉按鈕、返回按鈕、手機系統(tǒng)返回按鈕、點擊頁面空白處等）
- 彈窗內(nèi)的元素（文案、跳轉(zhuǎn)等）是否都定義清楚
- 是否每次滿足條件都觸發(fā)彈窗？還是只彈一次？
- 若該彈窗與其他彈窗同時滿足條件觸發(fā)，則優(yōu)先級如何？
（21）輪播圖
- 圖片數(shù)據(jù)為后臺配置or客戶端寫死？
- 圖片排序如何？
- 點擊是否有跳轉(zhuǎn)？跳轉(zhuǎn)頁面為內(nèi)部鏈接or外部鏈接？
- 輪播的頻次如何？
（22）圖片上傳
- 是否有圖片尺寸、像素、格式的要求
- 是否有上傳張數(shù)的限制及張數(shù)限制的提示
- 是否提供上傳的圖片預(yù)覽
- 是否有上傳成功后可以再次編輯上傳
- 上傳失敗如何處理及引導(dǎo)提示如何展示
- 上傳過程遇到突然中斷情況是否保存上傳記錄
（23）數(shù)據(jù)埋點
- 數(shù)據(jù)埋點的字段內(nèi)容及展示類型是否完整
- 數(shù)據(jù)埋點的時間范圍和時間段是什么
- 上線后驗證的數(shù)據(jù)是否都進行了埋點記錄
- 是否需要進行數(shù)據(jù)漏斗模型分析報表生成
- 埋點數(shù)據(jù)后續(xù)如何提取出來
- 是否有自動通知機制，通知形式是什么
- 據(jù)埋點不成功是否有報警機制
四、如何來做產(chǎn)品自查？
當我們擁有了產(chǎn)品自查表之后，要做的就是在遇到每一個需求，撰寫每一份產(chǎn)品文檔的時候，將自查表運用到當中去。
敲黑板，說重點了！打瞌睡的同學醒醒，這段聽完再睡~
阿境總結(jié)了一句話：先總后分，模塊劃分，按序核查，勿忘更新。
“阿境你又說出這么抽（zhe）象（li）的東西了，說人話行不行？”
不說點大家覺得高（ting）大（bu）上（dong）的話，能是廈門吳彥祖嗎？
（沒錯，第一厚臉皮也是阿境本境）
好了，不廢話，啥意思？簡單來說，分成四步：
- 先總后分：先按照宏觀的角度來審視整篇文檔，查看文檔的整體方向是否正確，文檔的結(jié)構(gòu)是否無誤，暫時先不考慮細節(jié)。等到總體方向沒問題了之后，再去查看查看文檔的分支細節(jié)。
- 模塊劃分：根據(jù)模塊來進行文檔的撰寫，有個大忌就是在A模塊寫到了B模塊的內(nèi)容定義，文檔容易造成不易閱讀，冗長，劃分好文檔的模塊并且對文檔進行相應(yīng)的模塊定義，一個清晰的模塊就好比是樹木的枝干，能夠提升文檔的可讀性。
- 按序核查：當進行第二步模塊劃分之后，為的便是更好地進行順序的核查，例如產(chǎn)品需求、業(yè)務(wù)流程、功能主次關(guān)系、功能布局、模塊狀態(tài)等等順序進行一一校對。
- 勿忘更新：有了這份文檔，并不是一蹴而就的，時代在更新，產(chǎn)品在更新，自然，產(chǎn)品自查表也需要不斷更新。這份自查表是阿境在自身實踐當中總結(jié)而出，可以看出，產(chǎn)品的理論大多源于實踐，脫離實踐則無從談起。所以，朋友們可實踐當中，不斷完善這份產(chǎn)品自查表，一句話：沒有最完美的，只有適合自己的。
寫在最后
做產(chǎn)品是一個并不那么容易的活，寫一份合格的需求文檔也不是那么輕松的事情。為了確保產(chǎn)品能夠“活下來”，確保需求文檔能夠嚴謹、詳盡、完善，這份產(chǎn)品自查表希望能夠幫助到各位朋友。
但有一點要記住，產(chǎn)品自查表起到的作用是錦上添花，并不是雪中送炭。它是建立在有一定產(chǎn)品思考方向的前提之下。
同時阿境也想拋磚引玉，以這份產(chǎn)品自查表來提醒各位朋友，需要有核查、糾錯、校對的意識，對產(chǎn)品對需求保持敬畏之心，才能夠做好產(chǎn)品。
最后，愿天下沒有難寫的需求文檔。
作者：阿境，產(chǎn)品界的吳彥祖，一個沉穩(wěn)又不沉悶的男人。野蠻生長，產(chǎn)品汪一枚，做過電商、醫(yī)療、教育行業(yè)項目，現(xiàn)4399產(chǎn)品經(jīng)理。堅信”產(chǎn)品源于生活”，歡迎交流。公眾號：夢想家阿境
本文由@阿境 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議
更多精彩內(nèi)容，請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
編輯導(dǎo)讀：對于產(chǎn)品經(jīng)理來說，由于平時的工作比較繁瑣，在產(chǎn)品工作中容易對一些細節(jié)有所遺漏，這樣會導(dǎo)致需求反復(fù)和研發(fā)資源的浪費。本文作者從自身工作實踐出發(fā)，對產(chǎn)品各階段需要自查的問題進行了梳理總結(jié)，制作了一份產(chǎn)品自查表，供大家一同參考學習。
產(chǎn)品經(jīng)理在日常工作當中，由于其崗位的職責范圍廣，所需要具備的能力也較多，事情也相對較“雜”。
往往在有限的腦容量當中，要完美地做好每一件事，是極其有難度的。
不知道朋友們是否在產(chǎn)品工作當中有沒有遇到這類問題：
- 產(chǎn)品文檔寫完，自己審視后沒問題（自認為沒問題），評審的時候“舌戰(zhàn)群儒”，搞得心力交瘁！
- 產(chǎn)品文檔寫完，評審也順利通過，但實際開發(fā)當中，還是遇到了需求變更！
- 產(chǎn)品文檔寫完，需求也順利開發(fā)了，但推向市場，卻發(fā)現(xiàn)用戶不買賬？
- 產(chǎn)品文檔寫完，需求順利開發(fā)，用戶也用了一段時間，數(shù)據(jù)分析的時候發(fā)現(xiàn)，效果極差！
看完上述四點，相信每一個產(chǎn)品朋友都會有或多或少這類的問題。（是讀心高手阿境了）
所以就需要有個規(guī)范，在做產(chǎn)品當中，也需要有份自查表，能夠清楚每一篇文檔每一個需求是否清晰準確。
做好每一個需求，不管大小，都是非常重要的。而每一點需求也都是每一個產(chǎn)品人最初接觸產(chǎn)品崗的工作內(nèi)容之一，但也是極其重要。
（有一說一，有蠻大部分產(chǎn)品人沒辦法面面俱到地寫好一個需求）
阿境在這篇文章當中所說的產(chǎn)品自查表，主要指的是需求文檔的產(chǎn)品自查。深感需求的重要性，于是乎整理了這份產(chǎn)品自查表，望能夠給到各位產(chǎn)品朋友一點啟發(fā)（強烈建議收藏！）
簡單來說，文章適用于以下幾類朋友：
- 還不明白產(chǎn)品自查的重要性，目前在“野生”地寫文檔。
- 意識到目前產(chǎn)品需求文檔不完善而造成的問題后果，但沒有行動，想要有規(guī)范的產(chǎn)品自查流程。
- 已經(jīng)在逐步搭建自身的產(chǎn)品自查表，但卻并不完善，想了解其他人的產(chǎn)品自查。
當然，產(chǎn)品自查表并不局限于產(chǎn)品需求自查，還包括產(chǎn)品項目流程自查，產(chǎn)品調(diào)研自查等等，阿境對于這些，會簡單先概括下，這部分更詳細的內(nèi)容，后續(xù)阿境會持續(xù)整理，再分享給朋友們。
阿境會以兩個方面來闡述產(chǎn)品自查表，第一個是宏觀角度的自查，主要指產(chǎn)品整體全局；一個是微觀角度的自查，主要針對產(chǎn)品需求文檔（這個是重點！）。
另附上本文導(dǎo)圖框架，節(jié)約時間。若您感興趣，可繼續(xù)深入閱讀；若不感興趣，感謝光臨。
一、什么是產(chǎn)品自查表？
什么是產(chǎn)品自查表？顧名思義，自查表也就是checklist文檔，是一份給到產(chǎn)品崗的朋友來驗證自身產(chǎn)品的規(guī)劃是否合適、妥當?shù)谋砀瘛?/p>
當然，格式并不局限于表格，僅僅是以表格的形式來展示。
二、產(chǎn)品自查表的作用
講作用之前，給大家講個故事：
A：“你細心嗎？”
B：“超細心好吧！人送外號[心細如塵廈門吳彥祖]”
A：“好的，寫一份需求文檔看看”
n分鐘，寫完后小A審閱…..
A：“你這叫哪門子細心？”
沒錯，這真是比悲傷更悲傷的故事，當中的小B就是曾經(jīng)的阿境。（不堪回首）
許多人自認為自己做產(chǎn)品的合格及細心，僅僅局限于“自認為”而已。
產(chǎn)品經(jīng)理是一個比較吃經(jīng)驗的崗位（當然，也并不是年限越多越厲害，因人而異）；這里所指的經(jīng)驗主要是針對于產(chǎn)品的定義及對細節(jié)的執(zhí)行程度。
年輕的產(chǎn)品經(jīng)理往往拿到一個需求洋洋灑灑地敲打鍵盤，毫無考慮；而有經(jīng)驗的產(chǎn)品經(jīng)理則是經(jīng)過深思熟慮之后再開始進展。
什么是差距，這就是差距！
話說回來，產(chǎn)品自查表表面上是一張表，一個導(dǎo)圖，但實際上是一名產(chǎn)品經(jīng)理對于細節(jié)的把控程度，一名好的產(chǎn)品經(jīng)理腦子里面已經(jīng)有一份自身的產(chǎn)品自查表。
在產(chǎn)品想法還沒完成之前，它能夠幫助產(chǎn)品經(jīng)理思考需求的可行性及必要性；在產(chǎn)品正在規(guī)劃當中，它能夠幫助產(chǎn)品經(jīng)理梳理清楚產(chǎn)品業(yè)務(wù)及細節(jié)；在產(chǎn)品規(guī)劃后正在落地，它能夠幫助產(chǎn)品經(jīng)理規(guī)范進行查缺補漏，復(fù)盤思考。
那么，產(chǎn)品自查表有用嗎？阿境認為對于大部分產(chǎn)品經(jīng)理都是有用的，減少與開發(fā)的撕X，與老板的爭論，思考清楚產(chǎn)品及需求的細節(jié)。
認清產(chǎn)品，寫好需求實在是太太太太太重要了?。ㄊ÷訬個太）
噢對，一份適合自身的產(chǎn)品自查表能夠讓你瞬間變專業(yè)，工作瞬間變輕松！
所以，阿境姑且稱為這份產(chǎn)品自查表為“讓你瞬間變專業(yè)工作瞬間變輕松的產(chǎn)品自查表”。（別問，問就是標題瞎取的）
三、產(chǎn)品自查表內(nèi)容
在產(chǎn)品自查表內(nèi)容部分，阿境分為兩部分，一是產(chǎn)品整體自查，是站在宏觀角度來思考產(chǎn)品，主要適用在產(chǎn)品想法的階段；二是產(chǎn)品需求文檔自查，是站在微觀角度上，思考一份文檔是否嚴謹、細節(jié)流程是否得當，主要適用在產(chǎn)品規(guī)劃中及規(guī)劃后。
1. 產(chǎn)品整體自查
對于產(chǎn)品整體自查，主要考慮的是產(chǎn)品的市場可行性、需求可拓展性等因素。是以一個宏觀的角度來思考產(chǎn)品本身。
由于本文著重描述的是產(chǎn)品需求文檔的自查，故該部分僅簡單講述下。
- 產(chǎn)品的受眾人群是誰？
- 產(chǎn)品的定位是什么？
- 產(chǎn)品的核心功能是什么？
- 產(chǎn)品與其他競品的核心競爭點？
- 產(chǎn)品是否滿足了各個場景下用戶的需求？
- 在做需求之前，是否有進行需求調(diào)研（包括競品分析）？
- 在做需求之前，是否了解需求包含功能所涉及的業(yè)務(wù)？
- 在做需求之前，是否了解需求包含功能所涉及的歷史邏輯？
- 產(chǎn)品要完成的目標是什么？
- ……
整體自查更多的是在產(chǎn)品想法誕生的時候來進行自查，只有想清楚了大方向是否正確，才不會造成“南轅北轍”。
2. 產(chǎn)品需求文檔自查
產(chǎn)品需求文檔的自查部分，從第1點到10點更多的也是站在文檔的宏觀部分，而第11到第23點則是針對于需求當中的細節(jié)規(guī)范自查，涉及到產(chǎn)品的功能模塊，例如文案、數(shù)據(jù)、彈窗、輪播圖、圖片等等。
（1）需求階段
在需求階段，通常會出現(xiàn)的問題是“你認為你想清楚了需求的場景、對用戶側(cè)的作用、對產(chǎn)品的影響等”，但其實沒有深入全面，最后導(dǎo)致需求做出來了，沒人用亦或者是用了效果不好的情況發(fā)生，由此可見，深入思考需求是極其重要的。
- 是誰在什么樣的場景下產(chǎn)生的什么訴求，希望用什么方法解決什么問題？
- 是否需要進一步調(diào)研相關(guān)用戶/需求提出方，是否需要數(shù)據(jù)佐證？
- 是否符合當前核心業(yè)務(wù)場景、是否符合用戶畫像和用戶故事？
- 是否存在類似競品，是否完成競品分析？
- 當前方案是否是同類場景下的共性訴求？
- 對核心用戶的影響程度，盡可能量化。
- 對核心業(yè)務(wù)的貢獻程度，盡可能量化。
- 當前技術(shù)是否可以支持
- 當前業(yè)務(wù)是否可以支持
- 是否存在關(guān)聯(lián)功能的改造點？
- 是否完整梳理當前規(guī)劃內(nèi)容下線后的影響點？
- 是否已預(yù)估業(yè)務(wù)高峰數(shù)據(jù)爆發(fā)量級，及其處理措施？
- 是否已計劃好功能上線后的驗證方法？
- 是否引發(fā)諸如騷擾、欺詐等安全隱患？
- 是否存在負面輿情風險？
- 是否存在法律及合規(guī)風險？
- 用戶覆蓋度
- 使用頻率
- 對核心場景的影響
- 實際收益的高低
- 對KPI的影響
- 實現(xiàn)難度的高低
- 產(chǎn)品成長時機
（2）整體框架設(shè)計階段
在整體框架設(shè)計的階段，更多的是站在一個全局的角度，可以理解為樹木的枝干，通過這些用戶能夠清晰地感知到產(chǎn)品的清晰度及易用性。
- 設(shè)計時是否結(jié)合了用戶畫像、用戶習慣、業(yè)務(wù)場景等因素。
- 架構(gòu)層次是否清晰，是否足夠扁平，是否容易能使用戶理解。
- 所有信息均需要進行重要級評定，以決定在界面和功能中的重要程度。
- 信息分類是否合理，一定要“高內(nèi)聚，低耦合”。
- 架構(gòu)拓展性是否足夠大，后續(xù)對信息模塊進行增刪改查時，是否容易施行。
（3）流程設(shè)計階段
產(chǎn)品流程主要指的是業(yè)務(wù)流程部分，整體產(chǎn)品業(yè)務(wù)是重中之重，了解業(yè)務(wù)后再了解產(chǎn)品。拆分現(xiàn)有業(yè)務(wù)流程，持續(xù)優(yōu)化它，排除不合理的流程走向，同時通過業(yè)務(wù)流程也能夠探索現(xiàn)有問題。
- 流程設(shè)計是否結(jié)合了用戶畫像、用戶習慣、業(yè)務(wù)場景、競品等因素。
- 主干流程是否最簡化，是否覆蓋了足夠多的場景。
- 是否有特殊流程（分支流程、逆向流程）
- 是否有異常流程
- 是否歸納出所有的操作節(jié)點、數(shù)據(jù)交互點。
- 操作節(jié)點是否足夠精簡易理解。
- 是否考慮了操作節(jié)點的容錯性（二次確認、撤銷操作）
- 數(shù)據(jù)交互點是否依賴其它系統(tǒng)。
- 特殊、異常流程是否需要增加切換流程的引導(dǎo)，避免流程斷頭。
- 相關(guān)流程的用戶體驗路徑是否一致
- 各圖形形狀/字號統(tǒng)一。重點內(nèi)容可特殊標識，關(guān)鍵節(jié)點增加注釋說明
- 流程均以開始框開始，以結(jié)束框結(jié)束，避免斷頭風險。
- 流程圖從左到右、從上到下排列。
- 流程圖從左到右、從上到下排列。
- 流程完成后是否進行了場景驗證，是否符合用戶預(yù)期。
（4）需求文檔設(shè)計階段
需求文檔設(shè)計階段時，是整體文檔的自查，關(guān)于流程、文檔文案、名詞、場景、信息等大方向進行的把控。
- 完整流程是否可形成閉環(huán)？
- 逆向功能流程是否可逆，如果逆向操作，是否考慮對應(yīng)的機制：比如退款、退貨操作
- 各個步驟可能出現(xiàn)預(yù)期外的情況。
- 歧義需求文檔的語法、功能文案、名詞是否易懂，是否存在歧義。
- 兼容是否存在兼容問題：不同業(yè)務(wù)人員對功能都能接受嗎？各個系統(tǒng)之間兼容嗎？新舊功能的兼容嗎（比如歷史數(shù)據(jù)要不要初始化）？
- 備用是否有備用方案，次級選項。比如當正常流程無法傳輸?shù)臅r候，是否可以用導(dǎo)入的機制救急。業(yè)務(wù)高峰的系統(tǒng)，是否有降級處理邏輯。
- 窮盡業(yè)務(wù)場景和可能原因是否窮舉完畢。
- 脫敏是否存在敏感信息，是否有脫敏機制。
- 文案描述切記要精確，“可能”、“也許”、“大概”等模糊性詞語避免出現(xiàn)。
- 不是本需求的功能避免加入文檔中，給開發(fā)、測試人員造成干擾
（5）特殊因素
特殊因素主要列舉的是一些客觀因素（例如手機系統(tǒng)、賬號、網(wǎng)絡(luò)等外在情況）的問題，由于其大部分脫離產(chǎn)品本身功能，是一個輔助的作用，容易被產(chǎn)品朋友忽略。
- 是否存在不同登錄狀態(tài)下展示內(nèi)容或操作有不同（登錄、未登錄、帳號異常狀態(tài)）
- 是否存在不同用戶狀態(tài)下展示內(nèi)容或操作有不同（非會員、不同等級的會員，特殊付費會員等）
- 是否考慮多賬號切換，切換時，本地緩存數(shù)據(jù)是否需要同步清空。
- 是否允許多終端同時登錄一帳號，若允許，操作同一數(shù)據(jù)時是否產(chǎn)生沖突。
- WiFi網(wǎng)絡(luò)、移動網(wǎng)絡(luò)（4G）
- 集團局域網(wǎng)、公共網(wǎng)絡(luò)
- 連接超時，多久為超時
- 網(wǎng)絡(luò)顯示什么內(nèi)容？是否給予用戶友好引導(dǎo)檢查網(wǎng)絡(luò)或重試按鈕。
- 網(wǎng)絡(luò)變化從WiFi到4G網(wǎng)絡(luò)環(huán)境時是否需要提示
- 服務(wù)器出問題返回數(shù)據(jù)失敗時，是否給予用戶友好提示或重試按鈕
- 橫豎屏是否有橫屏展示的需要，如不需要需要鎖定豎屏
- 分辨率高低：分辨率情況下是否會有適配問題，是否備注清楚。
- SD卡Android手機，沒有SD卡、SD卡存儲已滿、存儲位置等情況是否考慮并備注。
- 硬件不同，手機物理按鍵的不同衍生不同操作。
- 系統(tǒng)版本的不同是否同步支持，iOS、Android、Windows及其不同版本
- 定位提示是否打開定位
- 相機提示是否打開相機
- 閃光燈提示是否調(diào)用閃光燈
- 藍牙提示是否打開藍牙
- 設(shè)備數(shù)據(jù)是否需要調(diào)用，步數(shù)、心率等，主要在iOS設(shè)備中。
- 夜間日間模式是否考慮光線較暗的場景。
- 編輯模式下出現(xiàn)意外情況是否提示保存或自動保存已填信息。
- 無痕模式：不記錄用戶所有操作信息（實際是否記錄根據(jù)數(shù)據(jù)需求來看）
- 無圖模式：節(jié)約用戶流量，加快頁面加載速度。
（6）賬號狀態(tài)及用戶權(quán)限自查
- 不同賬號狀態(tài)說明：登錄狀態(tài)、非登錄狀態(tài)不同情況是否說明完整？
- 不同用戶等級和權(quán)限說明，不同等級用戶有哪些權(quán)限？在頁面展示上有什么不同？
- 不同賬號狀態(tài)切換時是否有特殊展示？
- 不同賬號狀態(tài)切換時是否有特殊展示？
- 是否考慮多賬號切換問題？
- 是否支持第三方賬號登錄？
（7）設(shè)備相關(guān)
- 是否支持橫豎屏操作；檢查不同屏幕效果
- 不同分辨率下的適配問題，是否有空白溢出變形
- 操作過程是否有卡頓
（8）特殊場景
- 網(wǎng)絡(luò)加載慢情況下無圖顯示效果
- 考慮夜間模式下的展示效果
- 區(qū)分編輯模式下可變更內(nèi)容的權(quán)限
（9）全局
- 修改頁面時，考慮在系統(tǒng)中其余地方是否也有相同的業(yè)務(wù)，是否需要修改？
- 全局控件樣式是否具有一致性
- 全局控件交互行為是否具有一致性
- 是否周全地考慮了所有操作成功的反饋。
- 是否周全地考慮了所有操作失敗的反饋。
- 控件觸發(fā)的提示類型是否恰當（小紅點、Toast、彈窗）
（10）版本發(fā)布自查
- 確認完需求之后，要告知運營同事們有哪些新功能，何時能交付版本，這樣方便運營童鞋們也好對應(yīng)的落實相關(guān)的運營工作。如果運營的部分/全部工作也是PM干的話，那么自己心里要有數(shù)；
- 該版本開始就要落實是否要做新的應(yīng)用商店圖、新的歡迎頁、新的功能引導(dǎo)頁，并且相應(yīng)的安排人手。在上線前3天最好再確認一下，萬一有漏，也有時間能再補；注意：針對這三個東西，都有相應(yīng)的文案要出；
- 確認這個項目中沒有完成的需求或者中途協(xié)商修改的需求，都已經(jīng)被記錄下來，并且最好開始確認沒有解決的需求怎么辦，修改的需求怎么辦的問題；
- 確認該新功能的埋點列表是否給出；
- 確認新功能帶來的相關(guān)新數(shù)據(jù)的查看地方以及方法，這里會涉及一些常用的統(tǒng)計平臺；
- 確認新功能帶來的后臺新的管理模塊使用或者從某個地方切換到另一個地方的使用方法的切換，培訓過相關(guān)人員，并且已經(jīng)正確掌握；
- 確認提交給應(yīng)用商店的新功能文案是否有出；
- 確認最終提交給應(yīng)用商店的應(yīng)用商店圖、新功能介紹更新了；
- 確認各個渠道中的最新版確實為最新版本；
- 每個版本都要觀察上個版本的埋點數(shù)據(jù)是否正常，及時發(fā)現(xiàn)是否打錯點，進行及時修正，避免數(shù)據(jù)浪費；
（11）按鈕
- 按鈕文字是寫死還是服務(wù)端配置
- 是否有默認的按鈕文案
- 按鈕文字的字數(shù)超過了怎么辦
- 按鈕的樣式是否有特殊樣式？若有，什么情況下會觸發(fā)特殊樣式（例如帶icon情況與不帶icon情況）
- 考慮點擊按鈕后的情況（頁面不變/跳轉(zhuǎn)到其他頁面…..）
- 點擊按鈕后出現(xiàn)的情況是否會與頁面其他情況沖突，如何處理（例如點擊按鈕出現(xiàn)浮窗，與其他浮窗重疊，則需要考慮浮窗優(yōu)先級）
（12）內(nèi)容型文案
- 內(nèi)容是靜態(tài)的or動態(tài)調(diào)用
- 內(nèi)容描述是否完整？頂部標題，按鈕里的文字等
- 內(nèi)容加載方式描述是否完整？本地緩存or加載網(wǎng)絡(luò)刷新內(nèi)容等
- 輸入型內(nèi)容是否完整？是否有初始內(nèi)容？
- 內(nèi)容違禁如何處理？敏感詞，違禁內(nèi)容等如何處理？
- 數(shù)據(jù)內(nèi)容為空時如何處理
- 內(nèi)容長度是否有限制
- 數(shù)據(jù)內(nèi)容過期or刪除or違禁后如何展示？
- 用戶內(nèi)容輸入是否描述完整？
（13）描述型文案
- 必填or非必填
- 若為非必填，則界面樣式如何
- 定義文案的行數(shù)or字數(shù)
- 文案的截斷策略是否考慮？超過字數(shù)or行數(shù)如何展示處理（例如超過兩行，超出部分“…”展示）
- 出現(xiàn)同一場景時，提示文案是否保持一致？
- 文案由服務(wù)端控制還是客戶端？
- 是否有默認文案？
- 是否易理解？是否有歧義？是否有錯別字？
（14）輸入型文字
- 輸入文字前是否有默認值， 是否有輸入提示。
- 輸入框內(nèi)容為空時如何顯示？
- 輸入框獲得焦點時，默認文字是消失（即僅作為提示文字或占位符）還是保留（即作為可編輯的默認文案）？
- 獲得焦點后，調(diào)取的鍵盤類型（數(shù)字鍵盤、英文鍵盤等）
- 輸入焦點丟失和存在時是否有展示內(nèi)容的差異。
- 輸入文字是否存在極限長度或最低長度。
- 輸入文字是否可存在特殊字符，若用戶輸入如何處理。
- 輸入文字是否存在對敏感詞（密碼、存款金額等）、違禁詞的禁用或過濾展示。
- 輸入文字后是否需要一鍵清空操作。（加個一鍵清空的按鈕等）
- 輸入文字后是否顯示輔助結(jié)果（輔助詞），輔助詞的搜索規(guī)則。
- 輸入文字后遇到流程打斷的情況是否保留輸入記錄（斷網(wǎng)、離開當前頁面或關(guān)閉瀏覽器等）
- 是否說明了鍵盤喚起后需要頁面的滾動來避免輸入框的遮擋（移動端）
（15）輸入型圖片
- 是否強制要求上傳圖片的必須參數(shù)（尺寸、格式、大小等）
- 是否設(shè)置了不符合尺寸的提示，圖片過大或過小，格式錯誤等。
- 是否提供上傳完成圖片的預(yù)覽。
- 是否提供了再次編輯操作，引導(dǎo)是否明顯。
- 上傳失敗的情況是否給予用戶提示，引導(dǎo)再次上傳。
- 上傳完成后遇到流程打斷的情況是否保留已上傳的記錄（斷網(wǎng)、離開當前頁面或關(guān)閉瀏覽器等）
（16）頁面跳轉(zhuǎn)
- 頁面跳轉(zhuǎn)流程是否完整順暢，流程中間是否有頁面缺失
- 頁面跳轉(zhuǎn)是否有提示和引導(dǎo)說明
- 頁面跳轉(zhuǎn)加載的loading展示是否友好
- 頁面跳轉(zhuǎn)動作是否有跳轉(zhuǎn)特效
- 頁面跳轉(zhuǎn)的方式是什么，點擊？滑動？等
- 頁面加載不出來或者報錯時展示什么內(nèi)容
- 頁面點擊過程中是否包含權(quán)限限制，如果有如何提示
- 頁面跳轉(zhuǎn)盡量要減少跳轉(zhuǎn)次數(shù)，縮短用戶操作流程，盡可能在一個頁面內(nèi)完成
- 一個頁面內(nèi)是否有功能冗余的內(nèi)容
- 頁面跳轉(zhuǎn)時是否需要進行輔助性說明
（17）標簽
- 標簽是系統(tǒng)做的還是用戶標記上傳的
- 標簽下的列表展示（回歸到列表的問題即可）
- 用戶是否可自定義上傳標簽
- 用戶上傳標簽后是否可修改、刪除
- 用戶上傳的標簽，考慮敏感詞庫
- 標簽是寫死還是服務(wù)端配置
- 是否必填
- 是否有默認的標簽
- 標簽的內(nèi)容是文字還是圖片？
- 標簽的文字是否有字數(shù)限制？
- 標簽的個數(shù)是單個還是多個，多個的話考慮優(yōu)先級排序
- 標簽個數(shù)多個的情況，是否會遮擋住頁面其他元素（例如，多個可以收納起來處理）
- 多種類型的標簽，對類型進行排序
- 多種類型的標簽，出現(xiàn)重復(fù)的情況（一般做去重處理）
- 后臺：是否必填、標簽名（是否限制字數(shù)）、標簽內(nèi)容（文字/圖片）、排序（是否有默認值，越大排越前）、是否顯示、標簽個數(shù)、快捷的標簽配置
（18）列表
- 列表的排序如何？
- 列表中的元素是否都定義清楚？
- 列表中涉及的數(shù)據(jù)來源定義
- 列表數(shù)據(jù)為空時的展現(xiàn)形式
- 若部分元素為后臺配置，則配置前后的情況定義
- 列表的數(shù)據(jù)是否分頁展示？還是一次性加載？單頁展示的數(shù)量是否有限制
（19）數(shù)據(jù)
- 數(shù)據(jù)的來源（具體后臺的哪個地方）
- 展示數(shù)據(jù)是否使用的是服務(wù)器數(shù)據(jù)，或使用的是本地緩存（客戶端）數(shù)據(jù)？
- 展示數(shù)據(jù)是否是初次加載讀取的靜態(tài)數(shù)據(jù)，或?qū)崟r、定時展示的動態(tài)數(shù)據(jù)。
- 數(shù)據(jù)未加載出來前展示什么？
- 是否規(guī)劃數(shù)據(jù)為空時的展示效果
- 數(shù)據(jù)的極值情況（為0的情況，最大值的情況）
- 數(shù)據(jù)長度是否有限制？是否規(guī)劃數(shù)據(jù)字數(shù)超長展示效果（幾位小數(shù)點，超出如何展示）
- 若為多個數(shù)據(jù)，則數(shù)據(jù)的排序如何？
- 是否選取全部數(shù)據(jù)or部分數(shù)據(jù)？（數(shù)據(jù)根據(jù)什么搜索規(guī)則篩選出來的）
- 對過期的緩存數(shù)據(jù)是否需要告知用戶刷新（活動過期）
- 前置場景的不同是否對當前展示數(shù)據(jù)產(chǎn)生影響，不同場景是否需要展示不同數(shù)據(jù)。
- 移動端從后臺喚醒應(yīng)用時，是否需要刷新當前頁面數(shù)據(jù)。
- 數(shù)據(jù)在什么條件下進行展示？
- 數(shù)據(jù)是否分頁展示？
- 數(shù)據(jù)去重策略如何？
- 什么時候開始請求數(shù)據(jù)？
- 什么情況下觸發(fā)更新數(shù)據(jù)？
- 數(shù)據(jù)更新頻次？是定時更新還是實時更新？
- 是否有部分數(shù)據(jù)需要過濾掉不展示？是否對特殊內(nèi)容進行過濾、標記（敏感、違禁的詞語）
- 當數(shù)據(jù)被刪除后，展示的狀態(tài)如何？
- 過期的緩存數(shù)據(jù)如何處理（定時清理還是繼續(xù)保存）？
（20）彈窗
- 什么時候觸發(fā)彈窗？
- 什么時候彈窗消失？（關(guān)閉按鈕、返回按鈕、手機系統(tǒng)返回按鈕、點擊頁面空白處等）
- 彈窗內(nèi)的元素（文案、跳轉(zhuǎn)等）是否都定義清楚
- 是否每次滿足條件都觸發(fā)彈窗？還是只彈一次？
- 若該彈窗與其他彈窗同時滿足條件觸發(fā)，則優(yōu)先級如何？
（21）輪播圖
- 圖片數(shù)據(jù)為后臺配置or客戶端寫死？
- 圖片排序如何？
- 點擊是否有跳轉(zhuǎn)？跳轉(zhuǎn)頁面為內(nèi)部鏈接or外部鏈接？
- 輪播的頻次如何？
（22）圖片上傳
- 是否有圖片尺寸、像素、格式的要求
- 是否有上傳張數(shù)的限制及張數(shù)限制的提示
- 是否提供上傳的圖片預(yù)覽
- 是否有上傳成功后可以再次編輯上傳
- 上傳失敗如何處理及引導(dǎo)提示如何展示
- 上傳過程遇到突然中斷情況是否保存上傳記錄
（23）數(shù)據(jù)埋點
- 數(shù)據(jù)埋點的字段內(nèi)容及展示類型是否完整
- 數(shù)據(jù)埋點的時間范圍和時間段是什么
- 上線后驗證的數(shù)據(jù)是否都進行了埋點記錄
- 是否需要進行數(shù)據(jù)漏斗模型分析報表生成
- 埋點數(shù)據(jù)后續(xù)如何提取出來
- 是否有自動通知機制，通知形式是什么
- 據(jù)埋點不成功是否有報警機制
四、如何來做產(chǎn)品自查？
當我們擁有了產(chǎn)品自查表之后，要做的就是在遇到每一個需求，撰寫每一份產(chǎn)品文檔的時候，將自查表運用到當中去。
敲黑板，說重點了！打瞌睡的同學醒醒，這段聽完再睡~
阿境總結(jié)了一句話：先總后分，模塊劃分，按序核查，勿忘更新。
“阿境你又說出這么抽（zhe）象（li）的東西了，說人話行不行？”
不說點大家覺得高（ting）大（bu）上（dong）的話，能是廈門吳彥祖嗎？
（沒錯，第一厚臉皮也是阿境本境）
好了，不廢話，啥意思？簡單來說，分成四步：
- 先總后分：先按照宏觀的角度來審視整篇文檔，查看文檔的整體方向是否正確，文檔的結(jié)構(gòu)是否無誤，暫時先不考慮細節(jié)。等到總體方向沒問題了之后，再去查看查看文檔的分支細節(jié)。
- 模塊劃分：根據(jù)模塊來進行文檔的撰寫，有個大忌就是在A模塊寫到了B模塊的內(nèi)容定義，文檔容易造成不易閱讀，冗長，劃分好文檔的模塊并且對文檔進行相應(yīng)的模塊定義，一個清晰的模塊就好比是樹木的枝干，能夠提升文檔的可讀性。
- 按序核查：當進行第二步模塊劃分之后，為的便是更好地進行順序的核查，例如產(chǎn)品需求、業(yè)務(wù)流程、功能主次關(guān)系、功能布局、模塊狀態(tài)等等順序進行一一校對。
- 勿忘更新：有了這份文檔，并不是一蹴而就的，時代在更新，產(chǎn)品在更新，自然，產(chǎn)品自查表也需要不斷更新。這份自查表是阿境在自身實踐當中總結(jié)而出，可以看出，產(chǎn)品的理論大多源于實踐，脫離實踐則無從談起。所以，朋友們可實踐當中，不斷完善這份產(chǎn)品自查表，一句話：沒有最完美的，只有適合自己的。
寫在最后
做產(chǎn)品是一個并不那么容易的活，寫一份合格的需求文檔也不是那么輕松的事情。為了確保產(chǎn)品能夠“活下來”，確保需求文檔能夠嚴謹、詳盡、完善，這份產(chǎn)品自查表希望能夠幫助到各位朋友。
但有一點要記住，產(chǎn)品自查表起到的作用是錦上添花，并不是雪中送炭。它是建立在有一定產(chǎn)品思考方向的前提之下。
同時阿境也想拋磚引玉，以這份產(chǎn)品自查表來提醒各位朋友，需要有核查、糾錯、校對的意識，對產(chǎn)品對需求保持敬畏之心，才能夠做好產(chǎn)品。
最后，愿天下沒有難寫的需求文檔。
作者：阿境，產(chǎn)品界的吳彥祖，一個沉穩(wěn)又不沉悶的男人。野蠻生長，產(chǎn)品汪一枚，做過電商、醫(yī)療、教育行業(yè)項目，現(xiàn)4399產(chǎn)品經(jīng)理。堅信”產(chǎn)品源于生活”，歡迎交流。公眾號：夢想家阿境
本文由@阿境 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議
這不就是剛?cè)胄械奈?，夢寐以求的自查表嘛！我甚至覺得這是一份產(chǎn)品工作的SOP！太有幫助了！
這個博主的專業(yè)能力和邏輯能力很強
可以關(guān)注公眾號：夢想家阿境；
聯(lián)系阿境領(lǐng)取一份自查表源文檔
產(chǎn)品自查表，厲害了！
阿鏡好棒廈門吳彥祖
小白，求推薦書籍，想轉(zhuǎn)行智能硬件產(chǎn)品
考慮挺周全，謝謝分享，已收藏！
可惜我加不上你的微信，加你的人好多??！
超級無敵的好
深度好文，請問我可以摘抄一些筆記上傳到Timing學習app上嗎，會備注作者和出處的
挺全，收藏了
有沒有文檔可供下載