George Yeo 網路自強號

陳建隆：創業現場實況——你的「團隊債」是不是債台高築？（上）

科技新創榜 Posted by: 懶泥陳 2015 年 01 月 08 日    in 觀點, 陳建隆的創業者觀察

前一陣子，有人問我，你們究竟在創什麼業？到底每天這麼忙，工作都在做些什麼？當時想了想，腦袋中晃過一個念頭，我們是不是都在瞎忙！？越忙越瞎，越瞎越忙。

可以說，每天的工作情境都不太一樣，但最常做的一件事情，莫過於「解決問題」這件事情。這個解決問題的範圍很大，從解決客戶在產品遇到的問題，到我們產品不賺錢怎麼辦？團隊中起了衝突要怎麼面對，是否有流程可以參考讓衝突造成的傷害變成團隊的養分？團隊中有夥伴離開了，是否能有機會挽回以及是否要挽回？

每天看見的問題很多很多，解決的很少，衍生出來的問題總比解決的還要多！後來逐漸觀察跟經歷過一些事情，慢慢的讓我有了一些體悟。

說一個平常軟體開發時常會遇到的情境故事好了。

當在開發產品或者是產品新功能的時候，不管進度表看起來是多麼輕鬆，總是無法避免在某個時期又面臨重大的壓力。當發現自己陷入了難關，必須選擇把事情「做好」或者「先快速做完」，自己往往會訴諸於「先快速做完」，之後再回頭修補。

當我這麼對自己說，或者對團隊還有客戶承諾時，我是認真的。可是往往在下個開發循環會帶來新的問題，於是焦點就轉往去解決這些新問題了。沒錯，這在軟體工程上有一個詞，就叫做「技術債」。

當你欠的債不還，往往就會由這些債務再衍生出利息（新的問題），直到你無力負荷為止。

好吧，在開發上，這類的技術債務我往往能避免就盡可能避免，因為這類型的衍生問題想要徹底解決的成本實在是很高。往往之後所要花的時間，都超出想像的久，幾次之後，對於這類債務的警覺性就非常高，大概就跟有人忽然要借我錢或者是要我去 ATM 轉帳的感覺吧！

但在實際的每日工作現場，關於團隊成員的類似事件頻頻發生，我們卻對「團隊債」 視而不見沒有警覺，往往使用很粗暴直接的方式去解決問題或者乾脆就逃避問題當沒這回事發生。

什麼是團隊債？什麼是造成團隊無法凝聚、上下一心的負面因子？

團隊債就是當團隊的領導者，因為壓力（金錢、時間、交情、 想當好人）作出類似下方的決策，而不是根據公司的使命、願景、文化等，去決定團隊成員每日工作的內容，這樣就會產生「團隊債」。

    這很快、很簡單就可以做完，做完了就有錢拿 （拿技術換錢）
    幫忙他們做一下這個沒有關係，說不定下次就換他們幫我們了 （拿技術換資源）
    幫她做一下這個，說不定……嘿嘿嘿 （拿技術換愛情……?）
    收不到尾款，想說日後好相見，就不了了之

團隊債也有可能是團員因為個人因素（喜好、不在乎、懶散、專斷獨行）做出類似下面的決定

    我想要玩玩新技術（iBeacon、 Apple Pay……），而不是選擇對整個團隊來說最佳的解法 （工程師喜愛新挑戰的心態）
    這做法反正也不關我的事，所以有什麼問題也就隨便啦，真出了問題就「還不是你們當初……所以才害我……」
    我覺得一定要這麼做，如果不這麼做我就……（威脅）
    這樣做最快最簡單，我之前就做過了，聽我的就對了……（工程師的自尊）

簡單說團員如果思考時考量自己遠大於團隊， 都從自身利益出發而不管團隊他人感受時， 往往也很容易產生「團隊債」。在各種壓力之下，追求極短期的效果或者僅求渡過眼前的難關，往往會成為解決方案。

止痛劑快又有效地去除疼痛之時，往往也剝奪了深入了解問題發生的根本原因。

一拖再拖，一再使用止痛劑後，當短期手段不再有效，往往帶來長期負面影響，會讓整個團隊要花上更多的時間弭平，而後才有辦法繼續前進。


陳建隆：創業現場實況——你的「團隊債」是不是債台高築？（下）

科技新創榜 Posted by: 懶泥陳 2015 年 01 月 09 日    in 觀點, 陳建隆的創業者觀察

止痛劑快又有效地去除疼痛之時，往往也剝奪了深入了解問題發生的根本原因。

一拖再拖，一再使用止痛劑後，當短期手段不再有效，往往帶來長期負面影響，會讓整個團隊要花上更多的時間弭平，而後才有辦法繼續前進。

短期有效不管長期的解法只會造成團隊債的快速累積，那有沒有讓團隊凝聚的正面因子，可以用來清除團隊債的？

從馬斯洛的需求層次理論來看，社會需求 (Love & Belonging needs) 在金字塔中的層次並不高，這說明了社會需求是很基本的需求。可是不同的人之間對於社會需求的理解卻千差萬別。

好吧，工程師這種生物，對於人情世故或社交原則的認知往往是糟糕透頂，而這往往也是造成團隊債發生的主因之一。而造成人情世故糟糕透頂的原因， 跟他們所受的訓練脫不了關係。純粹以理性邏輯的思維做判斷跟推斷，理直氣壯的說話跟做事風格，往往很容易莫名的傷害到團隊成員的自尊心或感受，更別說當兩個人為了自己認定對的事情在做爭論時，總是要爭到贏才開心，贏了爭論，卻輸了團隊氣氛。

恩， 還不會檢討反省， 因為有理走遍天下……

這件事情在我們團隊，再常發生也不過了，因為四個資工科的男生同學，想像一下那畫面就知道。但幸運的是，我們在不斷犯錯的同時，也學會到了一些事情，下面是我覺得對於團隊有益的因子。

正面因子1：尊重他人是有益的

讓工程師認知到尊重他人是有價值的，這些人際交往也是必要的。

    使用 80-20 法則，關於禮節，要記住三件事：尊重別人，傾聽別人的話，每天洗澡。如果你能做到這些，你的禮節已經達到80分了。
    — Kirrily Robert

有時候別人讓你覺得很煩，但你還是得要認真地聽他們在說什麼，確實需要付出努力。而為了尊重他人，必須聽他們在說什麼，這有時候的確是挺令人容易發怒的。

為何要擁抱團隊的禮節？主要是讓人覺得你這個人是可以共事的。

還記得在美國矽谷的一次面試經驗，是全公司的人出來與我一對一或者二對一的交談、詢問問題。每次面試都大概四十分鐘到五十分鐘，時間是一整天。後來在與公司老闆面談時，很好奇的問了他們為何採用這樣的方式去面試一個要進來的工程師，因為這樣費時耗工的面試方式，當時是我第一次經歷到。

他說這樣做的好處是透過這樣的面談，可以很清楚地了解面試的人，在面對問題時，他的處理跟思考的邏輯以及流程是否是他們想要的。先是聆聽問題、確認並釐清問題、思索問題、當場回答解說問題，透過這樣面對面地交談，員工可以知道他有沒有辦法與這個人共事？

而每個人在乎的點不盡相同，是否聰明、是否能融入團隊、面對問題或衝突時的處理方式是否能夠接受等等。最後他們的錄用流程就是詢問每個員工是否願意與這個面試的人共事？只要有一個人說不，就不錄用。

恩，我記得最後我沒有被錄取。

正面因子2：建立一個人人都熱忱相信的願景

這個願景就是企業的 Mission Statement，之前有一篇文章在分享這件事。

這件事情，應該是團隊的領導者應該謹記在心，並且需要積極的去尋找跟定義的。如果說領導人已經先有了這樣的願景， 可以透過這樣的願景去尋找你團隊的成員。如果說你已經先有了團隊的成員，在不放棄任何一個人的前提下，就需要團隊每個人共同去深入的探討並找出真心想要相信的事。

相信一件事情， 是有力量的。

一個願景的驗證方式，就是你在聽到這個願景時，是否願意成為這個項目的一份子。當團員擁抱那個願景，他們就會發自內心的產生熱情， 激發出創新的活力。

正面因子3：建立擁抱錯誤的團隊文化

新創團隊很容易犯錯，這個錯誤的定義比較像是選擇了錯誤的方式去解決了錯誤的問題。錯誤的問題靠正面因子 2 去修正跟完善。

但選擇了錯誤的解決方法， 則需要有一個擁抱錯誤的團隊文化去不斷地學習跟進步才能去優化選擇。

    愛迪生（Thomas Edison）在試圖找出能夠讓白熾熱燈泡變成實用產品的金屬絲時，曾說過一句名言：「我並沒有失敗七百次，我一次也沒有失敗過，我成功地證明了那七百種方法是行不通的。當我排除了那些行不通的方法時，我就會找到那個成功的方法。」 – 別在稻殼堆中找麥粒

當然，一個新創團隊很難去失敗或犯錯七百次，因為每次犯錯都有相對應的成本。之所以不是去建立一個避免犯錯的文化，而是擁抱錯誤的團隊文化是在於創業本來就是在尋找一個團隊可能成功的方法，不敢去嘗試自己團隊可行的方法，只願意去做自己會做的事情， 是很難在激烈的競爭中存活。

別人成功的路很難複製，因為你不是別人。

    關於創造熱情，我認為其中最重要的一個就是要歌頌錯誤。如果你做一件零風險的事，那麼你的報酬率是零。因為如果沒有風險，那你為什麼會得到報償呢？

    但是什麼是風險呢？風險就是壞事會發生的可能性。

    如果你把風險降為零，那還有什麼東西也跟著降為零呢？當然是成功的機率也會跟著降為零。這也就是為什麼有些公司在創立初期都會抓住難得的機會。他們取得了成功，在接下來的日子裡卻又讓那些成果化為烏有，因為他們害怕失去已經擁有的東西。這種患得患失的行為，終究會導致失敗 — 團隊之美

誠實的去面對錯誤， 跟從錯誤中學習， 把錯誤的成本變成團隊的學習成本， 是不斷讓團隊變好的一個很重要的文化。

而讓團隊的成員認知到，犯錯了，不是他一個人的錯，而是團隊做了一個合理的決定， 但是最後的結果很糟糕。而這也只是說明了團隊冒了一次險， 碰上了出錯的機率。

如果不斷進步， 下一次會更好， 而明天也會更好的！


三種工程師——Coder, Hacker and Architect

鉅亨網新聞中心　(來源：Inside 硬塞的網路趨勢觀察)　2015-01-14  16:30　

從小時候開始，工程師在我的心目中就不是一份太高尚的職業。

工程師必須要用沒人聽得懂 （也沒人有興趣） 的語言，去架構出能被使用的東西。這些東西可能是建築物、車子、機器、電路板、軟體等等⋯⋯

一般大眾會將一樣產品的功勞歸給「計畫者」（如 Steve Jobs） 以及設計、行銷、管理者，而工程師似乎就是一些可以被替換的零件，沒有人會記得他們的名字，而他們所做的事情也可以被其他人所取代。

後來我自己加入了軟體工程師的行業，對於工程師的想法也有所改變，在這邊跟大家分享一下我對於「工程師」的看法。

雖然在中文裡，大家都叫做工程師，但其實根據工程師喜歡做的事情、心中對於程式的想法，可以分成幾種類別的人。這邊簡單的以我的認知，把寫程式的工程師分成三類。

第一，寫程式的人 （Coder、Employee、Worker）

這種類型的人單純的只是為了工作、功課、任務而寫程式，雖然職務名稱叫做工程師，但是寫程式對他們來說只是獲取成績、金錢的工具，寫程式對他們來說枯燥無味，但為了生活，他們繼續產出他們的程式碼。他們喜歡簡單的任務，最好是一看到就知道要怎麼做，最好有別人的程式碼可以直接套用。而當他們的程式可以過關，他們就開心的回家睡覺去，連一秒都不想看到程式碼。

第二，有目標而寫程式的人 （Hacker、Doer、Entrepreneur）

這種類型的人並不是因為熱愛「程式」本身而開始寫程式，他們寫程式是為了要達成某些目的。這些人雖然不是天生的程式高手，但是很會用別人寫好的套件去兜出一些應用，當有一個好的點子時，他們第一件事不是去想：「我本身不是學這個的，我要怎麼樣才能找到別人來幫我做⋯⋯」他們會去找既有的資源架構，嘗試做出原型 （Prototype），有時候雖然做出來雖然有點破 （像是下圖右方的機器人），但他們樂在其中，並且常常不眠不休的寫程式。我自己會將 Mark Zuckerberg（Facebook）、Drew Houston（Dropbox）、David Karp（tumblr） 這些創辦人歸在這類。

第三，熱愛程式本身的人 （Architect、Theorists、Change Maker、Geek）

這類工程師喜歡程式本身，他們欣賞程式設計的架構、可擴充性、可被測試性。他們喜歡最新的科技，並且會主動的去接觸、試用它們。他們喜歡寫有架構、能夠被別人重複使用的套件 （Library）。他們樂於貢獻自己所知所學到這個世界，並且常常在想有沒有什麼最新科技、理論能夠套用到某個工具或服務上，讓這個服務更快、更大、更好。他們是三種類型的工程師中技術最高超的一群 （如上圖左方的人），也常常是能夠改變整個程式世界遊戲規則的人。如 jQuery 的發明者 John Resig、Linux 發明人 Linus Torvalds、個人電腦發明者 Stephen Gary Wozniak，還有許許多多的 Google 工程師們。

寫到這裡，我忽然想要澄清一個大眾對於工程師的誤解。當大家看到一個東西、軟體不好用，或是 UI、UX 設計上有問題時，常常會說製作這個東西的人用「工程師思維」在設計。又或是團隊在討論一樣東西時，PM（Product Manager） 或管理者常會對工程師說：「你那是『工程師思維』，站在『使用者』的角度來說⋯⋯」工程師常因為大眾對自己身分的刻板印象，被弄到連發言權都沒有，或是提出的意見不被重視，但事實是怎樣呢?

如上面所說，工程師分成三種。而所謂的「工程師思維」，充其量只能形容第一種人 （Coder） 的所作所為。

Coder 的工程師思維

Coder 因為只想把事情做到交差了事，因此他們每天的任務就是把上面說要做的事情完成，一分不多、一分不少。因此，假設管理者、PM 在 Spec、Feature 中沒有把整個使用流程、步驟、使用情境全部拆解成任務，這些 Coder 是不會自動幫忙把 UX 做好的，當他們發現這個系統使用起來會有問題，他們會選擇默不吭聲，因為提出一個好的意見，只代表自己的工作會增加 --- 而這是讓 Coder 最不開心的事情。

在充滿 Coder 的工作環境，做出來的東西就有機會充滿「工程師思維」（不好用、UX 爛），因為這些東西只是一堆 Feature（Coding 任務） 的結合。要營運這樣的公司必須要有很強的 PM 和設計者，能夠有效管理員工、定義產品，才能讓 Feature 拼湊出好的產品。

Hacker 的工程師思維

而第二種人 （Hacker） 是最討厭別人說他們有「工程師思維」的人，因為他們其實是普通人和第三種人 （Architect） 的混種。Hacker 知道怎麼完成一樣事情，但技術沒有這麼高超。他們重視目的和 UX，因為他們喜歡使用自己做的東西。當公司要規劃一項新產品時，他們不會因為這項新產品做起來簡單、輕鬆，工作負擔輕而開心 （Coder 會），相反地，他們會因為這些東西好用、創新而興奮不已。當有任務下來，Hacker 不會讓使用的細節從眼前溜過，他們會默默的將設計不完整的地方補完。有時候他們甚至會和管理者爭論，這個 Feature 到底該不該有，因為他們認為使用者不會喜歡。

假如在公司沒有權力，Hacker 其實是角色最尷尬的人。至於尷尬在哪⋯⋯，我想這個秘密就留給 Hacker 們了。

Architect 的工程師思維

而第三種人 （Architect） 的確是有工程師思維，但工程師思維對他們來說應該要是種稱讚。Architect 的工程師思維源自於兩個面相，第一個是他們喜歡有秩序、可以永久保存、重複使用的東西，第二個是他們無私的想要貢獻自己做出的東西給這個世界。當公司或團隊在討論時程時，Architect 的第一個思維會讓他想要阻止大家天馬行空的亂提點子，因為他知道這些點子拼湊在一起，程式或產品架構會是個一團亂 （但這時候 PM 會說：「那是因為你從工程的角度去想，但使用者使用起來不會這樣覺得，你這是工程師思維」）。但實際上，一個好的產品設計，從工程上面來看應該也要是規律、優雅而有深度的。若工程設計本身具有規則，使用者在使用時是可以隱約感受到其背後令人舒適的邏輯的。因此我認為 Architect 喜歡秩序的工程師思維是好的。

而 Architect 的第二種思維 --- 貢獻於整個世界，有時候對於末端使用者 （也就是我們所稱的「大眾」） 來說，會是一個小災難。Architect 會希望把一個東西做到擁有很大的擴充性、以及很多的功能，如此一來任何一種人都可以視自己的需求，去變化使用這個東西。而這種想法最知名的例子，就是蘋果電腦的發明人沃茲尼克，曾和 Steve Jobs 爭論，它希望電腦上面要有很多可擴充的插槽，如此一來各類的科技人才能視自己所需去改裝電腦。（後來 Steve Jobs 沒讓他這樣做，沃茲尼克還小生氣了一陣）。

但 Architect 的第二種思維，常常是他們做出來的東西能影響這整個世界的關鍵。Internet、Linux、python、ruby、C 語言⋯⋯Architect 創造出來的東西，無私的奉獻給這個世界，成為科技發展的基石，因此一般大眾才有機會使用簡單易懂的科技產品。

在我們的環境中，有太多的 Coder、也有許多從 Coder 變成的 Hacker（他們的差別只在有沒有目標，還有去實作的毅力），但比較少真正願意奉獻、熱愛程式的 Architect。

至於我呢? 目前還只是個有目標的 Hacker 而已，距離真正厲害的工程師還有很長的一段距離。但自詡為一個 Hacker，還是希望自己能夠繼續做出對世界有貢獻的東西 （ 之前做的 Timego 也該繼續更新了 ）。

當你有一個想法，並用自己的雙手實現出來，然後按下一個按鈕，讓幾百萬人都能分享你的成果。我想我們是世界上第一代能夠有此經歷的人。 --- Drew Houston in "What most school don't teach"


高學歷、高薪「廢業」逐夢 人生小停機

2015-03-02 09:16:42 聯合報 記者郭政芬、王慧瑛／新竹市報導

年薪百萬的科技新貴，人人稱羨，但近年愈來愈多的高學歷科技新貴，厭倦一成不變技術性工作，放棄百萬高薪，離職「廢業」尋著夢想創業，走出自己的路。

「嘗試走一條自己從沒走過的路。」交大材料所畢業的黃秋淵，退伍後順利進入台積電，年紀輕輕就有百萬年薪；但面對每天超過十二小時的長時間工作，日漸倦怠。去年八月離開台積電，創立「以樂造型氣球工作室」。

黃秋淵說，和每天上下班領固定薪水相比，創業得面對收入不穩窘境，無論時機好壞都得承擔；幸而有家人支持，讓他勇往直前開拓市場。現在社區大學、學校社團、園遊會活動，都見到他的身影。

政大圖書資訊與檔案學研究所畢業的林美玉，在中研院、交大客家文化學院服務多年，去年底辭去穩定工作，當起滷味店老闆。

她說，朝九晚五的工作讓她感覺心不自由，開店賣滷味，除擁有自己的事業，生活也過得更自在。

擁有清大碩士學歷的林宜璇與學設計的江新燕同在有機店工作 成為知己，兩名女孩放棄安定工作創業創立「樸食小舖」，幫助有機小農。去年搬到苗栗，熱情鄉親認為年輕人還是該找份安定工作，好心介紹「郵局有在招考」。但兩人從沒動搖。

「再辛苦都要開心過生活」，林宜璇說，「對的事情，時間到了就去做，進退都有原因，只要自己心裡不退」。

國立新竹教育大學特教中心主任孟瑛如說，許多人成長、求學都順著父母期許，選擇名校、熱門科系，忽略思考究竟是不是自己的興趣。直到有能力、有勇氣改變時，才終能「廢業」圓夢。

廢業，是日本近年流行語。指重新思考人生價值，寧放棄安穩工作，有勇氣為夢想出走，讓人生小停機，尋覓生命中最重要的東西。

孟瑛如表示，過去高學歷的人很少創業，因為一畢業很容易找到年薪百萬元的穩定工作。但近年風氣改變，勇於主動「廢業」，追求心中的願景，從熱情中找到自己的方向。