## 產品設計體會（六）——再談流程 接著上一回說網店版的日常需求流程，本篇是一個日常需求的提出到發布的流水賬，有個挺pp的圖附在后面。大需求自然是要起一個項目的，不再討論之列，但原則上也是相通的。 ? 需求是產品變動的發起方，所以在開始階段涉及會比較多，我覺得可以用三個會議來概括。這里不要理解成嚴格的會議室里幾個人正襟危坐，更多的是兩三個人圍在電腦前談幾分鐘就搞定。 ? 第一，?? 需求pk會。一直覺得pk這個詞用的很傳神，每個PD帶著自己的需求來討論，爭奪那僅有的開發和測試資源，人性的本能讓每個人都極力的維護自己提出的需求，設法反駁別人的，當然出發點都是為了客戶，最終會達成一致，哪些進入“需求分析中”，哪些“HOLD”。 第二，?? 需求評審會。PD覺得需求分析差不多了，就會召集一個評審會，大家會一起討論下這么做有哪些問題，PD收集到意見以后去修改需求，這是一個視需求復雜度可能反復多次的環節，當大方向都沒問題時，評審通過。 第三，?? 需求確認會。在進入實施前，最后要有個需求確認，具體負責開發、測試的同學都要參加，大家一起保證對需求的理解是一樣的，沒問題后，就開始做吧！ ? 接下來進入開發和測試階段，PD需要不斷的和開發、測試確認各種細節，一直想在之前的步驟中盡量減少這種費時費力的確認（也許真的已經減少了不少），但事實證明細節總是多到無法預計，甚至有的會要上線后才發現。 ? 最后一步，當功能上到測試環境之后，負責的PD需要去確認一下與自己設計是否相符，沒問題的話，就ok發布，結束一個小需求。 ? 當然上線后會有升級的可能，或是客戶反饋或是自己發現問題，但我們把這視為一個新的需求，重新進入流程，或者當作一個bug。