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

一、文檔制定目的

本文檔的制定，主要是為了規(guī)范公司不同項目組之間，產(chǎn)品、設(shè)計、研發(fā)、測試等童鞋的工作標(biāo)準(zhǔn)和協(xié)作流程。通過實施完整的產(chǎn)品研發(fā)管理流程，做到在重點環(huán)節(jié)都有相應(yīng)的工作文檔產(chǎn)出及任務(wù)記錄作為項目進(jìn)展的沉淀，盡量減少人為因素對整個項目的干擾和影響。

二、整體項目開發(fā)流程

互聯(lián)網(wǎng)產(chǎn)品整體研發(fā)管理流程如下圖所示，具體包含6個環(huán)節(jié)：

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

三、項目管理工具

1. TAPD協(xié)作工具

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

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

實施之前，需要由項目負(fù)責(zé)人在TAPD內(nèi)創(chuàng)建一個項目，并邀請自己的項目組成員進(jìn)入到這個項目，這樣就可以開始自己項目的團(tuán)隊協(xié)作之旅了。

2. 每日項目站會

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

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

會議過程中，項目負(fù)責(zé)人可以結(jié)合進(jìn)度及任務(wù)優(yōu)先級，對項目成員的任務(wù)做相關(guān)調(diào)整；項目站會結(jié)束后，項目負(fù)責(zé)人可將每日站會小結(jié)發(fā)到微信群里，將項目進(jìn)展信息同步給所有人。

四、具體實施流程規(guī)范

1. 需求管理階段

（1） 需求管理簡介

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

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

（2）參與人員及職責(zé)

需求管理階段的參與人員主要是產(chǎn)品經(jīng)理，當(dāng)然項目里的任何一個成員都能提出自己的產(chǎn)品需求建議（包含技術(shù)工程師提出的代碼優(yōu)化需求等），具體職責(zé)如下：

• 項目成員：任何一個項目成員都能提出自己的產(chǎn)品需求。
• 產(chǎn)品經(jīng)理：負(fù)責(zé)需求的采集、分析、篩選，負(fù)責(zé)管理和維護(hù)產(chǎn)品需求池，并制定版本迭代計劃。

（3）需求池管理

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

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

（4）文檔輸出

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

市場調(diào)研文檔：產(chǎn)品經(jīng)理做的市場調(diào)研、用戶訪談、競品分析等一系列工作所產(chǎn)出的文檔，同樣，需要將這些文檔上傳到TAPD中進(jìn)行管理。

2. 產(chǎn)品設(shè)計階段

（1）產(chǎn)品設(shè)計簡介

產(chǎn)品設(shè)計階段主要由產(chǎn)品經(jīng)理將需求轉(zhuǎn)化為產(chǎn)品方案的輸出，包含基本的功能流程設(shè)計、原型設(shè)計、PRD文檔撰寫等工作。

（2）參與人員及職責(zé)

產(chǎn)品設(shè)計階段主要由產(chǎn)品經(jīng)理參與，負(fù)責(zé)輸出整體產(chǎn)品方案設(shè)計，包含需求背景、需求目標(biāo)、及具體產(chǎn)品方案等；完成PRD文檔的撰寫后，需要組織和邀請相關(guān)人員進(jìn)行產(chǎn)品需求評審的會議，在會議上闡述清楚自己的產(chǎn)品方案。

（3）產(chǎn)品需求評審會議

由產(chǎn)品經(jīng)理來進(jìn)行組織的一次會議，需求評審目的是讓項目的參與者（這里主要指設(shè)計研發(fā)測試）能夠快速理解產(chǎn)品的意圖，認(rèn)可采用的方案。

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

關(guān)于需求評審的推進(jìn)步驟：

1. 先說我們這次需求的目標(biāo)與目的；
2. 在目標(biāo)與目的達(dá)成一致的基礎(chǔ)上，闡述具體的產(chǎn)品解決方案；
3. 經(jīng)過討論后，產(chǎn)品經(jīng)理整理好會議結(jié)果進(jìn)行郵件通知，如果PRD方案調(diào)整較小則可以不用進(jìn)行第二次需求評審，如果方案調(diào)整較大建議進(jìn)行第二次需求評審。

（4）文檔輸出

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

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

3. UI設(shè)計階段

（1） UI設(shè)計簡介

UI設(shè)計階段主要由UI設(shè)計師來完成，包含做界面的視覺設(shè)計，進(jìn)行布局、配色、樣式不同風(fēng)格的嘗試等。

（2）參與人員及職責(zé)

UI設(shè)計階段主要由UI設(shè)計師、產(chǎn)品經(jīng)理等進(jìn)行參與：

• UI設(shè)計師：完成UI設(shè)計稿的設(shè)計、進(jìn)行UI設(shè)計稿的評審宣講等。
• 產(chǎn)品經(jīng)理：對UI設(shè)計進(jìn)行相應(yīng)的把控。

（3）UI設(shè)計稿評審會議

UI設(shè)計稿的評審可由UI設(shè)計師進(jìn)行組織，也可由產(chǎn)品經(jīng)理來協(xié)助設(shè)計師進(jìn)行組織，邀請項目參與人員進(jìn)行相關(guān)評審，評審內(nèi)容主要如下：

整體方面：

• 設(shè)計理念是否與產(chǎn)品定位符合，整體風(fēng)格是否與產(chǎn)品氣質(zhì)相符；
• 色調(diào)搭配是否舒適，整體的色調(diào)是否保持一致規(guī)范；
• 版面樣式是否平衡，有沒有存在一邊倒的設(shè)計，或者整體不夠協(xié)調(diào)；
• 內(nèi)容層級是否清晰明了。

細(xì)節(jié)方面：

• 設(shè)計元素的選擇是否與整體風(fēng)格搭配，包括大小，色彩，質(zhì)感等；
• 圖標(biāo)、button等元素是否與整體界面統(tǒng)一和諧；
• 文字、元素等細(xì)節(jié)是否存在冗余或錯誤、遺漏等。

（4） 文檔輸出

UI 設(shè)計稿：通過設(shè)計軟件進(jìn)行創(chuàng)作的UI設(shè)計稿件，做好標(biāo)注后上傳到TAPD的文檔管理中心。

4. 產(chǎn)品研發(fā)階段

（1）產(chǎn)品研發(fā)簡介

產(chǎn)品研發(fā)階段主要是指各類型的工程師為實現(xiàn)產(chǎn)品功能、頁面、邏輯所做的代碼研發(fā)工作。

（2）參與人員及職責(zé)

• 前端工程師：搭建前端框架，根據(jù)原型設(shè)計稿/UI設(shè)計稿實現(xiàn)產(chǎn)品前端的靜態(tài)頁面，在靜態(tài)頁面的基礎(chǔ)上綁定數(shù)據(jù)接口；
• 后端工程師：搭建后端框架，結(jié)合需求文檔提供產(chǎn)品功能所需的各類接口，并與前端一起進(jìn)行接口調(diào)試工作；
• 算法工程師：搭建算法框架，為產(chǎn)品提供算法方面的研發(fā)工作。

（3）代碼庫管理

①代碼庫權(quán)限分配

• 使用公司內(nèi)建的GitLab保存和管理屬于本公司的代碼資源；
• 公司總技術(shù)負(fù)責(zé)人和項目直接負(fù)責(zé)人有項目的Master權(quán)限；
• 負(fù)責(zé)項目的權(quán)限管理；
• 項目內(nèi)人員管理；
• 受保護(hù)分支的操作；
• 參與項目研發(fā)的技術(shù)人員設(shè)置為Developer權(quán)限；
• 白盒測試人員和相關(guān)人員設(shè)置為Guest權(quán)限。

②代碼庫分支管理方法

分支:

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

使用：

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

5. 產(chǎn)品測試階段

（1）產(chǎn)品測試簡介

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

研發(fā)團(tuán)隊在這個階段要對缺陷進(jìn)行修改，測試工程師則需要跟蹤缺陷的修復(fù)情況。

（2）參與人員及職責(zé)

產(chǎn)品測試階段主要由測試人員和開發(fā)人員進(jìn)行參與：

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

（3）測試用例評審會議

測試用例的評審會議由測試工程師組織相關(guān)項目人員進(jìn)行參與，會議過程應(yīng)該著重于如下幾點：

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

（4）文檔輸出

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

產(chǎn)品測試報告：測試報告是把測試的過程和結(jié)果寫成文檔，對發(fā)現(xiàn)的問題和缺陷進(jìn)行分析，為糾正產(chǎn)品存在的質(zhì)量問題提供依據(jù)，同時為產(chǎn)品測試驗收和交付打下基礎(chǔ)。

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

6. 產(chǎn)品上線階段

（1）產(chǎn)品上線簡介

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

（2）參與人員及職責(zé)

產(chǎn)品上線主要參與人員包含項目負(fù)責(zé)人、產(chǎn)品經(jīng)理、開發(fā)等。

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

（3）灰度發(fā)布

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

（4）文檔輸出

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

灰度測試報告：結(jié)合灰度版本的發(fā)布情況，撰寫灰度測試報告，包含產(chǎn)品數(shù)據(jù)總結(jié)、用戶反饋總結(jié)等，并闡述下一步具體行動方案。

#專欄作家#

壹百度，微信公眾號：倒退集，人人都是產(chǎn)品經(jīng)理專欄作家。暢銷書《產(chǎn)品之旅》作者，AI、區(qū)塊鏈資深產(chǎn)品人，擅長多平臺產(chǎn)品設(shè)計。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議