讓傳統行業研發團隊插上用戶思惟的翅膀

 

 共計 5469 字｜建議閱讀時間 15 分鐘

 

本文是top100 summit 2016主題演講的整理文稿，演講主體分三部份內容：

1. 2015年羅輯思惟跨年演講說的「互聯網恐慌」，其根本緣由是什麼？

2. 什麼是傳統行業的最大痛點？

3. 經過三個實際案例來說述傳統的研發團隊如何理解並得到用戶思惟。

 

 

01「互聯網恐慌」的根本緣由

 

互聯網企業現在吸引了大量的資源和目光，讓傳統行業的企業顯得無所適從，感受如今已經徹底是互聯網企業的天下，傳統行業已經日薄西山，正在「混吃等死」了。

 

但其實咱們來看一組2015年的數據：

 

• 華爲營收3950億，超過BAT總和

• 騰訊利潤288 億

• 中國菸草總公司利潤1700 多個億

• 中國工商銀行利潤2700 多個億

• 中國移動利潤1000 多個億

 

不管營收和利潤，BAT都不是最好的，甚至相差甚遠，但爲何還會處處瀰漫着濃濃的「互聯網恐慌」呢，羅胖在他的跨年演講上給了一個特別形象的比喻叫「你等着」，就是中學上課的時候，忽然有我的告訴你說「你給我等着，下課後我要揍你！」，你會是個什麼心情，確定這節課都會充滿焦慮，沒法專心聽講了。而互聯網企業就是那個叫囂「你等着」的人，其根本的緣由在於：互聯網企業更懂用戶，並且是愈來愈懂用戶，這幾乎是一種不可逆轉的趨勢。

 

馬雲曾經說過阿里巴巴最值錢的是數據，想一想看咱們的吃喝拉撒他們都清清楚楚，早上出門坐的哪輛車去的機場，坐的哪一個航班去到哪一個城市，下榻的是哪一個酒店，在酒店旁的小餐館吃了什麼，買了什麼，這些數據都老老實實躺在支付寶的數據庫中。現金消費的場景將會愈來愈少，他們的數據也就會愈來愈完整，這是互聯網企業真正可怕之處。

 

這就引出了傳統行業企業的最大痛點：離用戶太遠了。

 

 

02 傳統行業最大的痛點

 

由於傳統行業企業離用戶太遠，致使難以瞭解用戶的真正訴求，相較互聯網企業就是愈來愈不懂用戶了。對於仍舊財大氣粗的傳統企業來講，彷佛直接從BAT挖人，而後照搬互聯網的模式是解決這個痛點的最快捷之道。

 

但有太多的案例證實徹底照搬是行不通的，由於傳統行業企業和互聯網企業存在着基因的不一樣。

 

首先，互聯網企業用戶和客戶相同，或者說互聯網企業是先經過得到足夠的用戶，而後才能吸引來或者直接將用戶轉化成客戶，也就是說對互聯網企業而言用戶是入口。而對於傳統行業的企業來講用戶和客戶並不相同，要先找到客戶以後，才能清楚使用產品的用戶到底是誰，也就是說對傳統行業企業而言客戶是入口。

 

其次，互聯網企業需求是內生的，本身主導需求，而傳統行業企業的需求少許內生，好比優化類需求，而絕大部分需求來自於客戶。第三，互聯網企業的產品自主運營，好比微信必定是騰訊本身在運營，由於直面用戶，運營數據屬於本身，而傳統行業企業的產品通常是客戶來運營，想要得到用戶數據很是困難，這就形成了離用戶比較遠。最後，互聯網企業質量容忍度相對較高，試錯成本小，而傳統行業企業質量容忍度相對低，特別是對於電信級軟件，好比核心網，一旦出現問題，影響的可能就是一個城市的通話質量，犯錯成本很是大。

 

這些不一樣，本質上決定了雖然明知道這個痛點很痛，也不能照搬互聯網的開發模式。

 

 

03 案例一 動用一切手段拉近和用戶的距離

 

不是離得遠麼，那就想辦法拉近。

 

項目背景：從傳統嵌入式開發項目，跨入到行業應用軟件開發項目。

 

產品迭代現狀

這個是公司當時正在執行的產品迭代模型示意圖，產品經理會先蒐集一個超級大的需求包，大概十幾甚至幾十萬行代碼量級的需求，直接按照「交接棒」的方式扔給研發團隊。研發團隊吭哧吭哧作完以後，發現一年已通過去了。

 

從X2里程碑點一直到X5里程碑點，時間跨度很是長，半年到1年的時間，整個過程嚴格控制產品質量，不得外發，也形成了這一至關長的時間內沒有任何用戶參與。研發工程師更是長期見不到用戶一次。

 

這種質量至上的模式，主要造成於公網電信業務，面向的客戶是電信運行商，一旦業務出現問題，成本很是大。另外，需求比較固定，客戶也不可能給咱們快速試錯的機會。可是對於面向企業的專網項目，甚至是行業應用類項目，用戶的反饋及現場真實環境測試的重要性愈來愈重要。

 

咱們意識到必須作出改變。

 

典型互聯網產品迭代模式：

互聯網模式相較而言，除了時間維度，多了一個用戶的維度。全部的活動開展均是圍繞用戶展開。

 

發產品時先作出一個簡單的原型——MVP（最小化可行產品）而後經過測試並收集用戶的反饋，快速迭代，不斷修正產品，最終適應市場的需求。這也是精益創業的核心理念。

 

調整，拉近與客戶的距離

經過借鑑互聯網迭代模式的思想，在X2到X5階段，增長了「給明白人演示」、「創建展廳給客戶演示」、「迭代演示」、「創建友好客戶」、「補丁發佈流程」、「灰度發佈」等環節。這些環節使得產品的亮點功能不斷產生，推出後在行業裏得到了極大的口碑，成爲了競相效仿的對象。

 

另外在創建了友好客戶以後，經過灰度發佈除了能儘早得到用戶需求反饋以外，對於實驗室環境覆蓋不到的特性，還能提早進行真實場景下的測試，提前發現實驗室環境發現不了的問題。

 

除了增長上面的環節以外，在執行過程了，還發現了以下問題：

• 需求提出方PLM彷佛不太關心咱們的產品究竟作成了什麼樣；

• 咱們一直在服務客戶，真正在使用咱們產品的那羣人，彷佛沒有獲得咱們的重視；

• 作了一堆功能，咱們並不清楚，哪些功能用戶真正使用。

   

針對以上問題，咱們採起了以下行動：

• 從新梳理外發流程，灰度發佈涵蓋版本早期階段；

• 流程中增長用戶訪談環節；

• PLM/SE/開發表明/版本經理都要把本身當用戶真實使用產品，人人都是產品經理；

• 版本自帶用戶行爲分析功能。

 

敏捷邊界

咱們一個項目完整的流程是先從客戶那收集需求，而後啓動項目論證，論證經過後立項，需求分析，方案設計，開發實現、測試驗收，達到GA（General Availability）點意味着產品能夠批量交付給客戶，而後產品上線，客戶運營。

 

不少企業都推行了敏捷模式，可是咱們能夠對照一下本身團隊執行的敏捷的邊界究竟在哪。

 

項目級敏捷，基本上只有開發人員在敏捷，執行着迭代和自動化系統集成的工做，通常自動化也不太完全。往外擴展就是版本級敏捷，把設計人員以及測試人員歸入進來一塊兒進行敏捷，可是這兩種敏捷都有一個問題是敏捷的邊界沒有達到GA態，也就是說迭代出口或者說是敏捷的出口產品是沒辦法直接交付的。再往外擴展就是產品級別敏捷，把需求分析人員涵蓋到敏捷團隊中，其對應着持續交付，也就是產品通過了產品級敏捷以後會到達GA態，是能夠批量交付的。可是以上三種敏捷形態的邊界都沒有把客戶涵蓋進來，而商業級敏捷就是要聯合客戶一塊兒敏捷，其對應的邊界就是隻要客戶一個idea，通過了商業級敏捷以後這個idea就能直接變成功能上線了，這個和目前互聯網的模式就很是接近了。

 

經過敏捷邊界的劃分很明顯的看到，工程師文化爲何容易誕生在互聯網公司，而傳統型的公司幾乎沒有，就是傳統行業企業的敏捷邊界大多數還停留在項目級敏捷的階段，研發人員離客戶和用戶很是遙遠，少有話語權，天然難以造成工程師文化。

 

但這至少給咱們研發團隊指明瞭一條通往離用戶愈來愈近的路，就是敏捷邊界外擴。

 

精細化用戶思惟

隨着大數據處理技術的發展，用戶思惟已經不只僅是簡單的跟用戶聊聊天就能夠了，逐漸產生了精細化的用戶思惟，比用戶更瞭解用戶，直達用戶心裏。如下幾個案例能夠幫忙理解什麼是精細化的用戶思惟：

 

• 今日頭條經過分析用戶點擊及閱讀時長，不斷推薦用戶感興趣的內容給用戶；

• 沃爾瑪在顧客結帳的時候，若是發現顧客的商品裏含有紙尿褲，那麼就會隨機自動打印出一張奶粉的優惠券給顧客；

• 大型超市裏邊的水，其實都不貴，甚至虧本，由於水是價格敏感的商品，顧客若是發現水的價格偏高，就會認爲整個超市的商品價格偏高；

• 電商平臺顧客買了商品，下面會有「猜你喜歡」的商品推薦，高達30%的商品是經過這個推薦功能賣出去的。

   

技術手段在將來的管理中將會扮演愈來愈重要的做用，利用技術手段更好的服務用戶將是趨勢。

 

用戶思惟的邊界

以上種種彷佛在說明只要用戶提的需求就必須知足，作產品以前只要作一下市場調研就能夠了，其實否則。

 

首先市場調研存在樣本範圍是否足夠大是否能表明多數人的問題，即便調研樣本足夠大，可是用戶反饋的和本身心裏真正想的是否一致也是個問題，此次的美國大選就是一個典型的例子。

 

福特曾經說過，若是要去馬路上問你們須要個什麼東西，你們必定會說須要一個更快的馬，而不是汽車。因此用戶思惟自己也存在着邊界，特別是對於跨越式的創新產品，每每更依賴技術洞見，而非市場調研。

 

案例小結

案例一講的內容比較多，核心內容就是拉近研發和用戶的距離，首先就是開發模式中須要增長用戶維度，雖然傳統行業客戶是入口，可是用戶纔是留存及得到下一個入口的手段，對於打磨產品相當重要。其次敏捷邊界外擴，聯合客戶一塊兒敏捷。第三，用戶思惟已經發展到很是精細化的程度，再也不僅僅侷限於作用戶訪談，經過各類技術手段幫助咱們比用戶本身更瞭解他們。最後，用戶思惟自己也存在着邊界，市場調查並不老是可靠的，咱們要識別出邊界和坑在哪裏。

 

 

04 案例二 把本身當作第一個用戶，取悅本身

 

你最快能找到的第一個用戶是你本身。咱們常犯一個錯誤，就是一邊在抱怨離用戶太遠，一邊卻連本身這個用戶都沒有利用好，作出來的東西連本身都不滿意。

 

關於取悅本身，咱們應該都有過這樣的經歷體驗，曾由於本身寫過的一篇文章、畫過的一張畫、設計過的一個方案、寫過的一段代碼而以爲身心愉悅。取悅本身首先關乎思惟方式的轉換，從告知思惟轉變爲打動思惟。告知思惟就是作完了一個功能，只是告訴本身或者告訴其餘人我作完了，我有了這個功能，而打動思惟則是作的這個功能是否可以的打動本身，只有打動了本身才有可能打動你們。

 

古斯塔夫·勒龐在其著名的心理學著做《烏合之衆：大衆心理研究》一書中闡述：「羣體的理解能力差，但行動能力強」。因此針對這一理論，對於團隊或者羣體的行動可使用適合的流程引導、約束，使得產出最大化，但對於理解、創造、靈感類工做，須要鼓勵我的行爲。好比：流程能保障版本質量符合迭代出口要求，可是沒法預測有人能在轉測時就作到了「零缺陷」。這是一種遠超團隊標準，沒法用廣泛質量曲線描繪的結果。

          

取悅本身的行爲屬於個體行爲，甚至每每是靈光突顯。創意和想法是寶貴的財富，咱們對於取悅本身的行爲必定要給予及時鼓勵，創意一旦被發現，加以必要規範化後引導到團隊，發揮羣體的行動力，回報最大化。

 

在咱們項目過程當中，就有一個典型的發現個體的取悅本身行爲，鼓勵並推廣到團隊的案例：

 

• 取悅本身行爲：在項目開發過程當中，有一個系統須要大量的採用報表系統，團隊成員比較新，你們各自寫各自模塊的報表前端展現，開發人員小張，開始在任務之餘提取出了一套很是實用的前端公共組件，本身使用事後我的感受特別好，上報給主管。

        

• 及時獎勵：主管意識到這個是一個很是好的創意，當即給小張申請了公司的」及時獎勵「，並取消了他下個迭代的story任務，專心完善這項工做。

          

• 回報最大化：團隊進行全體重構，提取出8大前端公共組件，節省代碼量700 * 38 LOC。

          

經過這套方法，咱們還在項目實踐過程當中針對具體問題，不一樣場景，嘗試了多種優秀敏捷實踐活動「L型團隊的打造」、「看板迭代」、「日報引入今日心情」、「交叉迭代」、「技術回顧會」，取得了很是好的效果。

          

咱們很容易發現，一個偉大的產品，好像都有一個不斷取悅本身的產品經理。好比喬布斯之於蘋果，張小龍之於微信。他們都在作本身產品的第一個用戶，他們的產品首先要取悅本身。他們堅持着本身產品的理念，蘋果的突破、極致體驗，微信的剋制、不打擾。因此一個高度取悅本身的行爲，若是跟公司的當前流程不符，建議首先須要質疑的是公司的流程制度，而不是一開始就一味迎合。

 

案例小結

最快能找到的第一個用戶是你本身，因此首先要打動本身，而且要善於發現團隊中取悅本身的行爲，引導到團隊實現創意價值最大化，另外任何偉大的產品必定是取悅本身的。      

 

 

05 案例三 平臺靠創造用戶價值演化而來

 

在引出第三個案例以前，咱們先來看下週鴻禕在他的《個人互聯網方法論》一書中提到的一段話：「互聯網裏的平臺都不是作出來的，都是積累起來的，是在爲用戶服務的過程當中造成的，最開始都是從一個點作起」。

 

我理解成平臺不多是一開始就設計好的，甚至都不能說是優化來的，由於優化每每仍然是從本身的角度出發，平臺必須具有演化的能力，順着創造用戶價值的枝幹不斷進化得來。

 

項目背景：光伏行業第一個業務版本尾聲，開始投入專一平臺打造，以圖複製20個行業。

 

這是一次對商業級敏捷的探索，首先完成從無到有的孵化，在一個行業找到一個客戶，咱們跟客戶一塊兒作業務，從客戶的角度一塊兒想問題，從需求，設計，開發，測試，交付各個環節甚至團隊招聘都是一塊兒完成的，和客戶造成緊密的利益共同體。第二步完成從1到N的複製，複製到不一樣的行業，進一步完成API,SDK。最後造成生態，組成合做夥伴聯盟，創建和合做夥伴的營銷，分紅機制。

 

案例小結

即便是作平臺一樣須要用戶思惟，幫助客戶創造用戶價值纔是平臺真正的價值。另外平臺源於演化，而非一開始的設計，熟悉技術的都知道平臺自己就分爲兩種形態，一種是用戶量巨大須要考慮併發量的，另外一種用戶量很小可是業務吞吐量巨大的。最後就是聯合客戶一塊兒敏捷和客戶組成利益共同體。

 

文章最後，引用一句喬布斯的話「我對作過的事情感到自豪，但我對決定不作的事情一樣感到自豪。」

 

互聯網行業如今經過MVP、精益等手段對這句話已經踐行的挺好了，可是傳統行業屬於重災區，合同是按照功能清單簽定的，每每在簽定合同時功能越多越好，根本不會關心功能越多，質量會存在風險，可能沒法聚焦真正的價值功能等等問題。有一個技巧就是研發團隊在接產品經理的需求的時候，須要產品經理把哪些功能是客戶願意花錢買的，哪些功能是本身吹牛吹出來的附贈品劃分出來，研發聚焦那些客戶願意花錢買的功能，作出一個模型以後，給客戶看一下，再來看接下來是否還須要作那些看起來其實不過重要的功能。