中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

敏捷模式隨著移動互聯網的發展變得越來越普遍與流行，那么對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產品說，人人都是產品經理專欄作家。14年To B研發與產品設計，團隊管理經驗；主導過多款大型企業管理軟件的設計、研發、上線，也有過數年移動互聯網TO C的創業經驗。

本文原創發布于人人都是產品經理，未經許可，禁止轉載。

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