產(chǎn)品經(jīng)理在工作中要做好自查，從而避免出錯。那么，有沒有什么方法可以幫助自己自查？這篇文章里，作者做了梳理和總結(jié)，一起來看一下，或許會對產(chǎn)品經(jīng)理同學有所幫助。

一、需求處理

1.你獲取需求的途徑是什么？（用戶調(diào)研，競品分析，市場分析，數(shù)據(jù)分析等）。

2.確認需求背景，了解需求產(chǎn)生原因。

3.了解用戶的真是需求，挖掘痛點。

4.確認是否有數(shù)據(jù)支撐。

5.分析需求（分析需求收益、成本、周期風險、需求是否滿足當前業(yè)務(wù)目標及業(yè)務(wù)場景、當前系統(tǒng)是否能很好的將需求進行轉(zhuǎn)化落地、需求的必要性及可行性、確定需求是否滿足用戶需求、確定需求目標是為了達到什么樣的效果、需求的緊急重要程度、需求是否為技術(shù)可實現(xiàn)的，有沒有技術(shù)壁壘、是否需求進行上下溝通，看看是不是有其他指示）。

6.是否能實現(xiàn)更好的實現(xiàn)商業(yè)價值利潤？能否將需求轉(zhuǎn)化為幫助實現(xiàn)商業(yè)價值的功能等。

二、分析整理階段

1. 信息架構(gòu)

1.戰(zhàn)略層：這些戰(zhàn)略不僅僅包括了經(jīng)營者想從網(wǎng)站得到什么，還包括了用戶想從網(wǎng)站得到么（例：就我們的網(wǎng)上商店的例子而言，一些戰(zhàn)略目標是顯而易見的，用戶想要買到商品，我們想要賣出它們）。

2.范圍層：功能及其內(nèi)容需求整合。做了什么，而不做什么，就是范圍（例：有些電子商務(wù)網(wǎng)站提供了一個功能，使用戶保存之前的郵寄地址，這樣他們可以再次使用它。該功能是否應(yīng)該成為該網(wǎng)站的功能之一，就屬于范圍層要解決的問題）。

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

3.結(jié)構(gòu)層：信息架構(gòu)，交互設(shè)計，操作流程，用戶體驗（在功能產(chǎn)品，結(jié)構(gòu)層將從范圍轉(zhuǎn)變成系統(tǒng)如何響應(yīng)用戶的請求，即設(shè)計用戶如何到達某個頁面，并且在他們做完事情之后能去什么地方）。

注：在信息產(chǎn)品方面，結(jié)構(gòu)層則是信息空間中內(nèi)容元素的分布，確定哪些類別應(yīng)該出現(xiàn)在哪里。

4.框架層：界面設(shè)計、導航設(shè)計和內(nèi)容（信息）設(shè)計（界面設(shè)計：按鈕、輸入框、界面控件、導航設(shè)計：呈現(xiàn)信息 、信息設(shè)計：呈現(xiàn)有效地信息溝通）。

• 目標一：必須提供給用戶一種在網(wǎng)站間跳轉(zhuǎn)的方法；
• 目標二：必須傳達出這些元素和它們所包含內(nèi)容之間的關(guān)系；
• 目標三：必須傳達出內(nèi)容和用戶當前瀏覽頁面之間的關(guān)系。

5.表現(xiàn)層（功能及內(nèi)容的視覺呈現(xiàn)）

2. 流程設(shè)計

1. 上下表肯定，左右表否定；
2. 先走主流程（正流程），再走逆流程；
3. 流程圖里只能有一個開始，可以有多個結(jié)束；
4. 連續(xù)超過3個判定拆開做；
5. 一個流程，多個場景拆開做，不要做成結(jié)構(gòu)圖；
6. 不要指向子流程，指向母流程；
7. 矩形可以是流程、頁面、功能，線段是動作；
8. 不要指向開始；
9. 禁止死胡同；
10. 做完自檢3遍；
11. 版本命名要規(guī)范；
12. 繪制順序，應(yīng)從上至下，從左到到右的順序。

三、設(shè)計階段

1. 符合需求的原型圖。
2. 產(chǎn)品交互和UI完成溝通，是否已產(chǎn)出，UI需要協(xié)調(diào)資源。
3. 需求文檔，文檔內(nèi)容是否完整，是否邏輯縝密，是否完成需求閉環(huán)。
4. 產(chǎn)品方案是否簡潔并具有拓展性。
5. 產(chǎn)品方案是否已上下溝通并完成確認。
6. 是否需要準備其他物料（比如上新功能需要準備產(chǎn)品使用說明文檔）。
7. 是否有統(tǒng)計需求，是否已產(chǎn)出數(shù)據(jù)需求，是否已和數(shù)據(jù)分析師溝通。

四、評審階段

立項階段

1. 是否有明確立項的目標和主題（項目名稱、背景）。
2. 是否需要準備立項材料。
3. 需要其他部門配合協(xié)助，是否已經(jīng)提前溝通。
4. 是否已經(jīng)確認好各端負責人。
5. 是否已協(xié)調(diào)好立項會時間、地點，并通知好項目相關(guān)人。
6. 宣講會PPT。
7. 完成立項宣講會，并收集問題給予解答。
8. 確認各項任務(wù)資源是否已經(jīng)分配。

五、需求評審階段（各相關(guān)人了解、討論、確認方案細節(jié)）

1. 針對需求評審，需要產(chǎn)品組織主講方案給技術(shù)人員。
2. 確認參會人是否已了解需求。
3. 方案是否存在遺漏點并是否補充完整。
4. 方案是否存在可以提升優(yōu)化的點。
5. 方案是否存在技術(shù)難點，是否有解決或替代方案。
6. 若方案改動大或評審時問題多，需要多輪需求評審確認。
7. 對于方案改動點是否已向上同步并確認。
8. 技術(shù)評審。確認技術(shù)方案是否可以滿足產(chǎn)品需求。
9. 確認技術(shù)方案是否存在未來可拓展性。
10. 確認技術(shù)排期是否可接受。
11. 測試用例評審。由測試組織、測試主講根據(jù)需求設(shè)計的測試方案和用例，確認測試方案是否可以涵蓋所有需求點。
12. 確認測試方案是否可以涵蓋到異常情況。
13. 確認測試排期、最終上線時間。

六、開發(fā)階段

1. 確認技術(shù)是否完全按照方案進行開發(fā)實現(xiàn)。
2. 開發(fā)過程中的需求溝通，需求調(diào)整，更新文檔。
3. 定期確認開發(fā)進度，組織周會同步跟進。
4. 是否有延期風險，若有風險是否已同步到相關(guān)人。

七、測試階段

1. 確認產(chǎn)品驗收是否通過。
2. 確認UI是否通過。
3. 確認所有Bug是否都已解決，未解決的是否可以遺留。

八、上線階段

1. 上線前，是否有需要提前準備的材料或培訓。
2. 統(tǒng)計數(shù)據(jù)需求，確認埋點及統(tǒng)計指標。
3. 上線后確認產(chǎn)品運行是否有異常，線上回測。
4. 確認產(chǎn)品數(shù)據(jù)是否異常，數(shù)據(jù)效果是否符合預(yù)期。
5. 及時給項目相關(guān)人同步產(chǎn)品上線郵件，產(chǎn)品數(shù)據(jù)郵件。
6. 收集用戶反饋，做需求優(yōu)化規(guī)劃。
7. 跟進項目效果，及時做項目復(fù)盤和接下來的規(guī)劃，是否有第二、三階段。