本文來源于我所在公司的產(chǎn)品交付流程，比較適用于其他中小型團隊绞蹦。目的主要是介紹一下產(chǎn)品交付過程中涉及到的幾個關鍵步驟力奋，大家可以參考本文并結合自己團隊的實際情況，進行查漏補缺幽七。
本文目錄：
第1步：需求評估和接收
第2步：產(chǎn)品立項
第3步：測試用例評審
第4步：開發(fā)/測試溝通確認
第5步：上線前準備
第6步：上線后收尾
第1步：需求評估和接收
工作一：需求評估
工作描述：
需求討論景殷，需求方描述現(xiàn)狀和表達期望，產(chǎn)品進行引導澡屡，結合場景進行需求描述猿挚，使得在需求前期能考慮到各種場景，一方是避免場景遺漏和未滿足情況驶鹉；另外一方面結合場景可以較快的識別需求真?zhèn)巍?/p>
需求評估绩蜻，涉及到評估2個部分，一是需求是否合理梁厉；二是需求優(yōu)先級辜羊，需求評估的形式可參考《需求分析：它從哪里來，到哪里去词顾？》
進入需求池，將已明確的需求放進需求池內(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)品交付流程進行整理匯總，可能存在一定的局限性娱据，僅供參考蚪黑，歡迎大家多交流學習！
