文／ThoughtWorks 張久坤

在莊子的《南華經(jīng)》中有一則寓言崇棠。說是有位叫丁的廚師，替梁惠王殺牛蔽午，其技法之嫻熟易茬，有行云流水一般的順暢感〖袄希惠王就問他為什么有如此高超的技術(shù)抽莱。他回答說：“臣所喜好的是『道』，早就超越所謂的技術(shù)了骄恶。最初臣殺牛的時候食铐，眼里看到的都是『完整的牛』僧鲁；三年之后眼中就再看不到『完整的排吧耄』。到了現(xiàn)在寞秃，臣以精神接觸斟叼，而不用眼睛看牛，視覺感官停止了而精神在活動春寿。按天然的道理朗涩，擊入牛筋骨的縫隙，順著筋骨的空洞進刀绑改，依照它本來的構(gòu)造谢床，牛的筋骨接合的地方，臣都未以刀刃碰到過厘线，而何況是大骨頭呢识腿！”

同樣的道理。當(dāng)我們在面對一頭牛－－復(fù)雜的業(yè)務(wù)需求時造壮，如果不得其構(gòu)造渡讼，不明其法，是不能夠很好的拆解的耳璧。只有對需求深入了解硝全，按照其本來的構(gòu)造，在筋骨的縫隙處下刀楞抡，才能拆出不錯的用戶故事。今天在這里析藕，就給大家介紹一些解牛之法召廷。非『道』，唯術(shù)爾。

工作流系統(tǒng)

我們平時經(jīng)常會接觸到工作流類的系統(tǒng)竞慢。所謂工作流先紫，就是我在完成一件工作的過程中，需要經(jīng)過多個步驟筹煮，可能還會有多個不同的角色參與遮精。對于這種系統(tǒng)，我們一般有兩種方式 —— 橫切和縱切败潦。

1本冲、橫切

所謂橫切，就是先切分出工作流中核心且輕薄的一層劫扒，然后再去實現(xiàn)各個步驟中的細節(jié)部分檬洞。這對于那些核心業(yè)務(wù)邏輯比較簡單、但每個步驟的附屬功能多且復(fù)雜的工作流系統(tǒng)來說比較適用沟饥。

（橫切示例）

舉個例子：

假如現(xiàn)在我們需要做一個商旅訂票系統(tǒng)添怔，其簡化的訂票流程如下圖所示：

（攜程商旅的工作流案例）

在這個流程中，每個步驟都包含了很多個功能贤旷。比如“會員查找需要預(yù)定的航班”這一步广料，會員的需求可能會包含：

• 根據(jù)起始城市搜索航班
• 根據(jù)選擇的城市，找出最近的機場所在城市
• 使用GPS定位所在城市
• 翻轉(zhuǎn)起止城市
• 根據(jù)航班號選擇航班

如果采用橫切的話幼驶，我們僅會選取讓本流程可以工作的最小故事集艾杏，如

• 根據(jù)起始城市搜索航班

甚至，在本故事中县遣，我們可以設(shè)置會員僅能通過精確輸入起落地城市名稱的方式糜颠，來進行航班搜索，在不影響本步驟走通的情況下萧求，來最小化這個步驟的工作量其兴。其它的流程也使用同樣的策略，來加速打通整個業(yè)務(wù)流程夸政。

橫切的優(yōu)勢在于可以快速實現(xiàn)核心邏輯元旬，并快速上線，驗證假設(shè)并收集反饋守问，可以根據(jù)反饋的結(jié)果來決定每個步驟中的功能應(yīng)該如何設(shè)計匀归、優(yōu)先級是什么，來避免一些可能出現(xiàn)的浪費耗帕。缺點在于整個工作流設(shè)計會采用短平快的原則穆端，用戶體驗較差。

2仿便、縱切

另一種方式是縱切体啰≡芪。縱切就是按照工作流中的每一個步驟進行切分，這樣可以使每一個步驟都具有相對完善的功能荒勇，這在某些需要關(guān)注終端用戶交互體驗的產(chǎn)品中應(yīng)用較多柒莉。注意，這里有個技巧：如果在整個工作流中沽翔，需要跟終端用戶進行交互的功能僅出現(xiàn)在某幾步中兢孝，如第一步和最后一步，而中間的N-2步都是后臺流程仅偎，在開發(fā)中跨蟹，我們可以先實現(xiàn)第一步和最后一步的功能，而中間的流程處理環(huán)節(jié)哨颂，仍然采用逐步線上化的方式喷市，這樣可以使整個工作流系統(tǒng)最快的上線，同時能平衡用戶的交互體驗威恼。

（縱切）

比如上面攜程商旅訂票系統(tǒng)的例子品姓，我們可以把涉及終端用戶操作的步驟：

• 會員查找航班
• 會員發(fā)起訂票申請
• 公司審批人審批訂票申請
• 會員收到訂票成功通知

把這幾個步驟拆出來優(yōu)先實現(xiàn)，及早上線箫措；而中間的跟票務(wù)相關(guān)的步驟腹备，仍然采用線下的形式。比如工作人員在攜程商旅后臺斤蔓，把訂單導(dǎo)出到excel表中植酥，人肉打電話給票代，再把票代確定的訂票信息填入系統(tǒng)弦牡，然后手動通知會員友驮。這種方式對于一些流程復(fù)雜但用戶量較小的初創(chuàng)公司比較適用，可以在保證用戶體驗的情況下驾锰，大大提升產(chǎn)品上線速度卸留，并降低試錯成本。

在這里要注意的是椭豫，不管是橫切還是縱切耻瑟，工作流中的每一個步驟都會遵循80/20法則，也就是20%的功能決定了這個步驟的核心價值赏酥，而80%的功能僅僅是錦上添花的喳整，所以我們需要更深刻地研究客戶的真正需求是什么，提煉出這20%的業(yè)務(wù)價值到底在哪里裸扶，從而進行更加合理的拆分框都。

功能模塊拆分

對于已經(jīng)拆出的功能模塊，仍然可以根據(jù)一些方法進行進一步的拆分呵晨，這里介紹三個方法瞬项。

1蔗蹋、按業(yè)務(wù)規(guī)則拆分

同樣的流程和操作，由于輸入的數(shù)據(jù)業(yè)務(wù)規(guī)則不同囱淋，因此進行數(shù)據(jù)處理時采用的方式也不同。對于這樣的情況餐塘，我們可以把功能按照業(yè)務(wù)規(guī)則來進行拆分妥衣。

典型的例子是搜索引擎，比如Google戒傻。在Google中税手，輸入框只有一個，但Google會根據(jù)你所輸入的數(shù)據(jù)規(guī)則的不同需纳，來進行不同的處理操作芦倒。看下面幾種情況：

• 在Google搜索框中輸入一個關(guān)鍵字不翩，得到這個關(guān)鍵字相關(guān)的搜索結(jié)果
• 在Google搜索框中輸入一個算式兵扬，如“ 1+1=”，得到算式的結(jié)果
• 在Google搜索礦中輸入“ThoughtWorks site:www.example.com”口蝠，得到在www.example.com這個站點中出現(xiàn)ThoughtWorks的頁面
• ...

對于這樣的情況器钟，我們可以把每一個業(yè)務(wù)規(guī)則都單獨拆分成一個用戶故事。當(dāng)然妙蔗，雖然這些用戶故事看起來很相似傲霸，但是大部分情況下，這些規(guī)則的優(yōu)先級是截然不同的眉反￡甲模總會有一簇最高優(yōu)先級的用戶故事以及圍繞在外圍的用戶故事。比如在這個例子中寸五，對于Google來說梳凛，支持關(guān)鍵字搜索一定是最高優(yōu)先級的，需要在產(chǎn)品設(shè)計的一開始就要實現(xiàn)播歼，而能夠計算算式的伶跷，可能很多年之后，才開始考慮加這樣一個功能秘狞。

2叭莫、1+N模式

第二種情況，是對同樣一個流程烁试，在終端接不同的網(wǎng)關(guān)或渠道雇初。最典型的例子是在線支付。比如减响，我在京東上買了一盒磁力橡皮泥靖诗，提交訂單進入支付流程郭怪，在支付頁面可以選擇微信支付、京東支付刊橘、銀行卡支付等等鄙才。

第一次實現(xiàn)支付的功能，可能會比較復(fù)雜促绵，但后面如果從一種擴充到多種支付方式攒庵，就相對比較簡單。而且最先需要支持什么樣的支付方式败晴，你可能在一開始也拿不定主意浓冒。這個時候，我們不妨將支付功能拆成2張卡尖坤，形如

• 會員可以使用微信支付/京東支付/網(wǎng)銀支付中的一種進行支付
• 會員可以使用微信支付/京東支付/網(wǎng)銀支付三種渠道進行支付

使用這種拆分方法稳懒，可以延遲決策-我們需要最先支持哪種支付方式，同時合理的評估項目的工作量慢味。

3场梆、復(fù)雜的業(yè)務(wù)模型拆分

對于有的系統(tǒng)，業(yè)務(wù)模型可能會非常復(fù)雜贮缕，比如一個房產(chǎn)交易平臺中的房產(chǎn)信息辙谜，可能包含戶型信息、中介信息感昼、地理位置信息装哆、價格及購買相關(guān)的稅率信息、展示圖定嗓、效果動畫等等蜕琴，當(dāng)我們需要在系統(tǒng)中引入這樣一個業(yè)務(wù)模型時，如果一上來就要考慮清楚這個業(yè)務(wù)模型的方方面面宵溅，是個性價比很低的事情——做了很多功課凌简，但沒有給客戶帶來真正的業(yè)務(wù)價值。

這個時候恃逻，我們需要將業(yè)務(wù)模型雏搂，按照我們實際需要提供的功能進行拆分。比如寇损，我們要做一個中介搜索系統(tǒng)凸郑，可以僅取出模型中的中介信息，而不需要處理其它部分矛市。即使我們需要整個業(yè)務(wù)模型去做一些事情芙沥，也可以把其拆成一個個子模型，根據(jù)子模型的業(yè)務(wù)價值及優(yōu)先級去設(shè)計相應(yīng)的功能。

比如在這個例子中而昨，我們需要對房產(chǎn)的信息做展示

• 對于戶型信息救氯，需要有戶型圖，戶型相關(guān)的文案展示
• 對于中介信息歌憨，可以看到中介人的頭像着憨、聯(lián)系方式，可以使用多種方式在線聯(lián)系中介代理
• 對于地理信息务嫡，我可以在Google Map上查看其地理位置享扔，并能夠從我的位置導(dǎo)航過去
• 對于展示的圖片和動畫，我需要像幻燈片一樣植袍，可以在頁面上播放
• ......

那么，如果我們一開始就著手于解析這個房產(chǎn)業(yè)務(wù)模型籽懦，那可能浪費了很多時間于个，而沒有交付對用戶有價值的業(yè)務(wù)功能。這個時候暮顺，我們需要區(qū)分哪些信息是核心信息厅篓，是對用戶來說最有價值的，把這些信息從業(yè)務(wù)模型中提取出來捶码，而后設(shè)計相應(yīng)的更小的業(yè)務(wù)功能羽氮，切忌一蹴而就。

需求拆分是否有一套完美的方法惫恼？

需求拆分是沒有銀彈的档押，要根據(jù)具體的場景、限制來選擇合適的拆分方法祈纯。在遇到使用某個拆分方法令宿，不能滿足當(dāng)前業(yè)務(wù)需求時，看看是不是可以換個思路腕窥，換個方法粒没。

當(dāng)然，在選擇拆分方法時簇爆，也有一些技巧癞松，如

• 基于80/20法則，選擇那些可以拆出低優(yōu)先級卡片（或者可以被扔掉的卡片）的拆卡法入蛆。
• 選擇可以把卡片拆的大小差不多的方法响蓉，未來在發(fā)布計劃中更容易做需求置換
• 選擇開發(fā)團隊更容易理解和實現(xiàn)的方式

當(dāng)然，這一定不全面安寺，每個人在不同的場景厕妖、限制條件下，都會有不同的技巧。相信你自己的拆分方法言秸，多與團隊成員溝通才是不變的法門软能。

以終為始-故事驗收方法

Bill Wake提出了一個好用戶故事的驗收標準——INVEST模型，它由六個單詞的首字母組成举畸，分別是

• Independent：每個用戶故事應(yīng)該是獨立的查排，不會和其他用戶故事產(chǎn)生耦合
• Negotiable：并不會非常明確的闡述功能，細節(jié)應(yīng)帶到開發(fā)階段跟程序員抄沮、客戶來共同商議
• Valuable：每一個用戶故事的交付都要能夠給用戶帶來用戶價值
• Estimable：不需要能夠準確的估計跋核，但需要能輔助客戶排定優(yōu)先級
• Small：要小一點，但不是越小越好叛买，要大小合適砂代，可以更容易的圈定故事范圍
• Testable：需要能夠進行驗收測試，最好能把Test Case提前加進去

這不僅僅是故事的驗收原則率挣，更是在進行需求拆分的時候所需要考慮的拆分原則刻伊。當(dāng)然，凡事有例外椒功。在需求拆分中捶箱，有時會拆出一些實在不能滿足INVEST原則的故事卡片，也不要太糾結(jié)动漾，我們追求完美丁屎，但也總要接受現(xiàn)實的不完美。這個時候旱眯，跟開發(fā)團隊多交流晨川，開拓思路，協(xié)調(diào)一個比較好的拆分方式键思，比自己一個人憋大招要好的多础爬。

最后

再介紹幾個反模式。

• 按照技術(shù)架構(gòu)分層進行拆分吼鳞，常見的會按照持久層看蚜、應(yīng)用層、展示層進行拆分赔桌。這種拆分方式拆出來的用戶故事供炎，會明顯破壞INVEST中的Valuable的原則，而且各個故事卡由于各方面的原因疾党，如開發(fā)進度不統(tǒng)一音诫，無法靈活的集成上線。
• 拆分時雪位，把復(fù)雜的UI交互算在故事卡片中竭钝。大部分情況下，比較fancy的UI交互都不是核心的業(yè)務(wù)功能，這部分功能可以作為用戶體驗優(yōu)化的卡片香罐，獨立拆出來卧波。
• 拆分時，過早考慮性能問題庇茫。在性能基本達標港粱、不出現(xiàn)大問題的情況下，提升性能很多情況下也屬于用戶體驗的一部分旦签，可以單獨拆出來查坪，左右優(yōu)化卡片。
• 拆出一些管理類的卡片宁炫。比如管理產(chǎn)品偿曙，實際上可能包含很多產(chǎn)品相關(guān)的操作，如導(dǎo)入羔巢、編輯遥昧、同步信息、改變狀態(tài)朵纷、上架、下架等永脓，所以應(yīng)該根據(jù)具體的功能袍辞，拆分成更為準確和大小合適的故事卡片。

歐陽修在《賣油翁》中常摧，提到一個老翁搅吁，在倒油時能通過銅錢中心的方孔，卻不灑一滴油落午，大家都很驚嘆谎懦，他只說了一句話——“無他，但手熟爾”溃斋。需求拆分也一樣界拦，并沒有什么高深的學(xué)問，拆的次數(shù)多了梗劫，也便有了那份手熟享甸。