產品設計體會（六）——再談流程

接著上一回說網店版的日常需求流程，本篇是一個日常需求的提出到發布的流水賬，有個挺pp的圖附在後面。大需求自然是要起一個項目的，不再討論之列，但原則上也是相通的。

 

需求是產品變動的發起方，所以在開始階段涉及會比較多，我覺得可以用三個會議來概括。這裡不要理解成嚴格的會議室裡幾個人正襟危坐，更多的是兩三個人圍在電腦前談幾分鐘就搞定。

 

第一，   需求pk會。一直覺得pk這個詞用的很傳神，每個PD帶著自己的需求來討論，爭奪那僅有的開發與測試資源，人性的本能讓每個人都極力的維護自己提出的需求，設法反駁別人的，當然出發點都是為了客戶，最終會達成一致，哪些進入“需求分析中”，哪些“HOLD”。

第二，   需求評審會。PD覺得需求分析差不多了，就會召集一個評審會，大家會一起討論下這麼做有哪些問題，PD收集到意見以後去修改需求，這是一個視需求複雜度可能反覆多次的環節，當大方向都沒問題時，評審通過。

第三，   需求確認會。在進入實施前，最後要有個需求確認，具體負責開發、測試的同學都要參加，大家一起保證對需求的理解是一樣的，沒問題後，就開始做吧！

 

接下來進入開發與測試階段，PD需要不斷的和開發、測試確認各種細節，一直想在之前的步驟中盡量減少這種費時費力的確認（也許真的已經減少了不少），但事實證明細節總是多到無法預計，甚至有的會要上線後才發現。

 

最後一步，當功能上到測試環境之後，負責的PD需要去確認一下與自己設計是否相符，沒問題的話，就ok發布，結束一個小需求。

 

當然上線後會有升級的可能，或是客戶回函或是自己發現問題，但我們把這視為一個新的需求，重新進入流程，或者當作一個bug。