筆者所在的業(yè)務(wù)團隊恰好處于高速發(fā)展的B端業(yè)務(wù)團隊，為了更加“快速”的傳遞價值，無論是產(chǎn)品交付過程還是內(nèi)部的協(xié)作鏈路，都經(jīng)歷過或者正在經(jīng)歷一些典型的“陣痛”，因此借筆者所經(jīng)歷的一些經(jīng)驗和教訓(xùn)在此文中闡述一二。

B端產(chǎn)品與C端產(chǎn)品有著比較大的區(qū)別在于，B端產(chǎn)品的需求容易走向定向渠道，即某一類客戶或者某一個客戶提出來的需求，這對產(chǎn)品經(jīng)理識別需求和過濾需求的能力要求就會不斷變高。同時在B端的業(yè)務(wù)線中，業(yè)務(wù)決策鏈或者協(xié)作重要干系人的差異也很明顯，比如：銷售和客戶就會成為影響我們內(nèi)部決策的重要影響因素。

然而，在互聯(lián)網(wǎng)的產(chǎn)品發(fā)展過程中，唯快不破，我們的終端用戶無論是企業(yè)還是個人都對于“快速交付”會有著越來越高的訴求。

首先，我們要確定的是：我們交付的是什么？

作為B端業(yè)務(wù)產(chǎn)品，一次成功的交付必須以客戶所見為標(biāo)準(zhǔn)，即需求不是只存在于我們產(chǎn)品經(jīng)理的構(gòu)想中，而有可能來源于客戶現(xiàn)場的調(diào)研或者是同類競品的分析過程。如果一個需求產(chǎn)出經(jīng)歷研發(fā)上線之后，客戶根本用不起來，那也可以稱其為不是一個成功的交付，這就意味著我們后續(xù)還需為此付出較多的迭代成本。

從產(chǎn)品發(fā)展的沿革過程來看，我們大致經(jīng)歷了以下幾個階段：

1. 產(chǎn)品起步階段
2. 產(chǎn)品發(fā)展期
3. 大客戶時代

一、產(chǎn)品起步階段

毫無疑問，任何一個產(chǎn)品在起步階段的最重要問題是要搞清楚“我是誰”、“我在哪里”、“我即將去向哪里”， 因此我們更多在摸索產(chǎn)品從0到1的建設(shè)階段。此時更多的是遵循Workshop的開發(fā)模式，按照業(yè)務(wù)的形態(tài)區(qū)分，大概會持續(xù)3-6個月時間不等，直到我們可以生產(chǎn)出第一個具備完整形態(tài)的0.1版本。

在這個過程中遵循以下幾個原則：

• 快：以最快速或者集中開發(fā)的形式進行版本交付，甚至不用care一個版本的周期具體時長，可以按照每一個功能點的滾動交付為完成的依據(jù)，不停的完善版本功能；
• 準(zhǔn)：產(chǎn)品經(jīng)理除了需要梳理功能點，還需要明確我們最小MVP 版本的完整路徑，梳理產(chǎn)品的roadmap；
• 狠：快速的收集市場或者種子用戶的反饋，分析與競品的差距。

二、產(chǎn)品發(fā)展期

什么是產(chǎn)品發(fā)展期？

當(dāng)產(chǎn)品形態(tài)逐漸穩(wěn)定，需要搶占市場份額時，會主攻追趕核心功能——我們一般可以將這個階段定義為發(fā)展階段。

在這個階段，我們的團隊和產(chǎn)品一般會具備如下幾個特征：

1. 因為要追趕競品的某些核心功能，版本的周期傾向于較短；
2. 銷售、售前、服務(wù)的團隊配備逐漸健全，信息收斂的速度變慢；
3. 團隊的整體意識遭遇B端市場的沖擊加大。

由于團隊規(guī)模的不斷壯大，團隊建制不斷完整，各種角色產(chǎn)生信息的速率上升，而信息收斂的速率會下降，尤為典型的就是需求的采集過程。

大家會發(fā)現(xiàn)，我們在這個階段的需求來源不斷增多，如：產(chǎn)品經(jīng)理自生的需求池，銷售反饋的需求池以及服務(wù)在售前售后過程中獲取的需求范圍，稍不注意就會信息爆棚。因此產(chǎn)品團隊在此刻需要運用工具化手段管理需求渠道，并且逐漸依賴比較嚴(yán)格的需求管理標(biāo)準(zhǔn)，否則即使是需求管理的過程都容易造成瓶頸。

不難發(fā)現(xiàn)，“客戶數(shù)量上升”是在這個階段非常典型的特征之一?？蛻魯?shù)量增加了，版本覆蓋需求范圍更廣，而客戶依賴的交付管理也會逐漸呈個性化趨勢。

因為B端產(chǎn)品不同于C端產(chǎn)品，C端產(chǎn)品可以很好的自我控制產(chǎn)品交付的時間和周期，而B端的用戶卻是非常容易提出比較獨立且分散的期望交付時間，然而這也是符合B端市場發(fā)展的訴求的。

因為企業(yè)不同于個體，雖然我們提供的是SaaS平臺的服務(wù)，而對企業(yè)而言，它期望獲得的每一個產(chǎn)品收益也是符合它自身發(fā)展路徑的，“時間”就會變成我們的不可變量。

當(dāng)我們意識到這一點時，就需要相應(yīng)的調(diào)整我們自身的版本交付規(guī)劃，如：

1. 重在響應(yīng)：產(chǎn)品作為售前資源，充分考量和評估銷售側(cè)、服務(wù)側(cè)的需求；快速響應(yīng)前向團隊；
2. 版本彈性：雖然周期不固定，但基本維持在較短時間范圍內(nèi)；同時允許某些客戶的需求彈性上線。

這非常符合我在團隊內(nèi)推崇的“響應(yīng)力”over “效率”的產(chǎn)品交付模型，而我們也確實在很長一段時間內(nèi)都享受著這種模型給我們帶來的“福利”。因為看起來，每一個提出特殊要求的客戶無論是申通還是順豐，我們在進行數(shù)輪的需求調(diào)研和評審之后，都會盡量滿足他們各自的上線時間要求，看起來——似乎一切都很完美，直到我們大客戶時代的真正來臨。

三、大客戶時代

什么是大客戶時代？

按照我們業(yè)務(wù)規(guī)劃的定義，它可以幫助我們提升客單價，也幫助我們不斷的聚焦于某一些行業(yè)或者某幾類客戶。然而，隨著大客戶數(shù)量的不斷增多，我們也很快就遭遇了瓶頸，如下圖：

因為我們不斷的允許大客戶需求的臨時插入和臨時上線，所以我們可以將此圖命名為：一條生產(chǎn)線上的崩潰。 當(dāng)我們的大客戶需求還可以被盡量收斂時，我們認(rèn)為團隊資源和大家原本已經(jīng)熟悉的研發(fā)模式是可以幫助我們順利度過的。

因此大家一拍腦袋，設(shè)計了這樣一個我們原本以為可以稱之為“美好“的新模式：

如上圖，大家天真的以為將每一個中途進入的大客戶并行排布，就可以以此來拉伸原有主版本的交付周期。

然而事實證明，它們不但不可以完美的并行開發(fā)，團隊在研發(fā)過程中還會付出遠超出于需求本身的溝通成本和代碼管理的成本，以至于我們在曾經(jīng)經(jīng)歷過的一個版本中，會發(fā)現(xiàn)缺陷的收斂趨勢變慢、版本后期的風(fēng)險也幾乎無法收斂，導(dǎo)致我們不得不采取最后的防御措施來控制版本上線日的風(fēng)險。

同時，我們在整個迭代周期中，因為響應(yīng)不同客戶的不停上線也為自己帶來了不可控制的風(fēng)險，因為每一次線上變更需要花費的風(fēng)險控制成本趨勢也是在逐漸上升的。

綜上所述，我們在這樣一個為了響應(yīng)“所有”大客戶而設(shè)計的產(chǎn)品研發(fā)過程基本可以論述為“瀑布式交付是如何誕生的”。同時，我們的團隊內(nèi)還帶來了很多的次生災(zāi)害，因為無法完美的交付給團隊帶來的不自信、團隊的焦慮、以及不同角色間發(fā)生沖突的概率也隨之上升。

因此，我們必須要快速的采取行動了，否則將無法控制事態(tài)的發(fā)展。

如上圖所示，客戶雖然都是重要的， 但不應(yīng)該將每一個客戶都定義為緊急的，甚至是同等重要的。因為客戶本身的需求極容易對我們的產(chǎn)品過程造成沖擊， 因此客戶的分級也就需要去進行推算，通過一定的客戶等級概念來決定哪一些客戶的需求可以成為緊急的，就如同每一個需求本身都應(yīng)該對應(yīng)一個優(yōu)先級一樣。

另外，我們強行固定版本的交付周期，如現(xiàn)在的3周一迭代，看起來我們可以做的需求規(guī)?？隙〞仍瓉淼纳?，但卻可以保障部分客戶的需求可以優(yōu)先且準(zhǔn)時的交付，這對管理客戶預(yù)期來說是一個利好的消息。同時也會讓我們的產(chǎn)品和研發(fā)團隊的規(guī)劃，以及相應(yīng)的工作更加的有節(jié)奏感，明確的知道自己的交付標(biāo)準(zhǔn)和完成度應(yīng)該是多少。

只有當(dāng)我們客觀的解決了客戶的問題，以及擺在我們面前現(xiàn)實的痛點后，才可以從本質(zhì)上去緩解協(xié)作團隊間的沖突，因為大家的最終訴求是一致的，即：滿足客戶訴求，提升客戶的滿意度。

作者：夏力云，網(wǎng)易資深項目經(jīng)理，PMP，曾在傳統(tǒng)軟件行業(yè)具有多年項目管理經(jīng)驗。

本文由 @網(wǎng)易杭研項目管理（微信公眾號：NetEasePM） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。