清單能幫助我們記憶如何處理復雜的工作，幫助我們整理眾多事情中的優先級，幫助我們不遺漏重要的工作環節，并且促使我們進行團隊合作。

我們所掌握的知識的數量和復雜程度已經超過了個人正確、安全和穩定地發揮其功效的能力范圍。知識的確拯救了我們，但也讓我們不堪重負。我們需要開展一場偉大的變革來防止錯誤與失敗，這一變革立足于已有的經驗，既能充分利用我們所掌握的知識，又能彌補人類不可避免的缺陷和不足。

這一變革并非艱難之舉，而且簡單至極，特別是對那些花了多年時間來培養和磨煉高超技藝的專業人士來說，投身這一變革簡直讓人貽笑大方。這個變革就是：清單革命！

——《清單革命》

作為一名產品汪，日常的工作非常繁雜瑣碎：處理需求、制定方案及邏輯、輸出需求文檔、協調各方資源、推動需求按時上線、產品培訓及使用說明、分析數據、調研用戶、調研競品、了解行業、洞察用戶需求、項目管理、規劃產品迭代節奏、跨端跨部門合作、對接業務方……。

下面以項目為例，給出了一個項目從無到上線所要經歷的流程：

如此眾多類型的工作，對產品經理的能力要求也各不相同。在日常工作中，除了上述的工作內容之外，還會經常被各種瑣碎的事情“打擾”，以至手頭上的工作經常被臨時擱置。

在此背景下，產品經理若想比較完美地處理日常工作，需要在具備各種維度的能力基礎之上，能夠在不同的場景下靈活且正確的使用對應能力去處理，且保證所有工作和步驟都沒有遺忘。

怎奈何“理想很豐滿，現實很骨感?！?/p>

由于人類的認知缺陷和有限的記憶力，在日常工作中面對大量繁雜的工作內容且還會被中途“打擾”的場景下，我們難免會多多少少遺忘一些步驟或工作。而遺忘掉的這些步驟或工作，很可能就是能對產品產生致命影響的那極少數，你說刺激不刺激！

難道我們就沒有辦法解決了嘛？

當然有！

只要一張清單，真的只要一張清單，以上問題就能引刃而解?。X海中是否浮現出了那句經典廣告語：只要998，真的只要998，以上商品全部帶回家！hhhhh）

清單為我們提供了一種認知防護網，不僅能夠抓住每個人生來就有的認知缺陷，如記憶不完整或注意力不集中；還能會提醒我們不要忘記一些必要的步驟，并讓操作者明白該干什么。這不僅是一種檢查方法，更是一種保障高效且高質量完成工作的法寶。

下圖便是本文的核心內容：

下面將對清單中提到的內容進行詳細說明：

產品經理自檢清單V1.0—詳細說明

項目環節

1）需求獲取

獲取需求時，首先應全面并充分利用各種獲取用戶需求的途徑，其次是在需求獲取階段盡量不要拒絕來自任何人的需求，將需求與身份和動機區分開來，在之后的需求分析階段在充分考慮它們。

2）需求分析

需求分析時，首先結合自己對業務的理解，從用戶角度出發，判斷需求是否合理；其次，應結合業務現狀及未來規劃，判斷需求是否真的有必要；最后，需要結合需求反饋者及業務現狀，判斷需求的重要緊急程度給出需求優先級后納入需求池中。

3）需求確認

需求確認時，結合業務現狀，開發資源，業務方實際需求情況等因素，評判選出來的需求是否是需求池中最為重要緊急的。

4）方案設計

慢思考快執行。

動手設計方案之前一定要全面深入思考，提前磨好刀，經過全面的深入思考之后再開始設計方案。設計方案的過程中要本著“結果導向”的原則，先輸出結果再追求完美，輸出初版方案之后再不斷優化。

5）需求文檔

先概述后具體。

輸出需求文檔時，要先概述性的介紹此次項目的背景，目標以及涉及到的需求點和影響面，讓受眾在看的時候能夠先對本次項目擁有一個全面的認知。而后再對具體的需求實現細節進行詳細的介紹，要保證文檔簡潔易懂。

需求文檔輸出之后，自己要反復仔細看幾遍，看看有沒有遺漏掉的點，有沒有存在邏輯不完善的地方，然后再對文檔進行優化，修改文檔時一定要有修改記錄。需求文檔沒問題之后，如果涉及到UI或其他協助的需求，要確認好相關協助資源準備完善。

若產品功能較為復雜，還應著手準備產品使用說明或培訓資料。

6）立項評審

立項評審之前，先通盤考慮此次項目是否會涉及到產品其他模塊或者其他部門支持，如有需要應提前向各端同步信息。在拉會進行立項評審之前，最好能夠先跟相關人員提前打聲招呼，約好時間，然后按照約定的時間定會議室發布會議邀請，拉項目群，在會議快開始之前再在群里提醒一下大家。

立項評審的主要目的是跟相關人員初步簡單評審將要做的項目，大家一起從各自的角度評估一下項目的可行性。

若立項評審通過，則需要在會議上確定好各端的負責人及需求評審時間，以便項目后繼工作能夠更好地開展。在立項會議上要確認項目是否需要進行灰度測試，以及是否需要市場及運營部門協助進行運營推廣，如有需要，應當提前做好相應準備。

7）內部評審

內部評審的主要目的是：提升方案和需求文檔的質量。

同行從不同的角度來對方案和文檔進行檢查評估能夠更好地發現問題，在此基礎上再對項目方案和需求文檔進行迭代優化，從而使得方案和需求文檔更加完善。

8）需求評審

需求評審是一個項目的生命周期中較為重要的環節，此環節需要產品經理通過需求文檔和講述的方式，讓項目相關成員能夠對此次需求有一個完整的清晰的了解，只有在清晰了解了需求的基礎上，才能將需求實現地更好。

根據立項評審上定好的需求評審時間，給項目成員提前發好會議邀請并在會議快開始時提醒大家。會議過程中，產品經理要詳細地向各位項目成員介紹需求，根據文檔的每個模塊講完之后用幾分鐘作為QA環節，加深項目成員對需求的了解程度，在會議結尾要確定好技術評審的時間。

9）技術評審

技術評審的主要目的是項目開發成員從技術的角度，對此次項目的影響面以及實現細節進行討論評估，給出各自需要的開發時間，而后匯總得到項目的排期。

在得到排期之后要跟預期做比較，如果遠超出了預期時間，則需要再次評審，通過增加人員等方式縮短周期，盡量達到預期。一般情況下，如果項目周期超過一個月，則需要將項目分期進行開發上線。

10）開發過程

項目進入開發過程后，產品經理需要著重關注項目開發進度是否正常。對于較大的項目，要結合項目周期適時拉著項目成員，通過簡短的站會形式跟大家一起同步各自的開發進度，尤其在聯調和提測的時間節點之前，需要加大進度跟進及同步頻率，確保項目能夠如期聯調和提測。

若發現延期風險，需要及時向相關負責人及領導同步，尋找解決辦法。若無法避免延期，則需結合實際開發進度及剩余時間重新給出合理排期并向相關人員同步最新排期。

11）測試過程

項目提測后，如果涉及到有UI協助，需要及時通知相關UI同事介入幫忙進行UI走查，確保UI層面的問題能夠在早期修復。

在測試階段，要跟測試同事緊密溝通，掌握BUG數量及解決進度，確保BUG能被以合理的時間修復好不要影響整體的排期。

測試過程中也應盡量親身參與測試過程，發現一些細節層面的問題，推動測試過程更快的進行。當測試同事提出驗收申請后，要全面仔細的走一遍整體流程，確定此次需求沒有問題之后再上預發環境。預發環境中重復一遍測試環境的步驟，確認驗收通過后達到上線標準。

若測試過程發現延期風險，需要及時向相關負責人及領導同步，尋找解決辦法。若無法避免延期，則需結合實際測試進度及剩余時間重新給出合理排期并向相關人員同步最新排期。

12）上線前后

上線前若項目需要進行灰度測試，則需要提前給出灰度測試的用戶范圍；若需要市場及運營部門協助進行推廣，則需要在上線前后的相應時間點與市場運營部門緊密溝通，確保項目在上線前后能夠得到及時的推廣。

正式上線后，要做的第一件事是對線上環境進行回歸測試，確保上線后的產品功能沒有問題之后再發布上線郵件（里程碑性的產品上線還應適當慶祝）。若產品功能較為復雜，需要及時跟相關人員約好時間進行內部培訓，或向用戶發布產品使用說明。在上線后也應及時對項目整個過程進行全面復盤，如有需要可召集所有項目成員一起進行復盤會議。

而后，需要持續對新上線的產品功能進行體驗，分析相關數據，評估項目的效果和收益情況，也應主動及時搜集用戶對新功能的反饋，形成相應的迭代需求，然后再次以迭代優化的形式進入項目開發流程。

其他環節

1）溝通前后

溝通之前要先明確此次溝通的目的，開始時先向溝通對象介紹溝通的背景和此次溝通的主題，溝通過程中語言要盡量簡練，盡量不要說與此次溝通主題無關的話題，最終要達成明確的結論。

2）調研前后

產品經理的日常工作中，需要經常對用戶，競品及行業進行調研。在調研之前需要先明確好調研的目標，根據目標選擇合適的調研對象及調研方法，而后需要設置好調研的問題或者是思路。待這些都思考清楚之后，在開始調研，調研的過程中要細心，應當盡量圍繞目標展開，最終要形成有效的調研結論。

3）匯報前后

在匯報工作之前，要先明確好匯報的目標，結合目標提前做好相應的準備工作，如有需要還需準備PPT。

匯報過程應盡量簡練，本著結論先行的原則，先匯報結論然后再闡述原因，理由需要足夠充分且有說服力，如果涉及到相應問題，需提前想好幾個解決方案讓領導做選擇題。

4）遇到問題

遇到問題之后，不要一上來就想解決方案。需要先認真了解清楚問題的背景及產生的原因，深挖出問題的本質，在此基礎之上對問題的影響面進行評估，看是否需要其他產品端或部門的協助。而后再開始針對問題的本質思考解決方案，解決方案要能夠從根本上解決問題且最簡最優，具備良好的拓展性。還應及時向相關人員同步問題解決進度。

5）主持會議前后

會議開始之前，要先明確召開本次會議的目標和會議主題，提前跟相關參會人員打招呼約好時間，根據約定好的時間提前發送會議邀請，在會議快開始之前再提醒一下大家。

會議開始時，需要先向大家介紹會議的主題及目標，然后進入主題。會議的過程中要注意對論題及節奏的把控，不討論與會議主題無關的話題，推動會議正常進行，最終要達成明確的會議結論和后繼TODO。會議結束后，及時將會議達成的結論整理成會議紀要同步給相關人員。

最近看了《清單革命》這本書，聯想到產品經理的日常工作，便有了此文。

本著小馬哥“小步快跑，快速迭代”的思想，本文結合筆者將近一年（算上實習）的產品工作經歷，輸出了【產品經理自檢清單】的V1.0最簡版本。后繼會結合該清單在實踐中的使用情況，及用戶反饋對其不斷迭代優化，也非常歡迎閱讀本文后對此清單有優化建議的用戶，通過微信公眾號與我建立聯系，互相交流學習。

清單的力量是有限的。它雖然能幫助我們記憶如何處理復雜的工作，幫助我們搞清楚哪些事情是最重要的，幫助我們不遺漏重要的工作環節，并且促使我們進行團隊合作，但解決問題的主角畢竟是人，而不是清單。

愿本文能給你我帶來一定的幫助和啟發。

以上。

本文由 @心中有這個世界 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議