這篇文章想和大家討論的是作為一個產品經理，是如何完整地完成一個項目的流程。很多產品經理日?？赡芏荚谶M行以下的工作，卻比較少的去完善的整理，系統的匯總！不惜的繞道，點擊右上角“X”，走好不送。志同道合的產品經理們，歡迎在底部留言評論，互相進步！

目錄：

1、需求設計期
1.1、需求收集
1.2、需求預擬（自行完成）
1.3、需求審核會議
2、需求跟進期
2.1、設計師環節（美術、切圖）
2.2、前端/后端環節
3、測試協作期
4、線上優化期

需求設計期

需求收集

1、0-1的產品，提前做好MRD（選對競品），MRD內容重點分析：

• 競品的框架層級結構
• 競品的功能點拆分
• 競品頁面布局分析
• 詳情可以查看我發布的《如何利用競品分析，快速構建新產品的框架？》

2、優化迭代的產品，收集各個需求方的需求：

• 用戶（意見反饋系統，社交工具，問卷調查等）
• BOSS（BOSS的需求，可以是必要，但不一定是優先）
• 同事（主要是運營和市場）
• 自己（自身日常對產品的跟進維護和使用，讓自己成為一個目標用戶）

需求預擬（自行完成）

1、0-1的產品，幾個重要的思考點：

• 競品的框架層級分布，是否適合我們的產品定位；這個定位，需要根據各PM的工作來自行定義了
• 競品的功能點，是否是我們需要的功能點
• 在上一步的基礎上，細分這些功能的出發點是什么？適用的場景是什么？我們能否進一步優化，以便于更貼合我們的產品

2、迭代優化的產品，幾個重要思考點：

（1）需求甄別，區分需求方的需求是需求還是一個解決方案

舉個最近比較火的游戲狼人殺！用戶說我想要能夠通過微信邀請好友！溯源到真實情況，原來是APP中支持各種第三方登錄，也支持游戲中添加好友，但是無法對好友進行實時要求，同時用戶想要進行社交，不僅僅是微信，還有QQ、手機聯系人等；這個時候用戶的真實需求是社交+實時要求，而不是我要微信邀請！

（2）需求價值評估，對甄別后留下的真實需求進行優先級評估：

• 充分利用四象限原則，重要，緊急為必然要實現的
• 重要，不緊急，要綜合考慮到時間成本問題，來確認是否要在本次實現
• 不重要，緊急，在滿足重要緊急的程度下，可以去完成
• 不重要不緊急，呵呵帶過

（3）如何去判斷重要緊急程度，附帶幾個參數

• 該功能覆蓋的用戶數為多少？
• 如果不是相愛需求，會造成什么影響
• 需求是不是老板重視的（一個笑臉）

需求審核會議

1. 與會人員

BOSS/上級、前端、后端、產品、運營等相關人員

2. 與會內容

• 預擬的需求是否可以實現
• 再次確認預擬需求的優先級
• 評估需求所需耗時
• 對預擬需求的增減
• 確認研發進度時間表【設計師/切圖/前端/后端】

3. 會后

• 進行會議整理，評估是否需要下一輪補充會議。
• 對會議內容進行輸出，體現為版本迭代計劃，可以以任何內部能夠接受的形式/寫法輸出。
• 書面郵件周知，背鍋，你怕了嗎？

需求跟進期

設計師環節（美術、切圖）

1、需求文檔，內容包含：

• 設計圖初稿截止日期，最終定稿截止日期。
• 頁面風格需求，建議使用參照頁面，便于互相理解。
• 其余特殊細節需求。諸如：什么地方需要把圖片和文字切到一起。

2、當面溝通，實現目的：

• 設計師正確理解你的需求，無論是風格還是細節。
• 設計師在日期進度上和你達成一致。

3、書面郵件周知

前端/后端環節

1、需求文檔，內容包含：

• 每個功能點擊時，要進行什么判斷【登錄/未登錄，注冊/未注冊/】。
• 每個功能點擊后，觸發什么樣的效果。
• 對同一個功能，進行多狀態操作后，界面中要怎么展示【下載/暫停/安裝/卸載但是不刪除安裝包/卸載并刪除安裝包】。
• 每一個數據要讀取什么地方的數據，要進行怎么樣的判斷轉換。
• 確認出測試包的時間和最終上線日期。

2、當面溝通，實現目的：

• 技術工程師正確理解你的需求。
• 技術工程師在日期進度上和你達成一致。

3、書面郵件周知

測試協作期

1、測試用例

• 不同的項目需求不一樣，根據項目的簡單/復雜程度，有些項目是不需要測試用例的。測試工程師只要對照我們提交給前端的需求文檔，基本就可以滿足了。
• 不同的團隊需求不一樣，有些是產品經理編寫，有些是測試工程師自行編寫，個人建議產品經理在時間充足的情況下自行編寫，因為最清楚產品的是你。

2、測試參與

• 產品經理要對需求進行第一輪驗證，確認技術工程師完成的功能，是我們想要的需求。
• 中途完全放權給測試工程師。
• 產品上線前要對產品進行最終驗證。

3、確認測試時間進度

簡單來說，就是規劃測試時間進度，第一輪的測試時間是XX-XXX，諸如此類。

4、最終上線，報備，還是要，郵件通知！

線上優化期

1、意見反饋系統

建議每一個產品都有一個意見反饋入口，這個對產品的線上維護和下一次版本迭代更新起到一個直接/暴力的正引導作用。

2、用戶溝通反饋

去融入到你的產品用戶群，游戲類APP，可以去參與到各種游戲圈。生活類APP，就去找生活圈。

3、隨意測試

在測試期，無論是產品還是測試工程師，進行的是系統化/邏輯關聯化測試，目的是確保新功能無BUG；有個弊端就是，比較難去注意到新功能的用戶體驗問題。

針對這個，就需要隨意測試：在家里，在車上，打開你的產品隨意點擊使用，讓自己成為一個真實用戶，體驗用戶體驗環節，不斷的發現一些體驗性而非BUG性的問題！

小結

聊一聊產品推進過程中常見的問題如何解決吧：

技術說：這個功能做不了

技術是真做不了還是不想做？

然后看看競品實現了嗎？如果實現了，麻煩你啃下來！

啃不下來，再拉兩個技術一起商量對策，集思廣益；

技術說：時間來不及，太趕了！

真來不及還是技術想偷懶？

想偷懶，你可以把boss和技術拉到一個討論組，問題/進度，直接在群里互相周知

真來不及，分兩個情況：

• 必須上線的功能——女的可以撒嬌賣萌，男的可以稱兄道弟，多培養下感情，然后，技術大大，歡迎你加班，零食已經準備好了！一切，以解決問題為導向！
• 不是必須上線的功能——能說服你的老板，那你就砍需求吧！

大概就聊這么多了！真不是打廣告，有喜歡狼人殺的小伙伴嗎，哈哈！

本文由 @PM-Seven 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議