京東精益敏捷教練分享:敏捷助力產品創新!

b3cb168d-6594-442d-88ae-ea6c3a03b526.png

 

李國柱-京東精益敏捷教練架構

 

導語:微服務

通常咱們想到產品創新,會以爲這個是產品經理的事,是產品經理應該關心的,咱們研發團隊好像通常關注比較少。根據我本身的經驗我發如今創新上面很是強的團隊,一般研發團隊有很是深的參與度,並且對整個創新過程的支撐是很是強。單元測試

敏捷思惟在創新過程其實也可以扮演很關鍵的角色,接下來我結合本身的工做經歷跟你們分享一下,在產品創新過程中如何作到敏捷思想和敏捷實踐起到助推產品創新的效果。學習

1、產品創新面臨的挑戰

首先咱們在企業裏工做中會作各類各樣的創新嘗試,大到產品的全新業務模式的創建或者舊有業務模式的重構,小到用戶體驗的提高,很是很是的多。產品經理可能有一些不錯的想法拋出來,咱們研發團隊來幫助實現,這個過程會投入到不少的人力或者不少的金錢,最後結果如何呢?至關多的結果是很是不肯定,頗有可能達不到咱們須要的這種效果。也就是說實際上是很是不肯定性,有很是多的不肯定性,或者是成功的機會其實並非很是的高。測試

 

屏幕快照 2019-05-23 上午10.30.16.png


 

根據我本身的經驗作過一些統計,互聯網行業新產品成功率,我本身的經驗不會超過5%。以前一家公司我參與產品的創新和孵化工做,當時有39個項目進入孵化階段,兩年之後還活着的只有3個, 這個成功率是很是低。即便是小的創新,好比說用戶體驗提高的工做,至少有一半以上是不成功,也就是說咱們上線之後,發現用戶並無指望那樣喜歡咱們的產品,或者更多的用戶流入。這個取決於作用戶體驗的目的,你是拉新仍是促活,仍是保證留存等等諸如此類。因此創新成功的領域很是低。優化

 

屏幕快照 2019-05-23 上午10.39.17.png

 

另外,咱們在這個過程中不得不依靠一些老司機,比較資深的,對用戶,對行業有比較深洞察的產品經理,可能他們提出來的想法是靠譜一些。咱們須要這樣的人,這樣也是在咱們的行業當中是不可或缺。可是問題是這是可遇而不可求,你也許有機會跟一個靠譜的資深產品經理一塊兒工做,可是也許不是這樣的。並且即便有這樣的人在團隊當中,這麼長時間下來我發現他不可能一直對下去,此次多是OK,可是過一段時間在另一個功能點,他的洞察力不必定靠譜了。這個實際上是咱們的現狀決定的。ui

如今互聯網行業基本紅利期結束了,好摘的果子基本摘掉了,剩下都是難啃的工做,剩下都是比較難的工做,有不少不肯定性,到底有哪些路能夠走通,其實誰都說不清楚,這個也是咱們面臨的很大挑戰。3d

咱們常常聽到VUCA時代,說的就是這個,咱們這個時代瞬息萬變,不肯定性很是強,無論是在各個業務領域,基本上都是這樣:blog

V(Volatility)、U(Uncertainty)、C(Complexity)、A(Ambiguity)接口

 

屏幕快照 2019-05-23 上午10.42.16.png

 

創新面臨最大的挑戰就是不肯定性,咱們面臨不少路,可是沒有辦法搞清楚哪一路真的能夠走通,這個創新面臨的最大不肯定性,可是好消息是敏捷最大的長處就是應對不肯定性。

2、產品須要敏捷思惟

敏捷應對不肯定性的方式

咱們工做中兩種不一樣的思惟方式或者工做方式,一種是預測式的過程,另一種是經驗式的過程。

預測式過程就是傳統的這種作事模式。咱們以爲要把這件事情作成,就意味着一開始什麼都要作對,什麼都要想對,這種工做模式一開始花大量的時間和精力但願在一開始什麼都作對,什麼都要靠譜,經常事與願違,就是這種不肯定性。這個會致使團隊覺得快接近目標的時候,才發現這個不是咱們去的方向,趕忙換方向,多是另一個目標。這個時候你調整方向會花大量的代價。可能接近調整目標了之後,其實發現目標還在另外的地方,又要再作調整。不少團隊死在調整路上,你根本沒有爲不肯定性作準備。

敏捷方式就經驗式的過程,它的方式是什麼?假定沒有辦法在一開始就獲得全部須要的信息,從而沒有辦法什麼都作對,這種前提下就不期望咱們一開始作的是最正確的決定,咱們先基於現有的信息先作靠譜的決定,而後往前走兩步,走兩步之後,這個時候有新的信息進來,我再基於新的信息作更加靠譜的決定,再往前走兩一步。這樣不斷往前走,新的信息不斷進來,不斷修正方向,反而更好,更快達到咱們的目標,這個是敏捷應對不肯定性的方式。

屏幕快照 2019-05-23 上午10.48.37.png

 

打破肯定性思惟

平時咱們怎麼把洗澡水調到合適的溫度?水頭沒有刻度,我沒有辦法去調,怎麼辦?難道就沒有辦法洗澡,咱們就試,咱們先擰開再說,要不斷的調整,不了多久就調到合適的溫度這就是所謂經驗式的過程,敏捷應對不肯定性的方式。

咱們必須打破不肯定性思惟,咱們但願從肯定性思惟向右邊轉變。這個過程中,不少團隊不敢輕易嘗試,由於失敗了就要背鍋,這種環境是不可能有什麼創新動力在,咱們必須轉變以最小成本快速試錯。

 

屏幕快照 2019-05-23 上午11.13.45.png

 

關鍵在於,不肯定性環境下要試錯,可是要想成功有兩個關鍵詞兒,第一是最小成本,第二是快速,這兩個缺一不可。

①-因此咱們須要從不肯意輕易嘗試,極力避免失敗,轉變爲以最小成本快速試錯。

②-追求大而詳盡的計劃轉變爲迭代式小規模計劃。

大而詳盡計劃沒有意義,沒有過不了多久狀況變得不同,你原來想跑的東西沒有辦法試用。

③-追求完整、詳細的需求文檔轉變爲需求漸進明晰,切分小粒度。

在這個過程當中,你花大量時間到寫需求文檔,不少時間都浪費掉了。咱們指望方式是需求漸進明細,遠的需求按照優先級來排好,很快立刻要作的需求,最近一兩週作的需求把它仔細細化能夠開始開發,更加遠的需求容許必定程度的模糊性或者是粗粒度,這樣更加容易應對變化。

④-對範圍、時間、質量毫無差異的堅守轉變爲堅守時間、質量、範圍可協商。

舉個例子:

老闆把你叫到辦公室跟你說,這些需求某一天全都要,保質保量。這個意味着範圍、時間、質量所有限死了,你在這個過程沒有什麼調整餘地,這些需求在那個時間點要保質保量所有上,實際當中咱們發如今不肯定環境下,這個其實至關難作到,你們都會硬頭皮作。這個時候問開發能不能實現,開發說壓力太大了,可是不行,老闆要,你必須作到,99六、247你隨便選。

開發同窗面臨這種情況會怎麼選,可見都弄上去,你要的功能,要的界面這些都弄上,可是很差見的地方很差意思要作不少的妥協,各類臨時的解決方案都在裏面了,代碼看上去一團糟,接手的時候很難在這個基礎作開發。由於你已經把時間卡在那兒了,咱們真的要這樣嗎?

咱們回過來看一下:時間、質量、範圍

時間能不能妥協?一般不能妥協。由於畢竟不少東西是要時效性,好比說雙十一活動和6.18活動,時間不妥協。

質量能不能妥協?質量固然不能妥協了。這個是咱們的責任,咱們有責任有義務保證質量把咱們的產品功能奉獻給客戶,服務奉獻給客戶。

咱們的範圍能不能妥協?其實是能夠的。咱們再把老闆交過來一大包需求拿過來,仔細切小看看,你會發現他們優先級度是不同,有些東西能夠日後放一放,這個時候會發現不少協調、討價還價的餘地。

也就是說範圍應該能夠接受,這個是自然決定,你要切開小粒度,必須切下,切開,而後再說這個重要,仍是那個重要,這個先作,那個先作,這個時候纔有討論餘地。

⑤—精確的進度把控及對任何便利的追究,到接受意外變化並以最小的代價快響應。

「構建-衡量-學習」循環

在精益創業裏面,全部構建、衡量、學習就是來自於精益創業,一開始有想法,而後快速造成開發,造成上線,而後能夠收集到用戶的反饋,基於用戶的反饋,用戶的數據分析出來獲得和驗證咱們的路子,這個路子是否是走的通,是否是用戶須要,而後造成新的想法再進一步實現,這個過程就是「構建—衡量—學習」咱們以快速試錯成本的一個方法。

 

屏幕快照 2019-05-23 上午11.39.16.png

 

探索創新方式的學習循環

產品方向搞清楚了,咱們在後面須要持續推進產品的增加,咱們在局部不斷作這種優化,因此後面優化的思路徹底是同樣,它來自於增加黑客的思路。

能夠在團隊成立專門增加團隊,有了新的想法開始排優先級,以爲靠譜就趕快作出來,上線驗證。咱們只作驗證咱們想法需求最小集,只要驗證咱們的想法,甚至不開發均可以,不少時候不開發,作一個假的界面,背後是人工在弄,就沒有開發現成的系統,只要驗證咱們的想法就足夠了。快速評估、學習裏面的驗證思路,而後造成新的想法。

 

屏幕快照 2019-05-23 上午11.45.25.png

 

3、創建低成本快速試錯的工程能力

若是要支撐以前的以最小成本快速試錯,咱們必須創建低成本快速試錯的工程能力,這個實現不了,咱們很難實現最小成本快速試錯。

例如

「團隊一」 能夠作到一週快速有五六次上線,

「團隊二」 可能一個月就試一兩次

「團隊二」一個月作的嘗試試錯數量都比不上「團隊一」一週作的,若是咱們競爭對手能作的這麼快,咱們的危機就來了。他一個月嘗試試錯次數是咱們一年的量,這個意味着他能夠比你更早找到正確的方向,咱們的生存危機就很大了,因此咱們必須創建低成本快速試錯的能力。

讓創新置換快速運轉

咱們有想法、快速實現上線,基於數據分析,而後造成新的想法,不斷來進行循環。這個過程要作不少的事情,咱們要讓創新的環快速運做,你們看各類各樣的事情要作。這個須要不少人緊密配合,才能讓環轉起來。

在你的團隊裏面,轉一圈要多久?一般以前參與比較好的團隊,若是一個想法好比說一天開發,一天測試的想法,轉一圈很是快,基本一天半就轉完了,你有一個想法,產品同窗有一個想法立刻要驗一下,這個很是重要,一天開發一天測試,兩天半就夠了,這個是很是快的。

 

屏幕快照 2019-05-24 上午10.01.42.png

 

若是把這個創新環比作成齒輪,咱們想讓齒輪快速轉起來,就須要加入潤滑油,這個潤滑油就是精益的實踐。

 

屏幕快照 2019-05-24 上午10.04.11.png

 

跨職能自管理團隊

咱們要把咱們的這種創新團隊組織起來,這個創新團隊跟以前不同,它必須是跨職能自管理團隊,首先咱們要堅持的是圍繞價值流組織跨職能團隊,下圖是電商業務價值流,所謂價值流就是經過一系列的過程可以提供用戶有價值的產品。這個過程是企業的命脈,若是這個過程出問題,那麼企業就有了問題。圍繞這個過程順利進行,咱們必須下面有不少的系統支持,就是有系統羣。每個系統羣有相應的研發價值,研發團隊確保這個系統正常運做,若是有新的需求快速迭代,快速上線作嘗試,這是首先要作到的。

 

屏幕快照 2019-05-24 上午10.14.20.png

 

在團隊劃分的時候不要對抗康威定律。康威定律說的是軟件系統組織和架構有一一對應的關係,若是沒有對應就意味着有更高的溝通協做成本。

 

屏幕快照 2019-05-24 上午10.22.27.png

 

團隊邊界和系統的邊界重合是溝通成本最小,個人團隊須要按照這種方式來組織。這個意味着咱們的系統要通過比較合理的劃分,使得系統間高度結耦,只保留最小程度的依賴,消除沒必要要的依賴,這種狀況下每一個系統可能對應相應的團隊。這種狀況下團隊之間的跨團隊溝通協做成本最低,溝通協做的成本在這個過程會消除不少。

 

屏幕快照 2019-05-24 上午10.35.56.png

 

咱們須要打破巨石架構,採用微服務的形式。

 

屏幕快照 2019-05-24 上午10.36.04.png

 

微服務是高度類聚,咱們但願增強交付爲主的跨職能團隊。

 

屏幕快照 2019-05-24 上午10.41.00.png

 

還有寬組織溝通協做機制,確保團隊能夠高效的運做。

 

屏幕快照 2019-05-24 上午10.42.43.png

 

管理風格是很是關鍵一點,這裏面象徵了兩種管理風格,一種是牧羊犬,另一種是領頭羊。

牧羊犬的模式:走偏了趕回來,模式壽命比較短。

領頭羊的模式:把領頭羊管好就能夠,領頭羊走到哪裏,其餘羊就走到哪裏。

這兩種模式區別很是明顯,咱們但願團隊能夠高效進行產品創新,個人經驗是下面的方式有利於團隊創新。

緣由其實挺簡單:

牧羊犬的方式:要想運做起來,必須制定複雜的流程,各類檢查機制,各類文檔,確保整個團隊可以運做起來。可是問題是,對於須要創造力和反覆試錯的任務,沒法經過簡單的遵循一套規則來實現。

領頭羊的方式:對指望高效創新的團隊來說是很是須要的,咱們就是但願有人站起來引領你們往前走,而不是拿着鞭子趕着你們往前走。

 

屏幕快照 2019-05-24 上午10.44.45.png

 

咱們須要激發和引領團隊內在驅動力,但願團隊有掌控感、成就感,同時有明確的目標和知足感。若是但願這個團隊有這種感覺,咱們讓團隊本身來造成這種組織,制定團隊運做的規則來推進團隊的運行,讓他們來管理。

透明和信任也是很重要,咱們把信息透明起來,有透明纔有機會帶來信任。沒有透明信任就無從談起。一旦沒有信任,團隊間協做成本很是高,由於你們都忙着自我保護。

小批量快速反饋跟交付

剛纔提了研發的價值,咱們從需求一直到有價值功能,整個過程就是研發價值流,這個過程就是價值實現的過程。這個過程當中咱們通常都是小計劃,短迭代,小批量的方式來運做。咱們不作大的計劃,咱們能夠有長期路線圖,可是隻聚焦在短時間要作的事情上,批量切小,把需求切小,每一次聚焦咱們在作事情,快速完成再作下面的事情。

 

屏幕快照 2019-05-24 上午10.54.53.png

 

小批量就是快速得反饋,這個事情一個月才能作完,若是做爲一個月的需求來看,你靠近一個月纔有可見的東西出來,纔有測試介入,才能告訴開發,這個地方沒有做對。若是切小就有機會分析上線,原本一個月要上線,咱們切了四批,第一週結束的時候就能夠上線,第二批在第二週結束就能夠上線了,有些時候有些功能早上線一天,生存機率就大不少。還有若是是大包東西沒有拆開,要作就是一開始一批所有開始作,把需求切小了很重要的一點,就是減小浪費了。

 

屏幕快照 2019-05-24 上午10.58.52.png

 

快速需求探索和規劃

其實需求跟規劃、探索是挺花時間的一個過程,並且你會發現這個過程中,如何充分發揮團隊的這種智慧,實際上是很大的挑戰。咱們知道有不少人有不錯的想法,若是把你們合到一塊兒來就會發現討論的過程,你們作出來的決策趨於平庸化,咱們採用了一些羣策羣力頭腦風暴的方式,咱們叫作需求探索工做坊,模式就是你們羣體一塊兒頭腦風暴。

可是爲了讓你們充分發揮每一個人聰明才智,這個裏面有一些方法和技巧:

① 引導的技巧 ,保證團隊可以在過程進行高效的討論,不跑題,不被某些人主導而壓制其餘人,主持人角色很重要。

② 整個過程是可視化 ,一旦可視化溝通效率就增長了不少。

 

屏幕快照 2019-05-24 上午11.05.27.png

 

工做透明化

這是咱們辦公場所,其實放眼望去,這麼團隊在忙,他們是一個團隊,他們作一些重要的事情,可是沒有可視化是搞不清楚。也許每一個人專一於本身那一塊,到底卡在什麼地方?哪些地方須要你們一塊兒協商討論介入,這個過程是看不出來。沒有過程的可視化就沒有辦法作優化的工做,或者是協調共同的工做,就不會發生了。因此咱們須要把價值流動過程可視化出來,咱們就有機會作更多的事情。

 

屏幕快照 2019-05-24 上午11.08.10.png

 

可視化什麼?就是價值流動過程,包括咱們整個待開發的隊列,工做項和各類各樣問題和阻礙,甚至是人力資源分配都是可視化。

持續交付流水線

流水線包括兩部分,一部分是持續集成,另一部分是持續部署。

持續集成有一些規則,好比說盡量頻繁集成,及時提交代碼等等

持續部署有一些要求,讓整個過程高效運做起來,從代碼的集成,編譯打包、測試,單元測試,功能測試和接口測試到最後部署等等都自動化起來,減小盡可能人工干預。

 

屏幕快照 2019-05-24 上午11.11.56.png

 

持續改進

我所經歷過的高效創新團隊裏面,沒有一個團隊是一步成功的,都是通過常年不斷的改進才實現快速高效的交付能力。回顧會是個好東西,就是按期開回顧會,認真落實你們的想法,落實一些改進的項。時間長了確定有效果。

 

屏幕快照 2019-05-24 上午11.16.56.png

 

4、總結

最後想說,這整個過程我最有感觸,咱們想要團隊不斷提高,根本聚焦是對人的改變。咱們發現無論是對敏捷而言,仍是精益也好,本質就是思惟的轉變,人的思惟轉變,作事方式的轉變。一旦人變了,作事方式和態度有所變化,作事就不同了。

相關文章
相關標籤/搜索