月份: 二月 2015

All Blacks Hakka, 圖片出處

絕對不只有軟體工程能用！

儘管身為陳氏太極拳大師，我的拳頭師傅曾經不下 10 次跟堂下的徒弟們耳提面命說：『手快一定打手慢，沒有其他的可能』，這也是為什麼矽谷新創公司不止在產品開發上，而是在整個公司的治理上，都是使用 Scrum，因為他唯快不破。

在軟體工程界，Scrum 是個被講爛的議題，這個 Jeff Sutherland 在 20 幾年前整理出來的方法論，早已被全世界的軟體工程圈奉為圭臬，在矽谷，99.99 % 的工程師沒有聽過 CMMI（政府蓋過很多章的軟工方法論） ，但是連 100% 的 PM 絕對都可以跟你來上兩句 Scrum。

很可惜的，在矽谷以外的地方， Scrum 還是一門僅限於軟體工程的方法論，當那些宅宅工程師每天早上在會議室站上那 15 分鐘的同時，外人看起來只是例行的早餐匯報，毫無特別之處。

Scrum 真的不是只有軟體工程適用，跟 Daming 在 2 次世界大戰後所提出的 PDCA 與一樣，它其實是則以『航向未知』為前提下所設計出來的合作哲學，在美國，除了矽谷新創公司治理中使用以外，媒體公司 NPR New 用來驅動當時駐點報導 2011 年埃及革命的團隊，在跟美國華盛頓的通訊品質都不穩，全城動亂的情況下，還能一天兩次，次次傳回後來得到新聞大獎的報導。

Scrum 跟甘特圖一樣，是種團隊合作的方法論，唯一的不同之處在於，它並不自欺欺人地提倡高不可及的工作品質，反之，它在設計之初，就融入了人們工作時的不完美，用系統與團
隊的方式，把不完美的影響降到最低，把團隊最有效率的那面對準問題，強力進攻。

你還在用你阿公用的甘特圖嗎？

傳統的專案管理是以甘特圖（或是 Waterfall 專案管理理論）為基礎的，這個一次世界大戰時所發展的工具，在近 100 年後的今天仍然是所有專案管理師的壓箱法寶，甘特圖的道理其實很簡單，在專案開始前，先在沙盤推演整個專案進行過程與方式，時程，資源，與預算，把規劃出來的完美願景與執行順序一點一點畫在圖表中，然後再照著這個完美的規劃執行，一步步照表操課，完成專案。

如果專案小，時程短的話還沒有什麼關係，除非明天世界末日，計劃的跟執行的應該差不了多少。

問題是，如果專案時程拉長，或是執行過程有新加進來的變數，失之毫釐，結果常常謬以千里。

這就像是孩子剛出生，你就在幫他規劃成長中每一步的教育細節，一定要上這間小學中學的這些明星班級，要加強某某課外運動，學豎琴，學西班牙語，要對某某學科有興趣，大學要就讀公館大學的資訊工程學系，研究所申請柏克萊，畢業後馬上到 Facebook 上班，這時候他可以開始交男女朋友，對象不是公務員就應該在知名企業上班，在 28 歲生日前求婚/被求婚，29 歲左右養育出優質的下一代，一男一女 … 等。

聽起來很荒謬，但是傳統的甘特圖計劃就是這樣運行的。

如果 Facebook 在 20 年後不存在了怎麼辦？如果孩子喜歡同性怎麼辦（順道一提，我大力支持多元成家）？如果他數學很爛，但是有跟李安一樣的才能怎麼辦？如果哪天台灣亡國了怎麼辦（很有可能 XD）？

屆時，你要不是自欺欺人，繼續畫著原來的甘特圖，跟上級（祖先燒香）報告一切正常，瞞多久算多久，不然就是整個爆掉，歇斯底里？發狂之餘頹坐在地，根本不知道接下來怎麼辦？

反之，Scrum 的設計概念把這些執行中的不完美全都收納了進來，一開始就假設會出錯，當然執行的時候，就會有容錯的空間，與後續自我修正的方法。

團隊為重，一個好團隊，可以擋兩千個爛團隊

人類的自然邏輯是有很多盲點的，我們天真地認為，找到最強團隊的方法來自於找到最強的個人，也就是說，如果我把所有強者都囊括到我的團隊中，我的團隊就所向無敵了？

根據好書 SCRUM：用一半的時間做兩倍的事 （好書，大力推薦） 中所提到的科學研究，強者跟弱者的能力差異大概是 10 比 1 ，也就是強者能夠強弱者 10 倍，但是 A Team 的爛 Team 的差異卻可以達到 2000 比 1：

“A lot of managers don’t understand that the difference in the best performers and the worst performers as individuals is 1 to 10. But if you look at the difference between the best teams and the worst teams it’s 1 to 2,000. So the team effect is two orders of magnitude bigger than the individual effect."

一個好團隊，可以擋兩千個爛團隊！

一個好團隊，可以擋兩千個爛團隊！

一個好團隊，可以擋兩千個爛團隊！

因為很重要，所以要說三次。

換個角度來說，你花盡心力，上山下海，囊括所有強者到團隊中，頂多讓團隊強 10 倍。

但是，如果你有辦法讓原團隊從爛隊晉級到普通團隊，你所得到的效率可能已經是原來的好幾百倍了。

身為管理者，哪一個方法划算？

書中有提到， GM 早期在加州 Fremont 有個效率很差的車場，聽說工人們都很爛，很懶惰，又沒有紀律，所以後來 Toyota 把車場買過去的時候，GM 跟 Toyota 建議把所有工人換掉，但保留管理階級，因為管理階級在 GM 的眼中其實效率不錯。

Toyota 接手後，立刻把所謂的管理階級裁掉，反而留下當初那些很爛，很懶，沒有紀律的所有工人，換了做法，換了管理團隊後的車場，忽然間脫胎換骨，表現地跟其他 Toyota 的高品質車場一樣，狠狠打了 GM 管理階層那張自以為是的臉。

當團隊有問題，有問題的一定是老闆 XD ！

因此 Scrum 不強調個人，強調團隊，只要忽略掉個人的產出，團隊中的所有個人才能夠以團隊為考量，互相幫助地付出，而不是互相扯後腿，保障自己在團隊中的地位。

Scrum 在衡量表現的時候，不會有個人表現這個選項。

長時間加班是很蠢的事情

長期加班其實是很蠢的事情，除了上列提到的那本書中提到了他那麥肯錫顧問朋友的小實驗證實，一周工作約 40 小時左右所完成的工作質跟量都最好以外，網路上還可以找到各行各業的實驗證據，比如說下圖：

圖片出處：遊戲工程師的部落格

這位遊戲工程師就發現，他第一個禮拜能在約工作 60 小時的時候展現出最強的生產力，但是隨著時間拉長，生產力最佳的時數慢慢縮到了每週 40 小時，跟書中的數字如出一撤。

也就是說，長時間工作除了自我感覺良好，自以為是英雄以外，實質上對工作本身是不好的，你完成的東西會更少，品質會更差，只剩下每天早上拖著疲累的身軀，在老闆面前買乖時的籌碼，家庭跟其他社交生活就全部都葬送了。

長時間加班會讓你出錯的機率變高，你之後還要花更多成本去彌補之前加班所搞出來的爛攤子。

既然長時間加班這件事情很蠢，Scrum 基於效率原則，當然極力反對。

ok ，Scrum 異于常人的基本假設解釋完了，下篇，我們來聊聊為何能夠達成唯快不破的神功，請拭目以待。

ps，Scrum 非常強調士氣與節奏，激勵士氣的方式借法于紐西蘭橄欖球隊 All Blacks 在每場賽前的 Hakka 戰舞，看過以後，我很慶幸我自己不是敵隊 XD

延伸閱讀，續集：
手快一定打手慢，唯快不破的合作方法（中）：Scrum 加速的方式，出招與變招

——————————————————————————————————–
如果喜歡我的文章，非常歡迎你填入您的 Email 信箱，訂閱 Winston Chen，
或是直接關注我的 Facebook 粉絲團。
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

也非常歡迎你來信跟我討論，謝謝。