敏捷模式隨着移動互聯網的發展變得越來越普遍與流行，那麼對B端產品來說，是否可以運用敏捷開發模式呢？如果可以的話，又有哪些注意要點呢？

在中國移動互聯網流行之前的2011年以前，B端軟件的研發大多還是傳統的瀑布式研發的方式，後面隨着移動互聯網的發展，To C端軟件普遍使用敏捷模式來做。

但是目前仍然還有很多人採用瀑布式方式來進行B端軟件的開發，不看好敏捷模式進行B端產品的開發，那麼重流程，業務高耦合度的B端軟件是否適合敏捷的開發模式？

今天我們探討一下什麼樣的B端軟件適合敏捷開發，以及B端軟件進行敏捷開發的一些要點，在此之前我們看一下敏捷的定義以及價值觀：

01 敏捷的定義

敏捷是一種管理項目的方式。它將大型項目分解爲可管理的小塊，稱爲迭代（sprint）。在每次迭代結束時，都會產生一些有價值的功能，每次迭代期間的產出物都應該能夠發佈出去，用來獲取市場用戶的反饋。

02 敏捷價值觀

正如“敏捷宣言”所宣稱的，敏捷價值觀如下：

• 交流比流程以及工具更加重要
• 運行的軟件勝於完整的文檔
• 與客戶合作而非談判
• 響應計劃變更

敏捷意識到軟件項目本質上是不可預測的。在任何項目過程中，市場，團隊，戰略都可能會發生變化，在產品推向市場之後，變化也是隨時發生的， 敏捷擁抱了這種不可預測性。 通過將項目分解成小塊，可以輕鬆地在項目中對功能進行優先級劃分，進行添加刪除，在傳統的瀑布項目中，這是不可能的，敏捷模式大大增加了項目成功的可能性，也降低了市場試驗成本。

03 敏捷開發適合B端產品嗎？

瞭解了敏捷的定義以及價值觀，我們實際上知道了敏捷開發的本質是什麼，是擁抱變化，擁抱不可預測性，更好的應對產品的不可預測性。

一般來說B端產品在確定產品定位要做什麼之後，相對來說公司需要管理的業務是比較固定的，HR,CRM,ERP等企業信息管理軟件都有相對固定的業務以及流程，不像C端產品那樣每個功能的推出，市場的反饋有很大的未知性。

所以從這種角度來說，C端產品天然就是更加適合敏捷開發的； B端軟件，如果可預測性越大，那麼實際上對於敏捷開發的需求強烈程度越小，基於這個概念你可以去判斷你的產品對於敏捷開發的需求程度。

B端項目又分爲那種單個客戶定製化的項目或者適合大量客戶的產品，對於一個面向廣大市場的通用產品來說，產品時間跨度大，市場客戶情況複雜，競爭對手多，這樣的情況基本來說都是敏捷模式是更適合的一種情況；對於一些定製化的B端項目，如果項目週期跨度很長，爲了減少不確定性，也是建議採用敏捷的方式來進行迭代；如果一些週期短的定製化項目，可以基於情況考慮瀑布式的開發方式。

04 敏捷模式開發的一些要點

很多B端產品公司想去實施敏捷模式，但是很難真正落地，或者最後搞的四不像，筆者將B端軟件敏捷實施中的一些要點概括如下，希望對大家有一些幫助：

1. 如果要實施敏捷模式，公司首先需要在理念上面統一起來

首先我們要知道敏捷模式的實施不只是產研部門的事情，敏捷模式是全公司的事情，公司這邊產研和業務，銷售部門建立密切合作而非對立的價值觀和文化。公司內部各部門通力協作，以客戶爲中心，形成產品快速迭代，快速推向市場，快速收集市場客戶反饋，快速基於反饋來進行調整的閉環。

2. 實施敏捷模式，需要首先從組織架構出發

敏捷模式的建立先從組織架構的調整開始，產研需要建立一個支持敏捷模式的組織架構，每個敏捷團隊人數在7-15人，不要超過15人，以7-9人爲佳，裏面包含PO，Scrum master，設計人員，開發人員，測試人員的角色。

如果項目比較複雜的時候，可以分割成爲多個敏捷小組，在敏捷小組之上設置總PO，負責多個敏捷之間需求的協同（這個總PO一般就是產品負責人）。

敏捷小組應該儘量負責相對獨立的功能模塊，降低敏捷小組之間的耦合性，可以將和其他小組高耦合度的共通功能模塊單獨分成一個敏捷小組。

在產研部門之外，每個相關的業務部門，包括市場，運營，銷售部門都要有項目的相應的Stakeholder, Stakeholder和PO 團隊在需求業務，需求優先級，產品評審，產品發佈方面密切合作，貫穿整個產品過程，共同協作爲產品負責。

3. 幾個角色的注意事項

每個敏捷小組有多個角色，重點將PO以及Scrum master的角色說明一下，PO就是一般意義上面的產品經理，負責需求收集，優先級管理，需求整理以及相關原型邏輯設計，產品驗收等等。

Scrum master這個角色很多公司有不同的理解，Scrum master實際上就是敏捷的教練，也爲流程，項目協調以及項目進度來負責，Scrum master可以是獨立的一個人來承擔，中小公司也可以兼任，一個很強的PO是可以來兼任這個角色的（雖然一般不這樣建議）。 一般建議Scrum master可以在每個迭代讓團隊所有的角色輪流來進行兼任。

4. 幾個關鍵會議的注意事項

主要的幾個會議包括迭代計劃會，需求梳理會，每日站會，迭代評審會，迭代回顧會。

這裏重點說明強調一下每日站會，每日站會由Scrum master來組織，說明昨天進展以及今天工作內容，敏捷強調的是建立一個自驅的團隊，任務的領取需要讓大家主動來領取，不要強行分配的方式,這裏不要擔心大家都領取簡單的任務，團隊保證足夠透明的時候，實際上這樣的事情很難成立。

迭代的評審會需要讓業務部門的stakeholder充分參與起來，進行產品的demo，這個會議不能舉行或者成爲形式，當然這個環節的執行情況很多時候取決於公司層面的宣導，以及產研外部的stakeholder的具體情況。

迭代的回顧會也很重要，敏捷的一個重要思想是通過回顧不斷迭代，不斷提升，回顧會是覆盤以及團隊成長的重要步驟，很多團隊在執行的時候爲了趕進度會漏掉這個環節，實際上這個環節很重要。  

5. 敏捷開發，先要做好產品的MVP

作爲一個新產品的開發，首先第一步就是要通過敏捷模式開發完成mvp，推向市場，然後通過敏捷的迭代進行後續的開發會相對容易。關於mvp定義的內容可以參考我原來的一篇文章 《如何做B端產品的MVP》。

一般來說mvp是由多個迭代組成，每個迭代都可以先內部發布，以及讓外部客戶參與評審，等MVP完成之後作爲產品向外發佈，進行PMF的試驗，關於PMF的試驗可以參考我原來的一篇文章《怎樣做B端產品的PMF》

6. 對於複雜的業務，化繁爲簡，層層遞進

一般來說複雜的業務更具未知性，無論是市場反應還是從產品質量保證來說都是如此，面對複雜業務一個原則是化繁爲簡，將一個複雜的內容變成多個簡單的部分，分迭代實施，層層遞進分步去試驗市場的反應，從而降低市場以及產品質量等各方面的風險，不要一下子推出一個非常複雜的內容，實際上用戶理解以及接受使用的成本也會比較高。

7. 慶祝小勝，覆盤成長

敏捷相對冗長的瀑布式開發，還有一個好處，就是可以看產品團隊快速看到產品的效果，一個產品的最終勝利是由這些小的迭代勝利組成的，在每個迭代的勝利之後，除了覆盤的成長，還需要慶祝這些小勝利，鼓舞團隊，慢慢形成一個團結，高速成長，戰鬥力強，士氣高漲的團隊。

總結上面內容的幾個關鍵詞，便於大家記憶， 那就是建立自驅的團隊和機制，和業務團隊合作，高頻交流，化繁爲簡，持續快速交付產品，覆盤成長 。另外敏捷模式在落地方式上面是基於公司情況，會有很多小變化的，大家可以基於自己公司的情況摸索選擇最好落地的方式來實操。

作者：李東林（微信公衆號：SaaS產品說；微信號：jianguzhuxin），菜小祕聯合創始人，原ADP大中華區產品負責人，14年To B研發與產品設計，團隊管理經驗，主導過多款大型企業管理軟件的設計、研發、上線，也有過數年移動互聯網TO C的創業經驗。

本文由@李東林 原創發佈於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基於CC0協議。

相關文章