對于敏捷開發(fā)，講它的價(jià)值、方法的內(nèi)容已經(jīng)夠多。而對于需求、設(shè)計(jì)、測試這三個(gè)環(huán)節(jié)，如何適配并融入敏捷開發(fā)的流程，卻著墨寥寥。本文主要從產(chǎn)品設(shè)計(jì)及需求表達(dá)兩個(gè)方面，介紹如何在敏捷開發(fā)的背景下，保證產(chǎn)品設(shè)計(jì)不挖坑，并為開發(fā)人員提供的高效支撐。文中所述適用于中小規(guī)模的團(tuán)隊(duì)，產(chǎn)品形態(tài)以web端非成熟期產(chǎn)品為最匹配。

1.遠(yuǎn)粗近細(xì)，規(guī)劃先行

在整個(gè)敏捷流程開始之前，應(yīng)該先檢視如下幾項(xiàng)：

（1）BRD & roadmap

此時(shí)產(chǎn)品團(tuán)隊(duì)已經(jīng)確定了所有大方向，以及達(dá)到這些方向的路徑。

（2）外部環(huán)境中的關(guān)鍵時(shí)間節(jié)點(diǎn)

此時(shí)應(yīng)該對接下來兩次迭代以內(nèi)的外部環(huán)境（如行業(yè)周期、市場壓力、節(jié)假日等運(yùn)營引爆點(diǎn)）有較為明確的把握，確保版本方向不會(huì)受迫產(chǎn)生較大的變動(dòng)。

（3）需求池

此時(shí)可能已經(jīng)積累有來自各方的需求，以及產(chǎn)品規(guī)劃中預(yù)計(jì)要新增的模塊。而每次迭代，需求來源都出自這個(gè)表格中。

根據(jù)以上，首先通過關(guān)鍵時(shí)間節(jié)點(diǎn)來修正產(chǎn)品roadmap，細(xì)化roadmap中距離當(dāng)前最近的一段時(shí)間，顆粒度最細(xì)須達(dá)到完成一次敏捷開發(fā)的所需要的時(shí)間。關(guān)于最終細(xì)化出來的產(chǎn)品路線，產(chǎn)品經(jīng)理的腦中一定要有非常清晰的節(jié)奏，明確每一步的整體目標(biāo)。完成后，應(yīng)該明確下一步迭代的兩個(gè)內(nèi)容，一是新增哪個(gè)模塊/欄目，二是優(yōu)化哪些功能、頁面。

對于新增的模塊，我們要讓它單獨(dú)進(jìn)入敏捷開發(fā)流程，必須保證它是相對獨(dú)立的，不會(huì)受到另一個(gè)未開發(fā)模塊的牽制。如果不是，那么這些模塊應(yīng)該在同一次迭代中，以最基本（基本到只剩關(guān)鍵流程）的形態(tài)同時(shí)上線。

2.先加后減，解構(gòu)產(chǎn)品

確保新增模塊的獨(dú)立性后，就到了產(chǎn)品設(shè)計(jì)的環(huán)節(jié)了。對于產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)不是非常豐富的PM來說，此時(shí)，一定確保設(shè)計(jì)環(huán)節(jié)的完整，需求分析、用戶任務(wù)和流程設(shè)計(jì)、產(chǎn)品結(jié)構(gòu)決不能被“敏捷”掉。直接動(dòng)手做流程和原型，無論時(shí)間多緊都不應(yīng)該，反而會(huì)因?yàn)橥诳樱瑢?dǎo)致在以后浪費(fèi)更多的時(shí)間去反復(fù)填坑。

我在做敏捷設(shè)計(jì)的時(shí)候，傾向于經(jīng)由完整的設(shè)計(jì)流程，產(chǎn)出相對完整的產(chǎn)品設(shè)計(jì)，然后根據(jù)敏捷周期，來對產(chǎn)品進(jìn)行精簡。這樣不會(huì)因?yàn)楹笃谪S富該功能時(shí)，由于思考不全面和先前沒有一個(gè)明確的理想解決方案，而推翻重做或者有較大改動(dòng)；也保證了產(chǎn)品功能拆分后，各個(gè)子單元在不同版本迭代完全時(shí)的產(chǎn)品一致性。

我們需要對完整稿進(jìn)行拆分和優(yōu)先級(jí)排序，找出主要流程、關(guān)鍵信息，先保證主線跑通，再考慮提升用戶體驗(yàn)的輔助性功能，以及提升用戶停留時(shí)長或提高轉(zhuǎn)化率的信息豐富手段。

由于這個(gè)完整稿，本身就是用來試錯(cuò)的，那么，我們在細(xì)化需求的時(shí)候，可以先細(xì)化主線需求到能夠交付開發(fā)執(zhí)行的程度，而對于可能有變動(dòng)甚至整體舍棄的其他分支，暫時(shí)到特性層面就可以了。

基于完整稿，我們可以提出幾種拆分方案，在需求評(píng)審時(shí)，與開發(fā)團(tuán)隊(duì)討論確定最終的目標(biāo)方案。對于該方案，我們需要在方案內(nèi)的特性中，再次排出優(yōu)先級(jí)。目的是，讓開發(fā)先做高優(yōu)先級(jí)特性，如果遇到不可預(yù)估的困難，可以馬上決策并削減優(yōu)先級(jí)低的特性，保證主流程的完成，盡量弱化工程延期的不利后果。

3.簡短明了，文盡其用

關(guān)于產(chǎn)品設(shè)計(jì)后的需求表達(dá)，我一直以來的原則就是不參考模板，靈活使用。在敏捷開發(fā)中，我們通常不可能去寫全面啰嗦的PRD，移動(dòng)端更甚。我的做法是，使用excel做產(chǎn)品backlog，省去所有對開發(fā)無意義的描述說明文字，從feature list直接獲得。審視自己寫下的每一個(gè)列首項(xiàng)，是不是對開發(fā)有用，省去所有無用項(xiàng)。

如果團(tuán)隊(duì)中沒有專職測試，甚至可以將測試功能融合進(jìn)backlog中，僅需增加測試結(jié)果與狀態(tài)兩列，而只要需求想的透徹，特性說明完全可以做基本的功能測試用例。

同時(shí)，該表格也可以融入項(xiàng)目管理的功能。狀態(tài)列中，單元格為下拉菜單，分別有待開發(fā)、待測試、完成三個(gè)狀態(tài)。

backlog表頭示例

適合每個(gè)團(tuán)隊(duì)的文檔形式各不相同，有的開發(fā)喜歡原型結(jié)合文檔進(jìn)行開發(fā)，有的喜歡看原型做，文檔備查，這些都需要PM提前溝通，了解PRD的用戶需求，砍掉無效的工作，制作出適合自己團(tuán)隊(duì)的文檔形式，并自己保證花在文檔上的時(shí)間，都是有效的。

作者：塵中之光（簡書作者）

原文鏈接：http://www.jianshu.com/p/0127f8f7b3e2

本文由 @塵中之光 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。