李國柱-京東精益敏捷教練
導語：
一般我們想到產品創新，會覺得這個是產品經理的事，是產品經理應該關心的，我們研發團隊好像一般關注比較少。根據我自己的經驗我發現在創新上面非常強的團隊，通常研發團隊有非常深的參與度，而且對整個創新過程的支撐是非常強。
敏捷思維在創新過程其實也能夠扮演很關鍵的角色，接下來我結合自己的工作經歷跟大家分享一下，在產品創新過程當中如何做到敏捷思想和敏捷實踐起到助推產品創新的效果。
一、產品創新面臨的挑戰
首先我們在企業里工作中會做各種各樣的創新嘗試，大到產品的全新業務模式的建立或者舊有業務模式的重構，小到用戶體驗的提升，非常非常的多。產品經理可能有一些不錯的想法拋出來，我們研發團隊來幫助實現，這個過程會投入到很多的人力或者很多的金錢，最后結果如何呢？相當多的結果是非常不確定，很有可能達不到我們需要的這種效果。也就是說其實是非常不確定性，有非常多的不確定性，或者是成功的機會其實並不是非常的高。
根據我自己的經驗做過一些統計，互聯網行業新產品成功率，我自己的經驗不會超過5%。之前一家公司我參與產品的創新和孵化工作，當時有39個項目進入孵化階段，兩年以后還活着的只有3個， 這個成功率是非常低。即使是小的創新，比如說用戶體驗提升的工作，至少有一半以上是不成功，也就是說我們上線以后，發現用戶並沒有期望那樣喜歡我們的產品，或者更多的用戶流入。這個取決於做用戶體驗的目的，你是拉新還是促活，還是保證留存等等諸如此類。所以創新成功的領域非常低。
另外，我們在這個過程當中不得不依靠一些老司機，比較資深的，對用戶，對行業有比較深洞察的產品經理，可能他們提出來的想法是靠譜一些。我們需要這樣的人，這樣也是在我們的行業當中是不可或缺。但是問題是這是可遇而不可求，你也許有機會跟一個靠譜的資深產品經理一起工作，但是也許不是這樣的。而且即使有這樣的人在團隊當中，這么長時間下來我發現他不可能一直對下去，這次可能是OK，但是過一段時間在另外一個功能點，他的洞察力不一定靠譜了。這個其實是我們的現狀決定的。
現在互聯網行業基本紅利期結束了，好摘的果子基本摘掉了，剩下都是難啃的工作，剩下都是比較難的工作，有很多不確定性，到底有哪些路可以走通，其實誰都說不清楚，這個也是我們面臨的很大挑戰。
我們經常聽到VUCA時代，說的就是這個，我們這個時代瞬息萬變，不確定性非常強，不管是在各個業務領域，基本上都是這樣：
V（Volatility）、U（Uncertainty）、C（Complexity）、A（Ambiguity）
創新面臨最大的挑戰就是不確定性，我們面臨很多路，但是沒有辦法搞清楚哪一路真的可以走通，這個創新面臨的最大不確定性，但是好消息是敏捷最大的長處就是應對不確定性。
二、產品需要敏捷思維
敏捷應對不確定性的方式
我們工作中兩種不同的思維方式或者工作方式，一種是預測式的過程，另外一種是經驗式的過程。
預測式過程就是傳統的這種做事模式。我們覺得要把這件事情做成，就意味着一開始什么都要做對，什么都要想對，這種工作模式一開始花大量的時間和精力希望在一開始什么都做對，什么都要靠譜，常常事與願違，就是這種不確定性。這個會導致團隊以為快接近目標的時候，才發現這個不是我們去的方向，趕緊換方向，可能是另外一個目標。這個時候你調整方向會花大量的代價。可能接近調整目標了以后，其實發現目標還在另外的地方，又要再做調整。很多團隊死在調整路上，你根本沒有為不確定性做准備。
敏捷方式就經驗式的過程，它的方式是什么？假定沒有辦法在一開始就得到所有需要的信息，從而沒有辦法什么都做對，這種前提下就不指望我們一開始做的是最正確的決定，我們先基於現有的信息先做靠譜的決定，然后往前走兩步，走兩步以后，這個時候有新的信息進來，我再基於新的信息做更加靠譜的決定，再往前走兩一步。這樣不斷往前走，新的信息不斷進來，不斷修正方向，反而更好，更快達到我們的目標，這個是敏捷應對不確定性的方式。
打破確定性思維
平時我們怎么把洗澡水調到合適的溫度？水頭沒有刻度，我沒有辦法去調，怎么辦？難道就沒有辦法洗澡，我們就試，我們先擰開再說，要不斷的調整，不了多久就調到合適的溫度這就是所謂經驗式的過程，敏捷應對不確定性的方式。
我們必須打破不確定性思維，我們希望從確定性思維向右邊轉變。這個過程當中，很多團隊不敢輕易嘗試，因為失敗了就要背鍋，這種環境是不可能有什么創新動力在，我們必須轉變以最小成本快速試錯。
關鍵在於，不確定性環境下要試錯，但是要想成功有兩個關鍵詞兒，第一是最小成本，第二是快速，這兩個缺一不可。
①-所以我們需要從不願意輕易嘗試，極力避免失敗，轉變為以最小成本快速試錯。
②-追求大而詳盡的計划轉變為迭代式小規模計划。
大而詳盡計划沒有意義，沒有過不了多久情況變得不一樣，你原來想跑的東西沒有辦法試用。
③-追求完整、詳細的需求文檔轉變為需求漸進明晰，切分小粒度。
在這個過程中，你花大量時間到寫需求文檔，很多時間都浪費掉了。我們期望方式是需求漸進明細，遠的需求按照優先級來排好，很快馬上要做的需求，最近一兩周做的需求把它仔細細化可以開始開發，更加遠的需求允許一定程度的模糊性或者是粗粒度，這樣更加容易應對變化。
④-對范圍、時間、質量毫無差別的堅守轉變為堅守時間、質量、范圍可協商。
舉個例子：
老板把你叫到辦公室跟你說，這些需求某一天全都要，保質保量。這個意味着范圍、時間、質量全部限死了，你在這個過程沒有什么調整余地，這些需求在那個時間點要保質保量全部上，實際當中我們發現在不確定環境下，這個其實相當難做到，大家都會硬頭皮做。這個時候問開發能不能實現，開發說壓力太大了，但是不行，老板要，你必須做到，996、247你隨便選。
開發同學面臨這種狀況會怎么選，可見都弄上去，你要的功能，要的界面這些都弄上，但是不好見的地方不好意思要做很多的妥協，各種臨時的解決方案都在里面了，代碼看上去一團糟，接手的時候很難在這個基礎做開發。因為你已經把時間卡在那兒了，我們真的要這樣嗎？
我們回過來看一下：時間、質量、范圍。
時間能不能妥協？通常不能妥協。因為畢竟很多東西是要時效性，比如說雙十一活動和6.18活動，時間不妥協。
質量能不能妥協？質量當然不能妥協了。這個是我們的責任，我們有責任有義務保證質量把我們的產品功能奉獻給客戶，服務奉獻給客戶。
我們的范圍能不能妥協？實際上是可以的。我們再把老板交過來一大包需求拿過來，仔細切小看看，你會發現他們優先級度是不一樣，有些東西可以往后放一放，這個時候會發現很多協調、討價還價的余地。
也就是說范圍應該可以接受，這個是天然決定，你要切開小粒度，必須切下，切開，然后再說這個重要，還是那個重要，這個先做，那個先做，這個時候才有討論余地。
⑤—精確的進度把控及對任何便利的追究，到接受意外變化並以最小的代價快響應。
“構建-衡量-學習”循環
在精益創業里面，所有構建、衡量、學習就是來自於精益創業，一開始有想法，然后快速形成開發，形成上線，然后可以收集到用戶的反饋，基於用戶的反饋，用戶的數據分析出來得到和驗證我們的路子，這個路子是不是走的通，是不是用戶需要，然后形成新的想法再進一步實現，這個過程就是“構建—衡量—學習”我們以快速試錯成本的一個方法。
探索創新方式的學習循環
產品方向搞清楚了，我們在后面需要持續推動產品的增長，我們在局部不斷做這種優化，所以后面優化的思路完全是一樣，它來自於增長黑客的思路。
可以在團隊成立專門增長團隊，有了新的想法開始排優先級，覺得靠譜就趕快做出來，上線驗證。我們只做驗證我們想法需求最小集，只要驗證我們的想法，甚至不開發都可以，很多時候不開發，做一個假的界面，背后是人工在弄，就沒有開發現成的系統，只要驗證我們的想法就足夠了。快速評估、學習里面的驗證思路，然后形成新的想法。
三、建立低成本快速試錯的工程能力
如果要支撐之前的以最小成本快速試錯，我們必須建立低成本快速試錯的工程能力，這個實現不了，我們很難實現最小成本快速試錯。
例如
“團隊一” 可以做到一周快速有五六次上線，
“團隊二” 可能一個月就試一兩次
“團隊二”一個月做的嘗試試錯數量都比不上“團隊一”一周做的，如果我們競爭對手能做的這么快，我們的危機就來了。他一個月嘗試試錯次數是我們一年的量，這個意味着他可以比你更早找到正確的方向，我們的生存危機就很大了，所以我們必須建立低成本快速試錯的能力。
讓創新置換快速運轉
我們有想法、快速實現上線，基於數據分析，然后形成新的想法，不斷來進行循環。這個過程要做很多的事情，我們要讓創新的環快速運作，大家看各種各樣的事情要做。這個需要很多人緊密配合，才能讓環轉起來。
在你的團隊里面，轉一圈要多久？通常之前參與比較好的團隊，如果一個想法比如說一天開發，一天測試的想法，轉一圈非常快，基本一天半就轉完了，你有一個想法，產品同學有一個想法馬上要驗一下，這個非常重要，一天開發一天測試，兩天半就夠了，這個是非常快的。
如果把這個創新環比做成齒輪，我們想讓齒輪快速轉起來，就需要加入潤滑油，這個潤滑油就是精益的實踐。
跨職能自管理團隊
我們要把我們的這種創新團隊組織起來，這個創新團隊跟之前不一樣，它必須是跨職能自管理團隊，首先我們要堅持的是圍繞價值流組織跨職能團隊，下圖是電商業務價值流，所謂價值流就是通過一系列的過程能夠提供用戶有價值的產品。這個過程是企業的命脈，如果這個過程出問題，那么企業就有了問題。圍繞這個過程順利進行，我們必須下面有很多的系統支持，就是有系統群。每一個系統群有相應的研發價值，研發團隊確保這個系統正常運作，如果有新的需求快速迭代，快速上線做嘗試，這是首先要做到的。
在團隊划分的時候不要對抗康威定律。康威定律說的是軟件系統組織和架構有一一對應的關系，如果沒有對應就意味着有更高的溝通協作成本。
團隊邊界和系統的邊界重合是溝通成本最小，我的團隊需要按照這種方式來組織。這個意味着我們的系統要經過比較合理的划分，使得系統間高度結耦，只保留最小程度的依賴，消除不必要的依賴，這種情況下每個系統可能對應相應的團隊。這種情況下團隊之間的跨團隊溝通協作成本最低，溝通協作的成本在這個過程會消除很多。
我們需要打破巨石架構，采用微服務的形式。
微服務是高度類聚,我們希望加強交付為主的跨職能團隊。
還有寬組織溝通協作機制，確保團隊可以高效的運作。
管理風格是非常關鍵一點，這里面象征了兩種管理風格，一種是牧羊犬，另外一種是領頭羊。
牧羊犬的模式：走偏了趕回來，模式壽命比較短。
領頭羊的模式：把領頭羊管好就可以，領頭羊走到哪里，其他羊就走到哪里。
這兩種模式區別非常明顯，我們希望團隊可以高效進行產品創新，我的經驗是下面的方式有利於團隊創新。
原因其實挺簡單:
牧羊犬的方式：要想運作起來，必須制定復雜的流程，各種檢查機制，各種文檔，確保整個團隊能夠運作起來。但是問題是，對於需要創造力和反復試錯的任務，無法通過簡單的遵循一套規則來實現。
領頭羊的方式：對期望高效創新的團隊來講是非常需要的，我們就是希望有人站起來引領大家往前走，而不是拿着鞭子趕着大家往前走。
我們需要激發和引領團隊內在驅動力，希望團隊有掌控感、成就感，同時有明確的目標和滿足感。如果希望這個團隊有這種感受，我們讓團隊自己來形成這種組織，制定團隊運作的規則來推動團隊的運行，讓他們來管理。
透明和信任也是很重要，我們把信息透明起來，有透明才有機會帶來信任。沒有透明信任就無從談起。一旦沒有信任，團隊間協作成本非常高，因為大家都忙着自我保護。
小批量快速反饋跟交付
剛才提了研發的價值，我們從需求一直到有價值功能，整個過程就是研發價值流，這個過程就是價值實現的過程。這個過程中我們一般都是小計划，短迭代，小批量的方式來運作。我們不做大的計划，我們可以有長期路線圖，但是只聚焦在短期要做的事情上，批量切小，把需求切小，每一次聚焦我們在做事情，快速完成再做下面的事情。
小批量就是快速得反饋，這個事情一個月才能做完，如果作為一個月的需求來看，你靠近一個月才有可見的東西出來，才有測試介入，才能告訴開發，這個地方沒有作對。如果切小就有機會分析上線，本來一個月要上線，我們切了四批，第一周結束的時候就可以上線，第二批在第二周結束就可以上線了，有些時候有些功能早上線一天，生存機率就大很多。還有如果是大包東西沒有拆開，要做就是一開始一批全部開始做，把需求切小了很重要的一點，就是減少浪費了。
快速需求探索和規划
其實需求跟規划、探索是挺花時間的一個過程，而且你會發現這個過程當中，如何充分發揮團隊的這種智慧，其實是很大的挑戰。我們知道有很多人有不錯的想法，如果把大家合到一起來就會發現討論的過程，大家做出來的決策趨於平庸化，我們采用了一些群策群力頭腦風暴的方式，我們叫做需求探索工作坊，模式就是大家群體一起頭腦風暴。
但是為了讓大家充分發揮每個人聰明才智，這個里面有一些方法和技巧：
① 引導的技巧 ，保證團隊能夠在過程進行高效的討論，不跑題，不被某些人主導而壓制其他人，主持人角色很重要。
② 整個過程是可視化 ，一旦可視化溝通效率就增加了很多。
工作透明化
這是我們辦公場所，其實放眼望去，這么團隊在忙，他們是一個團隊，他們做一些重要的事情，但是沒有可視化是搞不清楚。也許每個人專注於自己那一塊，到底卡在什么地方？哪些地方需要大家一起協商討論介入，這個過程是看不出來。沒有過程的可視化就沒有辦法做優化的工作，或者是協調共同的工作，就不會發生了。所以我們需要把價值流動過程可視化出來，我們就有機會做更多的事情。
可視化什么？就是價值流動過程，包括我們整個待開發的隊列，工作項和各種各樣問題和阻礙，甚至是人力資源分配都是可視化。
持續交付流水線
流水線包括兩部分，一部分是持續集成，另外一部分是持續部署。
持續集成有一些規則，比如說盡可能頻繁集成，及時提交代碼等等
持續部署有一些要求，讓整個過程高效運作起來，從代碼的集成，編譯打包、測試，單元測試，功能測試和接口測試到最后部署等等都自動化起來，減少盡量人工干預。
持續改進
我所經歷過的高效創新團隊里面，沒有一個團隊是一步成功的，都是經過常年不斷的改進才實現快速高效的交付能力。回顧會是個好東西，就是定期開回顧會，認真落實大家的想法，落實一些改進的項。時間長了肯定有效果。
四、總結
最后想說，這整個過程我最有感觸，我們想要團隊不斷提升，根本聚焦是對人的改變。我們發現不管是對敏捷而言，還是精益也好，本質就是思維的轉變，人的思維轉變，做事方式的轉變。一旦人變了，做事方式和態度有所變化，做事就不一樣了。
Worktile官網：www.worktile.com
內容整理：Worktile
文章首發於「Worktile官方博客」，轉載請注明來源。