當英雄,不是老闆的工作

圖片出處:We Are Marshall
想經營團隊,就要把個別英雄拿掉,注重整個系統的產出。
做 startup ,你不能當蝙蝠俠,你要學會當球隊教練。

這篇是幫 cheers 雜誌寫的,記錄了我跟某位矽谷經年新創公司老將的對話,原文出處在這裡,想轉貼請找 cheers 雜誌喔!

另外,我先前也寫過些團隊方法論相關的文章,羅列如下:

1. 手快一定打手慢,唯快不破的合作方法(上):Scrum 異于常人的基本假設
2. 手快一定打手慢,唯快不破的合作方法(中):Scrum 加速的方式,出招與變招
3. 手快一定打手慢,唯快不破的合作方法(下):如何用 Scrum 把妹 😉
4. 群眾募思 – 讓所有員工幫你想下一步的方式

多話了 XD,以下正文開始。

愛當英雄的老闆

JB是矽谷經年的VP Engineering (工程副總),帶領經歷過幾間大大小小的新創公司成功出場,經驗豐富,成果豐碩,不要看他這樣大忙人樣,他每天傍晚到十點固定把時間留給家人,是個工作與家庭並重的傢伙,「這樣才能長久啊~」他說。

幾次晃過他公司樓下,他都因為開會沒有辦法溜出來喝杯啤酒,今天好不容以逮著他,我們就坐在舊金山Soma區,2nd與Howard St.附近的Eddies酒館小酌。

最近怎樣,他問。

「忙啊,跟以前一樣,開發產品兼救火,新創公司不都這樣?」

怎麼感覺你們那邊一直在救火,緊急事件很常發生嗎?他皺了皺眉頭。

「是吧,因為產品開發趕快,交貨在即,有時候就會有緊急事件,這時候就要去修。」

看你的表情,好像團隊很享受這個過程是嗎?他笑笑。

「恩,只要最後有平安解決事件,那種炙烈的討論與 group hacking 很刺激,團隊的士氣高漲,合作無間,讓大家感情很好!」我把手張開,奮力解釋。

了解,那應該也有一兩個很強的工程師出盡風頭吧?老闆也是其中之一?

「是啊,那種解出來後,被當作英雄的感覺很爽 XD,不過最強的還是我老闆,他深知整體系統的運作,出將入相,每次都能夠及時找出問題點,對症下藥!」

這種英雄式的團隊看起來很風光,但是其實很容易累死三軍。你們用的 Scrum 架構是借鏡於二次世界大戰後最優秀的管理理論發展出來的東西,怎麼聽起來你們只學到皮跟骨,一點都沒有用到精髓?

「噎?我覺得我們執行得還不錯啊」這次換我皺眉頭了。

這樣啊?那你們每次產品都可以趕上交貨日期嗎?

「應該算有,每次交貨日前團隊要衝刺熬夜一下,但是大概都有趕上。」

真的嗎?一開始應該還好,但是漸漸慢下來了吧?你們真的很想兩個禮拜就熬一次夜嗎?

我為之語塞,所有新創團隊不都是這樣用肝與時間換出來的嗎?為什麼他好像覺得這樣經營團隊的方式很蠢?

要知道問題點,你必須要先學會工作的本質,分類,還有為什麼會有緊急事件。到我公司裡面來,我們需要一塊白版,他說。

唯有從頭到尾完成的工作,才有價值

走進他們磚牆圍繞的辦公室,他從冰箱中拿出兩罐啤酒,遞給我一罐,示意要我走進那有塊大白板的會議室等他,坐定後,他自顧自拿著筆在白板上口沫橫飛起來。

工作是一個生產價值的過程,他的概念跟工廠其實很像,原料從一邊進去,經過生產與加工,有價值的成品從另一邊出來,你有工作,組織有產出,皆大歡喜。

跟工廠有不同生產線,生產不同產品一樣,每個人的工作都有分不同種類,各自生產不同的價值,以你最熟的工程師工作而言吧,大概可以分為以下幾種工作:

1.產品功能開發工作 – 開發產品新功能
2.Bug 的修復工作 – 修復產品問題
3.業務營運工作 – 維持公司產品營運
4.救火大隊工作 – 產品營運出問題,搶救的工作

知道你的工作分為幾種,你就可以視覺化每種工作,畫出你每種工作的價值流程圖,來,你上白板來畫出你們第一項產品開發的所有步驟流程吧。

我接過筆,在白板上畫出幾個方格與箭頭:

設計功能 -> 架構討論 -> 功能開發 -> Code Review -> 測試 -> 部署上線 -> 功能營運

你覺得對公司而言,你功能做到哪個步驟才會產生價值?

「應該是上線營運後才能真正發揮效果吧?」我說。

沒錯,在製造業中,有個概念叫做「半完成品」,英文叫做 Work In Process,或是直接叫 WIP,簡單來說,就是製造到一半的東西,這種半完成品卡在中間,不能當原料或完成品賣出,一點價值也沒有,是製造業的死敵。你雖然在知識經濟下工作,概念是完全一樣的,唯有從頭到尾跑完的工作才有價值,其他都是 WIP ,堆再多都一點用也沒有。

窮忙、瞎忙、當英雄,不是主管的工作

現在你有4項工作分類:「產品功能開發工作」,「Bug 的修復工作」,「業務營運工作」與「救火大隊工作」,前3項工作聽起來都很合理,也都可以分別畫出其價值流程圖,執行完畢後,也都能夠創造價值,但是你想想,第四項「救火大隊工作」完成後,有為整個系統帶來任何價值嗎?

「系統就能夠正常運作了」我搔搔頭。

再回答我一個問題,緊急事件發生時,其他工作的排程怎樣?

「當然全部延後啊,救火優先。火救完了,進度再用力趕回來就是了」我一付理所當然地嘴臉說。

沒錯,救火工作不會為組織產生任何新價值,不僅如此,還讓其他工作能產生的價值延後,整體效能降低,最可怕的是,他通常還沒有辦法預測,你有可能整個月都在救火,組織價值的進度就會落後整整一個月。

然後救火的英雄模式結束後,整個組織為了趕原來的進度就進入了加班模式,加班模式完成的品質會比正常模式差很多,也會為未來埋下很多緊急事件的地雷,就形成了惡性循環,不斷加班,不斷趕進度,不斷窮忙,不斷瞎忙而不自知。

英雄模式的確會讓團隊的英雄們看起來很風光,很努力,很屌,但是英雄會累,團隊會累,一天工作 12 小時,絕對不是任何公司組織的長久之計。

「有出路嗎?」我睜大眼睛。

身為主管,你的工作跟工廠廠長一樣,要確定每條價值的生產線都正常運作無礙,還要確定你們產出的同時,在不影響效率的情況下減少未來的緊急事件。不是跟你一起下去救火,當英雄。

你要在緊急事件發生前就解決他們,方法就藏在你之前畫出來的價值流程圖中。既然知識經濟也是條條的生產線,我們就可以借鏡製造業品管的方式,管控最容易發生問題的流程,以你上列「產品功能開發工作」的價值流程來說吧,這麼多的意外事件,首先要檢查的是Code Review與測試這兩個步驟的執行有沒有問題,需要的話,要進行 Code Review check list 的定義與訓練,全自動化測試的流程,機器能做的,就不要讓人去做,人類絕對不會有機器精準。

在問題的源頭解決問題成本最小,不然你覺得Toyota為什麼給工人看到問題就停掉整條產品線的權限?難不成要等到整批問題產品都做出來了才在後面敲敲打打補救嗎?

「但是這樣步驟成本會變高,會慢下來啊!Startup不是要Move fast and break things嗎?」我翻出Facebook的座右銘挑戰他。

你要注重的是整個系統的速度,而不是單一步驟或是單一員工的速度,以整個系統而言,如果不是在瓶頸上改善,根本快不起來,能創造實質價值的產出也不可能會增加。

「瓶頸?」我問。

在瓶頸上的改善才是改善,其餘都是浪費時間

工廠就像是一個大沙漏,原料從沙漏的上面留下來,經過各個工作站,在沙漏的另一邊成為可以賣的完成品。

很久以前,在Theory of constraints(限制理論)或是Lean manufacturing(精實生產)這些慨念出來之前,工廠中的每個工作站為了表現,都盡全力發揮每個工作站的產能,製造出大量的 WIP,用力把這些 WIP 推往下一個工作站中。但問題來了,每個工作站的速度是不一樣的啊!這些大量產出的 WIP ,就堆在速度慢工作站的前面動彈不得。

這個速度最慢的工作站就是所謂的「Constraint(限制)」或是「Bottleneck(瓶頸)」,就像沙漏中最細的部分一樣,它完全決定你的整體產出。

任何在瓶頸以前的產出改善都只會讓WIP堆積如山,同樣的,任何在瓶頸後的效率改善都完全沒有辦法增加產出,因為瓶頸硬生生地卡在那邊。

圖片出處

只有針對瓶頸產出的改善可以讓整個工廠快起來!聽起來很直觀,有點白癡,但是在這些理論出來之前,根本沒有人注意到,每個工廠的員工都在窮忙,看起來工廠生氣蓬勃,存貨滿地,但是卻怎麼也快不起來,交不了貨,賺不了錢。

「具體怎麼做呢?」我問。

你列出「業務營運工作」這項的工作流程試試。

客服團隊交託客戶需求 -> 系統自動化處理客戶資料 -> 工程師手動確認資料與報表完整 -> 交還客服團隊確認 -> 移交給客戶

你們都卡在哪裡呢?

「工程師手動確認資料與報表完整這邊」

那你覺得「系統自動化處理客戶資料」這邊多給你幾台超級電腦,或是多給你 10 位客服人員,讓你「交還客服團隊確認」速度加倍,對整體產出有幫助嗎?

「當然沒有。」

是啊,這時候,不管客服多用心經營,電腦速度多快,或是客戶需求大增,都完全沒有效果,工作只會堆積如山,公司也不會賺更多錢。

「看起來理所當然啊,大家應該都懂吧。」

是的,但是這時候上面來一條命令,要每個部門提高效率,你看看客服部門會不會半夜打電話叫工程師死命地做下去?這些客服就連哄帶騙地帶工程師去吃飯,幫他們買飲料,罩的工程師會成為客服的英雄,資深工程師也會因為忙於做事沒有辦法訓練新來的工程師,客服v.s.工程師的黑市就漸漸形成了。

「但是整體產出還是不會變好」

沒錯,但是成本增加了,工時增加了,溝通成本跟管理成本都增加了。解決你「工程師手動確認資料與報表完整」的最好方式是把人工的部分拿掉,不管是直接寫進你的產品中,或是讓營運工程師寫程式來後製,不計一切地在瓶頸處加速,整體產出才會增加,公司才會賺錢。

「拎老師!我老闆是白癡,不會帶。」

你在跟我聊之前不也是白癡嗎?想經營團隊,就要把個別英雄拿掉,注重整個系統的產出。做 startup ,你不能當蝙蝠俠,你要學會當球隊教練。

他拍拍我的肩,你以爲矽谷這些千萬人團隊怎麼打造出來的?不是只有駭客松跟創業活動,生態圈內所累積的資本,技術,跟方法論才是精髓。

慢慢來,人生很長,但是矽谷就這麼大而已,他說。

我離開前,他推薦了幾本相關的書,分別是:

1. 2013 年出版,目前沒有中文版的 The Phoenix Project – by Gene Kim, Kevin Behr, George Spafford
2. 30 年歷久不衰,中文名叫目標:簡單有效的常識管理 The Goal: A Process of Ongoing Improvement – Eliyahu M. Goldratt

——————————————————————————————————–
如果喜歡我的文章,非常歡迎你填入您的 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. */

訂閱 Winston Chen – 台灣工程師的矽谷故事

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

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s