需求收集

敏捷開發(fā)模式下照樣有需求收集的過程，不然開發(fā)個(gè)什么勁呢，不管是產(chǎn)品經(jīng)理自己的想法，還是用戶的需求，總有一個(gè)收集驗(yàn)證的過程。那么如何進(jìn)行需求收集呢？除了老三樣的問卷調(diào)查、意見反饋、競品分析外，還可以有數(shù)據(jù)分析、同事反饋、用戶觀察等。

意見反饋：現(xiàn)在做任何互聯(lián)網(wǎng)的產(chǎn)品，一般都會在產(chǎn)品上預(yù)留一個(gè)給用戶反饋使用意見的口子，這就是我們經(jīng)常在各個(gè)產(chǎn)品中見到的“意見反饋”鏈接頁面或者是按鈕彈窗，用以收集用戶在使用過程當(dāng)中反饋過來的信息，進(jìn)而把這些信息收攏起來做統(tǒng)一分析，以得出相應(yīng)的分析結(jié)果，看是否可以轉(zhuǎn)換為產(chǎn)品需求。具體的處理過程可以參見意見反饋—小功能大設(shè)計(jì)。

問卷調(diào)查其實(shí)也是用戶反饋中的一種，用以對特定人群或者不限人群投放預(yù)先設(shè)計(jì)好的問卷調(diào)查內(nèi)容，適當(dāng)加以鼓勵(lì)填寫的措施，以收集到一定數(shù)量的用戶填寫信息。

競品分析應(yīng)該是最常用的一種方式，這種方式最為直觀，可以直接找到相類似的產(chǎn)品進(jìn)行使用，然后分析其功能點(diǎn)和特性，找出優(yōu)缺點(diǎn)。這種方式最常見，所以也經(jīng)常造成功能上先類似的產(chǎn)品之間長的都差不多，也就是大家都說的“天下文章一大抄”，加引號的哈，我們還是有創(chuàng)新的，呵呵。

數(shù)據(jù)分析的方式是比較適合敏捷開發(fā)的，原因在其分析的結(jié)果可以快速的反應(yīng)在開發(fā)結(jié)果上，以觀察實(shí)際更改后的效果，比如一個(gè)購物流程，發(fā)現(xiàn)用戶老是停留在購物車頁面，就是無法轉(zhuǎn)換成有效訂單，這個(gè)結(jié)論一出來，我們就可以去分析購物車頁面是否哪里體驗(yàn)做的不夠好，導(dǎo)致用戶提交訂單的比率下降，分析的結(jié)果可以馬上進(jìn)行開發(fā)改進(jìn)。

用戶觀察是要坐到用戶旁邊去觀察用戶使用產(chǎn)品的操作過程，不做任何限定，讓用戶以自己的方式隨意使用產(chǎn)品，觀察整個(gè)使用過程，適當(dāng)?shù)倪€可以進(jìn)行一些提問。這種方式成本比較高，比較適合觀察公司內(nèi)部用戶，或者是在用戶的電腦上安裝錄屏軟件，以達(dá)到事后觀察的效果。

同事反饋只能小范圍使用，其實(shí)就是內(nèi)部PK，三個(gè)臭皮匠頂個(gè)諸葛亮，一群產(chǎn)品經(jīng)理的智慧是比較可怕的，自己設(shè)計(jì)的產(chǎn)品要勇于拿出去分享，在PD內(nèi)部做頭腦風(fēng)暴，有時(shí)候會有意想不到的效果。

此外還有微博搜索、博客搜索等信息收集的渠道，不再一一闡述。

需求記錄

把搜集回來的需求做一定的分析之后得出的結(jié)論就是我們要記錄的需求條目，也就是可以排到敏捷開發(fā)計(jì)劃里面去實(shí)現(xiàn)的需求列表。一般我們記錄某個(gè)需求條目的時(shí)候都會考慮到用戶場景，以一個(gè)故事的形式表述出來。

用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個(gè)好的用戶故事包括三個(gè)要素：

1.角色：誰要使用這個(gè)功能。

2.?活動：需要完成什么樣的功能。

3.?商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么樣的價(jià)值。

用戶故事通常按照如下的格式來表達(dá)：作為一個(gè)<角色>, 我想要<活動>, 以便于<商業(yè)價(jià)值>。舉例：

作為一個(gè)“網(wǎng)站管理員”，我想要“統(tǒng)計(jì)每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他們帶來什么收益?！?/p>

需要注意的是用戶故事不能夠使用技術(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。具體的使用我想大家都非常清楚，畢竟產(chǎn)品經(jīng)理每天都在和各色的用戶故事做斗爭。

需要注意的是，這樣的需求條目在安排到敏捷開發(fā)的計(jì)劃當(dāng)中時(shí)，這些用戶故事必須滿足以下條件：

用戶故事的六個(gè)特性- INVEST（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable ）

一個(gè)好的用戶故事應(yīng)該遵循INVEST原則：

獨(dú)立性（Independent）— 要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事之間的依賴使得制定計(jì)劃，確定優(yōu)先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。

可協(xié)商性（Negotiable）— 一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個(gè)用戶故事卡片上只是對用戶故事的一個(gè)簡短的描述，不包括太多的細(xì)節(jié)。具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。

有價(jià)值（Valuable）— 每個(gè)故事必須對客戶具有價(jià)值（無論是用戶還是購買方）。一個(gè)讓用戶故事有價(jià)值的好方法是讓客戶來寫下它們。一旦一個(gè)客戶意識到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂意寫下故事。

可以估算性（Estimable）—開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級，工作量，安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時(shí)需要把故事切分成小些的）。

短小（Small）— 一個(gè)好的故事在工作量上要盡量短小，最好不要超過10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代或Sprint中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會越大。

可測試性（Testable）—一個(gè)用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測試，那么你就無法知道它什么時(shí)候可以完成。一個(gè)不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。

需求優(yōu)先級

如何判斷需求優(yōu)先級，這個(gè)根據(jù)不同的產(chǎn)品需求、業(yè)務(wù)場景會有不一樣的考量，不過一般可以遵循如下兩個(gè)原則：

1、? 價(jià)值，包括對產(chǎn)品自身的價(jià)值和對用戶的價(jià)值，價(jià)值越高的優(yōu)先級越高；

2、? 緊迫性，時(shí)間要求越高的優(yōu)先級越高，特別是線上問題的解決這種；

其他的考量具體的場景都會不大一樣，但是有一點(diǎn)，在評定需求優(yōu)先級的時(shí)候最好數(shù)值化，就是給每個(gè)需求條目打分，評定一個(gè)優(yōu)先級的值，這樣最直觀，單純的只是說優(yōu)先級高、中、低不夠直觀，直接給一個(gè)數(shù)字就直接多了。比如1~10中10代表最高，優(yōu)先級高的有10，9，8三種，顯然優(yōu)先級同為高的里面，10的就比8的優(yōu)先多了。

需求變更

不可避免，我們都需要面對這樣的問題，幸好，敏捷開發(fā)最大的優(yōu)勢就是可以擁抱變化。但也不是說就可以想變就變，產(chǎn)品經(jīng)理還是要盡量控制好這種變更的發(fā)生，只有當(dāng)一些不可控的因素發(fā)生后才行，比如政策法規(guī)改了這種，其他的都要盡量避免，所以說在制定需求規(guī)劃的時(shí)候一定要完善才行。

采用了敏捷模式，不代表產(chǎn)品經(jīng)理只要和開發(fā)人員口頭講一下需求就可以了，還是要有一個(gè)完整的需求規(guī)劃過程，口頭的方式變數(shù)太大，還是會影響到產(chǎn)品的進(jìn)展的。所謂以用戶痛點(diǎn)為中心的設(shè)計(jì)，就很適合敏捷的模式，快速迭代更改的都是用戶繼續(xù)得到解決或者改善的功能，自然需求優(yōu)先級也會比較高。需求規(guī)劃會貫穿產(chǎn)品過程，這樣才能保證在敏捷的過程中產(chǎn)品的一致性。

下一篇：敏捷開發(fā)模式中的需求實(shí)現(xiàn)

轉(zhuǎn)自：http://www.itfarmer.com.cn/1793.html