斷開兩難雲霧 – 談限制理論(一)

“Common sense is not so common. (常識其實並不那麼平常)" – 伏爾泰

限制理論 – 常識的力量(不是白目的力量喔,啾咪~)

“Common sense is not so common. (常識其實並不那麼平常)" – 伏爾泰

是的,包括我在內,大部份的人都是連常識都沒有的笨蛋。因為不是聖人,智商也沒有 150 ,我們的思考常常陷入五里霧中而不自知,等到聰明人質疑我們的想法,分析我們思考的缺點,點出我們論證的問題,一切攤在陽光下之後,我們常常拍著腦袋大叫:

『這麼簡單?這些不都是常識嗎?我們怎麼沒有想到?』

比如說吧,有些黨國立場的熱衷者,會到 Facebook 網友或是網路文章上挑戰他人文化的根源,人家在說媽祖,他要凹林默娘是不是中國人,人家在講電音三太字,他說封神榜是神州文化。

謎之音:eh,天下武術出少林,達摩是印度人,啊所有中國武術不就都是印度的?這是文化的重點嗎?

又或者吧,使用掃地機器人,洗碗機,化學產品,或是自動駕駛都是人類懶惰與滅亡的象徵,我們應該要多多用手與勞力。

謎之音:okay,那麻煩請用去砍柴,用柴火煮飯,燒洗澡水。

但是這些可以用常識擊敗的思考卻很容易讓人深陷其中,爭得面紅耳赤,卻各說各話,一點進展都沒有。

我對於聰明人系統性的思考方式一直非常熱衷,我希望能夠找到一種思考方法,幫我找到爭論的核心,讓我少笨那麼一點 XDD

延續上一篇限制理論的文章,Eliyahu M. Goldratt 在 80 到 90 年代中,為了解決企業家思考問題而發展出來的限制理論是我這幾年學到過最好,最有系統性的常識思考法,這次我們介紹的,是用來解開衝突想法的『Evaporating Cloud(直譯:蒸發衝突雲)』,我想翻做『斷開兩難雲霧』 XDDDD

那個雲啊,那個霧啊,斷開鎖鏈!

Evaporating Cloud(斷開兩難雲霧)的精髓就是完全視覺化你的想法跟假設,然後詳細審視一下這兩個衝突想法所建立起來的雲霧(Cloud)中,有沒有邏輯上的問題。

一旦你可以找到兩難雲霧(Cloud)中假設上的漏洞,這個雲霧就可以被斷開,這兩個想法就不再是互斥的。

我們用個比較有熱門的例子吧,其實很多人認為(不管是行為上或是思想上)要保持台灣的主體性,就不宜多跟中國人交友,這在台灣留學生中非常常見,很多人被逼著選邊站,親中,或是台獨 XD

先決條件

先決條件:要保持台灣的主體性,就不宜多跟中國人交友。

這個兩個乍看之下互斥的想法,就是我們兩難雲霧的先決條件(prerequisites),用白話文念出來,

  • 1. 追求台灣的主體性與跟中國人當朋友是互斥的,不能並存的。

需求

接下來我們加入這些先決條件的需求(requirements):

這些『需求』,其實就是先決條件想要達成的效果,我們可以這樣念,

  • 2. 為了不被中國政府統治,我們必須強調台灣的主體性。
  • 3. 為了更好的人際關係與更健康的朋友圈,我們必須跟中國人當朋友。

目的

最後,如果我們填入兩個需求的共同目的,得到

  • 4. 為了活得自由,民主,又快樂,我們不能被中國政府統治。
  • 5. 為了活得自由,民主,又快樂,我們要有健康的人際關係與朋友圈。

沒有說出來的論證

除了論證 1 到 5 之外,既然你認為這兩個先決條件是互斥的,就代表有另外兩個隱藏論證沒有被大聲說出來(交叉兩邊的需求與先決條件),因此很多人不知道他們的存在:

  • 6. 擁有健康的人際關係與朋友圈就不能追求台灣的主體性。
  • 7. 不接受被中國政府所統治就不能跟中國人當朋友。

這 1 到 7 就是你在搔破頭,思考要當所謂『親中』人士或是『台獨』份子時,邏輯上所建立的全部論證,我們來重新排列一下:

  • i. 為了活得自由,民主,又快樂,我們不能被中國政府統治。
  • ii. 為了不被中國政府統治,我們必須強調台灣的主體性。
  • iii. 為了活得自由,民主,又快樂,我們要有健康的人際關係與朋友圈。
  • iv. 為了更好的人際關係與更健康的朋友圈,我們必須跟中國人當朋友。
  • v. 追求台灣的主體性與跟中國人當朋友是互斥的,不能並存的。
  • vi. 擁有健康的人際關係與朋友圈就不能追求台灣的主體性。
  • vii. 不接受被中國政府所統治就不能跟中國人當朋友。

大聲唸唸看這七點,有好幾點聽起來怪怪的,舉例來說,

『不接受被中國政府所統治就不能跟中國人當朋友。』

這一句話中有太多有問題的假設,邏輯上根本站不住腳,它假設每個中國人都忠黨愛國,只要有那個一丁點不同意中國政府所制定的規則,沒有任何中國人會接受你。

它又假設,中國人民自己都非常認同自己政府在搞的那一套東西,我問你,你自己認不認同台灣政府現在的所作所為?願意誓死為他們辯護?更何況他們呢?

最直接的例子,你可找到很多不同意中國政府的中國網路名人,比如說變態辣椒或是公開反對封殺蒼穹之下那群網路大神們。

//platform.twitter.com/widgets.js

斷開那個雲霧

所以你找到這個兩難雲霧假設的弱點,就是你解開這個死結的突破口,這是你的機會,如果能夠成功運用這些反例,你將可以摧估拉朽地粉碎這個兩難雲霧。

你可能會想,解開這個兩難雲霧的好處在哪裡?不就是我能多交幾個中國朋友嗎?聽起來好像沒有很厲害。

耶?看起來是這樣,但是你發現的這個假設謬誤『中國人民自己都非常認同自己政府在搞的那一套東西』威力卻是非常驚人,它提供了溝通與談判的切入點,舉個例子吧。

有天,我跟幾個新認識的中國朋友在舊金山市區的 Super Duper 吃漢堡,有個很直接的中國朋友就這個問了:

『為什麼台灣年輕人不想回歸?』

『你相信你們中國政府跟體制嗎?我連我們自己的政府都不相信了』我問。

他想了想,沒有回話。

『我們可以在總統府前指著陳水扁,馬英九的鼻子大罵,可以寫文章,寫書,演講提倡環保反貪腐,甚至罵整個國家民族,不擔心明天會被政府封殺,或是無緣無故消失,搞示威遊行也不用擔心被機關槍掃射或是坦克壓,你覺得我們為什麼會想要找個坑跳?』

『可是有一國兩制啊』他不放棄。

『Again,你相信你們中國政府跟體制嗎?』我問。

『那假設我們有了你們要的那些東西,我認為台灣屬於中國,應該要回歸』他繼續進逼。

『如果你們有了這些東西,中國政府就會尊重我們的體制,到時候由全台灣的公民公投決定,跟愛爾蘭或是加泰隆尼亞的程序一樣』我說。

話說到這邊,另一個中國朋友跳了進來,強調他們非常了解自己政府在搞些什麼玩意兒,不太能相信,就體制而言,還是你們那邊好一點。

『那你們那邊是怎麼改變體制的?』他們問。

接下來就是台灣與中國近 30 年的政治經濟歷史介紹與討論,中國人果然不等於中國政府。

這次討論以後,他們依然喜歡洪秀柱的立場,他依然相信台灣最終要回歸,而我依然在在美國人面大大方方地說我是台灣人,不是中國人,不管他們在不在場。

沒有不斷跳針的辯論,沒有面紅耳赤的爭吵,只要雙方邏輯清楚,就可以找到雙方都同意的部分,雲霧被斷開,鎖鏈被斬斷,我們依然是朋友。

當然,上列兩難雲霧的弱點絕對不只有我挑出來的那個。

“A man may die, nations may rise and fall, but an idea lives on. Ideas have endurance without death.(人們會死,國家會興盛與滅亡,但是想法卻能長存。想法的延續性,是超越生死的。)" – 約翰甘迺迪

限制理論

常識其實並不那麼平常,當我們可以視覺化兩難的先決條件,需求,與各項假設後,很容易可以找到脆弱的假設進攻,翻轉兩難,建立雙贏,這還只是限制理論中其中一種思考方法而已。

有興趣的朋友,可以參考這邊

下次我們聊聊限制理論中的另一個精髓,成本心態與產出心態吧。

——————————————————————————————————–
如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

當英雄,不是老闆的工作

圖片出處: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 – 台灣工程師的矽谷故事

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

真台灣技術團隊的矽谷出場!

Fliptop 的台北團隊,整個產品都是台北團隊出產的 XD

賀!真!台灣技術團隊的矽谷出場!

我前一間參與的矽谷新創公司 Fliptop(我目前不再該公司中),在今天被 Linkedin 買下,從今天起,整個團隊會被併進矽谷最炙手可熱的軟體公司 Linkedin 中

光以薪水而言,Linkedin 開的價格,相對於 Google 與 Facebook,是不遑多讓的。以技術而言,Linkedin 團隊的技術能力卓越,長期在 java,scala,分散式運算,大資料,Stream Processing … 等領域中推出多項 Apache 大型專案。能夠被 Linkedin 接受,工程團隊的每個人都要跟不可能的任務中的湯姆嗑滷蛋一樣屌才行。

但是你知道,這整個產品,幾乎都是台灣分公司做的嗎?

誰說台灣本土沒有做世界級的軟體公司的技術實力?

公司團隊的組成的故事

創辦人 Doug Camplejohn

話說 2009 年, 連續創業家 Doug Camplejohn (請見上圖)才剛把他前一間新創公司 Mi5 賣給賽門鐵克,手立刻就癢了,想再弄一間公司來玩玩。

無奈他身邊的所有技術人員都被大公司的併購協議鎖住,沒有辦法跟他一起出來從零開始,於是他在 craigslist 中登出訊息,尋找技術人員跟他一起創辦下一間公司。
(看來 craigslist 不只能幫你找沙發,找公寓,找二手物,還可以幫你找共同創辦人 XD)

VP Engineering Dan Chiao (焦任俠,拿加油手套那位),台灣團隊就是他跟 Kevin 回台創辦的

台灣裔,兩歲移民美國的焦任俠(Dan Chiao)才從 Like.com(後來被 Google 併購) 出走,正在尋找下一個挑戰。

看了 Doug 的廣告後,Dan 跟 Doug 見了面,聊了聊,決定加入 Doug 團隊, 一起打拼,當時創業的產品,是 Doug 想做的 Fliptop Button。

產品『砍掉重練(XD)』過兩次

台北團隊每年都會來舊金山出差個幾個禮拜,一邊抵抗時差一邊工作,還要一邊玩,其實是很累的說

Fliptop 前前後後總共做了 3 個不同的產品,分別是 Fliptop Button,People/Brand Graph,與 SpendScore。

Fliptop Button

Fliptop Button 的概念很像 Google Alert,幫內容提供者推播 RSS,Email Newsletter,Blog … 等的資訊給訂閱內容的人。

有別於一般聽眾只能照單全收的狀況,Fliptop Button 可以讓讀者在自己訂閱的媒體中,再按照自己需要/不需要的關鍵字篩選這些資訊,避免資訊爆炸的情況。

可惜這個產品叫好不叫座,在經過一段時間掙扎後,團隊在 2011 年時決定 pivot。

Fliptop Button 當時的工程團隊在印度。

因為舊金山工程師真的太貴了,Dan 當初建立第一個 Fliptop 工程團隊時,沿用 Like.com 的做法,到印度去建立了個遠端工程團隊,打造產品的 prototype ,而舊金山這邊就由他一個人負責,他這種白天忙募資,產品/業務支援,公司營運,晚上忙指揮工程團隊打造產品的生活,一作作了 6 年(後來跟台灣團隊)。

舊金山的技術團隊與 Customer Success 團隊,舊金山的技術團隊負責客戶支援,
與資料科學技術的改良,產品則都是台灣團隊打造的。

People/Brand Graph

作 Fliptop Button 時,各個社群網站如日中天,百家爭鳴,美國大廠們面對這個突如其來的現象,束手無策,根本搞不清楚他們的用戶在哪些社群上面活躍,做些什麼事情,說些什麼事情,品牌們又要如何應對!

嗅到這個商機,Fliptop 的第一個 pivot ,就是幫大廠們找到他們的用戶在各家社群網站中的帳號,讓他們可以追蹤,是為 People Graph 產品。

當然,品牌們自己也有操作的社群網站帳號,身為大廠,對於對手們,供應商們,與客戶們如何操作社群網站,訊息,品牌定義都很有興趣,於是 Fliptop 也同時提供了這些品牌在社交平台上的帳號,讓客戶可以自行運用,是為 Brand Graph 產品。

把印度團隊關掉後, Dan 跟著亞美玉山走了一圈台灣,發現台灣軟體工程能力很不錯,很可以投資,剛好台灣裔大學同窗好友 Kevin 想回台灣一陣子, Dan 遂說服 Doug ,跟 Kevin 兩個人浩浩蕩蕩地飛到台灣設立台灣辦公室。

2011 年,當我關在內湖出租公寓中用力打造自己當時的新創公司好險網(這個創業失敗的故事我們容後再談 XD)時,Linkedin 上收到 Dan 的訊息:

素聞大俠武藝超群,有勇有謀,喊水結凍,放柴著火,又急公好義,身先士卒。敝公司原創於矽谷,因台灣軟體工程師質優(又便宜 XD),剛選在台北扎根落地,正在廣徵勇夫,一起挑戰哈利波特火盃的考驗 XD… 巴拉巴拉… 巴拉巴拉…(以下省略)

當時的我,對這種矽谷主管主動出擊,在社交平台上找人的公司很是好奇,便回信聯絡。

創業好險網當時當然不能加入 Fliptop ,但是完全沒有現金流生活,又對這個真矽谷公司團隊很是好奇,就決定在旁邊敲敲邊鼓,領領便當,當當技術顧問。

我加入當顧問時整個團隊才只有 8 個人, 4 個人在台灣負責工程, 4 個人(包括 Doug 與 Dan)常駐舊金山,負責業務開發。

SpendScore

People/Brand Graph 產品發展不斷地前進,為公司帶來的一定程度的現金流,但是深入市場一兩年後,團隊發現,蒐集與販賣社交資料的市場沒有想像中的大,而且隨著社交平台的整併與淘汰,市場有漸漸縮水的趨勢,身為 startup ,Fliptop 必須想辦法突破。

賣資料的同時,有不少客戶買社交資料去是為了多瞭解每天不斷進來的商機。當大量的潛在客戶在你官網上留下聯絡資料,成為一個個商機後,你的業務團隊優先聯絡誰?誰比較重要?誰的含金量更高?有沒有辦法事先知道?要怎麼排序優先權?

Fliptop 團隊的技術能量是有辦法回答這些問題的,看看 2013 年的市場中,需求方興未艾,但是已經可以撐起數個競爭團隊下場角逐,矽谷與美國的行銷與業務發展正在不斷地數據化,統計化,跟著 data science/big data 這股趨勢,這方興未艾的小火很有可能燒成燎原大火,正是切入市場的最佳時機,於是 Fliptop 又 pivot 了一次,把舊的 People/Brand Graph 業務賣給 DnB,換到了幾百萬美金的現金後,全力投入預測商機優先權(Predictive Lead Scoring)這塊市場。

台北直送,清晨抵達舊金山

這時台灣團隊約 10 人(包含 intern)左右,美國團隊也大概是 10 個人,還是以業務,行銷,管理,與客戶成功團隊為主。

此時我已經在 Fliptop 舊金山總部待上一年左右(請見出埃及記),負責擔任台灣工程團隊與美國客戶成功團隊的橋樑,簡單來說,就是客戶發現系統有問題,我就得負責當牛仔進去 production 把它修好,修不好得話,做最緊急的處理與診斷,等台北辦公室開始上班後,將問題往台灣送。

很多時候,一早醒來讀 email 的時候,問題已經解決了,直達舊金山的上班時間。

作為美國團隊唯一的工程師(Dan 不算的話)是有好處的,舊金山這邊每週一早上都會開個營運會議,整個經營團隊聚在一起,討論上週的業務,行銷,客戶發展狀況,並策劃該週的策略與進度。

每週一的這個會議,就是我學習在美國經營 startup 的邏輯,觀察美國發展業務,行銷,與經營客戶的絕佳時間,這有點像坐在每個團隊的副駕駛座上,看他們開車,看他們衝撞,看他們失敗,看他們成功,這期間所有的觀察與學習,也都被記錄在我自己的部落格中,與後來的書中

絕對不是台灣軟體工程不行,是你不行!

嚴格說起來,Fliptop 並不是台灣團隊,工程部門大多是台灣人組成的,但是從管理,行銷,業務,客戶成功團隊等等都是美國最本土的組合(設計則是法國人 XD),因此他並不是台灣團隊。

但是這次高價出場證明了一件事情,台灣軟體團隊是做得到的!

因此,如果你聽到有人說台灣軟體工程不行,請狠狠地揍揍他,因為除了 Fliptop 團隊以外,同樣模式的團隊們正如雨後春筍般一個個冒出頭來,最著名的有 SpoonRocketPiCCollageKono,與接下來的 Installments

上列新創公司將營運設在矽谷,攻打美國市場,軟體工程卻借力於台灣團隊的輸出。

這些團隊的存在,正在一巴掌接著一巴掌地,甩著那些唱衰台灣軟體能力酸民的臉。

看到上列團隊的相似處了嗎?創辦人們不是台灣裔,就是在矽谷的台灣人,走出去的台灣人們,正在世界各地串連台灣資源,做出很多很酷的事情,影響更多的台灣人。

找到濕的雪,和一道長長的山坡

到 exploratorium 做公義活動時,當然要自己先來玩一下 XD

慎選你的戰場,因為戰場決定你努力最終的影響力。

誰說台灣人才要留在台灣發展才有價值?只要懂得選戰場(市場),跟不同專業,能力,國籍的人組隊,同樣的人才,在不同的市場,往往能創造出完全不一樣的價值(價格)。

巴菲特說:

Life is like a snowball. The important thing is finding wet snow and a really long hill.
(人生就像雪球。重要的是要找到濕的雪,和一道長長的山坡。)

台灣市場小?台灣市場還沒準備好?沒有藉口,你得到別人市場,你能發揮的市場中組隊廝殺!

你的營運與業務,就得搬到市場當地才行。把總部設台灣,矽谷只是偶而才去臨幸一下的這種心態,就跟把孩子寄放在祖父母家養,卻希望他們不會變壞,他們可以愛你,他們會依照你期望長大的那種天方夜譚一樣荒謬。

重申一次,你必須搬到市場中心,從震央下手才行。

世界很大,但我們也不差,只要你的基因中有任何的可塑性,能夠逼近市場的文化,在這平的世界中,你應該要能葷腥不忌地跟各個文化的英才組成團隊,以成功為前提,找到團隊最佳的組成方程式。

能力跟職涯發展都一樣,你需要濕雪,與長長的坡道。

矽谷見了!

Fliptop 台灣技術團隊今年 9 月就會啟程揚帆矽谷,很可惜的是, Linkedin 並不想要台美兩端營運,因此台灣辦公室也會就此結束,Fliptop 台灣團隊的人才們,也將效力於美國經濟。

聽起來又是個人才出走,台灣滿盤皆輸的故事是嗎?

我不這樣想,因為這些來自台灣的人才們在未來幾年會在矽谷深耕,壯大矽谷中台灣人的社群,在世界軟體技術中心的矽谷,為台灣人發聲。

他們的所見所聞,未來的矽谷經歷,能力,與財力,都會再重新灌溉到台灣的經濟體中。

最後,一定要放一張有 Robbie 的照片,我們出場了,Robbie!

——————————————————————————————————–
如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

群眾募思 – 讓所有員工幫你想下一步的方式

圖片出處

人心從來就不古

最近社會上有很多長輩抱怨台灣『太民主』了,整個社會亂糟糟,每個方向都有個人的見解,反對,與噪音,領導人因為新的民主體制,也硬不起來,讓他們無所適從,覺得整個國家在原地空轉,窮忙至極,卻停滯不前。

對他們來說,這樣的民主,還不如回到過去專制的傳統價值來得好些,至少整個社會有一個同樣的目標,踏著一樣的步伐。

其實他們不是第一個這麼想的人,孔子當初遙想的周公,跟歷史學家,考古學家所研究發現的周朝時期出入就相當大。

人心不古的這種概念,其實都是自我理想世界的延伸罷了。

不是太民主!是你處理想法的系統出了問題

就跟之前文章中所說的一樣,他們遙想中的專制傳統價值有個很大的弱點,上位者一人犯錯,全民買單,想想過去對岸的大耀進,人民公社,與文化大革命,哪個不是決策者的錯誤,害慘了多數人的性命,甚至犧牲一整代人的價值觀與人生?

全世界的領導者都想做英雄,救世主,希望自己的一己之力,可以扭轉乾坤,為千古傳唱,因此當自己一片好心,推出自以為的完美政策或是作法被人民或是公司員工否定批評的時候,通常理智線會瞬間爆掉,不是否認過失,試圖整肅異己,就是不聞不問,把外界的浪潮定義成惡魔黨的逆襲,只要不加理會,挺過這波,(自以為的)正義終究勝利。

其實可以不用這樣。

強者我朋友的公司目前就正在經歷股東會與管理團隊不合,人才出走,員工人心浮散,公司管理團隊劇烈變動 … 等等這些個個都非常要命的種種可怕徵狀,但是新興的管理團隊,卻有辦法敞開心胸,一步步靠著群眾募思的角度,聚攏人心,慢慢地撥亂返正。

經歷過這波的他告訴我,不是太民主,而是大部份的組織根本沒有能處理由下往上大量想法的能力,聲音一多,就地自燃暴走。

劇烈的管理震動!

新創公司管理變動在矽谷是見怪不怪的事情,常見的事情是,經營團隊跟股東們有所衝突,股東大會一不爽,就叫公司的 CEO 走人,這在我待的公司也曾經發生過(請見拙作第一章)

強者我朋友在一間約 150 人的公司當宅宅工程師,公司前執行長募資不力,經過幾個月的爭戰,股東會在一天下午 All Hands Meeting 之前閃電把 CEO 炒了,並在 All Hands Meeting 中宣布,由 COO 代理 CEO 的工作。

原來的 COO 是個純管理出身的傢伙,儘管有一定程度的認知,技術方面卻是一點都不算內行,他第一個任務就是搞定募資,其他事情的優先權不高。

幾個月後,在他募資團隊的長袖善舞下,公司資金的狀況從地獄爬到天堂,也因為他的這項功勳,董事會正式任命他為 CEO 。

1 on 1 之後的震撼彈

募資結束後,整頓公司,把之前 CEO 捅出來的管理婁子處理掉當然就變成了第一要務(疑?清算前朝?),他家新上任的 CEO 就開始跟所有員工 1 on 1 會議,了解從員工的角度,整個公司遇到的是什麼問題,員工在執行個人業務的時候,又遇到了什麼樣的問題。

身為工程團隊的一員,強者我朋友某天早上剛上班,收到了一封緊急 Engineering All Hands Meeting 的 Email ,走入會議時,主持人不是 CTO ,卻是 CEO 與創辦人,正在摸不著頭緒時,CEO 宣布, CTO 在當天早上已經被火了。

原來這些 1 on 1 meeting,不光只是聊天摸頭而已,CEO 跟這些工程師聊過以後,發現 CTO 的工作模式造成了工程團隊不小的阻礙,讓下面幾個 Engineering Lead 都很不爽。

原 CTO 不喜歡這些 Engineering Lead 擅自合作處理事情,命令跨團隊的溝通全都要經過他,這政策不僅讓溝通效率很差,Engineering Lead 彼此之間也因為這樣的禁止溝通的體制出現嫌隙,人的問題又讓這群 Engineering Lead 沒有辦法專心打造完美的產品,惡性循環,執行力越來越差。

這招快刀斬亂麻雖然震撼,團隊看待的方式卻是非常正面的,所有 Engineering Lead 都贊成這樣的決定,管理團隊不是只是說說,喊喊口號而已,CEO 在團隊的威信自然與日俱增。

用 Agile 的方式重組公司 DNA

看到這裡,如果沒有接下來的部分,整個故事聽起來只會是公司內的內鬥而已,但是強者我朋友的 CEO 想要經營的是好公司,不是狗咬狗,鞏固自身權力的那種組織。

團隊整頓好了以後,他接下來要把公司的願景與目標搞好,讓全員都有有一樣的努力方向,他決定使用 Agile 的方法進行群眾募思,重組公司的 DNA。

Agile 其中一個主要的價值是公開,透明,只要願意,所有人都可以參加所有會議,這位 CEO 的想法是,過去管理團隊的黑箱(疑!?)是造成團隊彼此不互相信任的主要成因,經營公司又不是經營 CIA 那種情報單位,諜對諜,沒有人是朋友,所有人都是競爭對手,最後互砍的都是自己人?

他們 CEO 想,一旦一切開誠布公,團隊看到團隊彼此真誠以對,公司文化會漸漸改變,信任感自然會水到渠成。

群眾募思前的指北針,短,中,長期目標

首先,他跟管理團隊需要給出他對公司/產品的遠景,也就是群眾募思的骨幹,這個遠景不用很具體,應該說最好一點都不具體,如此一來,才會激發出團隊狂野的想像力。

於是他給出 2 年,10 年,與 50 年的目標,2 年之內,希望客戶可以達成 1000 位(現在約有 300 位),10 年之內,希望可以推出平價版本,客戶可以達成數十萬位,50 年內,希望推出免費版本,客戶數可以達成數百萬位(這些數字當然有搭上公司產品定位的演進,但是強者我朋友因為不想讓大家肉搜,希望我不要寫出來 XD)。

對 startup 來說,10 年或是 50 年的願景聽起來有點蠢,短進短出地套利不才是 startup 的核心精神?

對他們 CEO 來說,如果兩年內的可以衝到 1000 個付費客戶,每個客戶每月貢獻超過 1000 美金,他們這間新創公司其實很有 IPO 的本錢 XD

他想賭的,從來就不是短進短出,獲利了結。

再者,10 年,50 年這種指標性的願景之所以存在,是因為他們可以協助排序接下來群眾募思的每個想法。

每個想法都很重要的同時,到底哪個想法要先執行呢?端看這個想法能協助達成 2 年, 10 年,或是 50 年的願景。

比如說有人認為 Growth Hacking 中的 A/B Testing 很重要,因為能夠協助公司產品的成長,另外一個人認為產品支援其他語言比較重要,因為可以迅速擴展能夠銷售的國家與領域,身為公司的經營者,你要先做哪一個呢?

有了 2 年, 10 年與 50 年的目標,你可以很清楚的按照這些目標排序,使用 A/B Testing 能不能加速達到 1000 個客戶?可以。同時不增加其他語言的支援,我們在英語世界中能不能達到 1000 個客戶?可以,因此多語系支援的優先權就比較低。

如此一比,A/B Testing 落在短期計畫以內,但是其他語言的支援會落在中期計畫內,要先做哪一個不就一目瞭然?

各個團隊的頭腦風暴

接下來,為了讓最基層的聲音與想法通通浮現出來,CEO 請約兩百人的整個公司團隊成員用 3M 便利貼列出他們想要在公司看到的所有改變,一張便利貼只寫上一個想法。

有些想法很務實,比如說上列的產品語言支援,或是 A/B Testing,公司策略調整,人事調整,供應商調整,定價調整,團隊調整,資料中心與軟體架構的調整 … 等等。

有些想法也非常狂野不羈,有人效法 SpaceX 想上火星,有人希望公司有個專屬的酒吧,有人希望公司每個人發一台 Tesla… XD

總之管理團隊葷腥不忌,照單全收,跟所有團隊一一開會,讓團隊成員一一在會議中呈現,然後依照下述的方式排序。

指北針排序法

管理團隊先在會議室一邊的玻璃上依序畫出短,中,長期三個區塊,接者請團隊成員上台解釋他寫在 3M 便條紙上面的想法,然後請他決定這個想法應該要貼在短期,中期,還是長期的區塊裡,此時團隊其他人也會給出意見,討論該想法的落點。

上火星,或是每人發一台 Tesla 這些跟公司目標關係不大的想法,這時候就會被排到長期目標中,反之,A/B Testing,工程師效率提升,定價調整這種立即可以影響公司目標的想法,會從整堆想法中脫穎而出,被排到短期目標的區塊中。

當然,有些看似重要,但是沒有立即的短期效益的那些想法,就會被歸類到中期目標中。

如此一來,團隊想法的就像一塊塊磁磚,貼進公司目標的框架中,同時與會的團隊也會很清楚地感覺到想法的輕重緩急,有了這些準備,就可以開始依照 Agile 的方式,做出更精準的排序了。

用比較的方式讓重要的想法浮出

會議室的另一邊,有一條時事先畫好的時間軸,橫跨整個會議室的牆面,管理團隊於是從短,中,長期的區塊中,各選出一個想法,當作 baseline ,均勻分散地貼在時間軸上,短期目標的 baseline 貼在時間軸的前端,中期目標的 baseline 後面一點,長期目標則貼在時間軸的後端。

好了,有了短,中,長期的排序概念後,我們還是不知道如何排序短期,中期,與長期各區塊中的想法們,這時候我們要跟 Scrum 借兩個概念來協助想法的比較:

1. 找成本小,效果高(對公司正面衝擊大)的東西先做。
2. 人類的預測能力一點也不好,但是兩個想法讓他比較,卻很有辦法衡量出相對的重要性或是所需的工作成本。

有了上面這兩個原則,他們就從上列『指北針排序法』中的短,中,長期想法中,輪流拿 3M 便利貼過來,一個個跟時間軸上的 baseline 做比較,如果手上 3M 中的短期想法比 baseline 中的短期想法還要重要,就貼在時間軸的更前面,如果比較不重要,就貼在 baseline 的後面。

等到所有想法都貼進時間軸,該團隊募思所有想法的輕重緩急就完全排出來了,管理團隊這時候把這些想法與優先順序謄進一個公開的 Google Doc 中,讓其他所有團隊都看得見,也同時讓想法的創始人上去編輯或是解釋想法。

募思的彙總與演進

管理團隊一一跟所有子團隊進行上列『頭腦風暴』,『指北針排序』,與『比較想法』的動作,結果都上到 Google Doc 中。

最後由管理團隊開始彙總個團隊的想法,把相似的想法全都結合在一起,出現頻率高的想法給予更高的優先權,排序各個團隊所有的想法,把所有想法依照優先順序排到短,中,長期的目標中,最後開個 All Hands Meeting 跟所有人解釋,討論這個熱騰䲢出爐的 Roadmap。

All Hand Meeting 結束後,管理團隊建立起一個全公司都可以看到的大螢幕 Kanban Board ,把短期項目通通塞進 Scrum 待辦事項中,就要開始戮力執行了。

管理團隊也請 IT 架起另一個大螢幕,追蹤第一階段目標(1000 個客戶)的達成率,所有員工都可以看到公司的演進與成績。

中長期的項目呢?仍然好端端的躺在 Google Doc 中,隨時都可以查詢與編輯。

看到自己的想法受到重視,被排進 Roadmap 中,公司的目標明確可達成,再加上管理團隊很有誠意地公開透明,員工間的氣氛煥然一新,注滿活力。

根據他們的管理團隊,這套募思的方法每半年要來一次,讓新的想法進到 Roadmap 中來,不合時宜的想法就能夠自然淘汰掉,畢竟外在的環境一直在改變,要隨著環境進化才行。

不是所有矽谷公司都這樣,這也不是公司共產

矽谷的新創公司中,直接用這種 Agile 理論管理公司的不在少數,而且漸漸增加中,很多年輕的創業家與管理者深信只要組織透明,文化開放,信任員工的想像力與創意,公司的向心力與執行力就會大大提升。

同時,還是有些創辦人或管理者堅信要跟賈伯斯一樣把公司搞成 CIA 才可以跟賈伯斯一樣厲害 XD,但是有多少公司最後跟蘋果一樣厲害呢? XD

我自己倒是在這兩種方法論經營的新創公司都待過,我在新想法,新執行窒礙難行的組織中,能夠貢獻的是在開放組織中的十分之一不到吧,在 CIA 組織中,我只不過是隻會把 spec 轉成程式碼的程序猿罷了,其他想法不重要,因為組織不重視。

時代劇烈變動的時候,經營團隊與公司的方式就要更靈活才行,讓想法與執行力自由流動,借用所有人的力量吸收外界的資訊,轉換成想法,執行成行動。

最後,有一點需要釐清的是,群眾募思不是公司共產共管,管理階層還是肩負所有公司的管理責任,跟股東報告,各團隊還是要戮力執行出原本的業務,群眾募思只是打通公司溝通的任督二脈,讓所有人的眼睛變成管理階層的眼睛,讓所有人的想法變成管理階層多出來的 CPU ,讓所有團隊的執行進度被所有人看到,有了這些資訊,就更能合作無間。

開放 Agile 的組織不僅自由奔放,他還能夠強化員工對公司與管理團隊的信任,下次,我們來聊聊另一個強者我朋有待的硬體公司如何用 Agile 的方法論做出超越競爭者的夢幻產品,打造出連客戶都非常信任的強大公司。 ——————————————————————————————————–
如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

怒火宣泄了以後呢?怎麼沒有人討論怎麼預防無差別/連續殺人犯?

圖片出處:Criminal Minds

把這些殺人犯凌遲泄恨,就可以預防事件發生?

從去年到今年,台灣社會接連發生 3 起令人遺憾的無差別殺人事件,不僅引起社會恐慌,這樣的發生頻率,很難說多久之後還會有類似事件發生。

可是問題來了,整個台灣社會不管是臉書,報紙,政論節目,到政黨… 等,全都在瘋狂地討論死刑與廢死,言下之意,就是如果嚴刑峻法,亂世用重典,就可以嚇阻相似事件的發生。

真的是這樣嗎?

就我所知,死刑的可能達成目的有兩個:1. 嚇阻未來罪犯,使殺人率降低。 2. 聲張正義,為被害者報仇。

但根據廢除死刑是否會使殺人案增加 (http://elysii.net/4836文章中所呈現出來的各國統計數據,死刑的存在與執行跟各地區的殺人律沒有多少的正相關,換句話說,就算我們把這些殺人犯全都判以死刑,也完全沒有辦法預防或是阻止類似案件的發生。

這麼說來,討論死刑的重點就只剩下一個:我們要如何凌遲殺人者,替受害者報仇!

這是我們該討論的問題嗎?

如果是受害者家屬,有這樣的情緒反應當然再自然也不過了。

於是我們把殺人者抓出來在忠孝東路遊街示眾後,總統府前凱達格蘭大道上當街斬首,符合家屬與社會的期待。死刑執行以後,我們轉身回家,關起房門,坐在沙發上喝上一口茶,不公不義的憤怒終於得到伸張,自己的心也就慢慢地安定了下來,今夜,應該會有個好眠了。

等等!!

砍了一個殺人犯,少了一個殺人犯,就天下無賊了嗎?

不是這樣吧!從去年以來,這種無差別的殺人事件就發生了 3 起,難道每次我們都要以討論死刑,執行死刑的方式終結憤怒,然後就皆大歡喜了嗎?

更好的問題是?

身為一個智商 100 左右,資質極其平庸的正常知識份子,我認為死刑的存廢在這裡根本不重要,整個社會的精英應該討論的是下面的個問題:

我們要如何阻止類似案件發生?

這問題很難答,因為它非常廣:

1. 類似案件的殺人者為什麼會做這些事情?還是跟 chenglap 說的一樣,這只是一種對注意力的渴望?

2.  行為經濟學與犯罪心理學有沒有辦法解釋這些本土殺人者所使用的工具,鎖定的對象,以及犯罪的方式?

3. 如果把家庭狀況,教養過程,學校從小到大的成績,老師評語,聯絡簿記錄,社交狀況全部整理好,我們有沒有辦法用資料科學來找出殺人與成長經歷中間的關聯性? 

4. 如果下次連續殺人犯選擇躲在暗處,繼續犯案,不再當現行犯被逮,我們警政署有沒有本土的 BAU(FBI 有 behavior analysis unit,行為分析組)可以預測犯人的行為,進而早一步將犯人繩之以法嗎?

5. 到底是怎麼樣的社會結構與壓力創造出這樣的殺人者,知道問題後,我們有辦法釜底抽薪嗎?

6. 在找到這些問題的答案之前,有沒有什麼更好的自保方法呢?

7. 日本,挪威,美國都有做過類似的研究,他們的經驗與研究方法,成果,有哪些是可以借鏡的?

… 等等

這些問題全都比死刑與否重要,因為他們的答案攸關我們如何有效地鞏固我們未來的安全,而不是側重在報仇情緒的自然宣泄。

    過度簡化的是非題,是很危險的!

    那麼是為什麼臉書,報紙,政論節目,到政黨都鮮少討論到這些問題呢?而都只是煽動民眾的報仇情緒(割喉案媒體報導多煽動?),繼續騙關注呢?

    因為這是最偷懶卻是最有效行銷自己的做法,但是這同時也是最自己,對觀眾,對台灣最不負責任的做法!

    在工作的時候,老闆通常會丟給你一個申論題,你回答時,應該把這個申論題簡化成簡答題,再簡化成選擇題,再簡化成是非題,因為化繁為簡是你的工作,你要把你的理論轉成摘要,把摘要轉成選擇,把選擇轉化成行動。

    但是你不能不知道原來那身為申論題時的理論。

    在思考問題的時候,如果一開始上頭塞下來的題目就是是非題(死刑與否),你必須要知道,這表示他們要你跳過理論,摘要,選擇,而直接聽從它們的行動,任何一個受過教育的人都要知道,這樣的題目是異常危險的,因為他們不要你思考,他們只要你的行動。

    尤其是是政黨,你更沒有資格問這種過度簡化的問題,因為你是人民託付的對象!任何把人民當白癡的行為都只會讓有正常智商的人更火而已。

    接下來,情緒過後,冷靜下來的你,會想要問什麼問題呢?

    ——————————————————————————————————–
    如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

    手快一定打手慢,唯快不破的合作方法(下):如何用 Scrum 把妹 ;-)

    圖片出處:Hitch

    這篇文章要提供一個簡單的 Scrum 框架給大家,可以配著上兩篇文章一起看:

    直接講述 Scrum 的流程是枯燥乏味的,我們來發揮一點鄉民的創意好了,本魯一直覺得『全民情聖』中這位 Hitch 顧問的角色應該要用 Scrum 來經營顧客的每個 case ,那我們來試試看 Scrum 把妹術的效果如何。

    本魯已經離開愛情戰場非常多年,對現在情場中如何交火過招,已經有點生疏了,我們那年代追女生都是一次追一個的,雖然我相信 Scrum 可以增加效率,但是還是不建議利益極大化,劈腿多個追求對象 XD

    如果有需要劈腿 Scrum 技巧的朋友,請自行延伸,本魯本篇文章只提供專情版的 Scrum 把妹術。

    Scrum 適用於 3 – 9 人的團隊,而且最多不應該超過 9 人,畢竟 Product Owner 與 Scrum Master 這兩個角色很少是同一個人擔當的,不過為了劇情需求,我們先假設 Hitch 同時擔任 Product Owner 與 Scrum Master ,而執行團隊主要是故事主人翁 SW 跟她妹妹 DD 擔任。

    Product Owner(應該翻成產品經理吧)

    SW, 32 歲,是個宅宅工程師,沈默寡言,說話不敢看人眼睛但心地善良,除了技術社群聚會,動漫展跟桌遊比賽以外,平常不怎麼出門,除了資訊展發的免費 T-Shirt 跟牛仔褲以外,衣櫥裡什麼都沒有。

    SW 很喜歡 PM 團隊的主管 JJ,JJ 大 SW 3 歲,米國名校 MBA 學歷,個頭 170 公分左右,是個說話大聲,吃飯大聲,喝東西大聲,趴著睡覺也大聲的傻大姐個性女孩,但是不要看她平常談笑像白癡一樣,每當跟客戶或是 Sales 開會時,她就是有辦法撐起哪張精明的臉蛋,把所有人搞得服服貼貼的。

    SW 跟 JJ 平時雖然沒有接觸,但是辦公室其實相差不遠,每當 JJ 在走廊跟團隊大聲地談笑與討論時,SW 恨不得放下手邊工作跑過去參加。

    Hitch 跟 SW 約在新光山越 A9 館的美食街裡, Hitch 跟往常一樣,照例遲到,先躲在暗處把 SW 觀察個夠,最後再從容不迫地走到 SW 跟前,簡單地道個歉,以:

    “Why don’t you tell me about her?“ 切入。

    待辦事項(Backlog)

    在 Scrum 開始之前,Product Owner 必須要按照市場需求,把能想像得到的待辦事項全都列出來,先不要管輕重緩急,先不要在意事件大小,只要羅列出能讓 SW 追到 JJ 的所有待辦事項即可,舉例如下:

    • 1. 身為阿宅 SW,想要追到正妹 JJ,我們需要改頭換面(外表而言)
    • 2. 身為阿宅 SW,想要追到正妹 JJ,我們需要學習基本的美姿美儀
    • 3. 身為 Hitck,想要讓 JJ 對 SW 留下深刻的印象,我們需幫 SW 製造出完美的邂逅事件
    • 4. 身為 DD ,想要搜集更多未來大嫂的資訊,DD 需要混入 JJ 的朋友圈中
    • 5. 身為 Hitck,想要讓 SW 能順利約 JJ 出來,我們需幫 SW 構想約 JJ 出去的藉口與方
    • 6. 身為 Hitck,想要讓 JJ 願意再跟 SW 出來第二次約會,我們需要幫 SW 規劃出不敗的第一次約會劇本
    • … (篇幅有限,請自行想像)

    這種 身為 xx ,為了 yy ,我們要做 zz 的陳述方式叫做 user story,這種待辦事項的表達方式是為了讓所有讀該 user story 的人都了解這個待辦事項的背景資訊,包括為什麼需要做這件事情,做什麼事情,還有這件事情之所以重要的假設是什麼… 等等。

    換個方式說吧,如果不用 user story 的方式,上列的項目 4 跟項目 5 寫起來會是這樣:

    • 4. DD 需要混入 JJ 的朋友圈中
    • 5. 構想約 JJ 出去的藉口與方式

    看起來是不是少掉很多資訊?如果今天 Hitch 身體不舒服,找 Winston 來代班,Winston 要怎麼搞清楚 4 跟 5 項目的動機,相關人士,與想達成的效果呢?

    人類的記憶力有限,用有效率的方式記錄與傳達待辦事項是非常重要的。

    Task Score(待辦事項困難度)

    在列出完成任務條件下所有能夠想像到的待辦事項後,為了測量團隊每個 Sprint 循環的速度,我們必須要預估每個待辦事項的困難度 (task score),這個步驟,是需要跟整個執行團隊一起進行的。

    知道團隊的速度是很重要的事情,有了這個資訊,我們可以:

    • 1. 了解團隊有沒有在漸漸加速?加了多少速度?
    • 2. 如果突然慢下來,我們可以立刻察覺,並開始找原因。
    • 3. 隨時校正更精准的專案完成時間。

    如果幾個 Sprint 後,還是發現專案完成時間就是趕不及,要趕快讓相關人士知道,立刻研擬配套措施,或是重新定義專案的深度或廣度。

    一般而言,Scrum 團隊喜歡使用費氏數列來定義待辦事項的難度:

    1, 2, 3, 5, 8, 13 …以此類推,難度 2 的比難度 1 的還要困難一些,但是比難度 3 的還要簡單一些。

    其實人類預估的能力很差,就算在完全誠實,不自欺欺人的狀態下,你說 2 天內能完成的事情,有多少次是準確的?拿筆者最近用 TurboTax 報稅的例子來說吧,因為已經做過幾次了,資料也準備好了,想說這次頂多一個下午的時間就可以掰掰掉了,結果因為查不到 IRS 要提供的某個號碼,時數硬生生地拖了 3 倍不止,動用了兩個人的人力。

    我們工作上有多少次這種情形?那你還相信要求每個項目絕對準確的干特圖(Waterfall Model)嗎?

    雖然人類完全不擅長預估精準的數字,對於相對的難度卻是掌握得相當好,報稅這件事情比煮飯難一點,但是卻又比自己寫出一整個網站簡單一點,比較每個待辦事項相對的難易度,我們很容易可以預估出做完全部事情大概需要幾個『報稅』的時間(以報稅所需時間為基準的話)。

    用費氏數列的好處是,因為每個數字是前兩個數字的加總,每個數字跟前後的差距剛剛好,壁壘分明,你絕對不會認為難度 1 的跟難度 2 的差不多,難度 8 雖然跟難度 13 是鄰居,但完全沒有人會搞混。

    上列的待辦事項安上難度分數後,長成這樣:

    • 1. (3 分)身為阿宅 SW,想要追到正妹 JJ,我們需要改頭換面(外表而言)
    • 2. (1 分)身為阿宅 SW,想要追到正妹 JJ,我們需要學習基本的美姿美儀
    • 3. (5 分)身為 Hitck,想要讓 JJ 對 SW 留下深刻的印象,我們需幫 SW 製造出完美的邂逅事件
    • 4. (13 分)身為 DD ,想要搜集更多未來大嫂的資訊,DD 需要混入 JJ 的朋友圈中
    • 5. (8 分)身為 Hitck,想要讓 SW 能順利約 JJ 出來,我們需幫 SW 構想約 JJ 出去的藉口與方式
    • 6. (5 分)身為 Hitck,想要讓 JJ 願意再跟 SW 出來第二次約會,我們需要幫 SW 規劃出不敗的第一次約會劇本

    這樣,我們就完全知道,要完成這樣任務,需要做完哪些事情,以及大概會花多少功夫。

    Scrum Master(有點像專案經理,管進度的)

    接下來 Scrum Master 進場,要準備開始兩週循環一次的 Sprint 了!

    Scrum Master 與 Product Owner 這時候就會坐下來,看著成堆的待辦事項,用下列標準選出下個 Sprint 中要處理完成的項目:

    『最不費力,而且對專案完成影響力最大的』

    根據 80/20 法則,如果你選得好,你只需要做 20% 的事情,就會有 80% 的效果,因此,你應該謹慎選擇你花時間的項目。

    事情完成的好壞跟你當時的能力也有關係,比如說你要 SW 一開始就執行第五項約會邀約的待辦事項,等於是要了生性靦腆的他一條小命,倒不如先讓 JJ 對 SW 留下很深的印象(第 4 個項目),讓 SW 熱身一下,習慣一下跟 JJ 互動。

    深刻的印象不用很帥,也不用怎麼說話,很可愛勇敢的印象說不定效果好很多,在 Hitch 電影開頭,不是就有一幕做出來的英雄救犬嗎?

    看板(Kanban Board)

    為了追蹤每個待辦事項的進度,Hitck 在 SW 套房公寓的一面白牆上,寫下 Backlog(待辦事項),ToDo(在本 Sprint 中準備處理),Doing(正在處理),與 Done(完成) 這幾個字眼。

     看板(Kanban Board)範例

    把上面的所有待辦事項寫成便利貼,一張張貼到 Backlog 的字樣下方。

    Kanban 是日文『看版』的意思,在 Scrum 中,Kanban Board 是團隊拿來追蹤待辦事項進度的工具,所有人都能看到每項待辦事項的進度,誰如果手上有餘力,馬上可以跳進來幫忙處理還沒有完成的事項。

    Sprint 行前會

    好了,有了 backlog ,也有基本的優先順序,我們要開始實作了。

    Sprint 開始之前,Hitch 把團隊成員全都抓進會議室中,把第一次 Sprint 要處理完的待辦事項從 Kanban Board 的 Backlog 抓來 ToDo 中,跟團隊解釋每個待辦事項的細節,討論難度,執行方式,回答團隊的問題後,為期兩週的第一次 Sprint 就此展開,待處理的事項如下:

    • 1. (5 分)身為 Hitck,想要讓 JJ 對 SW 留下深刻的印象,我們需幫 SW 製造出完美的邂逅事件
    • 2. (13 分)身為 DD ,想要搜集更多未來大嫂的資訊,DD 需要混入 JJ 的朋友圈中
    • 3. (8 分)身為 Hitck,想要讓 SW 能順利約 JJ 出來,我們需幫 SW 構想約 JJ 出去的藉口與方式

    如果事項難度太高,比如說 13 分的那個『混入 JJ 的朋友圈中』,或是團隊認為要達成『搜集更多未來大嫂的資訊』,根本不用混入交友圈,那麼團隊就會把它拆成幾個小一點,同樣能夠達成目的的事項分別處理,比如:

    • 1. (2 分)身為 DD ,想要搜集更多未來大嫂的資訊,我們要研究 JJ 的好友圈,找出容易切入的方式。
    • 2. (5 分)身為 DD ,想要搜集更多未來大嫂的資訊,我們要研究 JJ 下班時間的生活方式,找出兩人的交集。
    • 3. (2 分)身為 DD ,想要搜集更多未來大嫂的資訊,我們要研究 JJ 在網路上的所有公開分享。

    在 Sprint Planning Meeting 中,團隊會對要處理的待辦事項進行溝通與重新定義(如果必要的話),一旦 Sprint 開始了,一般而言是不能更動 Sprint 要處理的待辦事項的。

    每天站 15 分鐘

    Sprint 開始以後,Hitch 每天在 SW 出門上班前 15 分鐘,會到 SW 家中跟 SW 與 DD 開會,會中只問三個問題:

    • 1. 你昨天做了什麼,來幫助團隊完成這個 Sprint ?
    • 2. 你今天打算做什麼,來幫助團隊完成這個 Sprint ?
    • 3. 你在執行的過程中,有沒有遇到什麼障礙?卡關?

    DD 這兩天本來想要處理『研究 JJ 在網路上的所有公開分享』這個項目,但是電腦不知怎麼了就是整個給他死當,掛了,偏偏 SW 的所有電腦都是灌 Linux ,整個房子裡面沒有一台他會用的 PC 。

    知道這件事情以後, Hitch 立刻把手上的 Asus 端出來給 DD 用,反正他的事情用 iPad 就可處理了 XD

    解決障礙,讓 Scrum 可以全速進行,是 Scrum Master 一個非常重要的責任。

    健康的 Daily Standup 不會超過 15 分鐘,超過 15 分鐘表示哪裡做錯了,在浪費大家的時間。

    Sprint 檢討會

    兩個禮拜過得很快,第一個 Sprint 就在大家的戮力合作下結束了,團隊完成了以下項目:

    • 1. (2 分)身為 DD ,想要搜集更多未來大嫂的資訊,我們要研究 JJ 的好友圈,找出容易切入的方式。
    • 2. (5 分)身為 DD ,想要搜集更多未來大嫂的資訊,我們要研究 JJ 下班時間的生活方式,找出兩人的交集。
    • 3. (5 分)身為 Hitck,想要讓 JJ 對 SW 留下深刻的印象,我們需幫 SW 製造出完美的邂逅事件

    研究 JJ 的好友圈與下班的生活方式剛剛好讓 Hitch 設計出非常不著痕跡的邂逅方式,Hitch 之前的客戶剛好是 JJ 好朋友 RJ 的老公,RJ 常跟 JJ 下班後一起去忠孝東路上的 Gym 參加瑜珈程。

    Hitch 當然不會錯過這個絕佳的機會,在瑜珈課程中不用說話,只需要氣喘吁吁地把自己的身體折來折去,衣著跟舉止也完全沒有關係,Hitch 隨即安排 RJ 帶 SW 一起參加體驗課程。

    於是在第二個禮拜, RJ 在課前介紹 SW 給 JJ 認識,SW 跟 JJ 很高興地發現他們『恰巧』在同一個公司上班,課堂中 JJ 發現雖然 SW 的身體真的硬到不行,做弓式時看起來像是在做鹹魚式,還做得哀哀叫,整個課堂都聽得到他的呼吸聲,但他真的很認真,很可愛。

    Sprint 結束後,整個團隊坐下來回顧 Sprint ,Scrum Master 請團隊在白板上寫出大家覺得做得很好的部分,以及可以改進的部分。

    這次 Sprint 團隊總共消化了 2 + 5 + 5 = 12 個分數,團隊一致認為在所有待辦事項中簡單寫出預想中的執行方式,讓其他團隊成員知道與貢獻,應該可以減少許多摸索與溝通的時間,Hitch (Scrum Master) 於是決定在接下來的 Sprint 中試試看。

    Sprint Review Meeting 是拿來改進未來 Sprint 的流程與執行的,不管團隊執行的多麼完美,一定都有可以改進的地方,因為環境與工作設定是不斷在變動的。

    加速,加速,加速

    時間推著第二次 Sprint ,第三次 Sprint,第四次 Sprint 向前,團隊消化分數的能力從原來的 12 分,增加到的現在的 25 分,漸漸地趨於穩定狀態。

    會造成這種加速的原因主要有下列兩個:

    • 1. 跟著節奏加速
      在之前的文章中有提到過,Scrum 要追求的其實就是那個 Sprint 的節奏,團隊會學著怎跟彼此合作,同時工作越來越上手的話,速度自然加快。
    • 2. 剷除障礙
      團隊加速的過程中,好的 Scrum Master 會很細心地發現大大小小的擋路石,有可能是團隊的溝通不良,導致資源空轉,有可能是因為硬體設備不佳,更換更有效率的設備會大大增加產出,更有可能是奇怪的潛規則,政策,或是文化讓進度裹足不前 … 等。

      Scrum Master 的工作就是要鏟除這些障礙,障礙剷除了,速度自然會大大提升。

      

    現在 Hitch 知道團隊大概的速度是 25 分,剩下來的待辦事項還有 70 分左右,所以大概還要 3 個 Sprint ,也就是再 6 個禮拜,就能夠把 SW 與 JJ 的感情推上軌道。

    在第二次 Sprint 中,搞懂 JJ 在公司的行程後,Hitch 要 SW 每天刻意營造在公司不期而遇的機會,同時 Hitch 也漸漸幫 SW 改造衣著與舉止,衣櫥裡資訊展的 T-Shirt 通通丟掉(SW 最後還是撿回來當睡衣用),換成幽默感話題性十足的 Star War Q 版 T-Shirt,JJ 在美國讀書時大學的球隊 T-Shirt ,甚至還有 Q 版 柯P 在抓頭的那種可以引起 JJ 興趣,創造話題的 T-Shirt,牛仔褲換成 Levis,可以襯托出 SW 瘦瘦高高的身材,舉止部分也嚴禁當眾挖鼻孔,講話要看人,臉上的鬍渣要處理,鼻毛切忌外露… 等。

    SW 的存在感越來越明顯,形象也因為一步步的改造漸漸清新可口,JJ 也開始習慣在公司會看到 SW,不忙的時候也會小聊一下,或一起約去吃中餐啥的。

    在美國把妹比較直接,你約妹出去,如果該妹說 yes ,基本上就表示他願意給你追他的機會,對他來說,你的意圖很明顯,所以不用搞『告白』那種蠢事,如果氣氛好,第一個約會就接吻不是難事。可是在台灣,直接跟女生說要跟他約會只會見光死,大家比較喜歡旁敲側擊,慢慢發展,所以有時候曖昧給你拖個好幾年,一定要『告白(那件蠢事)』才能確定彼此身份。

    拖個好幾年,Hitch 早就餓死了,所以他的方式都是搶快加速進行。既然 JJ 在美國待過,他決定讓 SW 用單刀直入的方式,用美國的方式進擊,避免曖昧的空間。

    SW 的口語表達仍然不脫宅氣,讓他直接去約 JJ 根本又是要了他的老命,在 Hitch 擬好稿後,讓 SW 用他最熟悉的方式出擊:公司 Email。

    Hitch 訂了兩張 Diana Krall 演唱會的門票,座位好到讓觀眾可以摸到大提琴震動的弦,在演唱會之前,他又安排了小巨蛋的冰上溜冰活動,讓整個安排有動有靜,有敞開心胸破冰,之後也有醉人心弦的爵士樂,暗暗的燈光下,坐在身邊對方的形象不知道美化了多少倍 XD

    這兩張票要價 6000 元台幣以上,在經歷過幾場戀情後,JJ 知道這種邀約絕對不是普通朋友的意圖,自己對 SW 沒有什麼特別的感覺,但是 SW 倒是很細心的記得他喜歡 Diana Krall 詮釋的 Jazz,有點可愛,她想了想,說不定可以試試看,於是回信答應。

    SW 的運動神經真的完全不行,說是溜冰,倒不如說是冰在溜他,跌了又跌,跌了又跌最後,JJ 看不過去,開始牽著手帶他,教他。

    雖然第一次約會就牽到手讓 SW 很爽,但是他高昂的自尊心讓他說什麼也想學會,認真的樣子讓 JJ 想到他做瑜珈的彳ㄨ ㄛ ˊ樣,JJ 笑得很開心。

    溜冰後 SW 整個快散掉了,癱坐在演唱會的位置上快要睡著,JJ 倒是聽得很認真,在北美的時候,他曾經專程飛到多倫多看過 Diana Krall,但那已經是好幾年前的事情了。

    第一次約會執行效果不錯,於是有了第二次,第三次約會,Hitch 安排的活動也漸漸把 JJ 帶到 SW 的生活圈中,比如說安排 SW 帶 JJ 去參加 coscup 中 SW 的演講,看到兩三百個宅宅聚精會神地吸收 SW 的 Talk,JJ 越來越覺得 SW 真得很不錯。

    不斷地變動,是世界唯一的真實

    不管規劃得多周延,要記得環境是不斷在變化的,很多無法預料的發展會在專案進行得最順遂的時候帶著三百壯士來敲門。

    JJ 之前因為出國留學而分手的前男友最近剛剛單身,跟 JJ 又聯絡上了,除了名校畢業,身為 183 俱樂部的成員以外,運動武術,文學音樂無一不精,最近瘋 cross-fit,把自己 38 歲的體能狀態練得比 18 歲還好,把他丟到 Zoosk 上面,信箱馬上被滿滿怨女的『安安』們所淹沒。

    SW 要怎麼競爭?

    你當然可以繼續依照傳統用甘特圖(Waterfall)方法論規劃出來步驟一步步前進,不管任何大環境的變動,但是強大的競爭者兵臨城下,鴕鳥心態只會讓之前的努力前功盡棄而已。

    幸好 Hitch 用的是 Scrum,身為 Product Owner 的 Hitch 早就想好應付這位前男友的所有待辦事項,再把所有剩下的待辦事項(包括上述針對前男友的那些)依照重要順序重新排序,在第五個 Sprint 中立刻開始執行。

    待辦事項的優先排序就是 Scrum 應付不斷改變大環境的方式,一旦吸收到新的環境資訊,不管是競爭者的新招,市場風向的變動,公司整體方針的調整 … 等,稱職的 Product Owner 與 Scrum Master 都會在每個新的 Sprint 中,把這些消化過的資訊在待辦事項的優先順序中反映出來,團隊的執行力也完全會發揮在這個稍微調整過的方向中,這就是在先前文章中提到的變招快。

    Hitch 在第五次 Sprint 中帶入了之前 backlog 完全沒有的幾個待辦事項:

    • 1. (2 分)身為 Hitch ,想了解更多關於前男友競爭者的資訊,我們要請 RJ(JJ 的瑜珈  buddy)充當我們的耳目,刺探敵情。
    • 2. (2 分)身為 DD ,想了解更多關於前男友競爭者的資訊,我們要研究這個人的網路足跡與下班後所做的事情。
    • 3. (1 分)身為 Hitch ,想要快點讓團隊的生產力用在對付競爭者的行動上,我們需要根據上列所得的資訊分析並擬定對策。

    環境改變,Scurm 方法論也立刻讓團隊做出反應。

    事半功倍,大功告成

    經過一番研究,前男友的所有條件都不是 SW 可以比擬的,但是他有個致命的缺點:他有個超級傳統的台灣家庭。

    他的家庭觀念是媳婦所有收入上繳母親,讓母親作為分派所有資源的中心,下班要立刻回家,在三代同堂的環境中,說話做事都有階級之差,忤逆上意是要罰跪的 XD (難怪 38 歲了,卻還沒有結婚)。會在 38 歲時瞬間單身,也是因為他那小他 8 歲的前女友,再也受不了這種家庭環境了。

    25 歲之前談的感情,跟 35 歲後所談的感情型態有根本上的不同,JJ 是新世代的女強人,不可能接受這樣的家庭條件。賭上這一把,於是 Hitch 設計,讓 JJ 了解到前男友的家庭狀況,JJ 果然興趣大減,於是不再積極回應前男友的聯絡。

    Scrum 繼續向前,SW 在第六次 Sprint 時牽上了 JJ 的手,在國父紀念館的石椅上吻上了 JJ 的唇,戀情穩定發展,持續升溫中,Hitch 的專案就此大功告成。

    Scrum 絕對不只有軟體工程是用,上自 IC 硬體設計,房屋的裝潢工程,下自準備考試把妹,甚至是經營人生,絕對可以讓不再規劃用不到的東西,用更少的時數與資源執行出更多的成效。

    ——————————————————————————————————–
    如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

    出埃及記 – 來矽谷不過就是一把梭哈

    Richard Mcbee 所畫的出埃及記

    (出埃及記是聖經舊約第二章,講的是摩西帶領猶太人穿過紅海離開埃及奴隸生活的故事)

    不約而同地,近來有三位讀者朋友寫信來請我寫自己的際遇。

    其實我一直反對寫這種文章,原因是:

    1. 1. 我不是成功人士,只是個很愛發表意見的工程師,參考價值不大
    2. 2. 他人走過的路通常沒有多少可以複製的空間,應該注重的是方法
    3. 3. 運氣是很重要的,我上輩子可能有燒些好香

    來信的有三位 XD (哪裡來的啊?)我該如何給這幾位看官一點交代呢?

    我實在不想寫那種很拔辣的『怎样出國工作,看完我沉默了』,『怎麼能看得出一個男人是不是真的愛出國工作』,或是『只要出國工作,不要拿来比較,不要老說别人的老公如何如何好』那種東西。

    但前幾天跟一位大神朋友聊天時,他問:

    『你的家庭背景很特殊,直接轉換職位薪水嗎?』

    「沒當過悠遊卡公司董事長,沒有募過私募基金,所以一點也不」我答。

    『你職場中的能力,很早就開始培養嗎?別人現在開始都太晚了嗎?』

    「也沒有,我出生的時候沒有金湯匙也沒有鍵盤,只有黑黑的胎記」

    『你的學經歷,是萬中選一,可遇不可求的嗎?』

    「在我朋友中,應該是中下吧,畢竟只有大學學歷啊」

    『那你這個普通人的操作方式,就變得非常有參考價值,寫寫分享出來吧!』

    他的想法是,只要這個過程可以讓很多人用很少的成本複製,那分享出來的價值就相當不菲,在大家都想當超人,當教父,當英雄的世界中,平凡人的經驗才是最珍貴的。

    這標題中的埃及不是台灣,是當時鎖在身上,鐵一般事實的低薪與成長遲緩。

    這是我的出埃及記。

    我的人生,平凡無奇

    就如同在書中的作者簡介一樣,台南二中,中央大學資訊工程系畢業,我完全不是矽谷處處可見的那種駭客神童,直到大學才學會使用 BBS ,大學時期,寫程式的實作經驗不會比寫作業的時間多,跟當下因為電機資訊很夯才進去混文憑的任何人都沒有差別,想說畢業後會念研究所,進竹科,寫硬體 driver 相關的東西吧。

    大學期間,雖然沒有集中任何火力在寫程式上面,運氣卻讓我矇到了個終身受用不盡的能力:英文。

    因為沒有想加班加到爆肝,我積極訓練英文,希望之後能出國,回國做個有工程背景的 MBA。

    我大學大概就只做對了把英文聽說讀寫全都訓練好這件事情,大學的後兩年,我靠著這個能力兼了不少翻譯口譯的差,混到了很多贊助學生免費出國的機會。

    回頭看看,單單做對訓練英文這件事情,我那連半調子能力都算不上的資工專業,就硬生生地從只有 2300 萬人的台灣人力市場,晉升到以英語為主的全球市場,市場基數大了數十倍不止,雖然有簽證的問題,但是至少可以一試。

    人生處處在歸零

    畢業後,我實在找不到念研究所的理由,如果想出國念 MBA ,首先要累積的是工作經驗,於是我就這麼半路出家,當工程師去了。

    半年後,我跳到一間新創公司上班,碰到了一群拿著鍵盤出生的駭客神童同事們,在他們的熏陶下,技術的眼界也就這樣被迅速地撐開,開始去參加技術社群,雕琢工程的技巧,投身在軟體的技術領域中,MBA 的想法,也就越來越不重要,而無限延宕起來。

    既然想繼續當軟體工程師,矽谷絕對是不二之選,在實地比較過上海與北京的環境後,我跟老婆決定,要去,就還是要去世界之巔試試看。

    我們解決簽證的方式很簡單:當學生(這還是目前最直接的方法)。老婆在幾年輾轉比較過台灣公部門與私部門的工作環境後,也有出走的想法,於是我們決定,讓他去念個 MBA ,而讓身為工程師比較容易找到工作的我,以 F2 簽證(不能工作)進美國找公司贊助工作簽證(H1B)。

    把銀行中所有餘額提領出來後,我們跟人生梭哈,賭所有身家,換一個機會。

    當初的邏輯是這樣的,就算我們全軍覆沒回到台灣,這百萬左右的新台幣,再賺就有了,對生活品質完全沒有影響。但是一旦成功了,不管是薪水還是人生歷練的報酬,都大大超過了現有的生活品質。

    既然生活品質只有可能提升,不可能後退,那這個投資是個好標的,要戮力執行。

    一萬的小時的努力

    你一定聽過,要成為某個領域的專家,你必須要至少投入一萬個小時的努力吧?

    這努力是有但書的,你不能一直在做同樣的事情,你的努力必須要:

    1. 1. 有目的性:漫無目的地拉單槓拉到脫臼沒有什麼屁用。
    2. 2. 注重每次過程的調整,而不是立即的結果:換句話說,就是要在每個努力的過程中,嘗試不同的可能性,看看新的實驗下,會不會有更好的表現產出。

    很幸運的,工作後才開始大量練習的軟體工程能力在五年內迅速累積,技術社群與大量的 side project 加速了這一萬小時的過程,在前往美國之前,我寫程式的能力與經歷至少可以唬過矽谷面試官與其他程式設計師。

    跟高手們一起混,你才會慢慢也變成高手。

    我在一間相熟的矽谷 startup 中找到的 H1B 的贊助,落地生根。

    選擇,與別的可能性

    我是何其幸運,大學誤打誤撞選到的學科資工,跟不知為什麼訓練起來的語言英文都剛剛好在關鍵時刻推了我一把,換作是別人怎麼可能有這種際遇?

    你當然可以這樣想,然而我在矽谷遇到的台灣人,印度人,中國人中,這樣的操作基本上再普遍不過了:

    有個台灣女孩用 Marketing 證照課程過來,所有學費相加不用台幣 100 萬,已經找到公司贊助 H1B ,今年參加抽籤。

    朋友的公司前幾天面試到一個很強的印度工程師,從印度申請號稱『開學第一天就可以全職實習』的 ITU 學店過來,因為實力堅強,可以預見找到 H1B 贊助的可能性很高。

    最普遍的,還是千千萬萬個以留學為方法,漂洋過海而來的學生,前幾個禮拜,在 Salesforce 任職的 Benjamin Tsai 邀請了一眾在舊金山市區工作的台灣人到 Salesforce 一起午餐,整場約20 歲到 40 歲, 40 個 Twitter ,Yelp, Salesforce 資料科學家,軟體工程師包圍的環境中,我喊了一個問題:

    『臺大資工畢業的舉手』

    在場 70% 左右的人舉手並轉過頭來 XD ,他們畢業後,到柏克萊,史丹佛,卡內基美濃,MIT… 等等學校念完碩士後,就留了下來。

    順帶一提,老婆昨晚參加矽谷台美產業科技協會的職涯活動(ps, 然後小孩我一個人帶 XD),同桌都是 MBA/商業出身的專業人士中,有 80% 都是臺大畢業的 XDDDDD。

    看起來我的經驗不是個特例,原來這種出埃及記,早在很多特定學校系所中代代傳承著。

    出走的方式有千百種,你可以選擇你的方式。

    這裡沒有什麼是你做不到的

    我的出身平凡無奇,學歷中下,能力也是後天,沒有什麼是任何人做不到的。

    我在人生的某個點梭哈我的所有存款,歸零所有,選定地點,重新在異地出發,希望能擺脫低薪與成長緩慢的禁錮。

    這我的出埃及記,沒有任何傳奇的成分,沒有高來高去,來時的路,紅海也沒有淹回來,我不知道這其中有多少成分可以複製,但希望多少有點參考價值。

    ——————————————————————————————————–
    如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

    砍掉重練的過去,現在,與未來

    我寫了一本書,叫做砍掉重練。

    過去 – 記錄來時路

    去年年中的某一個清晨,在 Santa Clara University (我不是學生)旁邊,兄弟會週末的喧囂與派對才剛剛安靜下來的時分,一封出版社編輯的 email 突然間降落在我的信箱中,它是這樣寫的:

    『希望有機會與您合作出書,附件是我們初擬的主題與企劃大綱,如果您有興趣,可以進一步詳談。謝謝您!期待好消息!』

    我當時才剛寫部落格不到一年,從來沒有想過要寫書,但正是因為沒有寫過,所以想來挑戰一下,最糟的情況,就是書本印出來沒人買罷了,既然有出版社想要賭我一把,沒理由不來試試看。

    於是合約從臺北寄到舊金山灣區,簽完後,又從灣區寄回到了臺北,簽約完成,開始動工,整理,改寫,重寫,增寫部落格的內容,完成了砍掉重練這本書。

    會開始這個部落格,其實也只是為了自己想要記錄一路上學習的點滴,從台灣到美國後,有太多的東西需要重新適應,我不想在掙扎過後回頭一看,看不到那些驅使我改變的因素與事件,最後渾渾噩噩地成為大家口中那種驕傲的華僑,好像對台灣的所有狀況都有意見,一味讚揚美國,貶抑台灣,卻無時不刻回台灣享受健保(我健保早就停掉,回台灣的醫療是自費,我可以驕傲地面對那位名叫『拎北骨科』的網友)。

    我是台灣人,是那種想要掙扎著看看太平洋彼端的經濟體,工作環境,思維邏輯,生活方式… 等候,再把這些學習應用在有興趣地方的台灣人,這部落格,是我記錄來時路的媒體罷了。

    現在 – 部落格的股利

    從沒有想到的是,這個部落格漸漸地為我帶來些驚喜。

    好多在各處發光發熱的高手們因為看了部落格,開始跟我搭上線,不管是在世界有名公司就職的高手們,新創公司的傳道者,喜歡挑戰黑客松的忍者設計師,駭客們,還是久經歷練的跨國合資企業 CTO ,都被文章的內容吸引過來,主動聯絡。

    這些朋友開拓了我有限的視野,聊天,吃飯,喝咖啡,不管是對工作文化的討論,業界的小道消息,某位身旁朋友的成功案例或是掙扎,科技技術的演進與資本的流向… 等,常常有勝讀十年書的感覺,這是當初部落格開張時完全沒有想到的部落格股利。

    ps. 所以大家應該用力經營自己的部落格啊!!

    這些分享出來的秘密反饋到部落格的寫作中,我想要把這些綿角(台語)分享給大家,讓大家知道很多時候,別人成功是有相當程度操作的成分,技巧,與時機在的,而且如果有足夠的資源與訓練,這些成功很可能是可以複製到任何一個人身上的,你,我,或是整個台灣。

    未來 – 做沒做過的事

    雖然感受到的文化衝擊仍然存在,但是三年後的現在,我美國化的程度正在漸漸加劇,我開始把漸漸變淡的文化衝擊視為理所當然,沒有剛到時那麼無比的震撼了,怎麼辦呢?

    我應該重新擦亮我的眼睛?每天埋首台灣新聞,PTT鄉民文章,Facebook 中更新故鄉的新聞,痛苦,喜悅,掙扎,想法,然後還是以一個帶著台灣觀點的角度來描述這些文化衝擊?

    還是應該順勢而為,讓矽谷的地氣徹徹底底地流過我,把我變成可能完全不一樣的一個人呢?

    身在太平洋的另一端,我想我沒有選擇,後者是必然之勢。

    既然沒有辦法避開,我決定加速後者的進行!我要加重下列活動的比重。

    英文部落格

    其實我還有一個以技術為重的英文部落格,雖然處於半荒廢的狀態,但是有時仍然會接到矽谷其他公司或是創業家的聯絡(雖然大多以想要延攬工程師為主)。

    矽谷職場/創業的秘密有很多時候都是藏在口耳相傳的酒吧中,雖然有很多人試著寫下來,在網路世界散播,但是事實上,沒有電子化的秘密與個人經驗還是要有心人自己去挖。

    我會用力經營英文部落格,然後聯絡所有藉此聯絡我的技術/創業人員,看看這邊世界的秘密長成什麼樣子。

    當地社群,活動的參加

    我很喜歡參加 meetup ,但都是以技術為主,但矽谷其實還有很多創業社群舉辦的 meetup 可以參加,不管是溜冰,美式足球,滑雪,自行車,登山,巴西柔術,健身,卡波爺拉,還是文靜一點的創業社群,讀書會,地產投資社群,媽媽寶寶分享會(Support Group)… 等林林總總,美國人是個很注重應用群體力量變強的民族(哈哈, 跟台灣認知的不一樣吧?)。

    以往我都是敲邊鼓式地選擇性參加,接下來我想找幾個社群長期投入,深入美國社會的這一個部分,看看這部分的參與會不會擠壓出更深層的文化對比。

    如果大家知道灣區這邊有什麼好的社群活動,非常歡迎推薦。

    這些實驗的點點滴滴,將來也都會記錄在這個部落格中,我們一年後再來回顧,比較一下差別吧。

    最後,非常感謝大家在部落格寫作期間的支持,鼓勵,討論,挑戰,與質疑,這些正面負面的反饋,都曾讓砍掉重練這本書論證更加全面,觀點更加鋒銳。

    看完本書以後,也非常歡迎直接聯絡我,跟我討論,就像我 10 幾年來那位企業家饅頭尤達大師跟我說的,真理越辯越明。
    ——————————————————————————————————–
    如果喜歡我的文章,非常歡迎你填入您的 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 – 台灣工程師的矽谷故事

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

    手快一定打手慢,唯快不破的合作方法(中):Scrum 加速的方式,出招與變招

    Scrum 加速的方式,出招與變招

    先來一點心理建設,你的團隊並不會像是學了瞬身術的鳴人,馬上變成黃色閃光,相反的,團隊的加速,會是在你暖身後,習慣節奏後漸進式的達成的,感覺起來有點像是在學跳舞,一開始你很賣力地跟上每個節奏,隨著你的心,技,體慢慢地成熟,你會很自然地可以加快節奏,並在節奏中做出令人驚豔的動作。

    Scrum 實踐的秘密,可以說全都在於這個節奏之中。
    回到拳法的比喻上, Scrum 加速的方式有兩個層面,一者是出招速度的加速,由 Scrum Master 負責帶領,另一者是變招的速度,由 Product Owner 負責操刀。

    出招的速度:Scrum Master – PDCA

    Scrum 的執行單位是以 backlog 中的 user story 所組成,這兩個術語的定義我們下篇再談,現在請先把這些執行單位想像成待辦事項即可。
    Scrum Master 的角色,就是負責想辦法把這些待辦事項迅速確實地處理完成。一般而言,在好的 Scrum Master 的帶領下,團隊消化待辦事項的速度會越來越快,以我自身的經歷來說,團隊可以在同樣長度的時間下,吃下 2 到 3 倍的工作量,主要是因為 Scrum Master 做了下列三件事情:

    1. 團隊合作的加速 – 以短跑(Sprint)為單位,定期 Demo 進度

    在傳統的干特圖(Waterfall Model)中,所有的執行細節在開春第一天之前都全部定義好了,所剩下的,只是找個執行團隊,照表操課,把一切都執行出來罷了,如此簡單,應該不費吹灰之力是嗎?畢竟難的部分是腦力規劃的工作,用腦工作的,賺得本來就比用勞力工作的人多,不是嗎(XD)?

    紙面上一切看起來相當完美,只要我把這個完美的干特圖規劃交辦下去,每個人都應該知道每個人的工作與應有的進度,戮力執行,我只要定期開會,確定專案 on budget on time ,不就天下太平了?

    問題是,執行是人做出來的,在多人合作的團隊中,溝通成本認知成本隨著人數呈指數性增加,很可能的情況是,有多少人,就有多少種對進度與工作的定義認知,就有多少種實作的想法與優先順序,你坐在干特圖的另一邊,怎麼管理這些在干特圖上面看不到的事實?

    於 是在 Scrum 中,執行是以 Sprint (短跑)為單位,你可以依照工作的本質來定義 Sprint 的時間,一般而言,矽谷 RD 團隊會以 2 周為一個 Sprint 的長度,如果是客戶 Support 團隊,因為要快速地回給客戶,一次 Sprint 可以是一天或是兩天。

    在每次 Sprint 結束時,團隊必須要交付出一個可以 Demo 的產品,沒錯,不是報告,不是投影片,沒有陳核,不需要蓋章,你要直接刻出最終產品的某部分出來,呈現演示給『所有有興趣的人』看,接受所有有興趣人的測試與評斷。

    有沒有摸魚整天打開心農場,就可以從這個定期的 Demo 中看出端倪,為什麼大家資質差不多,你所消化的工作量就是比較少?是不是有什麼心理/生理/家庭上的轉折?有沒有需要幫忙?有沒有需要改進? Scrum 這種逢 Sprint 必 Demo 的方式,會讓團隊中所有人更負責任(Accountable), Scrum Master 也才能及時處理團隊問題。

    於是 Sprint 讓專案/產品管理者,能夠跟著每個 Sprint 的節奏,第一手地直接測試產品,參與雕塑產品成型,而不是只是坐在干特圖的另一端,遙想專案結束的那天,真實產品與理想中產品慘痛的差距。
    隨著 Sprint 的推進,團隊與產品/專案經理的溝通與默契越來越好,團隊對工作的細節也漸漸熟能生巧,彼此間的溝通與合作漸漸進步,每次 Sprint 能做的事情越來越多,動作越來越精准,速度自然越來越快。

    2. 剷除障礙的加速 – 把浪費時間的因素一個個剔除掉

    Scrum Master 的另一個任務,就是剷除讓團隊慢下來的因素。

    一 開始合作的時候,團隊還沒有發展出彼此的默契,有時候 A 在等 B 把某件事情做完,但是 B 並不知道 A 在等他,慢慢處理比較不急的 C 的問題,於是 A 就慢慢逛 Amazon 買電子書等 B ,因為事情不緊急,B 跟 C 也就慢慢來,輕鬆來,團隊進度就在這樣的慢慢等待中度過,等到花兒也謝了。

    或是 D 與 E 在溝通上還沒有很純熟,每次 D 做出來的東西 E 都不能用,必須要回去跟 D 溝通修正,一來一往,又是時間的浪費,偏偏 D 跟 E 都是大忙人,怎麼都沒有想到下次實作之前,先坐下來把東西都定義清楚。
    Scrum Master 於是適時介入,用 Daily Standup 或是 Sprint 結束後的 Review Meeting 及時處理讓團隊慢下來的情況, A,B,C 在下次 Sprint 的過程中,要怎麼更有效率地把工作優先權定義清楚? D 與 E 這種來來回回的失誤發生多少次了?要怎麼在根本上剷除掉這個問題?有沒有團隊成員遇到自己沒有辦法解決的問題?或是本業以外的問題?跟其他團隊溝通合作的問題? Scrum Master 可以怎麼樣幫忙解決?

    更有可能的是,deadline 趕不上了,從管理層的角度來說,有沒有些東西真的沒有那麼重要,可以先捨棄不做?然團隊趕上客戶的時程?

    在這裡 Scrum 借用的是 Toyota 在生產線加速中的理論,剷除障礙(impediment),減少浪費。

    3. 團隊溝通上的加速 – Daily Standup Meeting 增加資訊交換的速度

    一般的公司,大概是一周跟團隊開一次會議,會議的過程要不是照個甘特圖盯進度,就是照本宣科,聽上級談論他的家庭與奮鬥歷程(那些甘我屁事啊?)。
    Scrum 在每個 Sprint 開始與結束分別有兩個 Sprint 的會議,我們下篇會談到,在這裡我想提到的事,是你看到工程師每天早上站 15 分鐘那場。

    每天早上同一時間,Scrum Master 會聚集所有團隊成員,依序問他們三個問題:

    • 1. 你昨天做了什麼?
    • 2. 你今天要做什麼?
    • 3. 有沒有遇到阻礙或是卡關?
    前兩個問題讓團隊成員彼此交換工作上的訊息,讓大家比較有工作的背景資訊 ,重點在第三個問題,第三個問題讓負責人把問題『及早』丟出來,用所有團隊的人力資源集思廣益,如果這是個技術性的問題,其他成員可能有更好的想法或是解法可以用,如果這是產品定義上的問題,Product Owner 或 Scrum Master 可以及時跳入澄清解釋,如果這是政治上,管理上,或是合作上的問題,Scrum Master 要想辦法再下一個 Standup Meeting 之前給出一個交代。

    非常注意的是,這三個問題都不是為了做進度,Stand up meeting 是在幫助團隊溝通跟發現問題,而不是在交代自己的工作,如果每天都有交出成績的壓力,團隊成員會有做短視決定的誘因,這是 Scrum Master 要儘量避免的。

    (這邊感謝網友 Pengyu Chen 的討論與協助)

    團隊的 Manager (有權管加薪人事的人) 如果參加這種 Standup Meeting,最好一句話都不要吭,不然會使隊友不敢說出自己的困難或是承認自己需要幫助,這對團隊的 Scrum 是有害的。

    每個 Standup Meeting 都像是一次專案的心跳,把需要的資訊與資源送到所有需要的組織成員手中,心跳正常運作,團隊資訊交換的速度大大提升,進度與挑戰所有人都清楚,Scrum Master 可以一手掌握,比起週會的反應速度至少快上 5 倍(一周一次 v.s. 每天一次)。
    Scrum 的團隊大小在 3 到 9 個人之間最佳,3 到 9 個人回答這三個問題,不應該超過 15 分鐘的時間,如果超過 15 分鐘,一定是哪裡出錯了。
    Scrum Master 的角色是根據二次世界大戰後讓日本製造業起死回生的 PDCA (Plan 計劃,Do 執行,Check 審核,Act 改善) 理論而設的,上列團隊合作的加速,剷除障礙的加速與團隊溝通上的加速的練習,會在每次 Sprint 之後檢討改進,每次 Sprint ,就是一個 PDCA 的循環,不斷改善,出招速度自然不同凡響。

    變招的速度:Product Owner – OODA Loop

    你知道在韓戰的時候,蘇聯的飛機其實在性能上比美軍的飛機還要好很多嗎?但是在真實空戰的時候,美軍卻能夠以 1 比 10 的比例打掉蘇聯的戰機,沒錯,1 比 10 !平均起來,美軍每被打掉一架飛機,蘇聯已經掉了 10 架飛機了,也就是說,蘇聯蓋飛機,訓練飛行員的速度要比美軍快 10 倍,才能跟美軍打上平手 XD。
    主要原因在於美軍軍機,可以讓飛行員的反應速度快很多,在蘇聯飛行員看到敵機,準備交火的時候,美軍飛行員早已經扣下機鎗的板機。
    沒錯,變招快,正是手快打手慢!
    Scrum 中 Product Owner 這個角色,就是為了團隊的方向與反應而設立的。Scrum Master 只管團隊出招的速度,方向與變招的速度則是由 Product Owner 負責。
    既然 Scrum Master 與團隊的主要工作是專注消化所有的待辦事項,把消化速度變得飛快,總需要有人負責出來制定這些待辦事項的細節與優先權啊,沒錯,Product Owner 正是掌管這兩項重要工作的角色。
    如果方向不對,快速地執行只是加速死亡的過程而已,理想中,Product Owner 必須要是個對產品與產業生態非常熟稔與敏感的人,富有業界的經驗與人脈,能夠在大環境變化時迅速察覺,並帶領產品改變方向。
    在 Growth Hacking 這麼興盛的年代,他對市場的理解並不能僅止于第六感,他必須要能夠以數字或是實驗說服(而不是強迫)團隊相信他所擘劃產品或專案的未來。
    Scrum 在這邊的架構世借用美國空軍的決策框架:OODA Loop,Observe(觀察),Orient(研究),Decide(決定),Act(行動)。

    1. Observe(觀察)

    身 為 Product Owner 你必須要在 Observe 這個階段中搜集所有有用的環境變數,理想中,Product Owner 要花超過 50% 以上的時間在客戶與市場中感受與打聽,Product Owner 是團隊的眼睛與耳朵。

    市場或是客戶如何反應我們上次推出的產品更新?他們喜歡什麼?不喜歡什麼?還是完全不感興趣?對手有沒有新的動作?有沒有新的對手加入戰局?市場對這些 player 的反應又是?
    對手被用 150 個 mm 美金買掉了,這數字怎麼這麼少?我們以為同等公司的產值至少可以賣到 300 個 mm,這個變化打亂整個團隊的退場機制,怎麼回事?

    2. Orient(分析)

    分析 Observe 階段所接收到的訊息,消化所有環境變數的 delta(變化) ,更新你之前所認知到的現實。

    從數字上面看來,上次的產品更新沒有騷到使用者的癢?是因為產品速度不夠快,還是這功能根本可以砍掉不做?新的對手一直在做我們之前沒做過的功能,他們的假設是什麼?有什麼樣的市場機會我們根本整個沒有看到?

    對手賤價出售的意涵是不是因為我們所在的產業其實含金量不高?如果真的如此,我們有沒有籌碼切入那含金量更高的區塊呢?

    3. Decide(決定)

    你不是光領錢的顧問,你是大將,負責團隊的總成績,觀察與分析後,你必須要迅速地歸納所學,決定下一步採取的行動。
    新對手到處找中小型企業合作,打的是鄉村包圍城市的算盤,我們的根基比較深,品牌名聲比較響亮,那就直接大張旗鼓地搶住那幾間最重要的大企業客戶,金角銀邊草肚皮(圍棋),我們先把所有重要的角加速拿到,趁對手還沒有站穩陣腳,在大企業客戶還競爭不過的時候,把這些灘頭堡搶下來。

    4. Act(行動)

    制定好策略後,就用 Get Shit Done 的精神戮力執行吧!衝到下一個檢核點。

    5. Loop(讓一切循環)

    跟 PDCA 一樣 OODA 是個循環,不是一個 Water fall (一條鞭法),雖然不像 Scrum Master 一樣,每個 Sprint 做一次循環(市場環境不太可能在 2 周之內改變一次),但每個 Sprint 就是 Product Owner 檢核產品 demo ,審視產品發展的優先權的時候。
    他必須要好好試用現在完成的產品進度,跟 Scrum Master 坐下來討論下一個 Sprint 要完成的待辦事項,幫 Scrum Master 調整這些待辦事項的優先權,要補的,要拿掉的一次搞定,然後立刻把頭伸回到客戶與市場中觀察,分析。
    幾個 Sprint 以後,如果感受到產品或是市場有異,產品有必要因而改變,他會招集團隊解釋分享他的觀察與他所做的決定,然後把這些決定,反應到接下來 Sprint 的待辦事項與其優先權中。

    一切都在於比對手快的節奏

    Scrum 的精神就在他一個 Sprint 接著下一個 Sprint 的節奏中,跟跳舞一樣,等你開始跟上節奏,在節奏中能夠放手表現的空間會越來越大,動作的品質也會越來越好。
    OODA Loop 的創始人 John Boyd 相信,只要你的 OODA Loop 比對手快,你就有辦法在對手 OODA 循環完成之前切入他的 OODA Loop 中搞怪,攔截他的決策,防堵他的陣線,甚至擊落他,無獨有偶地,李小龍所創的截拳道中所謂的『截拳』理論也是一般。
    只要你出招的速度比對手快(Scrum Master 所掌管的 PDCA),變招的速度對手跟不上(Product Owner 所控制的 OODA Loop),你就有辦法用 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. */

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

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

    手快一定打手慢,唯快不破的合作方法(上):Scrum 異于常人的基本假設

    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. */

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

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