本文來源於我所在公司的產品交付流程，比較適用於其他中小型團隊。目的主要是介紹一下產品交付過程中涉及到的幾個關鍵步驟，大家可以參考本文並結合自己團隊的實際情況，進行查漏補缺。
本文目錄
第1步：需求評估和接收
第2步：產品立項
第3步：測試用例評審
第4步：開發/測試溝通確認
第5步：上線前準備
第6步：上線後收尾
第1步：需求評估和接收
工作一：需求評估
工作描述：
需求討論，需求方描述現狀和表達期望，產品進行引導，結合場景進行需求描述，使得在需求前期能考慮到各種場景，一方是避免場景遺漏和未滿足情況；另外一方面結合場景可以較快的識別需求真偽。
需求評估，涉及到評估2個部分：一是需求是否合理；二是需求優先級。
進入需求池，將已明確的需求放進需求池內，標明需求優先級。之後高優先級的需求，會優先進入技術可行性討論階段。
涉及部門：產品（主導）、業務部門；
時間節點：V1.0版本提測-N1天；
關鍵產出：更新的需求池文檔；
備註：進入需求池前需要進行需求篩選和優先級初步判斷，這個環節也依賴於數據分析，通過數據來判斷需求場景多大、影響面多廣，從而綜合的進行需求篩選和優先級確定。
工作二：技術可行性討論
工作描述：將待可行性討論的需求彙總，然後與技術進行討論以確定實現方案。這裡需要產品初步評估什麼樣需求需要進入技術可行性討論階段，避免增加無效的討論。技術可行性討論的結果主要是需求能否實現、實現成本。
涉及部門：開發（主導）、產品；
時間節點：V1.0版本提測-N2天；
關鍵產出：完成需求方案（原型、流程圖）；
備註：這個環節前提是產品和開發明確好技術實現方案，之後產品才需要完成原型邏輯、流程圖以及相關數據統計模型。
工作三：接收需求
工作描述：需求明確可行或者需求因為技術限制做了變動方案，這時候需要和需求方溝通確認，最終讓需求方正式下達業務需求通知。主要是需求描述（現狀期望）、需求目的、需求預計上線時間等。
涉及部門：產品、業務部門（主導）；
時間節點：V1.0版本提測-N3天；
關鍵產出：需求單（word文檔）；
備註：在需求單下發之後，產品上線之前，若存在需求變更，則需要需求方提供相應的需求變更單。
第2步：產品立項
工作一：視覺確認
工作描述：主要是涉及到C端產品相關視覺，需要產品和業務部門共同進行確認，產品主要是確認原型上元素和交互，視覺是否已經呈現。業務需要確認現有視覺是否優化調整。
涉及部門：UI設計（主導）、產品、業務部門；
時間節點：V1.0版本提測+N4天；
關鍵產出：視覺交互稿
工作二：項目啟動會
工作描述：V2.0版本項目啟動會，主要是確定V2.0版本有哪些需求、預計上線時間以及各個關鍵節點時間。
涉及部門：UI設計、產品（主導）、QA、開發；
時間節點：V1.0版本提測-N5天；
關鍵產出：V2.0版本需求列表、接口定義列表、需求任務；
備註1：當產品兼顧項目時，需要給開發進行需求任務新建，若是跨開發組任務，則需要將跨組項目進行關聯。
備註2：底層接口提前上線，目的是跨組項目風險性較大，底層接口提前上線可以在一定程度上減小項目延期風險。
備註3：業務數據統計也屬於需求範圍，提前告知數據統計邏輯，有利於開發進行表結構設計，避免上線後無法有效的通知到業務數據。
第3步：測試用例評審
工作一：參與測試用例評審
工作描述：測試用例評審主要是QA針對於V2.0版本需求進行用例整理，以及解答QA和開發對於需求理解存在的細小疑問。即使是細小的邏輯遺漏，在開發中發現時可能需要花很長時間才能進行修復。提前進行測試用例評審的目的是：讓開發更清楚需求、減少因為需求邏輯不清晰導致的項目延期風險。
涉及部門：產品、QA（主導）、開發；
時間節點：V1.0版本發佈+N6天；
關鍵產出：測試用例文檔；
備註：主要是需求缺漏補充和影響面確認，以及對接口定義列表進行二次確認。
第4步：開發/測試溝通確認
工作一：開發和測試過程中溝通確認需求
工作描述：這個階段主要是進入到開發和測試階段，這個階段主要是針對異常情況的確認和溝通。前期需求明確的越清晰，這個階段需要產品確認的異常情況會越少。產品可以利用這段時間進行下個版本需求的整理。
涉及部門：產品（主導）、開發、QA（主導）；
時間節點：V2.0版本開發/測試中；
關鍵產出：原型邏輯和需求文檔完善；
備註：如果產品是兼顧項目工作，則在開發和測試階段仍需要關注項目整體進展，這個階段是產品上線主要階段，風險較大。
工作二：風險評估
工作描述：若前期需求足夠清晰，那這個階段主要是關注“人”，因為“人”這個因素會影響到事和時間，最終導致項目產生較大的風險。
涉及部門：產品（主導）、開發、測試；
時間節點：V2.0版本開發/測試中；
關鍵產出：項目進度表、產品自查表；
備註1：項目進度表是呈現項目進度情況，主要是關注開發/測試過程中的關鍵時間節點，避免因為這個環節的關鍵時間節點延期導致整個項目的延期。如果存在延期的話，那需要風險應對計劃，是進行刪減需求還是加班加點處理，這些都需要產品進行明確風險應對計劃。
備註2：產品自查表，主要是產品在項目上demo後進行模擬自查，主要是明確產品交互符合期望，另外確認產品流程基本正常，避免上線後才發現產品不是自己想要的東西。
第5步：上線前準備
工作一：數據埋點
工作描述：數據埋點主要是針對客戶端產品進行，客戶端產品的埋點需要在發版之前完成。不過越來越多的數據分析工具已經支持事前無埋點，事後定義事件名。
涉及部門：產品（主導）、開發；
時間節點：V2.0版本提測+N7天；
關鍵產出：埋點事件列表；
備註：需要確認開發是否完成埋點，以及是否正確的進行埋點，避免開發出現漏埋點和錯埋點的情況。
工作二：操作手冊和FAQ
工作描述：項目複雜度較高、跨業務部門多、影響業務主要工作的需求，在產品上線前，需要提供給不同的業務部門操作手冊以及相關FAQ，避免產品上線後大量業務反饋不瞭解需求的情況。
涉及部門：產品（主導）、業務部門；
時間節點：V2.0版本提測+N8天；
關鍵產出：系統操作手冊、FAQ文檔；
第6步：上線後收尾
工作一：上線內容通知
工作描述：通知需求影響的各個業務部門產品上線的通知，特別是客服部門，另外在通知中提供系統操作手冊和FAQ文檔。
涉及部門：產品（主導）、業務部門；
時間節點：V2.0版本發佈+1天；
關鍵產出：上線通知郵件；
工作二：數據分析及迭代方案
工作描述：產品上線後需要進行數據分析，分析的目的是為了檢驗產品上線效果和發現存在的問題。
涉及部門：產品組（主導）、數據分析；
時間節點：V2.0版本發佈+1天；
關鍵產出：數據分析報告、產品迭代方案；
備註1：數據分析報告需要結合業務數據和用戶行為數據，而不能單一隻看某一類數據。
備註2：通過數據分析，應該要發現產品的問題或者是可優化點，針對性的給到產品迭代方案，使得產品通過多個版本迭代達到最優的狀態。
總結
以上主要是適用於中小型團隊的產品交付流程，其中以下幾點大家也需要額外關注的：
需求過濾：對於業務部門來說，需求都重要、都緊急，所以產品更應該以專業的角度評估需求合理性，敢於給業務部門提建議和說“不”。一味的委曲求全，並不會得到業務部門的尊重；反而向需求方展現出自己的專業性，更能得到業務部門的尊重。
需求前置：上述N1、N2、N3……這些時間點雖然不確定，但是想表達的就是需求前置。至少有1個版本在進行中、1個版本已立項、1個版本需求大致已確認，這樣的產品規劃迭代週期對於產品來說，會是有條不紊的狀態。
持續性關注：主要是項目複雜度高且開發水平較弱、測試不熟悉業務的項目需要持續性關注，避免因為人的因素導致項目延期。
跨開發組任務：為了避免項目延期的話，儘量讓底層接口提前一個發佈週期上線。（同樣依賴於需求前置）
以上是基於我們公司現有的產品交付流程進行整理彙總，可能存在一定的侷限性，僅供參考，歡迎大家多交流學習！
#專欄作家#
董小白，人人都是產品經理專欄作家。喜歡研究各類好玩好用的APP，關注出行、電商等領域；擅長整理和分析APP亮點功能設計。
閱讀更多 實體小程序新零售燈塔 的文章
