不懂業務創新的工程師,不是好的架構師 | 深度
導讀:對於高階的工程師來說,光有持續交付價值的能力還不夠,我們必須保證交付的東西是有用的,能帶來真正的價值。持續交付和業務創新是相互關聯,相輔相成的。持續交付是業務創新的基礎,而持續交付的收益最後要落實到業務創新中去。
如何在深刻了解業務的基礎上,完成有效的業務創新?下面為你送上由阿里資深技術專家何勉老師帶來的精彩分享。
有效的業務創新離不開持續交付能力的支援。持續交付能力讓我們可以更快地獲取反饋,它是網際網路時代創新的基礎。網際網路時代的創新究竟有什麼不同呢?我們看下面這幅圖。
第一幅是部分共享單車App的圖示,其中相當部分在過去一年已經退出了競爭;第二幅是部分直播App的圖示,業界流行所謂“百團千播”一說,“百團”說的是當年的團購大戰,“千播”說的直播競爭的盛況空前,如今直播風潮還未過去,小影片的戰火又已經燃起。
移動網際網路時代,創業和產品開發的成本大幅降低,觸達使用者的渠道也更加直接,使用者的選擇急劇增加,選擇權迅速從生產者轉移到了消費者一側了。交付的東西,使用者不會選擇或者根本不在乎,成為創新過程中最大的浪費。
除此之外,我們還不得不面對加速變化的世界,業界稱其為烏卡(VUCA)時代。烏卡最早用來形容冷戰後的國際政治環境,它由Volatility(易變性),Uncertainty(不確定性),Complexity(複雜性),Ambiguity(模糊性)四個單詞的首字母構成。今天烏卡被更多用來形容技術和商業環境,而這也是產品交付和創新所必須面對的環境。
環境加速變化和選擇權向使用者側轉移,這兩個趨勢對產品的創新和交付模式,提出了全新的挑戰。我們需要更有效的產品創新模式。
以持續交付為基礎,我們有機會也必須引入系統創新方法。這就是我們後面要講的從持續交付到產品創新。
有效的創新從明確目標開始。目標從哪裡來?它源自使命和願景,源自使命和願景在空間和時間上的分解。所謂空間分解是指分解和分析達成目標的各個要素,以及各個要素之間的關係。而時間分解指如何按步驟的去構建這些要素,實現這個最終的目標。
先看一個空間分解。為此,要先介紹一個概念叫飛輪效應。飛輪的概念最早是在《從優秀到卓越》這本書提出來的,作者柯林斯透過研究那些基業長青的企業發現,在它們背後往往都存在一個飛輪——也就是業務的正向加強迴圈。如果去仔細分析,這個飛輪也存在於所有快速發展的網際網路業務中。
以亞馬遜為例,貝佐斯在97年上市招股書裡面就明確提出並描述了亞馬遜的飛輪。我們要為使用者提供足夠多的選擇,選擇多使用者體驗就好,體驗好使用者流量就會多,流量多,就會吸引更多賣家加入,從而提供更多使用者選擇,實現更好的體驗,形成正向反饋,不斷加強實現增長。這個飛輪還有另一個分支,業務規模的增長帶來更好的成本結構,這樣價格就會更低,這也會促進客戶體驗變好,這個迴圈也是飛輪的一部分。
飛輪效應看上去很美,然而它的困難之處在於如何啟動和維持它。為了使靜止的飛輪轉動起來,一開始你必須使很大的力氣,一圈一圈反覆地推,每轉一圈都很費力,但是每一圈的努力都不會白費,飛輪會轉動得越來越快。當達到一個很高的速度後飛輪所具有的動量和動能就會很大,使其短時間內停下來所需的外力便會很大,便能夠克服較大的阻力維持原有運動。
飛輪的另一個難點在於,它環環相扣,一個環節脫節它就轉不起來,比如在亞馬遜的例子中,如果使用者的核心體驗並不是選擇多,他們不會因為選擇多就來到網站,那我們就必須重新挖掘使用者的訴求或問題。正因為如此,我們才必須知道飛輪背後的邏輯是什麼,有哪些假設。驗證這些假設,構建合理的商業閉環,飛輪才能真正運轉起來。
我們可以從很多成功的業務中看到這樣的飛輪。淘寶、盒馬、抖音、微信背後我們都能看到他們的飛輪。飛輪是實現規模化的產品的必備選項,否則以今天競爭環境之殘酷,別人的產品有飛輪,而你沒能成功構建的話,那你就很難競爭了。
讓我們虛擬一個場景,假設我們要做一個短影片應用,類似抖音,看看我們最初設想的飛輪是什麼樣的呢? 以下只是理論上的推演,現實中的情況一定要複雜很多。
更好的觀看體驗帶來更多使用者使用,更多的使用者使用就帶來更多的內容創造,更多的內容創造就帶來更多的優質內容,更多的優質內容又帶來更好的體驗,形成加強迴路。這是飛輪的核心,問題是從哪裡開始旋轉飛輪呢?這成了先有雞還是先有蛋的千古難題。
我們先完善一下飛輪的構成要素,再來分析。更好的體驗,還可能產生更多的分享,而分享帶來新的使用者。增長帶來更多收入可能,收入多的話就會帶來更多KOL(達人),KOL帶來更多優質內容,並且一些素人也會成長為KOL。飛輪更完善了,但雞和蛋的問題依然沒有解決。比如在你能夠帶來可觀收入之前,KOL憑什麼來?KOL不來又如何實現增長和帶來收入?
為了飛輪轉起來,我們必須找到初始的轉動把手。比如,對於更多優質內容,我們可以先去梳理現有的內容供給,保障初期的供給。或者挖掘OGC周邊內容,保障持續的精品內容的供給,這些行為在飛輪的周邊,沒有先有雞還是先有蛋的問題,是我們可以著力的地方。因此我們稱之為把手。
圖上,我們分析了啟動和持續驅動飛輪的把手。比如,初始的KOL怎麼來?你可能需要內容補貼,或者是站外拉取等等。比如,如何構建更好的初始觀看體驗要素?比如,如何讓使用者貢獻內容創造?等等。
除此以外,還有非常重要的一點,就是在增長中如何建立合適的調性。這也是讓飛輪可以相對長期運轉必須考慮的。快手和抖音的調性就不同,也決定了其後的擴張路徑和難度的不同。並不是孰優孰劣,重要的是,這對你後面的增長策略影響很大,需在業務發展過程中給與關注。
基於業務目標,我們構建了增長飛輪,並分解了驅動飛輪運轉的把手。這是對願景和使命在空間上的分解,它給出了從哪裡著力去構建產品和業務模式的初始方向。
有了空間的分解,從理論上,我們有了轉動增長飛輪的著力點。但我們還必須面對一個問題——具體從哪個地方開始。這就是我們接下來要講的從時間上分解。先關注什麼,後關注什麼?這是一個路徑問題,錯誤的路徑是產品創新過程中經常會犯的錯誤。
關於產品創新的路徑問題,我們要介紹一下關隘模型。它認為做創業或者做一個新產品、新的業務需要經過各個階段,每個階段是上一階段的前置條件,因此稱之為關隘模型——過了上一關才能進入下一關。
關隘模型的第一步是共情——發現一個未被滿足的需求,有足夠強的理由引發使用者的興趣,這是產品存在的理由;接下來是粘性——解決方案要能夠讓使用者願意持續使用;然後是病毒——使用者願意告訴或拉來他們的朋友一起使用;再然後是收入——你得有支援持續運營和增長的收入來源;最後才是規模化。
關隘模型的核心是“關隘”——過了上一關才能進入下一關。比如沒有共情就不可能有粘性;沒有粘性你也無法讓產生口碑和病毒,即使透過激勵的手段又不持久,而且病毒帶來的使用者也會流失。
為什麼要介紹關隘模型呢,因為它看上去很簡單、合理,但現實中,我們還是會一再犯錯。特別是在產生粘性之前,就去規模化擴張。這是最常見的錯誤,這和人類急功近利本性以及KPI的影響都有關係。
關隘模型,為願景和使命在時間上的分解提供了概念上的指導。
回到增長飛輪,我們如何判斷從哪裡開始,找到著力點呢?基本的判斷是,從使用者體驗開始,它與使用者的共情和粘性直接相關。
還是以亞馬遜的飛輪為例,粘性來自於什麼?當然是使用者的體驗,所以從使用者體驗出發,是啟動飛輪運轉的關鍵。在亞馬遜的案例中,使用者的體驗的核心是價格和選擇。但做到這一點並不容易,如果亞馬遜一開始就做全品類,那需要花很長時間也不會構建起基本的使用者體驗,亞馬遜也不可能堅持到今天。
理解了這一點,我們就能理解亞馬遜為什麼要從圖書做起,因為在那個時刻,圖書是最有可能和快速建立起選擇和價格這兩大體驗的。亞馬遜最初的LOGO上也寫著,全球最大的書店就是這個道理。圖書是亞馬遜其後20年品類擴張的起始。
我們說以體驗為核心,但對體驗是什麼一定要有自己的理解。體驗絕不僅僅是網站或 App 的互動好這麼簡單,它體現為特定場景下,使用者核心訴求被滿足的程度。
比如盒馬,它最初定位解決的是25歲以上都市白領買菜的問題,那它的核心體驗就是:1)所想所得,你一想到馬上就能夠送到,半小時送達;2)一站式購齊,比如說買韭菜炒香乾,有韭菜,沒有香乾,就不是好的體驗;3)足夠新鮮和方便,這是它的核心體驗。
比如說百度做MP3的時候,俞軍面試產品經理,有一道題目是如何才能做好百度 MP3 產品。其他人洋洋灑灑寫了幾頁紙,而李明遠就寫了兩句話,六個字——搜得到,能下載。這就是抓住了核心體驗。
小影片的核心體驗又是什麼呢?我看到的是:持續供給的優質內容,並且能精準的分發。做到這兩點並不容易。這是我們一開始應該聚焦的地方。可能還應該更聚焦,如針對一小部分初始核心人群的優質內容和精準分發。
不同的人對核心體驗會有不同的理解, ,你可能也有自己的理解,比如覺得使用者的參與和自我展現才是最核心的訴求,這都可以,關鍵是你必須對核心體驗有一個明確且聚焦的定位,還必須能夠差異化和聚焦,這只是舉個例子,肯定不容易,特別是一個追趕型的產品。
這就是我們所說的時間上的分解。你必須在一開始聚焦核心的點,這個核心的點往往是體驗,不同產品體驗是不同的,圍繞體驗要做的事情也並不少,團隊應該儘量聚焦,比如抓住核心體驗和核心人群。盒馬就是一個很好的例子,儘管夢想很大,但一開始他們牢牢抓住了都市白領一日三餐這個核心場景,做深做透,滿足使用者的核心訴求,打造自己的核心能力。
這是時間的分解的例子,它的核心是必須聚焦,正確的時間做正確的事,一步一個腳印,才能更堅實的進入下面的步驟。還是以盒馬為例,解決好三口之家買菜的問題。為盒馬建立了兩個基礎:1)對使用者而言是心智——盒馬是一個身邊的可靠服務;2)對內部而言是能力——供應鏈能力,管理能力等等。這時我們進入下面的階段,才更可靠。不管是口碑的建立——如:本地社群的運營;還是服務型別的擴張——如:24小時應急服務,3公里的生活服務圈等;還是規模和渠道的擴張。
以上,我們分享了對目標和願景在空間和時間的分解。它們是產品創新過程的出發點。對於空間的分解我們講了,如何構建增長飛輪,以及找到飛輪的把手。它是對業務增長的基本邏輯的假設,而業務成功是建立在這些假設的基礎上的,因此我們必須在產品交付和創新過程中不斷的驗證調整,打造有效運作的業務閉環;對於時間的分解,我們介紹了關隘模型,以及從使用者體驗開始,找到著力點,開始最早的業務閉環的打造和探索。
對目標和願景在時間和空間上的分解,我們構建了業務大圖,它指導我們在什麼時刻關注什麼目標。接下來,我們還要對目標進行量化,量化的目標和度量讓我們更能夠知道我們是否在向著正確的方向前進。
怎麼去量化呢?這就要回到具體的產品,去看產品的指標。為此,我們需要構建產品的大圖,從產品的大圖上,發現和定義正確的指標。
滿足使用者的訴求是產品的核心,從使用者使用路徑出發來構建產品大圖是有效方法。還是看假想的小影片例子,圖中每一個框是使用者的一個行為節點,其中深藍色的框是內容生產的節點,淺藍色的是內容消費的節點,綠色的是我們最期望產生的使用者行為——在這裡是內容的釋出和觀看以及關係的沉澱。
看一下最核心的行為路徑。最上方是使用者從哪裡來。使用者進入後,可能會直接生產內容——如拍攝上傳,更可能從消費內容開始。內容消費過程中會產生互動,如:評論、關注等,也有可能被引導向話題參與或者是內容創作。對於內容創作也存在一系列路徑,包括進入、選素材、拍攝、編輯、釋出等,其中任何一步使用者都可能退出。不管是內容消費還是釋出,我們都希望使用者能夠積極的分享,分享帶來新的使用者流量。最左邊是站外的內容供給。
使用者路徑圖的核心是使用者,也就是產品滿足使用者並引導使用者行為的過程。產品的成功,很大程度上取決於使用者行為的轉化,我們的服務是否滿足了使用者,並且讓使用者產生了期望的行為。比如,各個環節的轉化率、活躍率和留存率等。
我們稱使用者路徑圖為產品大圖,基於產品大圖我們設計和審視更合理的產品路徑,定義核心的產品指標。圖中,紅色和灰色的文字是其中一些產品指標,其中紅色是當前時刻重點關注的指標,它們大部分與使用者的核心體驗和粘性相關,如使用者人均VV(video view播放影片)數、次日留存,影片的播放完成率等。
基於業務大圖,我們確定了特定時刻的主要目標。基於產品大圖,我們可以進一步確定相關的指標。定量目標回答的是 Why 的問題,接下來我們要探索用什麼抓手 (How) 實現目標,以及透過什麼樣的產品功能或運營活動 (what)。從Why 到 How 再到 What 這是定義產品功能的路徑。
比如提高某個活動的使用者參與率是我們的目標,是 Why。那如何才能實現這一目標呢?我們必須找到適當的抓手。比如:讓使用者感知到這個活動;要讓使用者有參與活動的意願;要降低使用者參與活動的門檻;要讓使用者參與這個話題後得到報償從而重複的參與其中,我們稱這些為抓手,也就是 How。
如何能產生這樣的 How 呢,我們需要提供相應的產品功能,比如為了讓使用者感知到話題,我們需要在產品中增加活動的透出,並精準的推送訊息;為了降低使用者的參與門檻,我們可能要重新設計活動的流程,這些是 What。
Why、How 和 What 這三個圈被稱為黃金圈,它也是從目標到功能的對映。在產品開發中,我們可以把 How 稱為抓手——如何影響使用者才能實現目標。有時在 How 這個層面,我們會區分對不同使用者的影響 (針對不同使用者的抓手),於是它就變成了 Why,Who,How 和 What。
這幅圖就是一個例子,目標是提高導購活躍度,這是 Why,對此我們可以做出量化的定義,如:即時回覆率達到xx%等等;為此我們要分別影響導購和品牌這兩個角色,這是 who;如何影響這兩個角色,來促成目標的達成,這是 How,如:“讓導購即時知道應該做的事”就是一個影響手段;最後如何實現這些影響呢,這是 What,如新會員的加入語音提功能,提供即時備註功能等等。
以上從業務目標出發定義產品功能的實踐,被稱為影響地圖。其背後的假設是:產品透過功能 (what),影響 (how) 特定使用者角色 (how) 的行為,從而實現業務目標 (why)。影響地圖幫助團隊更有效地擴充思路挖掘和組織需求。
基於影響地圖,接下來我們要做的是選擇其中最有效的功能,合理規劃,迭代的實現目標。關於規劃,我想問大家一個問題。我們的目標是實現整張地圖嗎?
顯然不是。在需求的挖掘階段,我們可以集思廣益、充分發散,但做規劃,我們則要有效收斂。我們的目標是在地圖上找到從功能到目標的最短路徑。以最少的功能,最快地實現目標,或驗證假設。影響地圖讓我們可以更聚焦。第一:聚焦有限的目標,過濾與目標無關的需求,防止範圍蔓延;第二:在資源有限的情況下,強制做出優先順序的判斷,選擇對實現目標影響最大的需求。
圖中標了“1”和“2”的就是對優先順序的標識。“1”表示接下來就要去做的,它們構成一個最小的可釋出產品——MVP (Minimal Virable Product) 。“2”則是後面將要考慮的。
我們做了選擇的需求,並完成交付。這就代表成功了嗎?顯然不是,我們的目的是實現目標,而不是交付功能。成功與否最終還是要看目標的達成情況,而功能只是手段。功能與目標之間還差著兩道假設。第一:我們假設這些功能會產生設想的影響,讓使用者產生我們期望中的行為;第二:假設對使用者行為的影響能幫我實現目標。這兩類假設,在被事實驗證之前,只能是假設。
影響地圖的一個重要的優點是,它保留並直觀呈現上面兩類假設。這樣,當功能交付後,我們可以也應該去檢視影響和目標的達成情況。我們希望引導團隊更多關注業務成果,為業務負責,而不僅僅只是交付功能。
所以,功能交付後,我們要基於影響地圖去檢視影響和目標的達成情況,並作出及時的調整,這樣才能形成閉環。之前我們對目標的量化為這一閉環的有效性提供了好的基礎,我們應該在交付功能後去收集和有效分析資料,形成資料化的閉環。透過這一套機制,我們希望培養:關注業務結果,資料驅動的實驗文化和增長文化。
到此為止,從持續交付到業務創新的內容就講完了。它的核心是要形成一個有效的創新迴圈。這個迴圈從確定業務目標開始。
基於業務大圖,團隊把整體目標拆解成相互關聯的子目標,確定實現目標的步驟和當前時刻應該重點關注的細分目標,並基於產品大圖確定相關的度量指標,讓目標量化;從量化目標出發,建立從 Why 到 How 再到 What 的對映,構建實現業務目標的影響地圖;接下來,基於持續交付能力,順暢的交付需求;需求交付後,我們要回到目標有效反饋並即時調整。
以上的各個環節構成了面向業務目標、資料驅動和即時反饋調整的有效創新迴圈,而持續交付能力則是這一迴圈運作的基礎,它讓創新迴圈得以加速。面對今天加速變化且競爭激烈的環境, 加速有效創新迴圈是產品交付及創新的必然選擇。
最後我做一個總結,圖中的這個人是阿基米德。我們都知道他在一次洗澡中得到靈感,發現了浮力定律。我今天的問題是,阿基米德在此之前洗過澡嗎?那之前為什麼沒有發現浮力定律呢?這一次有什麼不同?對,國王問了問題——皇冠中的黃金有沒有摻假?是問題引導阿基米德發現了浮力定律。正確的問題帶來好的結果。
我把這個故事作為總結,是想說:我們實施敏捷也罷,提升效能也罷,一定要知道我們想解決的問題是什麼,這樣才能找到正確的實踐和方法。
圖中,我們列出了產品開發實踐棧,大部分產品團隊更多關注的是中間橙色的部分。但今天的業務不確定性在持續提升,選擇權在向使用者側轉移。持續變化和激烈競爭的環境,對產品開發提出了更高的要求。產品開發的敏捷實踐需要突破原有邊界。這當然不容易,重要的是,我們首先必須弄清楚想要解決的問題是什麼? 它比答案更重要。
總結今天分享的內容,我們一直在回答兩個問題。
第一:沿著實踐棧往下追問,我們要回答的問題是:“如何才能順暢和高效的交付?”為此有了我們以流動效率為核心的技術和管理實踐,以及如何讓開發人員專注於業務邏輯,而不用過度分心於其他事務的工程實踐。
第二:沿著實踐棧往上追問,我們要回答的問題是:“如何保證交付的是有用的價值?”,為此才有了我們在第三部分所討論的有效創新實踐——從業務目標出發,並最終回到業務目標形成有效的閉環。
為了回答以上兩個問題,我們需要從業務目標到產品設計和交付,直至運維的全方位實踐,這是一種全棧的敏捷實踐,業界也稱之為Biz-Dev-Ops。
我們還想告訴大家,持續交付和業務創新是相互關聯,相輔相成的。持續交付是業務創新的基礎,而持續交付的收益最後要落實到業務創新中去。
我們今天講得更多是一個方法論,實踐不可能非常全面。最重要的是我們一定要明確問題是什麼。從正確問題出發,相信大家一定能找到適合自己的實踐框架,切實提升交付和創新能力,助力業務成功。
阿里內部分享現場
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562044/viewspace-2284735/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 不懂 Nginx 的前端不是好前端Nginx前端
- 不懂產品的碼農不是好程式設計師程式設計師
- Jeff Dean與David Patterson:不思考體系結構的深度學習研究者不是好工程師深度學習工程師
- 7大類深度CNN架構創新綜述CNN架構
- 走出架構誤區,架構師並不是想象的那麼容易架構
- 全棧工程師和架構師的區別全棧工程師架構
- 軟體工程師,如何繪製業務架構圖 — 2.框架圖軟體工程工程師架構框架
- 專車架構進化往事:好的架構是進化來的,不是設計來的架構
- 趣頭條 業務架構師架構
- 好的架構師都是善良的獨裁者架構
- 不懂物理的前端不是好的遊戲開發者(一)—— 物理引擎基礎前端遊戲開發
- 架構師之路 - 業務領域建模架構
- 在創業公司當好工程師的 7 個特質創業工程師
- 架構的演進,阿里資深Java工程師表述架構的腐化之謎架構阿里Java工程師
- 架構的演進, 阿里資深Java工程師表述架構的腐化之謎架構阿里Java工程師
- 【雲舒520表白篇】不懂浪漫的IT程式猿不是好男友?
- 不懂物理的前端不是好的遊戲開發者(二)—— 物理引擎的學習之路前端遊戲開發
- 要做軟體工程師,而不是前端工程師軟體工程工程師前端
- 你不是軟體工程師!軟體工程工程師
- 什麼樣的工程師才可能真正推動創新?工程師
- 業務架構架構
- 微服務業務架構的探索微服務架構
- [原創]測試架構師是做什麼的?架構
- 關於軟體架構和業務架構的思考架構
- 趣頭條 架構部 急招 中介軟體研發工程師/架構師架構工程師
- 趣頭條架構部 Golang開發工程師/架構師 火熱招聘ing架構Golang工程師
- 不懂業務的SQL優化方法SQL優化
- 不是嚇唬你,工程師不知道谷歌的深度學習系統在想什麼工程師谷歌深度學習
- 架構師的工作架構
- 在阿里架構師眼中構建一個較為通用的業務技術架構就是如此簡單阿里架構
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 新時代的測試工程師工程師
- 阿里巴巴架構師:十問業務中臺和我的答案阿里架構
- 三種軟體工程師——編碼員、程式師和架構師軟體工程工程師架構
- 架構師眼中的高併發架構架構
- 架構師日記-如何寫的一手好程式碼架構
- 創業公司的 Nodejs 工程師創業NodeJS工程師
- 工程師們不斷推動下的雲服務架構工程師架構