起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識攜程網類產品，開發之前該如分解產品工作？
在產品開發工作正式開始之前，如能有效合理的對產品工作內容進行很好的分解和規劃，那么整個項目就會行云流水，運轉良好。而正好文章分享了關于如何拆分產品工作內容的一些心得方法，希望對你有益。
作為一個產品經理，對待產品的心情與態度好比是什么呢？做個最形象的比喻就是將產品當做自己的親身骨肉一樣看待。 從產品的創意開始，一直到產品上線實際運營當中的每個細節都要無微不至的照顧到，負責到底。
對于一個產品最終出來，會不會有先天缺陷畸形，會不會很難帶大成人。其中重要的一環，就是在產品開發之前的策劃。工作內容的合理分解與計劃。這一步做好了，團隊就有了為之奮斗的目標。整體像一臺精密的設備一樣，按部就班的，運轉良好。如果沒做好，就會引來團隊內部人員的相互扯皮，埋怨。最終導致產品胎死腹中。
今天來談一談類似攜程網這樣的工作流產品，產品經理在開發之前需要做到如何的拆解工作，才能發揮團隊的最大效益。當我們面對一個復雜的業務需求時，如果不得其構造，不明其法，是不能夠很好的拆解的。
工作流系統
我們平時經常會接觸到工作流類的系統。所謂工作流，就是我在完成一件工作的過程中，需要經過多個步驟，可能還會有多個不同的角色參與。對于這種系統，我們一般有兩種方式 —— 橫切和縱切。
1、橫切
所謂橫切，就是先切分出工作流中核心且輕薄的一層，然后再去實現各個步驟中的細節部分。這對于那些核心業務邏輯比較簡單、但每個步驟的附屬功能多且復雜的工作流系統來說比較適用。
（橫切示例）
舉個例子：
假如現在我們需要做一個商旅訂票系統，其簡化的訂票流程如下圖所示：
（攜程商旅的工作流案例）
在這個流程中，每個步驟都包含了很多個功能。比如“會員查找需要預定的航班”這一步，會員的需求可能會包含：
- 根據起始城市搜索航班
- 根據選擇的城市，找出最近的機場所在城市
- 使用GPS定位所在城市
- 翻轉起止城市
- 根據航班號選擇航班
如果采用橫切的話，我們僅會選取讓本流程可以工作的最小故事集，如：
根據起始城市搜索航班。
甚至，在本故事中，我們可以設置會員僅能通過精確輸入起落地城市名稱的方式，來進行航班搜索，在不影響本步驟走通的情況下，來最小化這個步驟的工作量。其它的流程也使用同樣的策略，來加速打通整個業務流程。
橫切的優勢在于可以快速實現核心邏輯，并快速上線，驗證假設并收集反饋，可以根據反饋的結果來決定每個步驟中的功能應該如何設計、優先級是什么，來避免一些可能出現的浪費。缺點在于整個工作流設計會采用短平快的原則，用戶體驗較差。
2、縱切
另一種方式是縱切。縱切就是按照工作流中的每一個步驟進行切分，這樣可以使每一個步驟都具有相對完善的功能，這在某些需要關注終端用戶交互體驗的產品中應用較多。注意，這里有個技巧：如果在整個工作流中，需要跟終端用戶進行交互的功能僅出現在某幾步中，如第一步和最后一步，而中間的N-2步都是后臺流程，在開發中，我們可以先實現第一步和最后一步的功能，而中間的流程處理環節，仍然采用逐步線上化的方式，這樣可以使整個工作流系統最快的上線，同時能平衡用戶的交互體驗。
（縱切）
比如上面攜程商旅訂票系統的例子，我們可以把涉及終端用戶操作的步驟：
- 會員查找航班
- 會員發起訂票申請
- 公司審批人審批訂票申請
- 會員收到訂票成功通知
把這幾個步驟拆出來優先實現，及早上線；而中間的跟票務相關的步驟，仍然采用線下的形式。比如工作人員在攜程商旅后臺，把訂單導出到excel表中，人肉打電話給票代，再把票代確定的訂票信息填入系統，然后手動通知會員。這種方式對于一些流程復雜但用戶量較小的初創公司比較適用，可以在保證用戶體驗的情況下，大大提升產品上線速度，并降低試錯成本。
在這里要注意的是，不管是橫切還是縱切，工作流中的每一個步驟都會遵循80/20法則，也就是20%的功能決定了這個步驟的核心價值，而80%的功能僅僅是錦上添花的，所以我們需要更深刻地研究客戶的真正需求是什么，提煉出這20%的業務價值到底在哪里，從而進行更加合理的拆分。
功能模塊拆分
對于已經拆出的功能模塊，仍然可以根據一些方法進行進一步的拆分，這里介紹三個方法。
1、按業務規則拆分
同樣的流程和操作，由于輸入的數據業務規則不同，因此進行數據處理時采用的方式也不同。對于這樣的情況，我們可以把功能按照業務規則來進行拆分。
典型的例子是搜索引擎，比如Google。在Google中，輸入框只有一個，但Google會根據你所輸入的數據規則的不同，來進行不同的處理操作?？聪旅鎺追N情況：
- 在Google搜索框中輸入一個關鍵字，得到這個關鍵字相關的搜索結果；
- 在Google搜索框中輸入一個算式，如“ 1+1=”，得到算式的結果；
- 在Google搜索礦中輸入“ThoughtWorks site:www.example.com”，得到在http://www.example.com這個站點中出現ThoughtWorks的頁面
…
對于這樣的情況，我們可以把每一個業務規則都單獨拆分成一個用戶故事。當然，雖然這些用戶故事看起來很相似，但是大部分情況下，這些規則的優先級是截然不同的。總會有一簇最高優先級的用戶故事以及圍繞在外圍的用戶故事。比如在這個例子中，對于Google來說，支持關鍵字搜索一定是最高優先級的，需要在產品設計的一開始就要實現，而能夠計算算式的，可能很多年之后，才開始考慮加這樣一個功能。
2、1+N模式
第二種情況，是對同樣一個流程，在終端接不同的網關或渠道。最典型的例子是在線支付。比如，我在京東上買了一盒磁力橡皮泥，提交訂單進入支付流程，在支付頁面可以選擇微信支付、京東支付、銀行卡支付等等。
第一次實現支付的功能，可能會比較復雜，但后面如果從一種擴充到多種支付方式，就相對比較簡單。而且最先需要支持什么樣的支付方式，你可能在一開始也拿不定主意。這個時候，我們不妨將支付功能拆成2張卡，形如：
- 會員可以使用微信支付/京東支付/網銀支付中的一種進行支付
- 會員可以使用微信支付/京東支付/網銀支付三種渠道進行支付
使用這種拆分方法，可以延遲決策-我們需要最先支持哪種支付方式，同時合理的評估項目的工作量。
3、復雜的業務模型拆分
對于有的系統，業務模型可能會非常復雜，比如一個房產交易平臺中的房產信息，可能包含戶型信息、中介信息、地理位置信息、價格及購買相關的稅率信息、展示圖、效果動畫等等，當我們需要在系統中引入這樣一個業務模型時，如果一上來就要考慮清楚這個業務模型的方方面面，是個性價比很低的事情——做了很多功課，但沒有給客戶帶來真正的業務價值。
這個時候，我們需要將業務模型，按照我們實際需要提供的功能進行拆分。比如，我們要做一個中介搜索系統，可以僅取出模型中的中介信息，而不需要處理其它部分。即使我們需要整個業務模型去做一些事情，也可以把其拆成一個個子模型，根據子模型的業務價值及優先級去設計相應的功能。
比如在這個例子中，我們需要對房產的信息做展示：
- 對于戶型信息，需要有戶型圖，戶型相關的文案展示
- 對于中介信息，可以看到中介人的頭像、聯系方式，可以使用多種方式在線聯系中介代理
- 對于地理信息，我可以在Google Map上查看其地理位置，并能夠從我的位置導航過去
- 對于展示的圖片和動畫，我需要像幻燈片一樣，可以在頁面上播放
……
那么，如果我們一開始就著手于解析這個房產業務模型，那可能浪費了很多時間，而沒有交付對用戶有價值的業務功能。這個時候，我們需要區分哪些信息是核心信息，是對用戶來說最有價值的，把這些信息從業務模型中提取出來，而后設計相應的更小的業務功能，切忌一蹴而就。
需求拆分是否有一套完美的方法？
需求拆分是沒有銀彈的，要根據具體的場景、限制來選擇合適的拆分方法。在遇到使用某個拆分方法，不能滿足當前業務需求時，看看是不是可以換個思路，換個方法。
當然，在選擇拆分方法時，也有一些技巧，如：
基于80/20法則，選擇那些可以拆出低優先級卡片（或者可以被扔掉的卡片）的拆卡法。
- 選擇可以把卡片拆的大小差不多的方法，未來在發布計劃中更容易做需求置換；
- 選擇開發團隊更容易理解和實現的方式。
當然，這一定不全面，每個人在不同的場景、限制條件下，都會有不同的技巧。相信你自己的拆分方法，多與團隊成員溝通才是不變的法門。
以終為始-故事驗收方法
Bill Wake提出了一個好用戶故事的驗收標準——INVEST模型，它由六個單詞的首字母組成，分別是：
- Independent：每個用戶故事應該是獨立的，不會和其他用戶故事產生耦合
- Negotiable：并不會非常明確的闡述功能，細節應帶到開發階段跟程序員、客戶來共同商議
- Valuable：每一個用戶故事的交付都要能夠給用戶帶來用戶價值
- Estimable：不需要能夠準確的估計，但需要能輔助客戶排定優先級
- Small：要小一點，但不是越小越好，要大小合適，可以更容易的圈定故事范圍
- Testable：需要能夠進行驗收測試，最好能把Test Case提前加進去
這不僅僅是故事的驗收原則，更是在進行需求拆分的時候所需要考慮的拆分原則。當然，凡事有例外。在需求拆分中，有時會拆出一些實在不能滿足INVEST原則的故事卡片，也不要太糾結，我們追求完美，但也總要接受現實的不完美。這個時候，跟開發團隊多交流，開拓思路，協調一個比較好的拆分方式，比自己一個人憋大招要好的多。
最后
再介紹幾個反模式。
按照技術架構分層進行拆分，常見的會按照持久層、應用層、展示層進行拆分。這種拆分方式拆出來的用戶故事，會明顯破壞INVEST中的Valuable的原則，而且各個故事卡由于各方面的原因，如開發進度不統一，無法靈活的集成上線。
拆分時，把復雜的UI交互算在故事卡片中。大部分情況下，比較fancy的UI交互都不是核心的業務功能，這部分功能可以作為用戶體驗優化的卡片，獨立拆出來。
拆分時，過早考慮性能問題。在性能基本達標、不出現大問題的情況下，提升性能很多情況下也屬于用戶體驗的一部分，可以單獨拆出來，左右優化卡片。
拆出一些管理類的卡片。比如管理產品，實際上可能包含很多產品相關的操作，如導入、編輯、同步信息、改變狀態、上架、下架等，所以應該根據具體的功能，拆分成更為準確和大小合適的故事卡片。
最后，對新手來說，對于如上的方法，看似繁瑣復雜。但是當你親手操作了兩個項目之后，有些步驟已經內化成了你的潛意識。上手之后就知道第一步要做什么，第二步要做什么。需求拆分多了，并沒有什么高深的學問，拆的次數多了，也便有了那份手熟。
本文由 @牛頂風 原創發布于人人都是產品經理。未經許可，禁止轉載。
??