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

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

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

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

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

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

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

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

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

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

接著上一回說 版的日常需求流程，本篇是乙個日常需求的提出到發布的流水賬，有個挺pp的圖附在後面。大需求自然是要起乙個專案的，不再討論之列，但原則上也是相通的。需求是產品變動的發起方，所以在開始階段涉及會比較多，我覺得可以用三個會議來概括。這裡不要理解成嚴格的會議室裡幾個人正襟危坐，更多的是兩三個人圍...

產品設計流程

產品開發流程和專案管理流程時常被大家關注，合理的過程是團隊協作的基礎。在大家把產品的功能和特性放在第一位的時候，開發和專案的管理至關重要，而產品的設計卻往往被忽視，開發團隊會為了那些晦澀難懂 令人費解的功能而夸夸其談，複雜的產品特性通常會迫使產品團隊放棄優雅簡潔的設計，使用者體驗永遠是可能是專案過程...

產品設計體會（十六） Feature List

看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...