2B創業說 | 需求是商業的核心驅動力,而非其它

• 2019 年 11 月 20 日
• 筆記

從創業以來，一直在思考驅動一個2B公司走向成功的核心要素是什麼？不同的階段、不同的人都有不同答案，有內在因素（人、管理、文化），也有外在因素（客戶、技術、產品）等等。這些點思考下去，沒法形成共性的解釋，不同商業模式的公司對這些內外在因素表達和解釋都有不同。

前不久也看到一篇文章，認為一個2B企業的驅動過程一般遵循以下規律：技術驅動、產品驅動到銷售驅動。看著覺得很有道理，對於一個2B企業來說首先談的是技術，在第一層構建技術壁壘是最好了；技術打造出一個產品，產品沉澱場景，形成產品壁壘；產品出來後，需要通過銷售把它賣到客戶那邊，從而給客戶帶來價值。此時我更想增加一個階段叫需求驅動，需求驅動可以理解成一種高級形式，更應該是一種原點模式，就是那個最初的動力。對於一個創新型企業來說，需求的理解更是成功的關鍵，而創新的引領點是對客戶需求的把握程度。我的思考邏輯非常簡單，誰更貼近用戶，誰更貼近應用端，誰更了解場景，誰的機會就更大。

貼近用戶，是讓你知道誰會使用你的產品和服務，給他帶去的價值是多少？在IT服務方面，你更需要站在用戶的角度去思考他的用戶從你的產品和服務中獲得了什麼，否則IT價值不能體現在業務上。

貼近應用，應用是離用戶最近的IT業務系統，應用又分業務流應用和支撐性應用。無法說哪類型應用的價值更大，要看企業交付服務不同而定。誰讓應用端能夠快速的去支撐用戶的需求，誰的市場機會就會更大，這是把IT系統由成本中心變成價值中心的方式。

貼近場景，對於用戶角色和應用來說，裡面有很多活動進行在其中，我們稱之為場景。概括來說就是：who、what、why、when、where、how的描述，場景是有目標的，場景是有對象的，場景是有角色的，場景是有活動的等等。場景裡面能夠迭代出需求所在。

回到需求的討論上，從需求的表現類型來說，需求分顯性需求和隱性需求，前者是能被客戶直接提出，並加以描述的，這類需求有著明顯的特徵，加以經驗判斷和糾正則很容易模式化提煉出來，有些是通過問題轉換過來的，可以通過調查得出的。我曾經在阿里UC的時候，為了讓九游平台提供專業的IT服務給遊戲廠家，發起一次調查。現在回想起來，我們錯誤的預設了服務內容和前提，並以此內容發起問題調查，給到的結果讓我很意外——運維自動化不是核心需求而日誌分析是核心需求（如下圖）。從後續的優維計劃的三十家面對面客戶訪談得出，客戶的真實需求恰恰不是調查的結論。

沒有一家公司是通過調查做起來，除了那些做調查的公司。

隱性需求是客戶沒法直接提出和描述的，類似客戶的興奮需求，無法通過數據統計總結出來的。隱形需求是一種經驗的迭代優化，呈現模式於過去有根本性不同，比如說ITIL和DevOps，Docker等等，有對客戶已知需求的深刻洞察而迭代新的需求點。

對於一個IT服務行業來說，創業者需要有以下的正確認識：

個體需求和整體需求,拒絕用個體需求代替整體需求，這個在早期很容易陷入的誤區。早期很容易被個體需求所迷惑，無論他選擇的是與不是，此時有效避免該問題的方式就是多接觸客戶。同時我們需要篤定的從行業上判斷當前的現狀和水平是什麼樣的，堅持通往目標的優化之路是未來的方向。有些客戶向你要流程平台，那是不是我要做一個流程平台？當你去做流程平台，你的流程平台和OA、和ITSM流程平台到底有什麼不同？有些客戶說不要監控平台，那是不是真的不需要監控平台？此時我們需要問自己，這麼多年的監控平台真的幫客戶有效的幫客戶快速發現、定位問題了么？真的提升了業務品質了么？

我在早期接觸客戶的過程中，就很難識別出用戶是不是真實用戶？隨著客戶的接觸的不斷積累，最後我自己總結了十個維度來評估客戶是不是我們的潛在客戶/目標客戶/付費客戶等等，從而可以指導銷售可以快速進行決策判斷。

當下需求和趨勢需求，當下需求是階段性需求，是滿足當下的客戶需要，這類需求容易識別和判斷，是否該有產品提供還是服務提供等等，容易做匹配。而趨勢需求是未來的需求，帶著不確定性。這類需求需要豐富的客戶服務經驗，同時還需要團隊不斷的站在未來去思考。

當下處在IT模式的升級窗口期，傳統的IT模式和互聯網化的IT模式DevOps並存，未來相當長的一段時間內，新型IT模式帶來的變革力還是非常強的，畢竟傳統企業的業務也在轉型觸網，最終大家都要變遷的新型的IT模式之上，這是未來之勢。

對於用戶來說，需求是一個提出、引導、滿足和創造的過程。

提出需求，客戶提出自己的需求，這是當下的實際需要，而往往這些需求是七零八落，全面的。我曾經接觸一個客戶提出了一個海量的需求框架，通過自動化把過去N年沒有實現的想法全部放進去了。從作業自動化到告警處理自動化到容災切換到資料庫管理。對於這種需求，需要有清醒的邊界識別能力，拒絕誘惑；然後就是引導需求。

引導需求，提出的需求不一定就是合理的，此時需要對需求進行引導，這個過程是去偽存真和劃分邊界的過程。核心的準則一定是從組織的核心問題出發，核心問題的解決帶來是收益的大幅提升。把需求引導到一個正確的方向和範圍之上，才會讓項目變得更成功。

滿足需求，這是產品和實施服務與客戶需求的對接過程，讓需求落地。

創造需求，不是所有的需求都是客戶提出的，對客戶的現狀有了前面的對接過程之後，此時就需要有一個未來需求的提煉，從而讓未來的需求給客戶帶來更大的業務價值。

如何才能精準的把握用戶真實需求？ 堅持自己的產品和能力邊界，或者說叫定位。任何一個IT服務提供方提供的產品能力有兩種，一種是單角色多場景；另外一種是單場景多角色的覆蓋。

單角色多場景，是滿足一類角色的不同場景的需求，比如說測試人員的功能測試、自動化測試、探索性測試、驗收測試等等。而單場景多角色，是滿足多個角色的相同場景需求，比如說日誌分析需求，開發、測試、運維甚至是安全人員都有相應的日誌分析需求。這兩種策略，我更傾向於前者，一則需求能力很好聚焦，快速迭代優化，避免碎片；其次能力可以很好的形成閉環；第三在商業銷售端，可以減少多客戶角色帶來的溝通成本問題，產品帶來的銷售碎片。

有意思的是，現在很多創業者打了很多雲stack的旗號，從低到上、從前到後完全提供全棧的服務能力（這是一種貪婪策略），想想都知道IT能力的專業化需要很長的時間積累，否則沒法去真正引導客戶需求。這種策略很容易陷入最後的技術化理解，而無法做到真正的產品驅動。下圖是我給的一個標準模型來推導產品的能力如何覆蓋。

能力邊界是我非常堅持的一點，這個會反向影響你的產品脈絡。沒有控制好，很容易讓你的產品變成項目型產品，缺少行業通用性和適配性。在中國，IT型產品很容易被客戶需求牽制住，讓產品失去了強勢性。

尊重客戶的需求和經驗回饋，和客戶認真的溝通，了解他們的需求背後的動機，不要一味的看著自己的產品能力，讓客戶來適應。舉個例子，我們一直講運維自動化和傳統的ITSM是不是就完全不能兼容呢？我說不一定。在互聯網行業來看，越接近應用端，和ITSM的兼容性就越弱，但是到底層就不一定了。其次此時我們不能忽略了傳統行業，傳統行業還有不同的行業劃分，不同的行業對ITSM的要求也不一樣。明顯銀行去掉ITSM那一套變更流程、發布流程根本就不可能。此時要給出融合的方案，在線的自動化方案如何和ITSM做到融為一體，兼顧安全合規和效率的需求，產品上需要做點創新。

這個原則對於產品型公司來說，很難衡量，需要有很強的需求控制力和產品適配能力。

經驗是助力也是桎梏，隱性需求的思考是突破桎梏的關鍵。當下互聯網的經驗的確體現出優勢，但不要讓該經驗凌駕於客戶需求之上，更不能凌駕於產品之上，只因他有好處也有壞處。經驗是你領先於行業階段的時候，此時才是助力，落後於行業階段的時候，就是桎梏。

需求是企業級IT服務公司的制勝力量，你越了解客戶的需求，從項目、產品、銷售多個端都能帶來成功的收益；你越了解客戶的未來需求，你更是擁有了未來持續成功的鑰匙。需求的價值最終就是客戶的價值！