培訓一開始，我把3天的範圍、敏捷的主要概念講完後，立即在白板左右兩面寫上一些資料，讓學員猜它們分別是美國西岸哪兩家科網公司？

 
他們立即猜到左面是 YAHOO! ， 右面是Google 。

 
接下來我便依據Eric Schmidt ， Jonathan Rosenberg 編著的《How Google Works》一 書中的一些例項，講述了Google  公司的文化管理思路、溝通、創新等， 來說明敏捷的原則，以及公司如何實際使用。

2002年，Eric剛加入Google 不久，董事會的Mike 就發郵件提醒他要準備應對微軟的策略 （微軟會對有威脅的新公司極力打擊），Eric便向Larry page（Google的創始人之一）提一個對應計劃。這計劃是傳統教科書思維模式的典範，包含了步驟、稽核、優先次序，兩年內推出產品種類和上市日期。

Larry問他這種計劃有什麼用：你見過哪個團隊的表現能超越既定目標？你的團隊研發過比計劃中更出色的產品嗎？

Eric都回答沒有。
Larry說：如果是這樣，計劃還有什麼意義？
 最後Larry說一定還有比計劃更有效的方式，於是讓他們去和工程師談談。
他們便發現Google公司的工程師都是既有技術能力，也很有商業頭腦的創意精英，不需要用硬性的計劃來推動。計劃反而會妨礙他們的創意。
這故事讓學員知道要敏捷必須具備一些基本條件：敏捷不是一個萬應萬靈的魔術棒，不是照著去做便會敏捷成功。
另一方面 YAHOO 上市後 便有了各樣的 “大公司”病 —— 官僚化的管理，導致最終被收購。
講故事是最有效的培訓方式, 對此學員很有共鳴。
比如在Google的一些內部討論中，做決定不只是依據提出者的公司地位、權力， 一些由高管提出的意見不足同樣可以被工程師推翻 ，Google叫這些橫行的管理者為河馬(Hippo) ， 下午做活動練習時 不少組員 常常提到自己公司確實有不少河馬在橫行。

1「培訓後發現」

做完培訓後，我發現很多敏捷精益的概念，不僅可用於軟體開發 ，其他方面同樣適用，例如培訓。
在敏捷中，我們強調只做有用的檔案紀錄，不要浪費資源。強調計劃每一次2周衝刺(Sprint) 時 ，必須完成相關的故事點(Story Point)，就是說每一次衝刺 ，已通過測試 ，如果留了尾巴（軟體不是已通過所有測試 ）， 下次需要花更多時候把上次的遺留做好。與精益中減少廢物的道理一致。這些道理不只識用於軟體開發。 例如，不要同時間有好幾件事 ，導致每件事都做不完。 比如你很忙，只有3小時時間完成任務，便必須選一些優先順序高但可以3小時內完成的事來完成才會避免返工。
每次衝刺後， 要做回顧或覆盤(Retrospective) ，討論經驗教訓與可改進的地方。
我上一次做完同一個敏捷培訓後，因要忙其他的事情， 沒有實時總結材料，變成一套可複用的資料，導致這次培訓要想很久 才把三天的材料整理出來 ，最後令學生覺得整套教材次序比較亂，難以參考。

導致學員反饋： 雖然整體效果很好，但對教材有意見，覺得比較混亂，不容易查詢。
該如何改善？我回顧發現：傳統教材有其侷限，因為現在很多培訓的內容是沒有一定的關聯性，無法將其像傳統教材那樣有序列出，也許用超連結的方式更適合。

針對這難題，我便想到How Google Works書中提到三大科技潮流：
1.    網際網路讓資訊免費 ， 源源不斷無處不在
2.    移動裝置與網路
3.    雲端計算
大部分的創新都會用上這些潮流科技。

以前我提過的維基百科，它解決了傳統百科全書難以更新的的難題。
如今的 教材也應好好利用網際網路和微機技術，方便學生查詢也有利於資料的實時更新 。

所以吸收這次經驗教訓後，我立即把量化管理 相關的教材、案例等放進維基伺服器，準備後面使用 。

2「敏捷故事」

剛剛與一位香港 17歲已經去美國讀書的資深IT 管理人員談起敏捷 與 Google 。我們會問：
為什麼在大陸很少見到像Google這類公司？
大環境有一定的影響。
他認為大陸需要好一段時候 才會有類似美國西岸矽谷的生態環境 ， 在西岸史丹福的大學有不少學生中途輟學 追求理想， 因本身不會為基本生活擔心 ( 例如：Bill Gate)，但他從未聽過 清華大學生中途輟學 。
 員工 必須在不用擔心 基本生活的情況下 ，才敢為自己的理想暢所欲言，這有一定的道理。
另外一個例子，上面提過，Google強調所有資訊每一個員工都可以隨意獲取。
我剛在大陸另一場培訓提到這點，一位學員便說： 其實谷歌每年都因此起訴不少違規洩露公司資訊的員工。
所以雖然公司資訊透明有風險，但相對而言，這政策是利多於弊的。
但大陸因為沒有相關的法律保障，所以老闆為了保護公司的資產，便不敢讓每個員工都可以獲取任何公司的資訊，怕可能有一天整個團隊連公司重要資訊都拿走，公司也沒有辦法。

聯絡我們