當英雄,不是老闆的工作

9/14/2015 11:49:00 PM 0 Comments

圖片出處: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 粉絲團


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

Winston

陳昭穎 Winston Chen - 『砍掉重練:30歲開始也不遲的工作術 』的作者

中央大學資工系,從小到大從沒念過第一志願,沒念過研究所,出社會前想拿個國外的 MBA 回台灣爽爽過,但是沒錢出國,只好出賣靈魂當工程師存錢,怎知當上工程師後就愛上寫程式,回不去了!心想在未來墓碑上一定要刻上身為工程師的事實。

因為嚮往科技勝地矽谷的陽光與空氣,出社會五年後花光所有積蓄,跟老婆一起遠渡重洋,到矽谷尋找突破的機會。