確定：

　　確定需求往往是承接需求調(diào)研而來，目的是搞清楚產(chǎn)品部門究竟要解決的是什么問題，有時(shí)候業(yè)務(wù)部門會(huì)要求你能為他們做到些什么，但這種要求往往過 于含糊，你還需要再和他們多了解一些信息，才有可能真正了解他們希望得到是什么，避免發(fā)生買個(gè)MBP回來只為裝了winxp玩掃雷這樣的杯具……

　　在確定環(huán)節(jié)中，這只完成了一半的工作;接下來我們需要知道對(duì)應(yīng)這個(gè)需求，會(huì)有哪些角色來使用，我們需要能夠?qū)@些角色涉及到的不同需求做出細(xì)分。這也是需要和業(yè)務(wù)/需求部門溝通好的。

　　分解：

　　分解的意義在于把大問題化解為小問題，變成一個(gè)個(gè)可控的模塊，注意這里是說的可控是指你可以通過一定的約束條件和已知存在的變量來實(shí)現(xiàn)對(duì)問題的描述。經(jīng)?？吹降乃^需求拆解只不過是把業(yè)務(wù)部門的需求換個(gè)描述方式，這種糊弄人的做法要不得，山寨，害人害己。

　　大問題變成了小問題，我們就可以來討論如何去實(shí)現(xiàn)了。

　　至于該如何把大的需求拆解，這里提供兩種思路：

　　1、流程驅(qū)動(dòng)：根據(jù)業(yè)務(wù)流程和業(yè)務(wù)需求建立對(duì)應(yīng)的uml，或者也可以對(duì)應(yīng)每個(gè)角色建立起一個(gè)虛擬人物，把整個(gè)業(yè)務(wù)流程完整走一遍，這樣可以模擬 出實(shí)際操作中會(huì)出現(xiàn)哪些具體問題，在完成最終的業(yè)務(wù)目標(biāo)前，可能會(huì)出現(xiàn)的階段性目標(biāo)有哪些，同時(shí)又會(huì)有什么樣零星的小需求出現(xiàn)。很多這些過程中的需求是業(yè) 務(wù)部門不會(huì)提及的，你有責(zé)任告訴他們這些情況。

　　2、公式驅(qū)動(dòng)：以應(yīng)用類產(chǎn)品舉例，如果一個(gè)公司可以同時(shí)向用戶提供兩種服務(wù)A和B，二者的利潤(rùn)不同，同時(shí)又會(huì)受到市場(chǎng)季節(jié)性需求變化和產(chǎn)能供應(yīng) 量的限制出現(xiàn)數(shù)量上的波動(dòng);現(xiàn)在要求我們能夠找到合適的資源分配方式，來讓公司獲得最大的盈利。這其實(shí)就是一個(gè)根據(jù)制約條件來找到A和B兩種服務(wù)對(duì)應(yīng)各自 需要有什么變量的問題。不妨列出一個(gè)公式，看看究竟各個(gè)制約條件之間是如何影響的，從而找到合適的解決辦法。

　　要記得，在需求被拆解后的每一個(gè)問題有些是對(duì)應(yīng)固定的角色的，而一些則是可認(rèn)為是無所謂角色區(qū)分的共性問題，還有一些問題的處理結(jié)果會(huì)影響他角色。務(wù)須能分清楚來對(duì)待。

　　分解階段另一件重要的事情就是完成流程圖的設(shè)計(jì)，對(duì)應(yīng)產(chǎn)品人員要做的是業(yè)務(wù)流程圖，如果有核心開發(fā)人員也參與了前期的需求討論分析，可以建議他們同步展開架構(gòu)流程的思考。

　　在繪制流程圖的時(shí)候需要盡可能標(biāo)明其中的里程碑功能，大約需要哪些功能支撐、需要設(shè)計(jì)多少個(gè)頁(yè)面或頻道、組件，對(duì)應(yīng)的管理后臺(tái)需要有哪些對(duì)應(yīng)的 調(diào)用。這時(shí)候也需要一并帶著整理。我的實(shí)踐經(jīng)驗(yàn)是，可以先做完流程圖，然后把后面的這些問題帶進(jìn)去思考，一方面尋找答案，一方面也可以完善你的流程圖。

　　如果能夠一路堅(jiān)持走下來，基本上可以做到很完整地了解自己要解決些什么問題了。這時(shí)候你面對(duì)的就不再是一個(gè)總的需求，而是一個(gè)個(gè)細(xì)節(jié)的問題。接下來要做的就是對(duì)各個(gè)問題進(jìn)行評(píng)估，

　　評(píng)估：

　　如果我們把分解理解為找問題，那么評(píng)估就是為解決問題做準(zhǔn)備。

　　鑒于我們?cè)诜纸鈫栴}的時(shí)候，其實(shí)已經(jīng)涉及了一部分評(píng)估的工作，這里不妨更深一層。例如，你打算使用多少個(gè)頁(yè)面、會(huì)有多少個(gè)功能點(diǎn)出現(xiàn)。這些經(jīng)過分析提煉后的內(nèi)容可以用PRD或者低保真原型的方式展現(xiàn)給相關(guān)的開發(fā)人員和業(yè)務(wù)部門。

　　不過評(píng)估最重要的工作并不是要窮列出來究竟需要做哪些工作，而是需要對(duì)這些即將展開的工作做出排序，同時(shí)你可能必須舍棄一些原本精心構(gòu)思的內(nèi)容。

　　對(duì)工作的排序是產(chǎn)品自己無法完成的，需要盡可能和開發(fā)部門配合。開發(fā)人員對(duì)于業(yè)務(wù)需求有著自己的一套理解，同時(shí)由于涉及到很多實(shí)現(xiàn)細(xì)節(jié)的問題，也需要在達(dá)到共識(shí)的基礎(chǔ)上才能繼續(xù)推動(dòng)。

　　因此，在真正展開具體的產(chǎn)品設(shè)計(jì)工作之前，需要能和開發(fā)人員進(jìn)行溝通，盡可能做到以下幾點(diǎn)：我們需要多少個(gè)功能點(diǎn)來支撐這個(gè)產(chǎn)品或滿足需求;這 些功能點(diǎn)都是可以在規(guī)定項(xiàng)目時(shí)間內(nèi)開發(fā)完成的嗎;開發(fā)人員對(duì)于自己要做的事情有足夠的判斷，知道哪些應(yīng)該先做，哪些要后置;對(duì)于暫時(shí)無法實(shí)現(xiàn)的功能，是退 回給需求方，還是產(chǎn)品重新構(gòu)思或者延至2.0版本完成，需要說明清楚。

　　對(duì)于沒有技術(shù)背景的產(chǎn)品，這時(shí)候很容易陷入被動(dòng)，你可能會(huì)被技術(shù)提出的各種“不好實(shí)現(xiàn)”攪得心煩意亂。為了避免這種情況，你最好能找到一個(gè)能和你順暢溝通的技術(shù)經(jīng)理，很多問題其實(shí)并不需要你親自上陣的。

　　決策：

　　在經(jīng)過了前面幾輪重重的折磨，才是產(chǎn)品人員真正發(fā)揮創(chuàng)意的時(shí)候，你將左右會(huì)有怎樣的表現(xiàn)，你擁有整個(gè)產(chǎn)品開發(fā)的決策權(quán)。別人可以提意見，但是最終你才是那個(gè)決定事情該怎么做的人。

　　制定項(xiàng)目計(jì)劃，針對(duì)每個(gè)細(xì)分功能拿出具體的實(shí)現(xiàn)策略，給出產(chǎn)出物的交付時(shí)間，繪制原型圖和PRD文檔。從產(chǎn)品整體框架到頁(yè)面布局、頻道功能再到 按鈕的位置，彈出層的設(shè)計(jì)。設(shè)計(jì)的創(chuàng)意才在這里真正迸發(fā)，你所有知道的界面設(shè)計(jì)、導(dǎo)航架構(gòu)、交互形式的知識(shí)和才能都會(huì)在這里得到淋漓盡致的體現(xiàn)。

　　暫且撇下你的設(shè)計(jì)創(chuàng)意不表，如何把評(píng)估階段的成果應(yīng)用好是我們是否能順利進(jìn)入決策階段的關(guān)鍵?？倳?huì)有一些功能被砍掉，也有一些新功能提出來，原 本想好的某些流程也可能要重新調(diào)整。在決策階段，你需要有做減法的魄力和決心，拋棄一些東西，適當(dāng)做一些讓步，但是要能保證產(chǎn)品的核心功能不被閹割。對(duì)于 核心功能，任何為了減輕工作量或者無法實(shí)現(xiàn)而要求繞道而行的借口都是可恥的;如果你有有充分的理由相信產(chǎn)品的核心功能，那就一定要堅(jiān)持到底。

　　寫在最后的話：

　　至此，我們通過確定、分解、評(píng)估和決策把需求分析階段要做的事情做了一個(gè)梳理，也為后面的設(shè)計(jì)和開發(fā)開了一個(gè)好頭。當(dāng)然你仍然會(huì)面臨業(yè)務(wù)部門的 需求變更，設(shè)計(jì)或者開發(fā)人員在某個(gè)功能或表現(xiàn)形式上跟你死磕的局面，這時(shí)候你仍然可以應(yīng)用這四個(gè)步驟來解決具體的問題，但是在實(shí)現(xiàn)上需要做一些變通，項(xiàng)目 一旦進(jìn)入到開發(fā)編碼階段，時(shí)間會(huì)非常緊湊，你能做的就是根據(jù)新提出來的想法迅速協(xié)調(diào)好利益相關(guān)部門，在開會(huì)之前你就能要準(zhǔn)備好幾套方案，否則會(huì)議就會(huì)變成 一種折磨：低效，浪費(fèi)時(shí)間，不解決問題。