在大廠里，高級產品經理都在用的項目管理流程

編輯導語：在日常工作中，做好項目管理對于提高工作效率有著很大的幫助。如何規范項目管理流程，確保流程有序地進行并如期完成呢？作者給我們分享了幾個重點。

一、文檔制定目的

本文檔的制定，主要是為了規范公司不同項目組之間，產品、設計、研發、測試等童鞋的工作標準和協作流程。通過實施完整的產品研發管理流程，做到在重點環節都有相應的工作文檔產出及任務記錄作為項目進展的沉淀，盡量減少人為因素對整個項目的干擾和影響。

二、整體項目開發流程

互聯網產品整體研發管理流程如下圖所示，具體包含6個環節：

1. 需求管理階段：包含需求的采集、分析和篩選，主要由產品經理進行日常的產品/用戶需求收集，并制定相關的版本迭代計劃；
2. 產品設計階段：包含產品方案的設計和產品需求評審，主要由產品經理輸出PRD文檔，并組織相關同事進行需求評審會議；
3. UI 設計階段：包含UI設計稿的整理和輸出，主要由UI設計師操刀完成設計稿，并組織相關同事進行UI設計稿的評審會議；
4. 產品研發階段：包含架構設計、代碼設計、代碼實現等，主要由前、后端工程師完成產品架構、頁面及邏輯的相關開發；
5. 產品測試階段：包含功能性測試和性能測試等，主要由測試工程師撰寫測試用例，并在測試完成后輸出測試報告；
6. 產品上線階段：包含灰度發布和全量發布，主要是項目負責人來確定具體的發布時間和發布渠道。

三、項目管理工具

1. TAPD協作工具

公司的項目管理工具，使用騰訊開發的TAPD敏捷協作平臺。

TAPD強大的項目管理和協作功能，包含故事墻、迭代、看板、缺陷管理、在線文檔等（具體功能及作用可查看TAPD幫助手冊：https://www.tapd.cn/help）可以方便地支持互聯網產品的整個項目開發流程，尤其是對于敏捷開發的項目團隊來說，更是一款不錯的支持產品快速迭代的工具。

實施之前，需要由項目負責人在TAPD內創建一個項目，并邀請自己的項目組成員進入到這個項目，這樣就可以開始自己項目的團隊協作之旅了。

2. 每日項目站會

項目站會對于敏捷開發的互聯網團隊來說是非常有必要的一種會議，可以在每天上午10點進行召開，時間不宜過長，通常在15-20分鐘以內結束，會議的主要內容就是項目參與人闡述各自完成的任務，包括：

• 昨天都做了什么；
• 今天打算做什么；
• 遇到什么問題和挑戰。

會議過程中，項目負責人可以結合進度及任務優先級，對項目成員的任務做相關調整；項目站會結束后，項目負責人可將每日站會小結發到微信群里，將項目進展信息同步給所有人。

四、具體實施流程規范

1. 需求管理階段

（1） 需求管理簡介

需求管理階段為產品迭代的初始階段，產品迭代都是從需求出發。具體來說，需求管理包含如下幾個階段：

1. 需求采集：可以通過市場調研、競品分析、用戶反饋、數據分析、老板/同事反饋等；收集產品用戶需求或技術型需求。
2. 需求分析：通過場景分析法、kano模型等來進行分析。
3. 需求篩選：將分析過的靠譜需求篩選出來，制定產品新一版的迭代計劃或長期的版本迭代計劃。

（2）參與人員及職責

需求管理階段的參與人員主要是產品經理，當然項目里的任何一個成員都能提出自己的產品需求建議（包含技術工程師提出的代碼優化需求等），具體職責如下：

• 項目成員：任何一個項目成員都能提出自己的產品需求。
• 產品經理：負責需求的采集、分析、篩選，負責管理和維護產品需求池，并制定版本迭代計劃。

（3）需求池管理

產品需求池管理采用TAPD項目中的需求模塊，每一個項目成員（尤其是運營、業務人員）都可以創建一個產品需求反饋給到產品，注意在創建需求時不要將需求歸入到某一個迭代中。

查看需求池的時候，只需將查看視圖切換到【待規劃需求Backlog】即可查看全部需求狀況。

（4）文檔輸出

版本規劃文檔：產品經理在需求管理階段需要輸出產品近期的一個版本迭代規劃，如最近一個月，或一個季度的大致路線規劃，并且需要將版本迭代規劃文檔上傳到TAPD的文檔管理中心，和項目成員一起進行分享。

市場調研文檔：產品經理做的市場調研、用戶訪談、競品分析等一系列工作所產出的文檔，同樣，需要將這些文檔上傳到TAPD中進行管理。

2. 產品設計階段

（1）產品設計簡介

產品設計階段主要由產品經理將需求轉化為產品方案的輸出，包含基本的功能流程設計、原型設計、PRD文檔撰寫等工作。

（2）參與人員及職責

產品設計階段主要由產品經理參與，負責輸出整體產品方案設計，包含需求背景、需求目標、及具體產品方案等；完成PRD文檔的撰寫后，需要組織和邀請相關人員進行產品需求評審的會議，在會議上闡述清楚自己的產品方案。

（3）產品需求評審會議

由產品經理來進行組織的一次會議，需求評審目的是讓項目的參與者（這里主要指設計研發測試）能夠快速理解產品的意圖，認可采用的方案。

當然，需求評審并不是說誰要說服誰，而是我們要就一個具體問題尋找到最優的解決方案。

關于需求評審的推進步驟：

1. 先說我們這次需求的目標與目的；
2. 在目標與目的達成一致的基礎上，闡述具體的產品解決方案；
3. 經過討論后，產品經理整理好會議結果進行郵件通知，如果PRD方案調整較小則可以不用進行第二次需求評審，如果方案調整較大建議進行第二次需求評審。

（4）文檔輸出

PRD文檔：也就是產品需求文檔，主要由產品經理撰寫，包含產品背景及目標說明、全局說明、產品詳細方案說明等模塊，整理完畢后需上傳到TAPD文檔中心進行留存；

評審會議郵件：評審會議開完后，需要將會議記錄和結果做一個郵件通知抄送給所有的參與評審會議的人員，方便大家了解評審會議的最終結果。

3. UI設計階段

（1） UI設計簡介

UI設計階段主要由UI設計師來完成，包含做界面的視覺設計，進行布局、配色、樣式不同風格的嘗試等。

（2）參與人員及職責

UI設計階段主要由UI設計師、產品經理等進行參與：

• UI設計師：完成UI設計稿的設計、進行UI設計稿的評審宣講等。
• 產品經理：對UI設計進行相應的把控。

（3）UI設計稿評審會議

UI設計稿的評審可由UI設計師進行組織，也可由產品經理來協助設計師進行組織，邀請項目參與人員進行相關評審，評審內容主要如下：

整體方面：

• 設計理念是否與產品定位符合，整體風格是否與產品氣質相符；
• 色調搭配是否舒適，整體的色調是否保持一致規范；
• 版面樣式是否平衡，有沒有存在一邊倒的設計，或者整體不夠協調；
• 內容層級是否清晰明了。

細節方面：

• 設計元素的選擇是否與整體風格搭配，包括大小，色彩，質感等；
• 圖標、button等元素是否與整體界面統一和諧；
• 文字、元素等細節是否存在冗余或錯誤、遺漏等。

（4） 文檔輸出

UI 設計稿：通過設計軟件進行創作的UI設計稿件，做好標注后上傳到TAPD的文檔管理中心。

4. 產品研發階段

（1）產品研發簡介

產品研發階段主要是指各類型的工程師為實現產品功能、頁面、邏輯所做的代碼研發工作。

（2）參與人員及職責

• 前端工程師：搭建前端框架，根據原型設計稿/UI設計稿實現產品前端的靜態頁面，在靜態頁面的基礎上綁定數據接口；
• 后端工程師：搭建后端框架，結合需求文檔提供產品功能所需的各類接口，并與前端一起進行接口調試工作；
• 算法工程師：搭建算法框架，為產品提供算法方面的研發工作。

（3）代碼庫管理

①代碼庫權限分配

• 使用公司內建的GitLab保存和管理屬于本公司的代碼資源；
• 公司總技術負責人和項目直接負責人有項目的Master權限；
• 負責項目的權限管理；
• 項目內人員管理；
• 受保護分支的操作；
• 參與項目研發的技術人員設置為Developer權限；
• 白盒測試人員和相關人員設置為Guest權限。

②代碼庫分支管理方法

分支:

• 為項目創建 release(或相同職能的其它名字) 分支， 專用于發布生產環境；
• 創建develop(或相同職能的其它名字)分支， 專用于測試環境發布；
• Master分支用于備份release分支發布的最后一次穩定版代碼. 用于災備；
• 將release和master分支設置為受保護的狀態. 只有master權限的管理人員可以合并， 提交這兩個分支的代碼，并且在合并提交代碼的過程中對代碼review 并留痕。

使用：

• 開發人員每次任務都需要創建針對此次任務的開發分支(僅供個人使用)；
• 每個開發人員(不同的開發分支)可以在任何時間將代碼合并至develop分支，并由有權限的人員發布到測試環境。如果develop分支有任何異狀，可以隨時刪除并重建同名分支，這個分支不用擔心被污染。
• 開發分支的代碼全部開發完成，并在develop分支測試通過后。需要各個開發人員發起向release分支的merge request， 由項目負責人code review并完成合并（留痕）。如有沖突需要具體開發人員配合項目負責人解決沖突。
• 代碼合并至release分支后，需要經過回歸測試。無誤后由項目負責人發布至生產環境。

5. 產品測試階段

（1）產品測試簡介

產品測試階段主要由測試工程師來完成，根據由PRD文檔編寫的測試用例來對產品進行測試，找到產品界面、功能和不滿足產品需求文檔的相關bug缺陷。

研發團隊在這個階段要對缺陷進行修改，測試工程師則需要跟蹤缺陷的修復情況。

（2）參與人員及職責

產品測試階段主要由測試人員和開發人員進行參與：

• 測試人員：了解項目背景，熟悉產品的需求，通過產品需求文檔來編寫產品的測試用例，組織和邀請相關人員進行產品測試用例的評審會議，在會議上測試人員向其他參與人員講解自己測試用例的編寫原理。會議之后，測試人員對產品進行測試，在測試之前，需要向產品經理確認當前測試版本的版本號與版本名，并跟蹤提交的測試缺陷。
• 開發人員：對測試人員找到的缺陷進行代碼修復。
• 項目成員：所有項目成員在測試過程中都應盡量參與測試，提出發現的bug，讓產品在上線前得到完善。

（3）測試用例評審會議

測試用例的評審會議由測試工程師組織相關項目人員進行參與，會議過程應該著重于如下幾點：

1. 測試用例本身的描述是否清晰，是否存在二義性；
2. 是否考慮到測試用例的執行效率，往往測試用例中步驟不斷重復執行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下；
3. 是否覆蓋了所有的產品需求；
4. 是否完全遵守了產品設計需求的規定，即與PRD文檔匹配。

（4）文檔輸出

測試用例文檔：測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試產品是否可以正常上線，測試用例文檔做好標注需上傳到TAPD文檔管理中心。

產品測試報告：測試報告是把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正產品存在的質量問題提供依據，同時為產品測試驗收和交付打下基礎。

測試報告包含了測試目的、項目背景、測試安排、測試方案、測試結果、缺陷分析、測試總結等要素，完成撰寫后同樣需要上傳到TAPD文檔管理中心。

6. 產品上線階段

（1）產品上線簡介

產品上線對于項目組來說是具有里程碑意義的事件，指產品代碼從測試環境切換到正式的生產環境，外部的普通用戶通過更新APP或者打開線上網頁鏈接就可以直接對產品進行訪問。

（2）參與人員及職責

產品上線主要參與人員包含項目負責人、產品經理、開發等。

• 項目負責人：確定項目的發布版本、發布時間及發布渠道；
• 產品經理：上線前做最后的回歸測試，及時發現明顯的bug，撰寫好產品發版說明；產品上線后，撰寫產品上線發版郵件進行項目全員通知；
• 開發工程師：進行封版工作，同時經過項目負責人同意后在釘釘上提交發版申請。

（3）灰度發布

所謂灰度發布，是按照一定策略選取部分用戶，讓他們先行體驗新版本的應用，通過收集這部分用戶對新版本應用的反饋，以及對新版本功能、性能、穩定性等指標進行考核和評定，進而決定繼續放大新版本投放范圍直至全量升級或回滾至老版本。

（4）文檔輸出

產品發版說明：產品上線后的發版說明，包含產品更新的功能、范圍等，發版后需要發布發版郵件來進行項目全員通知；APP產品通過應用商店渠道進行發版，還要撰寫更新說明；

灰度測試報告：結合灰度版本的發布情況，撰寫灰度測試報告，包含產品數據總結、用戶反饋總結等，并闡述下一步具體行動方案。

#專欄作家#

壹百度，微信公眾號：倒退集，人人都是產品經理專欄作家。暢銷書《產品之旅》作者，AI、區塊鏈資深產品人，擅長多平臺產品設計。

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

題圖來自 Unsplash，基于 CC0 協議