【小廣告】今天在我的強烈要求下，出院了，進入在家休息階段，本週六去醫院拆線，發一篇慶祝~~~
敏捷（agile
）的乙個特點，先確定專案時間，專業點叫「迭代週期」，然後有乙個人員相對固定的團隊，意味著專案資源，要保證專案品質，根據專案的「多快好省」原則，最後能變得只能是量——專案範圍，前段寫過一篇
如何做好「老闆專案」
裡也有相關描述。
那麼，某個專案裡，做多少需求到底怎麼定？這個過程不妨用下圖來表示，這張圖也是pd的需求過程圖中的一小部分，即
「pd @ alisoft
做什麼」這張圖
裡最左邊乙個箭頭裡的「需求分析」那個小框，以後有機會再把全圖展開來說。
同學們可以先回顧一下之前說過的
excel功能列表
和需求管理**
，產品團隊的一項日常工作就是採集產品干係人，即「廣義使用者」，提過來的各種需求，並
整理轉化為產品需求
，即圖中的「需求轉化」，通常轉化之前我們用mindmap較自由的表達，轉化之後就成了excel裡的功能列表。採集到這個需求的pd，自己可以先「確定屬性」，即這個需求是屬於產品的哪個模組？是基本、擴充套件、增值功能？是功能、效能、使用者體驗方面的？等等，屬性的維度大家可以按照產品的不同自由定義，原則是為了便於需求的管理。
這樣我們得到的feature list，就有必要每隔一段時間、或是新需求積累到一定數量、或是由特別事件觸發，拿出來大家一起過一遍，這是最關鍵的，即圖中用紅色突出的「確定商業價值（產品內pk）」。我們的經驗，商業價值由單個pd確定風險很大，所以這個步驟是pd團隊集體討論，再叫上有必要的干係人，比如銷售、服務。對於商業價值可以從多個維度描述，並加權平均得到綜合的商業價值，詳細描述可參見
單向需求卡片
，但絕大多數情況下，我們發現只用乙個值的高中低，或者5、4、3、2、1分來衡量就足夠了。具體討論的時候，大家充分表達意見，最終往往是會場上級別最高的人綜合以後說乙個數字，這是現實，也是一種高效的辦法，我想過投票、群體打分的方式，可是實施起來成本太高。
注意一點，討論商業價值的會議上，會把所有狀態為「待討論」的功能點都過一遍，散會的時候，它們的狀態一定要變化，或是進入「需求中」、或是被「拒絕」、或是「暫緩」。拒絕的需求是被認為對產品的商業目的沒有價值的，而暫緩的需求是「有價值，但是現在不做」的，通常要表明重啟的條件，比如「3個月後再拿出來討論」、「某相關產品實現某功能後再拿出來討論」等等。
對於狀態變為「需求中」的功能點，下一步就是初定工作量了，因為需求不明確，所以只是簡單的評估，和真實情況的匹配程度很取決於經驗,要靠不斷的實踐來反覆修正。我們通常經歷的專案，三大類人力資源是「產品、開發、測試」，用團隊裡的瓶頸資源做評估基準，所以我們一般評估每個功能點的開發工程師工作量，因為在我們的團隊裡通常產品、測試資源相對可以調配，這個大家視自己團隊的情況靈活應用。具體的評估，通常是類似技術經理的角色來做，評估者按照自己做需要多少時間，乘以乙個係數確定，這個係數一般大於1。
繼續，既然對於每個迭代週期，我們有多少時間、多少人是早就知道的，那麼可用工作量是多少「人日」，也就知道了。有了每個功能點的商業價值和工作量，很自然的就能算出價效比，簡單的說即「商業價值/開發工作量」，我們把feature list按照價效比從大到小排序，再對應考察每行評估出來的開發工作量，從上到下依次納入專案，我們的可用工作量能做多少個功能點，一目了然。
上面談到的這些，也就是一步步確定某個專案能做多少需求的過程。
最後，我們把這些要做的功能點合在一起，把「需求打包」，再往下就要做這個
專案的brd
了。brd通過，立項之後，再全程跟蹤某個需求的進度，上述整個過程就是一步步確定某個需求的各種屬性的過程，而對某個需求的描述，可以用下面的**來表示（不妨起個名字叫做「乙個需求的dna」），表中紅色星號表示的專案，是我心目中的必填項。
這個過程完全是定量的，也就回答了「做多少」的問題。但，真實情況哪會這麼簡單明瞭，下面再說幾個需要注意的地方。
第一，需求打包最好打類似的功能點，是否類似取決於需求的屬性，「確定屬性」這步做的事情起作用了，一般來說業務上有邏輯關係的需求才會包含乙個專案裡，否則就是乙個純粹修修補補的「小需求專案」了。
第二，需求依賴，功能點互相之間有依賴關係，那沒辦法，只能先做某些功能，應該在feature list裡註明；功能點與人力資源之間的依賴關係也會經常存在，在這裡評估工作量的時候不會考慮「誰來做」的問題，但是在後續立項，組建團隊的時候需要注意，當然長期來說，為了避免這類風險，提公升與平衡團隊成員的能力是王道。
第三，功能點的粒度大小問題，商業價值很高的功能，如果細分的話，我們也會發現其中有價值相對低的部分，所以功能點的粒度應該盡量細，前提是細化引起的管理成本上公升在可接受的範圍內。具體細到多少，也只能具體情況具體分析，我想工作量的最小單位總不能超過「5人日」吧。
產品設計體會（五六） 《需求工程》培訓記錄
參加了2天的名為 產品經理需求工程實務 的培訓，和去年的 產品需求管理 培訓內容大約有60 的重合吧，但經過一年，還是聽出了大於40 的新東西。有關需求 需要 need，心理狀態？懷疑與want記反了 慾望 want，實物 需求 demand 自己看到過另一種說法，need是客觀上需要，want是主...
產品設計體會（1000）使用者與需求，系列說明
食色性也，一位同學給出過很扯蛋的解釋 食是為了生存，保證個體延續，色是為了繁衍，保證種族延續，這是生物，當然包括人，的本性，即最基本需求。一直很贊同馬斯洛的需要層次理論 需求深挖到底，總是那幾種最基本的需要。為什麼人會有需要？因為生活中存在太多的問題，而問題就是 理想與現實的差距 那麼使用者有 減少...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...