接著上一回說網(wǎng)店版的日常小需求的發(fā)布流程，本篇是一個日常需求的提出到發(fā)布的流水賬，后面有圖有真相，對于小公司應(yīng)該比較實用。大到功能模塊級的需求自然是要起一個項目的，不再討論之列，但原理上也是相通的。

需求人員是產(chǎn)品變動的發(fā)起方，所以前期的需求相關(guān)會議會比較多，我覺得可以用三個會議來概括。這里不要理解成嚴格的會議室里幾個人正襟危坐，更多的是兩三個人圍在電腦前談幾分鐘就搞定。

（iamsujie補，可以結(jié)合“1010：需求管理”那篇來讀。）

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

第二， 需求評審會?！靶枨笾小钡男枨?，PD覺得需求分析差不多了，就會召集一個評審會，大家會一起討論下這么做有哪些問題，PD收集到意見以后去修改需求，這是一個視需求復(fù)雜度可能反復(fù)多次的環(huán)節(jié)，當(dāng)大方向都沒問題時，評審?fù)ㄟ^。

第三， 需求確認會。在進入實施前，最后要有個需求確認（這個通常也可能和最后一次需求評審會合并），具體負責(zé)開發(fā)、測試的同學(xué)都要參加，大家一起保證對需求的理解是一樣的，沒問題后，就開始做吧！

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

（iamsujie補：這其實是符合敏捷思想的，小步快跑，不要需求過度，利用開發(fā)和測試過程完善需求，特別是對市場環(huán)境、用戶情況等等變化超級的互聯(lián)網(wǎng)產(chǎn)品。）

最后一步，當(dāng)功能上到測試環(huán)境之后，負責(zé)的PD需要去確認一下與自己設(shè)計是否相符，或者說是做一下驗收測試 & 代表用戶做一下可用性測試，沒問題的話，就ok發(fā)布，結(jié)束一個小需求。

當(dāng)然功能上線后會有升級的可能，或是客戶反饋或是自己發(fā)現(xiàn)問題，但我們把這視為一個新的需求，重新進入流程，或者當(dāng)作一個bug。

該文章出自《iamsujie的產(chǎn)品設(shè)計》,原文鏈接：http://iamsujie.com/3000/3006/