李國柱-京東精益敏捷教練
導語：
一般我們想到產品創新，會覺得這個是產品經理的事，是產品經理應該關心的，我們研發團隊好像一般關注比較少。根據我自己的經驗我發現在創新上面非常強的團隊，通常研發團隊有非常深的參與度，而且對整個創新過程的支撐是非常強。
敏捷思維在創新過程其實也能夠扮演很關鍵的角色，接下來我結合自己的工作經歷跟大家分享一下，在產品創新過程當中如何做到敏捷思想和敏捷實踐起到助推產品創新的效果。
一、產品創新面臨的挑戰
首先我們在企業裡工作中會做各種各樣的創新嘗試，大到產品的全新業務模式的建立或者舊有業務模式的重構，小到用戶體驗的提升，非常非常的多。產品經理可能有一些不錯的想法拋出來，我們研發團隊來幫助實現，這個過程會投入到很多的人力或者很多的金錢，最後結果如何呢？相當多的結果是非常不確定，很有可能達不到我們需要的這種效果。也就是說其實是非常不確定性，有非常多的不確定性，或者是成功的機會其實並不是非常的高。
根據我自己的經驗做過一些統計，互聯網行業新產品成功率，我自己的經驗不會超過5%。之前一家公司我參與產品的創新和孵化工作，當時有39個項目進入孵化階段，兩年以後還活著的只有3個， 這個成功率是非常低。即使是小的創新，比如說用戶體驗提升的工作，至少有一半以上是不成功，也就是說我們上線以後，發現用戶並沒有期望那樣喜歡我們的產品，或者更多的用戶流入。這個取決於做用戶體驗的目的，你是拉新還是促活，還是保證留存等等諸如此類。所以創新成功的領域非常低。
另外，我們在這個過程當中不得不依靠一些老司機，比較資深的，對用戶，對行業有比較深洞察的產品經理，可能他們提出來的想法是靠譜一些。我們需要這樣的人，這樣也是在我們的行業當中是不可或缺。但是問題是這是可遇而不可求，你也許有機會跟一個靠譜的資深產品經理一起工作，但是也許不是這樣的。而且即使有這樣的人在團隊當中，這麼長時間下來我發現他不可能一直對下去，這次可能是OK，但是過一段時間在另外一個功能點，他的洞察力不一定靠譜了。這個其實是我們的現狀決定的。
現在互聯網行業基本紅利期結束了，好摘的果子基本摘掉了，剩下都是難啃的工作，剩下都是比較難的工作，有很多不確定性，到底有哪些路可以走通，其實誰都說不清楚，這個也是我們面臨的很大挑戰。
我們經常聽到VUCA時代，說的就是這個，我們這個時代瞬息萬變，不確定性非常強，不管是在各個業務領域，基本上都是這樣：
V（Volatility）、U（Uncertainty）、C（Complexity）、A（Ambiguity）
創新面臨最大的挑戰就是不確定性，我們面臨很多路，但是沒有辦法搞清楚哪一路真的可以走通，這個創新面臨的最大不確定性，但是好消息是敏捷最大的長處就是應對不確定性。
二、產品需要敏捷思維
敏捷應對不確定性的方式
我們工作中兩種不同的思維方式或者工作方式，一種是預測式的過程，另外一種是經驗式的過程。
預測式過程就是傳統的這種做事模式。我們覺得要把這件事情做成，就意味著一開始什麼都要做對，什麼都要想對，這種工作模式一開始花大量的時間和精力希望在一開始什麼都做對，什麼都要靠譜，常常事與願違，就是這種不確定性。這個會導致團隊以為快接近目標的時候，才發現這個不是我們去的方向，趕緊換方向，可能是另外一個目標。這個時候你調整方向會花大量的代價。可能接近調整目標了以後，其實發現目標還在另外的地方，又要再做調整。很多團隊死在調整路上，你根本沒有為不確定性做準備。
敏捷方式就經驗式的過程，它的方式是什麼？假定沒有辦法在一開始就得到所有需要的信息，從而沒有辦法什麼都做對，這種前提下就不指望我們一開始做的是最正確的決定，我們先基於現有的信息先做靠譜的決定，然後往前走兩步，走兩步以後，這個時候有新的信息進來，我再基於新的信息做更加靠譜的決定，再往前走兩一步。這樣不斷往前走，新的信息不斷進來，不斷修正方向，反而更好，更快達到我們的目標，這個是敏捷應對不確定性的方式。
打破確定性思維
平時我們怎麼把洗澡水調到合適的溫度？水頭沒有刻度，我沒有辦法去調，怎麼辦？難道就沒有辦法洗澡，我們就試，我們先擰開再說，要不斷的調整，不了多久就調到合適的溫度這就是所謂經驗式的過程，敏捷應對不確定性的方式。
我們必須打破不確定性思維，我們希望從確定性思維向右邊轉變。這個過程當中，很多團隊不敢輕易嘗試，因為失敗了就要背鍋，這種環境是不可能有什麼創新動力在，我們必須轉變以最小成本快速試錯。
關鍵在於，不確定性環境下要試錯，但是要想成功有兩個關鍵詞兒，第一是最小成本，第二是快速，這兩個缺一不可。
①-所以我們需要從不願意輕易嘗試，極力避免失敗，轉變為以最小成本快速試錯。
②-追求大而詳盡的計劃轉變為迭代式小規模計劃。
大而詳盡計劃沒有意義，沒有過不了多久情況變得不一樣，你原來想跑的東西沒有辦法試用。
③-追求完整、詳細的需求文檔轉變為需求漸進明晰，切分小粒度。
在這個過程中，你花大量時間到寫需求文檔，很多時間都浪費掉了。我們期望方式是需求漸進明細，遠的需求按照優先級來排好，很快馬上要做的需求，最近一兩週做的需求把它仔細細化可以開始開發，更加遠的需求允許一定程度的模糊性或者是粗粒度，這樣更加容易應對變化。
④-對範圍、時間、質量毫無差別的堅守轉變為堅守時間、質量、範圍可協商。
舉個例子：
老闆把你叫到辦公室跟你說，這些需求某一天全都要，保質保量。這個意味著範圍、時間、質量全部限死了，你在這個過程沒有什麼調整餘地，這些需求在那個時間點要保質保量全部上，實際當中我們發現在不確定環境下，這個其實相當難做到，大家都會硬頭皮做。這個時候問開發能不能實現，開發說壓力太大了，但是不行，老闆要，你必須做到，996、247你隨便選。
開發同學面臨這種狀況會怎麼選，可見都弄上去，你要的功能，要的界面這些都弄上，但是不好見的地方不好意思要做很多的妥協，各種臨時的解決方案都在裡面了，代碼看上去一團糟，接手的時候很難在這個基礎做開發。因為你已經把時間卡在那兒了，我們真的要這樣嗎？
我們回過來看一下：時間、質量、範圍。
時間能不能妥協？通常不能妥協。因為畢竟很多東西是要時效性，比如說雙十一活動和6.18活動，時間不妥協。
質量能不能妥協？質量當然不能妥協了。這個是我們的責任，我們有責任有義務保證質量把我們的產品功能奉獻給客戶，服務奉獻給客戶。
我們的範圍能不能妥協？實際上是可以的。我們再把老闆交過來一大包需求拿過來，仔細切小看看，你會發現他們優先級度是不一樣，有些東西可以往後放一放，這個時候會發現很多協調、討價還價的餘地。
也就是說範圍應該可以接受，這個是天然決定，你要切開小粒度，必須切下，切開，然後再說這個重要，還是那個重要，這個先做，那個先做，這個時候才有討論餘地。
⑤—精確的進度把控及對任何便利的追究，到接受意外變化並以最小的代價快響應。
“構建-衡量-學習”循環
在精益創業裡面，所有構建、衡量、學習就是來自於精益創業，一開始有想法，然後快速形成開發，形成上線，然後可以收集到用戶的反饋，基於用戶的反饋，用戶的數據分析出來得到和驗證我們的路子，這個路子是不是走的通，是不是用戶需要，然後形成新的想法再進一步實現，這個過程就是“構建—衡量—學習”我們以快速試錯成本的一個方法。
探索創新方式的學習循環
產品方向搞清楚了，我們在後面需要持續推動產品的增長，我們在局部不斷做這種優化，所以後面優化的思路完全是一樣，它來自於增長黑客的思路。
可以在團隊成立專門增長團隊，有了新的想法開始排優先級，覺得靠譜就趕快做出來，上線驗證。我們只做驗證我們想法需求最小集，只要驗證我們的想法，甚至不開發都可以，很多時候不開發，做一個假的界面，背後是人工在弄，就沒有開發現成的系統，只要驗證我們的想法就足夠了。快速評估、學習裡面的驗證思路，然後形成新的想法。
未完，下期繼續
to be continue.....