前面幾章我們講述了當我們開(kāi)始想要策劃一款產(chǎn)品的好產(chǎn)劃產(chǎn)劃時(shí)候，首先我們需要認識、品設品設感知產(chǎn)品的計策計策用戶(hù)??，對用??戶(hù)有了正確認識才能找到我們產(chǎn)品所面對的南分目標用戶(hù)。

找到了目標用戶(hù)之后再分析他們所處的好產(chǎn)劃產(chǎn)劃環(huán)境，使用的品設品設場(chǎng)景以及當下所產(chǎn)生的需求。通(′?｀)過(guò)簡(jiǎn)單的計??策計策需求評估、需求分層、??南分以及痛點(diǎn)公式等我們可以分析用戶(hù)需求的好產(chǎn)??劃產(chǎn)劃真實(shí)性以及值不值得我們去做。

最后我們才能夠針對這些需求設計一些解決問(wèn)題的品設品設方案。

所有用戶(hù)需求及內部需求收集完之后我們會(huì )形成一個(gè)需求池。計策??計策當需求變得繁多時(shí)，南分如果沒(méi)有對需??求進(jìn)行有效管理以及優(yōu)先級的好產(chǎn)劃產(chǎn)劃評判那么產(chǎn)品規劃將變成一團亂麻。

所以在產(chǎn)品方案設計階段我們首先( ?ω?)要知道需求的品設品設輕重緩急，知道哪些是計策計策我們現在應該做的，哪些是放在以后我們可以慢慢優(yōu)化的。評估需求之前我(wo)們先通過(guò)以下三個(gè)方法查漏補缺，補充需求，明確需求的范圍。

第一個(gè)方法是同類(lèi)場(chǎng)景橫推法，想一想這個(gè)需求是用(yong)戶(hù)在什么情況下會(huì )產(chǎn)生的？有沒(méi)有存在類(lèi)(′?｀*)似的場(chǎng)景呢？比如前面提到的線(xiàn)??上問(wèn)診這個(gè)行為ヽ(′▽?zhuān)?/會(huì )發(fā)生在用戶(hù)已經(jīng)發(fā)病的情況下，那么還有沒(méi)有類(lèi)似的場(chǎng)景，是否可以思考用戶(hù)在復診的過(guò)程中會(huì )不會(huì )也希望使用線(xiàn)上問(wèn)診的方式呢？

第二個(gè)方法是特定場(chǎng)景縱向分析法，想一想這個(gè)需求的場(chǎng)景中，存在哪些(xie)關(guān)聯(lián)行為可以提供支持？還是線(xiàn)上問(wèn)診這個(gè)行為，我們提供了??問(wèn)診之后順著(zhù)需求鏈思考，用戶(hù)是不是會(huì )有預約(yue)就診這類(lèi)的需求？這個(gè)場(chǎng)景如果打通是不是能幫助用戶(hù)更好地解決問(wèn)題？

第三個(gè)方法是行為目的(′?｀*)深究法，這個(gè)方法就是產(chǎn)品經(jīng)理的內心中不斷問(wèn)自己，這真的是用戶(hù)確實(shí)需要的功能嗎？這樣做真的能解決用戶(hù)的問(wèn)題嗎？

在進(jìn)入需求管理階段，我們要明確需求的三要素，問(wèn)題、業(yè)務(wù)背景以及對應的解決方案。

了解清楚用戶(hù)目前面對的問(wèn)題是什么，(╯‵□′)╯線(xiàn)下是如何解決這個(gè)問(wèn)題的，以及對這個(gè)(╯°□°）╯︵ ┻━┻問(wèn)題有一個(gè)范圍界定的精確定義。對問(wèn)題有一定的認識后才能深究問(wèn)題產(chǎn)生的背景，充分了解用戶(hù)所處的場(chǎng)景。

在這個(gè)過(guò)程中除了需要搞清楚業(yè)務(wù)?場(chǎng)景、業(yè)務(wù)術(shù)語(yǔ)以及業(yè)務(wù)環(huán)境（比如就診行為的一些專(zhuān)業(yè)名詞和流程等）以外，我們可以嘗試詢(xún)問(wèn)用戶(hù)希望給出的解決方案用以評估用戶(hù)目前的認知水平和對問(wèn)題的認識。

根據以上(shang)的反饋再形成完整的解決方案，值得注意的是給出方案的同時(shí)我們務(wù)必要有解決問(wèn)題的方法以及實(shí)際成本??的評估，這也是對后續方案采納的重要考量因( ?° ?? ?°)素之一。

在評估需求的優(yōu)先級之前，我們還有兩件事要做。首先我們不妨做多點(diǎn)工作確認需求的真實(shí)性。吾??日三省吾身，產(chǎn)品經(jīng)理每天三省的問(wèn)題應該就是：

1.要解決的問(wèn)題是什么？–這里面的核心問(wèn)題是什么，這個(gè)核心問(wèn)題又帶來(lái)了什么樣的衍生問(wèn)題，在這個(gè)核心問(wèn)題中有沒(méi)有包含細分的問(wèn)題。

2.用戶(hù)的場(chǎng)景是什么？–比如我們要做一個(gè)手機快捷多任務(wù)切換的交互方案，那么就要去想用戶(hù)是在通知朋友的時(shí)候、看視頻打(╬ ò﹏ó)發(fā)時(shí)間的時(shí)候還是查看資訊時(shí)要回信息的時(shí)候最需要用到多任務(wù)切換這個(gè)功能呢？

3.用戶(hù)的環(huán)境是什么？—環(huán)境對產(chǎn)品??的使用也會(huì )有很大的影??響，比如用戶(hù)在(╯°□°）╯車(chē)上使用、在???出┐(′?｀)┌行過(guò)程中使用手機是否只能進(jìn)行單手交互？交互的過(guò)程中是不是不容易按(??-)?到手機上方的按鈕？

思考這些問(wèn)題幫助我們在面對繁多的需求池時(shí)也能保持清醒，清楚知??道自己在做什么需求，產(chǎn)品會(huì )有什么樣的改變。

接下來(lái)我們需要對需求進(jìn)行有序的分類(lèi)。首先我們可以有三個(gè)比較大得分類(lèi)分別是：功能型需求??、數據需求以及非功能需求。

功能型需求一般指有具體完成內容的需求，比如登錄行為、線(xiàn)上問(wèn)診行為、商城購物等等。這些行為根據不用的場(chǎng)景我們還可以細分為：使用場(chǎng)景、維護(′_ゝ`)場(chǎng)景以及(ji)運營(yíng)場(chǎng)景。

非功能需求一般指為滿(mǎn)足用戶(hù)業(yè)務(wù)需求而必須具有且除功能需求以外的特性，包括系統的性能、可靠性、可維護性等等。像我們?？吹降囊笙到y需滿(mǎn)足2W人同時(shí)在線(xiàn)使(shi)用、頁(yè)面反應時(shí)間不能超過(guò)2秒這些就是常見(jiàn)的品質(zhì)類(lèi)非功能需求。

數據需求一般指的是數值系統的設計以及報表監控指標的設計等等。

不同類(lèi)別的需求盡??量不要放在同一個(gè)維度評判優(yōu)先級，在產(chǎn)品的不同階段對不同類(lèi)型的需求也有不同優(yōu)先級。產(chǎn)品迭代的初期，我們更重視功能型需求的建設，這(?????)個(gè)時(shí)期就像一個(gè)拓荒的時(shí)期，需要快速做出ヽ(′?｀)ノ功能實(shí)現需求占領(lǐng)用戶(hù)；在產(chǎn)品日漸成熟穩定之后，為了維持穩定的運營(yíng)情況，非功能性需求的保障就變得尤為重要，這時(shí)候我們就要重(′_ゝ`)點(diǎn)評估新的功能需求對系統性能以及穩定等各方面的影響。

完成了以上工作，我們終于進(jìn)入需求評估的階段。正如前面所說(shuō)，當需求變得繁多時(shí)，如果沒(méi)有對需求進(jìn)行有效管理以及優(yōu)先級的評判那么產(chǎn)品規劃就會(huì )變成一團亂麻。那么如何有效評估需求的優(yōu)先級呢？在這里我重點(diǎn)講四個(gè)最(′?_?`)實(shí)用的方法。

第一個(gè)方??法是卡諾模型（KANO），??在KANO模型中定義了三個(gè)層ヽ(′ー｀)ノ次的用戶(hù)需求：基本型需求、期望型需求和興奮型需求。

基本型需??求指用戶(hù)認為產(chǎn)品“必須有”的(de)屬性(xing)或功(′Д` )能。例如一個(gè)攝影軟件最基本的就是要支持拍照功能，但客戶(hù)并不會(huì )因為你有拍照功能就對你感到滿(mǎn)意，充其量只是滿(mǎn)(′；ω；`)足了(le)基本要求。

期望型需求是指提供“比較優(yōu)秀”的屬性或功能，期望型需求通常是一(╯°□°)╯個(gè)產(chǎn)品的加分項，比如一個(gè)攝影軟件支持多種調整圖片的工具，不但支持傻??瓜式的濾鏡也能在這個(gè)基礎上進(jìn)行參數??的調整，這樣用戶(hù)就會(huì )感覺(jué)很滿(mǎn)意，當沒(méi)有這些功能時(shí)用戶(hù)就會(huì )感覺(jué)不滿(mǎn)意。

興奮型需求是指提供給用戶(hù)一些完全出乎意料的產(chǎn)品屬性，使用戶(hù)產(chǎn)生驚喜。興奮點(diǎn)和驚喜點(diǎn)常常是一些被用戶(hù)無(wú)意中發(fā)現的需求，顧客在看到這些功能之前并不知道自己需要他們。還是剛才攝影軟件的??例子，如果在拍人時(shí)會(huì )有與拍景色時(shí)完全不同的表現效果，那么用戶(hù)在(╬ ò﹏ó)潛意識中就會(huì )產(chǎn)生驚喜，同樣也會(huì )越發(fā)提升用戶(hù)的忠誠度。

在應用這個(gè)模型的時(shí)候首先我們要搞清楚我們的需求到底會(huì )放在圖中哪一個(gè)界限哪一個(gè)點(diǎn)，由圖中可以看出，右下(′▽?zhuān)?)方的箭頭一旦實(shí)現了一定的數據(╯°□°）╯︵ ┻━┻的必須功能，就無(wú)法再通過(guò)增加這類(lèi)功能來(lái)提高客戶(hù)的滿(mǎn)意度了。無(wú)論增加多少功能，客戶(hù)滿(mǎn)意度都不會(huì )超過(guò)中點(diǎn)以上。左上方的箭頭指示實(shí)現了一小部分就能明(?⊿?)顯(T_T)提升客戶(hù)滿(mǎn)意度，這就是一個(gè)產(chǎn)品中ヾ(′▽?zhuān)??的殺手锏功能。中間的箭(′?｀*)頭代表期望型功能的增加和客戶(hù)滿(mǎn)意度呈線(xiàn)性增長(cháng)，所以這類(lèi)需(╬?益?)求越多越好。

第二個(gè)方法是RFM模型，這個(gè)模型是衡量客戶(hù)價(jià)值??和客戶(hù)創(chuàng )利能力的重要工具。我們實(shí)現(╯°□°）╯任何的需(╥_╥)求做(zuo)任何的功能升級都是圍繞創(chuàng )利這一目標的，這里的利不一定代表實(shí)際的資金收入，也可以是流量、口碑等間接創(chuàng )利的東西。

我們可以用1-10分去量化這三個(gè)維度，把需求放在這個(gè)模型中，得出3(′?｀)個(gè)維度的評分，評分越高代表優(yōu)先級也越高。

第三個(gè)方ヽ(′ー｀)ノ法是上一章提(ti)到的痛點(diǎn)模型，通過(guò)對需求的持續性、厭惡程度、可替代度的分值量化，同樣把這三個(gè)維度用1-10分去量化，然后計算出需求的強烈程度，有限解決強烈的需求。因這個(gè)方法在上一章有詳細的講述，所以在這里不展開(kāi)分析過(guò)程。

第四個(gè)方法是重要性象限判斷，這個(gè)方法是由麥肯錫提出，根據事件的重要性和緊迫性為坐標軸，可(′?｀*)以將所有事情區分在四個(gè)象限中：重要且緊急、重要不緊急、不重要但緊急、不重要不緊急。對所有事件分類(lèi)后，才(°o°)能做更好地分析處理。

但這個(gè)方法其實(shí)是具有爭(zheng)論性的，原因在于重要與緊急的定義沒(méi)有一個(gè)大致統一的定義，所以只能根據不同公司的不同情況(kuang)按照你認為的重要與緊急去進(jìn)行區分，在這里我就不展開(kāi)講述。

分清楚了需求的優(yōu)先級，這時(shí)候我們就把優(yōu)先級高的需求挑選出來(lái)，重點(diǎn)分析這個(gè)需求當前的場(chǎng)景、問(wèn)題以及解決的方案。

在這個(gè)階段，我們可以借助UML中的工具幫助我們進(jìn)行系統地分析。通過(guò)圖中的問(wèn)題可以幫助我??們快速思考這個(gè)需求對應的場(chǎng)景中目前的做法是怎么(me)樣的？期望通過(guò)解決方案帶來(lái)什么(O_O)樣的改進(jìn)？這個(gè)思考的過(guò)程一方面幫助我們理清思路，另外一方面也能夠形成一個(gè)較為完善的用例（USE CASE）。

用例是一個(gè)UML中非常重要的概念，用例是對一組動(dòng)作序列的抽象描述，系統執行這些動(dòng)作序列得到相應的結果。這個(gè)定義可能有點(diǎn)拗口，我們可以理解成用例其實(shí)就是為了實(shí)現一個(gè)目標所需要的人機交互流程。比如我們常用的理財軟件中存在“提款”這樣??一個(gè)實(shí)例，我們首先需要登錄到理財軟件，然后點(diǎn)擊提現按鈕，輸入提現金額，輸入密碼，轉賬至銀行卡這樣一系列的流程，這個(gè)(ge)過(guò)程的描述就是一個(gè)用(yong)例。

但是在這個(gè)用例中，我們還必須考慮可能發(fā)生的各種其他情??況，比如提取的余額不足、輸入密碼錯誤等等，這些可能發(fā)生的情況(kuang)（包括正常的和異常??(′?ω?`)的）就被稱(chēng)為用例的場(chǎng)景，場(chǎng)景也被稱(chēng)為用例的實(shí)例。

下圖為一個(gè)用例的詳細描述過(guò)程，實(shí)際工作ヽ(′?｀)ノ中(zhong)我們挑選需要填寫(xiě)的(de)項目即可。

那么用例有什么好處呢？用例方??法的有點(diǎn)就是完全(??ヮ?)?*:???站在用戶(hù)的角度上來(lái)描述系統的功能，我們可以把系統看成一個(gè)黑箱，不需要關(guān)心系統內部是如何完成它所提供的功能(╯°□°）╯︵ ┻━┻，我們可以使用用例與實(shí)例來(lái)表述系統的功能性需求。對于一個(gè)完整的實(shí)例而言，我們需要補充這個(gè)用例當前發(fā)(′?_?`)生的場(chǎng)景以及前ヾ(?■_■)ノ置后置條件。前置條件代表完成這個(gè)用例需要得到什么的支持，比如我們提現這個(gè)用例首先得成功登錄軟件、判斷銀行賬戶(hù)沒(méi)有被凍結、綁定了銀行卡等等，后置條件代表這個(gè)用例完成后需??要產(chǎn)出什么，比如提現后我們的銀行卡內需要能查詢(xún)到提現出來(lái)的金額。

有(you)了這樣一條條具像化的實(shí)例，我們能夠輕松把業(yè)務(wù)流程圖轉化成人機交互的流程，明確每個(gè)階段的產(chǎn)出物以及關(guān)注的重點(diǎn)信息。這種人機交互的流程展示一方面來(lái)說(shuō)可ヽ(′?｀)ノ以幫助我們查漏補缺，梳理現有流程，找到不合理可優(yōu)化的地方，從而改善流程；另外一方面ヽ(′ー｀)ノ也幫助我們能夠輕松完成后續的原型設計。

制作原型的第一步需要根據上述??得到的流程圖把每個(gè)頁(yè)面模塊中的功能以及跳轉流程做一個(gè)直觀(guān)的展示，同樣也是幫助我們梳理思路發(fā)現問(wèn)題的方式，在這個(gè)環(huán)節也許你能看到某些功能放在同一個(gè)頁(yè)面同一個(gè)優(yōu)先(′-ι_-｀)級是否合理？某些功能是否另外一些功(????)能的分支功能？通過(guò)這樣的模塊功能展示圖可以幫助我們更合理安排每個(gè)頁(yè)面的功能布局以及流程設??計的可用性檢驗。??

最后終于到了產(chǎn)品經(jīng)理日常工作中一個(gè)很重要的環(huán)節，產(chǎn)品原型的制作。原型是產(chǎn)品、交互設計師與開(kāi)發(fā)工程師之間溝通最好的工具，當我們有了上述幾個(gè)??圖表的鋪墊，相信大家在制作原型時(shí)會(huì )感到異常的輕松。

我們可以根據模塊功能展示圖思考真實(shí)使用時(shí)頁(yè)面信息的架構、元素的擺放(fang)以及??每個(gè)頁(yè)面之間的連接跳轉和交(jiao)互方式。原型有幾種不同的選擇，我們可以選擇輸出交互式原型或者流程式的原型、低保真原型以及高保真的原型，這些根(╯°□°）╯據每個(gè)人的時(shí)間以及團隊的習慣都可(T_T)以有不同的選擇，我建ヾ(′?｀)?立落入實(shí)際開(kāi)發(fā)階段可ヽ(′?｀)ノ以使???用流程式的原型進(jìn)行詳細的開(kāi)發(fā)評審，在展示想法以及效果評估階段可以采用高保真的原型進(jìn)行效果演示；

最后一步是把原型圖交給UI設計師形成設計稿，看到最終呈現的界面效果。

在最后，我們補充一個(gè)概念叫MVP模型，即最小可行產(chǎn)品。當我們開(kāi)發(fā)一個(gè)全新??的產(chǎn)品實(shí)現一個(gè)全新的想法時(shí)，沒(méi)有必要把所有東西都做得盡善盡美再落入市場(chǎng)(′_｀)等待檢驗，我們可以(′ω｀*)通過(guò)一個(gè)最小可行性產(chǎn)品，保留最核心的幾個(gè)功能去掉一些錦上添花的功能(neng)，盡快上線(xiàn)驗證用戶(hù)以及市場(chǎng)的反饋，通過(guò)MVP產(chǎn)品實(shí)行快速的迭代，逐步完善。同樣(′▽?zhuān)?值得注意的是最小可行性產(chǎn)品往往是確定了一個(gè)方向之后，從一個(gè)方案開(kāi)始經(jīng)過(guò)快速迭代(dai)優(yōu)化形成更好的產(chǎn)品，并非每次上線(xiàn)都根據市場(chǎng)的反饋對產(chǎn)品進(jìn)行大刀闊斧的調整。