筆者所在的業務團隊恰好處於高速發展的B端業務團隊，為了更加“快速”的傳遞價值，無論是產品交付過程還是內部的協作鏈路，都經歷過或者正在經歷一些典型的“陣痛”，因此借筆者所經歷的一些經驗和教訓在此文中闡述一二。
B端產品與C端產品有著比較大的區別在於，B端產品的需求容易走向定向渠道，即某一類客戶或者某一個客戶提出來的需求，這對產品經理識別需求和過濾需求的能力要求就會不斷變高。同時在B端的業務線中，業務決策鏈或者協作重要干係人的差異也很明顯，比如：銷售和客戶就會成為影響我們內部決策的重要影響因素。
然而，在互聯網的產品發展過程中，唯快不破，我們的終端用戶無論是企業還是個人都對於“快速交付”會有著越來越高的訴求。
首先，我們要確定的是：我們交付的是什麼？
作為B端業務產品，一次成功的交付必須以客戶所見為標準，即需求不是隻存在於我們產品經理的構想中，而有可能來源於客戶現場的調研或者是同類競品的分析過程。如果一個需求產出經歷研發上線之後，客戶根本用不起來，那也可以稱其為不是一個成功的交付，這就意味著我們後續還需為此付出較多的迭代成本。
從產品發展的沿革過程來看，我們大致經歷了以下幾個階段：
- 產品起步階段
- 產品發展期
- 大客戶時代
一、產品起步階段
毫無疑問，任何一個產品在起步階段的最重要問題是要搞清楚“我是誰”、“我在哪裡”、“我即將去向哪裡”， 因此我們更多在摸索產品從0到1的建設階段。此時更多的是遵循Workshop的開發模式，按照業務的形態區分，大概會持續3-6個月時間不等，直到我們可以生產出第一個具備完整形態的0.1版本。
在這個過程中遵循以下幾個原則：
- 快：以最快速或者集中開發的形式進行版本交付，甚至不用care一個版本的週期具體時長，可以按照每一個功能點的滾動交付為完成的依據，不停的完善版本功能；
- 準：產品經理除了需要梳理功能點，還需要明確我們最小MVP 版本的完整路徑，梳理產品的roadmap；
- 狠：快速的收集市場或者種子用戶的反饋，分析與競品的差距。
二、產品發展期
什麼是產品發展期？
當產品形態逐漸穩定，需要搶佔市場份額時，會主攻追趕核心功能——我們一般可以將這個階段定義為發展階段。
在這個階段，我們的團隊和產品一般會具備如下幾個特徵：
- 因為要追趕競品的某些核心功能，版本的週期傾向於較短；
- 銷售、售前、服務的團隊配備逐漸健全，信息收斂的速度變慢；
- 團隊的整體意識遭遇B端市場的衝擊加大。
由於團隊規模的不斷壯大，團隊建制不斷完整，各種角色產生信息的速率上升，而信息收斂的速率會下降，尤為典型的就是需求的採集過程。
大家會發現，我們在這個階段的需求來源不斷增多，如：產品經理自生的需求池，銷售反饋的需求池以及服務在售前售後過程中獲取的需求範圍，稍不注意就會信息爆棚。因此產品團隊在此刻需要運用工具化手段管理需求渠道，並且逐漸依賴比較嚴格的需求管理標準，否則即使是需求管理的過程都容易造成瓶頸。
不難發現，“客戶數量上升”是在這個階段非常典型的特徵之一。客戶數量增加了，版本覆蓋需求範圍更廣，而客戶依賴的交付管理也會逐漸呈個性化趨勢。
因為B端產品不同於C端產品，C端產品可以很好的自我控制產品交付的時間和週期，而B端的用戶卻是非常容易提出比較獨立且分散的期望交付時間，然而這也是符合B端市場發展的訴求的。
因為企業不同於個體，雖然我們提供的是SaaS平臺的服務，而對企業而言，它期望獲得的每一個產品收益也是符合它自身發展路徑的，“時間”就會變成我們的不可變量。
當我們意識到這一點時，就需要相應的調整我們自身的版本交付規劃，如：
- 重在響應：產品作為售前資源，充分考量和評估銷售側、服務側的需求；快速響應前向團隊；
- 版本彈性：雖然週期不固定，但基本維持在較短時間範圍內；同時允許某些客戶的需求彈性上線。
這非常符合我在團隊內推崇的“響應力”over “效率”的產品交付模型，而我們也確實在很長一段時間內都享受著這種模型給我們帶來的“福利”。因為看起來，每一個提出特殊要求的客戶無論是申通還是順豐，我們在進行數輪的需求調研和評審之後，都會盡量滿足他們各自的上線時間要求，看起來——似乎一切都很完美，直到我們大客戶時代的真正來臨。
三、大客戶時代
什麼是大客戶時代？
按照我們業務規劃的定義，它可以幫助我們提升客單價，也幫助我們不斷的聚焦於某一些行業或者某幾類客戶。然而，隨著大客戶數量的不斷增多，我們也很快就遭遇了瓶頸，如下圖：
因為我們不斷的允許大客戶需求的臨時插入和臨時上線，所以我們可以將此圖命名為：一條生產線上的崩潰。 當我們的大客戶需求還可以被儘量收斂時，我們認為團隊資源和大家原本已經熟悉的研發模式是可以幫助我們順利度過的。
因此大家一拍腦袋，設計了這樣一個我們原本以為可以稱之為“美好“的新模式：
如上圖，大家天真的以為將每一箇中途進入的大客戶並行排布，就可以以此來拉伸原有主版本的交付週期。
然而事實證明，它們不但不可以完美的並行開發，團隊在研發過程中還會付出遠超出於需求本身的溝通成本和代碼管理的成本，以至於我們在曾經經歷過的一個版本中，會發現缺陷的收斂趨勢變慢、版本後期的風險也幾乎無法收斂，導致我們不得不採取最後的防禦措施來控制版本上線日的風險。
同時，我們在整個迭代週期中，因為響應不同客戶的不停上線也為自己帶來了不可控制的風險，因為每一次線上變更需要花費的風險控制成本趨勢也是在逐漸上升的。
綜上所述，我們在這樣一個為了響應“所有”大客戶而設計的產品研發過程基本可以論述為“瀑布式交付是如何誕生的”。同時，我們的團隊內還帶來了很多的次生災害，因為無法完美的交付給團隊帶來的不自信、團隊的焦慮、以及不同角色間發生衝突的概率也隨之上升。
因此，我們必須要快速的採取行動了，否則將無法控制事態的發展。
如上圖所示，客戶雖然都是重要的， 但不應該將每一個客戶都定義為緊急的，甚至是同等重要的。因為客戶本身的需求極容易對我們的產品過程造成衝擊， 因此客戶的分級也就需要去進行推算，通過一定的客戶等級概念來決定哪一些客戶的需求可以成為緊急的，就如同每一個需求本身都應該對應一個優先級一樣。
另外，我們強行固定版本的交付週期，如現在的3週一迭代，看起來我們可以做的需求規模肯定會比原來的少，但卻可以保障部分客戶的需求可以優先且準時的交付，這對管理客戶預期來說是一個利好的消息。同時也會讓我們的產品和研發團隊的規劃，以及相應的工作更加的有節奏感，明確的知道自己的交付標準和完成度應該是多少。
只有當我們客觀的解決了客戶的問題，以及擺在我們面前現實的痛點後，才可以從本質上去緩解協作團隊間的衝突，因為大家的最終訴求是一致的，即：滿足客戶訴求，提升客戶的滿意度。
作者：夏力雲，網易資深項目經理，PMP，曾在傳統軟件行業具有多年項目管理經驗。
本文由 @網易杭研項目管理（微信公眾號：NetEasePM） 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。