本文來源于我所在公司的產(chǎn)品交付流程，比較適用于其他中小型團隊。目的主要是介紹一下產(chǎn)品交付過程中涉及到的幾個關鍵步驟，大家可以參考本文并結合自己團隊的實際情況，進行查漏補缺。

本文目錄

第1步：需求評估和接收

第2步：產(chǎn)品立項

第3步：測試用例評審

第4步：開發(fā)/測試溝通確認

第5步：上線前準備

第6步：上線后收尾

第1步：需求評估和接收

工作一：需求評估

工作描述：

1. 需求討論，需求方描述現(xiàn)狀和表達期望，產(chǎn)品進行引導，結合場景進行需求描述，使得在需求前期能考慮到各種場景，一方是避免場景遺漏和未滿足情況；另外一方面結合場景可以較快的識別需求真?zhèn)巍?/li>
2. 需求評估，涉及到評估2個部分：一是需求是否合理；二是需求優(yōu)先級。
3. 進入需求池，將已明確的需求放進需求池內(nèi)，標明需求優(yōu)先級。之后高優(yōu)先級的需求，會優(yōu)先進入技術可行性討論階段。

涉及部門：產(chǎn)品（主導）、業(yè)務部門；

時間節(jié)點：V1.0版本提測-N1天；

關鍵產(chǎn)出：更新的需求池文檔；

備注：進入需求池前需要進行需求篩選和優(yōu)先級初步判斷，這個環(huán)節(jié)也依賴于數(shù)據(jù)分析，通過數(shù)據(jù)來判斷需求場景多大、影響面多廣，從而綜合的進行需求篩選和優(yōu)先級確定。

工作二：技術可行性討論

工作描述：將待可行性討論的需求匯總，然后與技術進行討論以確定實現(xiàn)方案。這里需要產(chǎn)品初步評估什么樣需求需要進入技術可行性討論階段，避免增加無效的討論。技術可行性討論的結果主要是需求能否實現(xiàn)、實現(xiàn)成本。

涉及部門：開發(fā)（主導）、產(chǎn)品；

時間節(jié)點：V1.0版本提測-N2天；

關鍵產(chǎn)出：完成需求方案（原型、流程圖）；

備注：這個環(huán)節(jié)前提是產(chǎn)品和開發(fā)明確好技術實現(xiàn)方案，之后產(chǎn)品才需要完成原型邏輯、流程圖以及相關數(shù)據(jù)統(tǒng)計模型。

工作三：接收需求

工作描述：需求明確可行或者需求因為技術限制做了變動方案，這時候需要和需求方溝通確認，最終讓需求方正式下達業(yè)務需求通知。主要是需求描述（現(xiàn)狀期望）、需求目的、需求預計上線時間等。

涉及部門：產(chǎn)品、業(yè)務部門（主導）；

時間節(jié)點：V1.0版本提測-N3天；

關鍵產(chǎn)出：需求單（word文檔）；

備注：在需求單下發(fā)之后，產(chǎn)品上線之前，若存在需求變更，則需要需求方提供相應的需求變更單。

第2步：產(chǎn)品立項

工作一：視覺確認

工作描述：主要是涉及到C端產(chǎn)品相關視覺，需要產(chǎn)品和業(yè)務部門共同進行確認，產(chǎn)品主要是確認原型上元素和交互，視覺是否已經(jīng)呈現(xiàn)。業(yè)務需要確認現(xiàn)有視覺是否優(yōu)化調(diào)整。

涉及部門：UI設計（主導）、產(chǎn)品、業(yè)務部門；

時間節(jié)點：V1.0版本提測+N4天；

關鍵產(chǎn)出：視覺交互稿

工作二：項目啟動會

工作描述：V2.0版本項目啟動會，主要是確定V2.0版本有哪些需求、預計上線時間以及各個關鍵節(jié)點時間。

涉及部門：UI設計、產(chǎn)品（主導）、QA、開發(fā)；

時間節(jié)點：V1.0版本提測-N5天；

關鍵產(chǎn)出：V2.0版本需求列表、接口定義列表、需求任務；

備注1：當產(chǎn)品兼顧項目時，需要給開發(fā)進行需求任務新建，若是跨開發(fā)組任務，則需要將跨組項目進行關聯(lián)。

備注2：底層接口提前上線，目的是跨組項目風險性較大，底層接口提前上線可以在一定程度上減小項目延期風險。

備注3：業(yè)務數(shù)據(jù)統(tǒng)計也屬于需求范圍，提前告知數(shù)據(jù)統(tǒng)計邏輯，有利于開發(fā)進行表結構設計，避免上線后無法有效的通知到業(yè)務數(shù)據(jù)。

第3步：測試用例評審

工作一：參與測試用例評審

工作描述：測試用例評審主要是QA針對于V2.0版本需求進行用例整理，以及解答QA和開發(fā)對于需求理解存在的細小疑問。即使是細小的邏輯遺漏，在開發(fā)中發(fā)現(xiàn)時可能需要花很長時間才能進行修復。提前進行測試用例評審的目的是：讓開發(fā)更清楚需求、減少因為需求邏輯不清晰導致的項目延期風險。

涉及部門：產(chǎn)品、QA（主導）、開發(fā)；

時間節(jié)點：V1.0版本發(fā)布+N6天；

關鍵產(chǎn)出：測試用例文檔；

備注：主要是需求缺漏補充和影響面確認，以及對接口定義列表進行二次確認。

第4步：開發(fā)/測試溝通確認

工作一：開發(fā)和測試過程中溝通確認需求

工作描述：這個階段主要是進入到開發(fā)和測試階段，這個階段主要是針對異常情況的確認和溝通。前期需求明確的越清晰，這個階段需要產(chǎn)品確認的異常情況會越少。產(chǎn)品可以利用這段時間進行下個版本需求的整理。

涉及部門：產(chǎn)品（主導）、開發(fā)、QA（主導）；

時間節(jié)點：V2.0版本開發(fā)/測試中；

關鍵產(chǎn)出：原型邏輯和需求文檔完善；

備注：如果產(chǎn)品是兼顧項目工作，則在開發(fā)和測試階段仍需要關注項目整體進展，這個階段是產(chǎn)品上線主要階段，風險較大。

工作二：風險評估

工作描述：若前期需求足夠清晰，那這個階段主要是關注“人”，因為“人”這個因素會影響到事和時間，最終導致項目產(chǎn)生較大的風險。

涉及部門：產(chǎn)品（主導）、開發(fā)、測試；

時間節(jié)點：V2.0版本開發(fā)/測試中；

關鍵產(chǎn)出：項目進度表、產(chǎn)品自查表；

備注1：項目進度表是呈現(xiàn)項目進度情況，主要是關注開發(fā)/測試過程中的關鍵時間節(jié)點，避免因為這個環(huán)節(jié)的關鍵時間節(jié)點延期導致整個項目的延期。如果存在延期的話，那需要風險應對計劃，是進行刪減需求還是加班加點處理，這些都需要產(chǎn)品進行明確風險應對計劃。

備注2：產(chǎn)品自查表，主要是產(chǎn)品在項目上demo后進行模擬自查，主要是明確產(chǎn)品交互符合期望，另外確認產(chǎn)品流程基本正常，避免上線后才發(fā)現(xiàn)產(chǎn)品不是自己想要的東西。

第5步：上線前準備

工作一：數(shù)據(jù)埋點

工作描述：數(shù)據(jù)埋點主要是針對客戶端產(chǎn)品進行，客戶端產(chǎn)品的埋點需要在發(fā)版之前完成。不過越來越多的數(shù)據(jù)分析工具已經(jīng)支持事前無埋點，事后定義事件名。

涉及部門：產(chǎn)品（主導）、開發(fā)；

時間節(jié)點：V2.0版本提測+N7天；

關鍵產(chǎn)出：埋點事件列表；

備注：需要確認開發(fā)是否完成埋點，以及是否正確的進行埋點，避免開發(fā)出現(xiàn)漏埋點和錯埋點的情況。

工作二：操作手冊和FAQ

工作描述：項目復雜度較高、跨業(yè)務部門多、影響業(yè)務主要工作的需求，在產(chǎn)品上線前，需要提供給不同的業(yè)務部門操作手冊以及相關FAQ，避免產(chǎn)品上線后大量業(yè)務反饋不了解需求的情況。

涉及部門：產(chǎn)品（主導）、業(yè)務部門；

時間節(jié)點：V2.0版本提測+N8天；

關鍵產(chǎn)出：系統(tǒng)操作手冊、FAQ文檔；

第6步：上線后收尾

工作一：上線內(nèi)容通知

工作描述：通知需求影響的各個業(yè)務部門產(chǎn)品上線的通知，特別是客服部門，另外在通知中提供系統(tǒng)操作手冊和FAQ文檔。

涉及部門：產(chǎn)品（主導）、業(yè)務部門；

時間節(jié)點：V2.0版本發(fā)布+1天；

關鍵產(chǎn)出：上線通知郵件；

工作二：數(shù)據(jù)分析及迭代方案

工作描述：產(chǎn)品上線后需要進行數(shù)據(jù)分析，分析的目的是為了檢驗產(chǎn)品上線效果和發(fā)現(xiàn)存在的問題。

涉及部門：產(chǎn)品組（主導）、數(shù)據(jù)分析；

時間節(jié)點：V2.0版本發(fā)布+1天；

關鍵產(chǎn)出：數(shù)據(jù)分析報告、產(chǎn)品迭代方案；

備注1：數(shù)據(jù)分析報告需要結合業(yè)務數(shù)據(jù)和用戶行為數(shù)據(jù)，而不能單一只看某一類數(shù)據(jù)。

備注2：通過數(shù)據(jù)分析，應該要發(fā)現(xiàn)產(chǎn)品的問題或者是可優(yōu)化點，針對性的給到產(chǎn)品迭代方案，使得產(chǎn)品通過多個版本迭代達到最優(yōu)的狀態(tài)。

總結

以上主要是適用于中小型團隊的產(chǎn)品交付流程，其中以下幾點大家也需要額外關注的：

1. 需求過濾：對于業(yè)務部門來說，需求都重要、都緊急，所以產(chǎn)品更應該以專業(yè)的角度評估需求合理性，敢于給業(yè)務部門提建議和說“不”。一味的委曲求全，并不會得到業(yè)務部門的尊重；反而向需求方展現(xiàn)出自己的專業(yè)性，更能得到業(yè)務部門的尊重。
2. 需求前置：上述N1、N2、N3……這些時間點雖然不確定，但是想表達的就是需求前置。至少有1個版本在進行中、1個版本已立項、1個版本需求大致已確認，這樣的產(chǎn)品規(guī)劃迭代周期對于產(chǎn)品來說，會是有條不紊的狀態(tài)。
3. 持續(xù)性關注：主要是項目復雜度高且開發(fā)水平較弱、測試不熟悉業(yè)務的項目需要持續(xù)性關注，避免因為人的因素導致項目延期。
4. 跨開發(fā)組任務：為了避免項目延期的話，盡量讓底層接口提前一個發(fā)布周期上線。（同樣依賴于需求前置）

以上是基于我們公司現(xiàn)有的產(chǎn)品交付流程進行整理匯總，可能存在一定的局限性，僅供參考，歡迎大家多交流學習！

#專欄作家#

董小白，人人都是產(chǎn)品經(jīng)理專欄作家。喜歡研究各類好玩好用的APP，關注出行、電商等領域；擅長整理和分析APP亮點功能設計。

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

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