1.????一切源于欲望

　　1.1 欲望?需求!欲望!何為欲望?心理學(xué)上對欲望的解釋是由人的本性產(chǎn)生的想達(dá)到某種目的的要求流礁。在這個定義里有兩個關(guān)鍵詞：本性、目的曾撤。它指出了欲望的源頭棠枉，是由人的本性產(chǎn)生的，是一種本能颠蕴，人人皆有泣刹。同時也指出了欲望的產(chǎn)生原因，是為了達(dá)到某種目的犀被。

　　舉個例子椅您，吃飯，這是一項最基本的生理欲望寡键，每個人為了生存必須要吃飯掀泳。要吃飯，就得先把飯做出來西轩。我們有微波爐员舵，電飯鍋等等很多可選擇的工具來幫我們做飯，甚至藕畔，做特殊的食物有專用的工具提供給我們马僻，比如面包機(jī)。再者注服，如果你不想做飯韭邓，連出門都懶得出，你可以用一款叫“餓了么”的軟件將食物快遞上門溶弟。

　　前面提到的微波爐女淑，電飯鍋，面包機(jī)以及“餓了么”軟件可很，都是我們可以用來滿足吃飯這項生理欲望的工具诗力。換個角度，這些工具不就是工具生產(chǎn)廠家的產(chǎn)品嗎?換句話說我抠，產(chǎn)品就是為了滿足人們欲望而產(chǎn)生的工具苇本。既然產(chǎn)品是為了解決人們的需求問題，也就是說需求就是人們的欲望菜拓。

　　1.2 欲望瓣窄，如何滿足每款產(chǎn)品都有自己要解決的核心的用戶需求，也就是說產(chǎn)品都有一個核心的欲望需要去滿足纳鼎。比如俺夕，“餓了么”軟件就是滿足人們叫外賣的欲望。但是贱鄙，叫外賣的方式有很多種劝贸，為什么用戶一定要用“餓了么”軟件呢?這個時候，就需要對欲望進(jìn)行深入的分析逗宁，已提供更好的服務(wù)來滿足人們的欲望映九，這個活動常常被產(chǎn)品人稱作需求分析。

　　舉個蘇杰大大在《人人都是產(chǎn)品經(jīng)理》中的一個例子：絕跡小朋友想去吃火鍋瞎颗，這是一個欲望件甥。但是絕跡小朋友真的是嘴饞了想去吃火鍋嗎?可能絕跡只是餓了，但是這四川娃子餓了就只想到吃火鍋哼拔。如果真的只是餓了引有，給他倆包子也可以滿足絕跡的欲望，還能節(jié)省成本倦逐，何樂而不為呢譬正。這就是一個典型的需求分析過程，通過需求分析找到了最簡單的滿足人們欲望的方式檬姥。

　　再來談?wù)劇梆I了么”軟件曾我，在這個軟件出現(xiàn)之前人們也是能叫外賣的，那么這款軟件有什么更好的滿足人們叫外賣欲望的方面呢穿铆。我們先來看看以前叫外賣的痛點(diǎn)您单。叫外賣有兩種方式，如果店鋪有官網(wǎng)荞雏，可以去官網(wǎng)訂餐虐秦，但是，這些只限于一些大型連鎖餐廳凤优，比如麥當(dāng)勞悦陋。另一種方式就是電話預(yù)定，但是前提是你要有店鋪電話筑辨，一般人肯定不會有附近所有餐廳的電話俺驶。“餓了么”軟件就解決了這兩個痛點(diǎn)棍辕，它能搜羅用戶周圍提供送外賣服務(wù)的所有餐廳暮现，并為所有餐廳提供網(wǎng)上訂餐服務(wù)还绘，同時也免去了獲得餐廳電話的需求。通過分析栖袋，“餓了么”軟件提供了更好的滿足需求的服務(wù)拍顷。

　　2.????合適的欲望碰到合適的人

　　2.1 用戶角色建模每一款產(chǎn)品都有自己的受眾，沒有哪款產(chǎn)品是每個人都需要的塘幅。為此昔案，我們需要對自己產(chǎn)品的受眾進(jìn)行分析，看看這些用戶使用產(chǎn)品的習(xí)慣是怎么樣的电媳。這樣可以更好的提取用戶的需求踏揣。

　　首先，要找出產(chǎn)品的受眾匾乓，這個流程一般被稱為用戶角色建模捞稿。用戶角色建模首先要通過頭腦風(fēng)暴的方式列出可能的用戶角色集合。還以“餓了么”軟件為例钝尸，一般都是什么樣的人會叫外賣呢?勞累一天的上班族括享，學(xué)校的學(xué)生，偶爾想改善伙食但不想出門的人珍促，加班的人铃辖，不會做飯的人。

　　在收集了用戶角色集合以后猪叙，我們需要對這些用戶角色進(jìn)行整理娇斩，看看角色之間有沒有包含或者重合的地方，如果有穴翩，則需要考慮是否用角色需要被丟棄犬第。比如上面的用戶集合中，不會做飯的人并沒有典型的特征芒帕，而且歉嗓，在上班族、學(xué)生背蟆、加班的人中都可能會有不會做飯的人鉴分。則，不會做飯的人完全可以被其他角色所代替带膀，這個用戶角色就可以被丟棄了志珍。

　　在整理完畢用戶角色后，可以將每個用戶角色寫在一個卡片上垛叨，并在每個卡片上寫下這個用戶角色的一些特征伦糯，這樣可以方便的對用戶角色進(jìn)行分析。比如，在上班族卡片上可以寫上對菜品質(zhì)量要求較高敛纲，可以熟練使用電腦喂击，可能會經(jīng)常使用該軟件等等。

　　有些時候為了對用戶角色更加深入的了解载慈，一般會對重要的用戶角色建立角色實(shí)例惭等。角色實(shí)例是一個貼近生活的用戶場景珍手，通過角色實(shí)例可以建立起一個真實(shí)的人物办铡，讓我們對角色有更真切的了解。如果上班族是我們主要的目標(biāo)用戶琳要，我們?yōu)樯习嘧褰⒁粋€角色實(shí)例如下：

　　有業(yè)界的大大建議在設(shè)計新系統(tǒng)時對一些極端人物建立角色卡寡具。這些極端人物并不是產(chǎn)品的典型用戶，但是他們卻是真的會使用我們的產(chǎn)品稚补。比如一些花癡小妹妹童叠，叫外賣或許對她們來說并不是必須的，但是她們可能僅僅是為了看某個送外賣的帥哥课幕，而經(jīng)常定那家餐廳的外賣厦坛。我們不需要浪費(fèi)太多時間在這些極端人物身上，甚至這些人物的需求根本不會被實(shí)現(xiàn)乍惊，但是花點(diǎn)時間在這些用戶身上杜秸，或許會產(chǎn)生一些意想不到的靈感。

　　2.2 需求源于角色前面在用戶角色建模上浪費(fèi)了很大精力润绎，其實(shí)都是在為這里的需求收集做準(zhǔn)備撬碟。不同的角色肯定會有不同的需求，這個時候莉撇，我們需要將自己代入角色呢蛤，仔細(xì)想想如果自己是這個角色，會有什么樣的需求棍郎。將所有考慮到的需求都記錄下來其障，為以后的需求整理做準(zhǔn)備。

　　比如涂佃，作為一名上班族励翼，很晚才回到家，這個時候叫外賣肯定希望外賣會很快的到達(dá)巡李。而且上班族一般都習(xí)慣刷卡抚笔，如果提供刷卡或者網(wǎng)上支付功能會很方便。而“餓了么”軟件就為用戶提供的外賣到達(dá)時間的預(yù)估侨拦，用戶可以方便的選擇可以快速到達(dá)的外賣殊橙。

　　再考慮學(xué)生，學(xué)生這是個沒有收入的群體，所以物美價廉的外賣是他們的首選膨蛮。學(xué)生一般對快遞的送達(dá)時間會有相對較大的容忍度叠纹。學(xué)生中對刷卡的需求不是很迫切，他們一般更喜歡現(xiàn)在付款敞葛，所以如果有貨到付款的服務(wù)會很合適誉察。同時，如果可以用學(xué)生卡打折惹谐，我想會很受學(xué)生們的歡迎持偏。

　　3.????欲望也有輕重緩急

　　在需求收集和整理完成后和項目開始開發(fā)之前，我們需要召開需求評審會來確定每個需求的優(yōu)先級和開發(fā)計劃氨肌。如果你的團(tuán)隊正在使用Scrum敏捷開發(fā)鸿秆，那么你們一定在用用戶故事來整理用戶需求。用戶故事通常使用客戶和團(tuán)隊都可以看懂的表達(dá)方式來寫怎囚，每一個用戶故事都是產(chǎn)品的一個需求卿叽。當(dāng)然，用戶故事還包括需求的商業(yè)價值和相關(guān)人員恳守。使用用戶故事可以方便的與客戶溝通考婴，而且不用查看繁瑣的需求文檔。

　　用戶故事一般使用如下格式：為了[商業(yè)價值]催烘，作為[角色]沥阱，我想要[做某事]。還是使用“餓了么”軟件為例颗圣，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達(dá)喳钟，作為上班族，我想要查看每家餐廳的外賣送達(dá)預(yù)估時間在岂。

　　在用戶故事確定以后奔则，我們需要召集開發(fā)人員，客戶還以一些產(chǎn)品的相關(guān)人員來參加需求評審會蔽午。在會議上易茬，我們需要對每個需求的商業(yè)風(fēng)險，技術(shù)風(fēng)險及老，開發(fā)耗時和優(yōu)先級作出評估抽莱。

　　首先需要確定的是商業(yè)風(fēng)險，也就是確定哪些是核心需求骄恶，哪些是亮點(diǎn)需求食铐。核心需求需要盡早完成，缺失了產(chǎn)品就不完整僧鲁。而亮點(diǎn)需求有則會給產(chǎn)品加分虐呻，沒有也不會影響用戶的使用象泵。一般來講，核心需求的商業(yè)風(fēng)險會比較低斟叼，因為這些需求都是產(chǎn)品必須的偶惠，被砍掉的可能性很低。而亮點(diǎn)需求的商業(yè)風(fēng)險就會高朗涩，可能會因為開發(fā)時間不足而被砍掉或者被放入下次版本迭代的周期中忽孽。

　　下來需要確定技術(shù)風(fēng)險和開發(fā)耗時，技術(shù)風(fēng)險代表的是這個需求開發(fā)的難易程度谢床。如果這個需求所需要的技術(shù)開發(fā)團(tuán)隊從來沒接觸過兄一，需要對這個技術(shù)從頭開始學(xué)習(xí)。那么這個需求的技術(shù)風(fēng)險就會很高萤悴，因為這個新技術(shù)不知道開發(fā)團(tuán)隊是否能掌握瘾腰，多久才能掌握。技術(shù)風(fēng)險的評估對開發(fā)耗時的評估有很大影響覆履。開發(fā)耗時在Scrum開發(fā)團(tuán)隊中一般用時間點(diǎn)來計算，一個時間點(diǎn)代表一個理想工作日费薄。在我的團(tuán)隊中硝全，一般使用斐波那契數(shù)列來劃分時間點(diǎn)的等級。因為我們發(fā)現(xiàn)工程師經(jīng)常在為一個需求的時間點(diǎn)而爭論不休楞抡。如果為一個需求是2個時間點(diǎn)還是3個時間點(diǎn)而爭論伟众，這是有意義的，因為3個時間點(diǎn)比2個多了一半的工作量召廷。但是如果在為一個需求是99個時間點(diǎn)還是100個時間點(diǎn)而爭論就是沒有意義的凳厢，因為這一個時間點(diǎn)的差別對我們的影響很小。為了避免這種無意義的爭論竞慢，我們使用斐波那契數(shù)列來劃分時間點(diǎn)先紫，這個時候工程師只需要考慮這個需求的耗時更靠近89還是144，而不用為了細(xì)小的差別而爭論不休筹煮。在評估技術(shù)風(fēng)險和開發(fā)耗時時遮精，一般都有技術(shù)人員和項目經(jīng)理來確定，其他人員不應(yīng)該左右技術(shù)人員和項目經(jīng)理的思維败潦。

　　最后則是評估需求的優(yōu)先級本冲，綜合分析以上三個要素，來最后給需求評估優(yōu)先級劫扒。一般情況下核心需求的優(yōu)先級往往是最高的檬洞，不過有時候由于技術(shù)風(fēng)險過大，或者開發(fā)耗時過長沟饥，有些核心需求的優(yōu)先級會被降低添怔。在優(yōu)先級評估完畢后环戈，開發(fā)團(tuán)隊會確定第一輪的迭代要完成的需求。如果是使用Scrum敏捷開發(fā)有一段時間的話澎灸，開發(fā)團(tuán)隊是知道自己在一個迭代周期能夠完成多少時間點(diǎn)的任務(wù)的院塞，也就是團(tuán)隊的速率。一些高優(yōu)先級的需求由于時間點(diǎn)太大而不能放入本次迭代性昭，而使用其他優(yōu)先級相對較低但時間點(diǎn)小的需求代替的情況也會時常發(fā)生拦止。

　　4.????讓欲望在掌握之中

　　在完成需求評估后，開發(fā)團(tuán)隊就會進(jìn)入開發(fā)階段糜颠。在Scrum團(tuán)隊中汹族，需要對開發(fā)中的需求進(jìn)行管理。常用的方法是在一塊木板或是一面墻上列出正在開發(fā)的其兴，開發(fā)完成的顶瞒，正在測試的和完成了的需求。這塊木板或強(qiáng)被稱為看板元旬。每個人都可以在看板上清晰的看到團(tuán)隊現(xiàn)在的開發(fā)狀況榴徐。我的團(tuán)隊沒有使用實(shí)體的看板，而是使用JIRA這個軟件提供的電子看板匀归。

　　在開發(fā)過程中坑资，需求的變更是必然會發(fā)生的。正常情況下穆端，如果一輪迭代已經(jīng)開始了袱贮，Scrum團(tuán)隊是不會中途停止的。新的需求必須在下一輪迭代中才能加入体啰，這樣可以保證開發(fā)的正常秩序攒巍。為此，我們在看板最前方新加了一項：待開發(fā)荒勇。我們會將變更的而且有限級高的需求放在這一列柒莉，以保證在下一輪迭代中實(shí)現(xiàn)這些需求。

　　大部分公司都會要求寫需求文檔枕屉，這樣對所有需求歸類常柄，并且可以方便以后的查閱。但是這些需求文檔有時候書寫的并不是很規(guī)范搀擂，或是很全面西潘。導(dǎo)致查閱的時候很難找到我們需要的內(nèi)容而且在需求，有時候甚至是寫完后根本無人去理會哨颂。而且喷市，在需求變更時需要進(jìn)行維護(hù)，耗費(fèi)人力威恼，文檔在多次修改后導(dǎo)致內(nèi)容很亂品姓，或是前后需求矛盾的情況時有發(fā)生寝并。

　　現(xiàn)在一個新的需求管理方法，需求的實(shí)例化腹备，可以解決這些問題衬潦。需求的實(shí)例化是不再編寫和維護(hù)需求文檔，而是直接使用高質(zhì)量的測試用例作為需求文檔植酥。通過測試用例可以很清楚的看到產(chǎn)品的需求內(nèi)容镀岛，而且，在需求變更時友驮，必然會產(chǎn)生新的測試用例漂羊，而不必費(fèi)力去維護(hù)。在清晰的表現(xiàn)需求的同時卸留，減少了維護(hù)需求文檔的人力走越。