內容來源：DevOps案例深度研究-Google敏捷實踐戰隊，本文只展示部分PPT及研究成果，更多細節請關注案例分享會。

本文內容貢獻者：陳霽、劉翀、談佳婧、張霖。

閱讀干貨前先感受一下熱烈的氛圍~

一、Google如何快速交付原型

1.1 Savioke公司實例

Savioke（公司真實存在，但公司名為化名）是一家剛創立6個月的公司。公司創立之初，大家都會思考一個問題：我們要做什么？他們的答案是：做智能機器人，并且致力于把機器人帶到人類的日常生活中，如餐廳、醫院和老人護理中心。

Savioke明確了目標并且通過這個目標獲得了一筆融資，而公司要想存活并發展，需要準確判斷和把握商機。產品已確定是機器人，那么要通過什么樣的機會將這一產品推向市場呢？

他們發現在所有的酒店中存在這樣的現狀：在早上和晚上的高峰期，客人辦理入住、退房、客房服務等各種需求會讓前臺人員焦頭爛額，而這些需求和操作都是高頻且重復的，這部分工作完全可以由機器人來代替，這就是機器人提供協助的絕佳機會。于是Savioke和百家連鎖酒店達成實驗協議，在這些協議酒店中引入機器人來解決上述痛點。

實施過程存在哪些困難呢？從我們自身出發，肯定首先想到的就是技術實現上的問題：怎么讓機器人知道是哪個房間？機器人怎么才能通過電梯去到客人的房間為客人送東西？等等。

但團隊發現其實更大的困難來源于場景：擔心客戶可能不喜歡遞送機器人，也不確定機器人在客戶面前會如何表現，畢竟機器人不可能表現得完全像真人一樣，那客戶會不會覺得機器人來提供服務這件事很詭異？比如下圖右側的圖片來自一個電影《機械姬》看上去確實有些違和。

困難客觀存在，實驗的時間又非常短，只有三周，對于Savioke來說，這是用設計沖刺的好時機。最終結果如下圖。

1.2 5天設計沖刺實例

設計沖刺-Savioke公司實例

還是以Savioke為例，詳細拆解設計沖刺的過程。在機器人從實驗到正式推向市場的三周中，最核心的只有五天，這五天就是在做設計沖刺，其中80%的時間在“設計”，技術實現只用了一天，剩下兩周是原型優化和迭代升級。?

1）第一天，列出問題。

這個過程中的很多做法跟我們現在所說的用戶故事地圖很像，第一件事都是頭腦風暴，把所有東西羅列出來。區別在于設計沖刺更專注于how級別的問題，而我們平時過早地把how轉化成what具體的問題了。

第一天的問題羅列決定接下來所要做的范圍。所以Savioke做了一件事，它選定了一個很常見的客戶需求：酒店客人忘記帶牙刷。圍繞這一需求來進行功能設計，這就是所謂的MVP(最小可行性產品)的理念。

要完成機器人為客戶遞送牙刷這一服務，這一過程中包含的角色有四種：客人、酒店前臺、機器人、其他相關人員。上圖右側是Savioke的機器人遞送地圖，詳細展示了整個交付路徑。

2）第二天，找出解決方案。

第一天把問題羅列好并確定下來之后，第二天就需要找出關鍵點，和對應的解決方案。羅列的問題和事情有很多，但不是所有的都要解決，不能給機器人設置過多的功能，而應該讓它專注在某一個核心功能點上，解決關鍵需求。

3）第三天，找出最佳方案。

每個人都依據“閃電演講”的方法對自己做出的場景規劃進行闡述，比如機器人看到客人時是說“Hello”還是“Bonjour”（法語“你好”），是不是需要考慮面對不同客人說不同的話？

通過閃電演講一共收集了23個方案，用HMW投票和結構化討論的方式選出最佳方案，即上圖右側所示。

4）第四天，制作測試原型。

三天過去了，似乎一點落地的東西都沒有，第四天開始制作測試原型。聽起來似乎有些不可思議，三天做計劃一天做出原型，但仔細想想是可能的，因為前面已經明確了要做的事情，Savioke就是一個成功的案例。

5）第五天，執行測試。

原型做出來后，第五天執行測試。這個測試不是把機器人直接放到酒店中心，隨機服務客戶，而是提前選擇用戶，并征得用戶同意，與客戶溝通好后，再由機器人執行給客戶送牙刷的工作。機器人到門口后會先敲門，客戶打開門后看到一個很可愛的閃光的圓柱體（機器人）。

上述就是Savioke五天設計沖刺的全過程，有幾點值得注意：

• 我認為它是一個比較典型的業務驅動的過程，需要在短時間內交付產品，并且強調花一天的時間去驗證。?

• 強調前面的設計過程，技術實現只用了一天時間，當然這取決于團隊的技術基礎，這也是后文將重點介紹的Google文化，業務敏捷和技術敏捷整合在一起，實現了Google敏捷化。

設計沖刺-實施準備

接下來我們通過幾張幻燈片來看這五天設計沖刺的細節。

1.3 Google最佳實踐總結-設計沖刺

這是一種用一周時間，把領導、開發者、相關專業專家聚集起來，從找問題到做出方案、制作原型，并通過用戶測試的快速驗證想法和試錯的方式，設計沖刺非常適合用于業務初期，利用很短時間快速試錯，驗證方案的商業可行性。

適合的項目和成功案例如圖所示。

1.4 設計沖刺帶來的啟示

對于我們這些并非創業公司的SM或者PM們，從上述案例中能學到什么呢？?

實際上我們現在實行的CI/CD只是一個技術上的交付，并沒有直接觸達用戶，敏捷的開發方式幫助我們快速實現價值交付的內環道，demo發布上線，還需要引入用戶進行線上的灰度和體驗。

用足以以假亂真的原型去替代我們以前做的內容，它會帶來意想不到的效果。如果能夠盡早做到真實性，且發起測試是在一個可控范圍，得到的反饋效果會變得及時且有效。

在實施過程中，如果不能有效模擬出最終想要的效果，可以通過技術手段去規避和調整。

1.5 構成敏捷核心基礎

Google具備兩個特點：

• 業務敏捷性，強調在初期使用五天設計沖刺的方法快速完成原型制作和與用戶的溝通。?

• 技術敏捷性，能夠支撐一天制作出原型、兩周把所有事情落地。

二、Google的核心文化

技術和業務是不可分離的，技術敏捷和業務敏捷共同構成了整個敏捷的核心。那么支撐整個敏捷核心的關鍵是什么？答案是文化。

2.1 選拔

在Google只招聘最優秀的人才。當然我們都知道要招優秀的人加入，但什么是最優秀的人才？Google如何招聘最優秀的人才？

2.2 使命

優秀的人才有了，如何讓他們發揮最大的潛力呢？為工作賦予使命。

“地球上最有才華的人才需要能夠激勵人心的抱負?！蓖ㄟ^賦予工作意義，更能激發和調動員工的潛力。

2.3 授權

人人平等和足夠的授權，才能讓員工有足夠的發揮空間。只有公司基于員工充分的授權和信任，才能取得業績提升。問題是如何讓授權不僅僅是一個口號？

當管理者被限制起來以后，員工才能真正的被授權，做到員工自治。

2.4 培訓

如何有效提升員工能力？

看數字很樂觀，實際上，結果卻是大部分的培訓沒有達到一個良好的預期，員工的行為并沒有改變。為什么大部分企業做培訓投入大回報少？

Google是怎么做培訓的呢？在Google，培訓是一種強目的性的活動。

2.5 激勵

Google是如何激勵員工的呢？在Google薪酬是不公平的，兩個相同崗位的人員獎勵卻又百倍之差的情況。

2.6 績效

Google如何評價員工？

評價員工最直接的方法就是通過績效，當一個員工績效不好的時候，如何對待他？傳統公司的做法是：績效糟糕要么走人要么好好干。Google是怎么做的呢？

2.7 Google的敏捷文化

Google的敏捷文化可以用16個字總結：以人為本、開放透明、互幫互助、有效激勵。

三、Google如何構建團隊

介紹了設計沖刺的實例和Google的敏捷文化，接下來簡單介紹Google的團隊結構。

3.1Google的 團隊角色

我們較熟悉的Google三類角色：

值得注意的是：中間SET（也就是大家所說的測開）的角色已經不存在，這部分的工作主要是提供給軟件開發工程師相關的自動化腳本測試支持等，現在大公司的一般做法是把測開重新調到工程效能團隊，逐漸降低測開人員比重，提供平臺承擔相應工作。

3.2 Google的軟件版本及發布規則

案例研究者介紹：

總結

以上是生活随笔為你收集整理的DevOps案例研究：知人善任——Google敏捷核心文化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。