有些時(shí)候?yàn)榱藢?duì)用戶角色更加深入的了解，一般會(huì)對(duì)重要的用戶角色建立角色實(shí)例。角色實(shí)例是一個(gè)貼近生活的用戶場(chǎng)景，通過(guò)角色實(shí)例可以建立起一個(gè)真實(shí)的人物，讓我們對(duì)角色有更真切的了解。如果上班族是我們主要的目標(biāo)用戶，我們?yōu)樯习嘧褰⒁粋€(gè)角色實(shí)例如下：
 
有業(yè)界的大大建議在設(shè)計(jì)新系統(tǒng)時(shí)對(duì)一些極端人物建立角色卡。這些極端人物并不是產(chǎn)品的典型用戶，但是他們卻是真的會(huì)使用我們的產(chǎn)品。比如一些花癡小妹妹，叫外賣或許對(duì)她們來(lái)說(shuō)并不是必須的，但是她們可能僅僅是為了看某個(gè)送外賣的帥哥，而經(jīng)常定那家餐廳的外賣。我們不需要浪費(fèi)太多時(shí)間在這些極端人物身上，甚至這些人物的需求根本不會(huì)被實(shí)現(xiàn)，但是花點(diǎn)時(shí)間在這些用戶身上，或許會(huì)產(chǎn)生一些意想不到的靈感。
 
2.2 需求源于角色
 
前面在用戶角色建模上浪費(fèi)了很大精力，其實(shí)都是在為這里的需求收集做準(zhǔn)備。不同的角色肯定會(huì)有不同的需求，這個(gè)時(shí)候，我們需要將自己代入角色，仔細(xì)想想如果自己是這個(gè)角色，會(huì)有什么樣的需求。將所有考慮到的需求都記錄下來(lái)，為以后的需求整理做準(zhǔn)備。
 
比如，作為一名上班族，很晚才回到家，這個(gè)時(shí)候叫外賣肯定希望外賣會(huì)很快的到達(dá)。而且上班族一般都習(xí)慣刷卡，如果提供刷卡或者網(wǎng)上支付功能會(huì)很方便。而“餓了么”軟件就為用戶提供的外賣到達(dá)時(shí)間的預(yù)估，用戶可以方便的選擇可以快速到達(dá)的外賣。
 
再考慮學(xué)生，學(xué)生這是個(gè)沒(méi)有收入的群體，所以物美價(jià)廉的外賣是他們的首選。學(xué)生一般對(duì)快遞的送達(dá)時(shí)間會(huì)有相對(duì)較大的容忍度。學(xué)生中對(duì)刷卡的需求不是很迫切，他們一般更喜歡現(xiàn)在付款，所以如果有貨到付款的服務(wù)會(huì)很合適。同時(shí)，如果可以用學(xué)生卡打折，我想會(huì)很受學(xué)生們的歡迎。
 
3.欲望也有輕重緩急
 
在需求收集和整理完成后和項(xiàng)目開(kāi)始開(kāi)發(fā)之前，我們需要召開(kāi)需求評(píng)審會(huì)來(lái)確定每個(gè)需求的優(yōu)先級(jí)和開(kāi)發(fā)計(jì)劃。如果你的團(tuán)隊(duì)正在使用 Scrum 敏捷開(kāi)發(fā)，那么你們一定在用用戶故事來(lái)整理用戶需求。用戶故事通常使用客戶和團(tuán)隊(duì)都可以看懂的表達(dá)方式來(lái)寫，每一個(gè)用戶故事都是產(chǎn)品的一個(gè)需求。當(dāng)然，用戶故事還包括需求的商業(yè)價(jià)值和相關(guān)人員。使用用戶故事可以方便的與客戶溝通，而且不用查看繁瑣的需求文檔。
 
用戶故事一般使用如下格式：為了[商業(yè)價(jià)值]，作為[角色]，我想要[做某事]。還是使用“餓了么”軟件為例，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達(dá)，作為上班族，我想要查看每家餐廳的外賣送達(dá)預(yù)估時(shí)間。
 
在用戶故事確定以后，我們需要召集開(kāi)發(fā)人員，客戶還以一些產(chǎn)品的相關(guān)人員來(lái)參加需求評(píng)審會(huì)。在會(huì)議上，我們需要對(duì)每個(gè)需求的商業(yè)風(fēng)險(xiǎn)，技術(shù)風(fēng)險(xiǎn)，開(kāi)發(fā)耗時(shí)和優(yōu)先級(jí)作出評(píng)估。
 
首先需要確定的是商業(yè)風(fēng)險(xiǎn)，也就是確定哪些是核心需求，哪些是亮點(diǎn)需求。核心需求需要盡早完成，缺失了產(chǎn)品就不完整。而亮點(diǎn)需求有則會(huì)給產(chǎn)品加分，沒(méi)有也不會(huì)影響用戶的使用。一般來(lái)講，核心需求的商業(yè)風(fēng)險(xiǎn)會(huì)比較低，因?yàn)檫@些需求都是產(chǎn)品必須的，被砍掉的可能性很低。而亮點(diǎn)需求的商業(yè)風(fēng)險(xiǎn)就會(huì)高，可能會(huì)因?yàn)殚_(kāi)發(fā)時(shí)間不足而被砍掉或者被放入下次版本迭代的周期中。
 
下來(lái)需要確定技術(shù)風(fēng)險(xiǎn)和開(kāi)發(fā)耗時(shí)，技術(shù)風(fēng)險(xiǎn)代表的是這個(gè)需求開(kāi)發(fā)的難易程度。如果這個(gè)需求所需要的技術(shù)開(kāi)發(fā)團(tuán)隊(duì)從來(lái)沒(méi)接觸過(guò)，需要對(duì)這個(gè)技術(shù)從頭開(kāi)始學(xué)習(xí)。那么這個(gè)需求的技術(shù)風(fēng)險(xiǎn)就會(huì)很高，因?yàn)檫@個(gè)新技術(shù)不知道開(kāi)發(fā)團(tuán)隊(duì)是否能掌握，多久才能掌握。技術(shù)風(fēng)險(xiǎn)的評(píng)估對(duì)開(kāi)發(fā)耗時(shí)的評(píng)估有很大影響。開(kāi)發(fā)耗時(shí)在 Scrum 開(kāi)發(fā)團(tuán)隊(duì)中一般用時(shí)間點(diǎn)來(lái)計(jì)算，一個(gè)時(shí)間點(diǎn)代表一個(gè)理想工作日。在我的團(tuán)隊(duì)中，一般使用斐波那契數(shù)列來(lái)劃分時(shí)間點(diǎn)的等級(jí)。因?yàn)槲覀儼l(fā)現(xiàn)工程師經(jīng)常在為一個(gè)需求的時(shí)間點(diǎn)而爭(zhēng)論不休。如果為一個(gè)需求是 2 個(gè)時(shí)間點(diǎn)還是 3 個(gè)時(shí)間點(diǎn)而爭(zhēng)論，這是有意義的，因?yàn)?3 個(gè)時(shí)間點(diǎn)比 2 個(gè)多了一半的工作量。但是如果在為一個(gè)需求是 99 個(gè)時(shí)間點(diǎn)還是 100 個(gè)時(shí)間點(diǎn)而爭(zhēng)論就是沒(méi)有意義的，因?yàn)檫@一個(gè)時(shí)間點(diǎn)的差別對(duì)我們的影響很小。為了避免這種無(wú)意義的爭(zhēng)論，我們使用斐波那契數(shù)列來(lái)劃分時(shí)間點(diǎn)，這個(gè)時(shí)候工程師只需要考慮這個(gè)需求的耗時(shí)更靠近 89 還是 144 ，而不用為了細(xì)小的差別而爭(zhēng)論不休。在評(píng)估技術(shù)風(fēng)險(xiǎn)和開(kāi)發(fā)耗時(shí)時(shí)，一般都有技術(shù)人員和項(xiàng)目經(jīng)理來(lái)確定，其他人員不應(yīng)該左右技術(shù)人員和項(xiàng)目經(jīng)理的思維。

 2/3   首頁(yè) 上一頁(yè) 1 2 3 下一頁(yè) 尾頁(yè)