如果你在軟體公司當中擔任 PM 職務，你的公司還沒有導入 Scrum 的話，你應該要導入 ，而且馬上就要。

一來，像是 Scrum 啦、XP 啦、敏捷開發啦、精實創業啦…雖然已經在國內外都已經講了好幾個年頭，但對很多人來說還是新奇的 Buzzword，導入這些號稱高效的工作方式，應該有助你提昇績效；另一方面，在 Scrum 裡頭「沒有 PM，只有 PO（Product Owner）」這一點，如果被錯誤解讀的話，那實在是種危險的想法，簡直就是思想的毒瘤。

如果改天有人不明就裡，也說要導入 Scrum，那麼，「沒有 PM，只有 PO」，就可能會讓公司誤以為可以開除所有的 PM，抹煞你多年來的貢獻，叫我們回家吃自己 — 我們絕不容許這樣荒唐的事情發生。與其消極地防堵有人提出這樣的想法，我們更應該主動出擊，先下手為強，率先主動導入 Scrum，並且要主導對 Scrum 的話語權，把持對 Scrum 的詮釋權，把 Scrum 變成我們想要的樣子。

我們要趕快要求公司打散原本的各部門，把人員編入多個小組，然後由我們 PM 來親自擔任每個小團隊的 PO－沒錯！「沒有 PM，只有 PO」真正的意思就是：導入了 Scrum 之後，PM 就會變身成 PO。PM 與 PO 這兩個名詞都是 P 開頭，而 M 與 O 這兩個字母在英文裡頭中間只差了一個 N，只要導入 Scrum，PM 就會自動升個兩級，變成 PO。

接下來才是挑戰的開始：你要能調和各種衝突的成分，兼融舊觀念與新作風，將績效管理與 Scrum 做一番完美的混搭。

你發現，就算你把職稱變成了 PO，但你好像沒辦法照著書本、或是那些貴森森的 Scrum 課程裡頭所講到的 PO 那樣行事，你的主管、更上層的老闆還是習慣你應該要有作為 PM 的產出，展露作為 PM 的績效。書本裡頭說，PO 不應該花時間做文件，因為 PO 擁有整個產品的最終決定權，應該要花時間思考產品、定義產品的價值（當初你學到不用做文件的時候，內心還不禁竊喜一番）。可是呢…老闆還是想要看到企劃書與投影片，所以你還是得做企劃書與投影片。而且要做什麼產品，做成什麼產品，你上頭還有好幾層的老闆可以隨時推翻你的決定。

即使如此，你還要表現出你在導入 Scrum。看來你只有一種方法，就是：Scrum 說要做的事情，我們都去做，Scrum 說不要做的事情，一樣都要做。

我們先來搞定團隊組成的問題。首先，由於公司原本人數的關係，所以沒有辦法讓每個 PM 變成 PO 之後，都可以有自己的一組人馬，導致我們得要把多個原本的 PM 放到一個團隊裡頭。說起來，如果我們把一些原本的 PM 放到新的團隊中的時候，變成其他 Scrum 需要的角色，像是擔任 Scrum Master，就可以解決、或紓緩問題，但我們不能這麼做。

教科書上說，Scrum Master 這個角色本身不負責開發過程中的實際工作，而是要從旁擔任教練的角色，觀察團隊成員，發掘團隊的問題，確保團隊中的成員都能遵守 Scrum 的遊戲規則，在開發過程中不被小問題卡住，讓整個團隊的 Scrum 運作順暢 — 這種角色實在是太沒績效了。就算兼任，也會影響我們拿來做投影片的時間，而且徹底違反 PM 在導入 Scrum 之後就會變身成 PO 的基本原則。就算我們當初為了證明我們具備在公司內導入 Scrum 的能力，我們都還去上了課，拿了 CSM 證照，但是，我們不可以當 Scrum Master。

換成讓來自其他部門的成員擔任 Scrum Master 呢？奇怪，沒有人想當，不知道是誰把 Scrum Master 沒有績效這種秘密洩漏出去的。也罷，讓外人擔任 Scrum Master，豈不是白端端把到手的 Scrum 詮釋權拱手讓人？讓菜鳥 PM 來當 Scrum Master 呢？雖然可以有效降低新人的績效，但是讓新人對你怎麼跑 Scrum 指指點點，想起來也不怎麼舒服，那還是來當 PO 吧，就算你到職不到兩個星期，我們也勉為其難讓你一起來 own 這個產品。

於是我們的成員名單拍板定案：在一個大概十個人左右的 Scrum Team 當中，有四個 PO，沒有 Scrum Master。四個 PO 也不可以相互代理，免得搶了彼此的績效。

這跟書本講的不一樣，但做事不應該墨守教條，每個團隊都應該要摸索出一套適應自己的方式，這就是我們的方式，這就是我們的 Scrum。

來跑第一個 Sprint 吧！因為我們要導入 Scrum，所以，Scrum 裡頭提到的所有會議，我們統統都要開。在每個 Sprint 開始的 Planning Meeting，每天的 Daily Standup Meeting、每個 Sprint 結束之後的 Review 還有 Retrospective Meeting，當然統統都要開，不開這些會，怎麼算 Scrum。

首先，我們要在 Sprint Planning Meeting 裡頭，決定這個 Sprint 要做哪些事情 — 或 Story，管他是什麼－不過，請注意，決定要做哪些事情的時候，不代表我們也就決定了這個 Sprint 中不做哪些事情。而且在列出每個 Story 的時候，書本上面教我們要用順序排列，讓開發團隊一件事情做完才去做另一件，而不是只有優先程度 — 這是完全錯誤的。我們的待辦任務都只有優先程度，而且每件事情的優先程度都是最高。

在我們的 Backlog中，有些是來自老闆的直接命令，有些是董事會的指示，有些是直接來自客戶的意見，我們不應該妄自對不同的人做先後高低之分，決定誰比較重要，我們對待所有需求都該保持相同的謙遜，這種謙遜是我們最重要的美德與智慧，甚至是職場上的求生本能：你非要在老闆跟董事會之間決定個順序，搞不好還惹上一身腥，捲入台灣公司常見的公司派與法人派之間的鬥爭呢。

我們在週一開了 Sprint Planning Meeting，週二就可以去另外一個例會上，跟老闆的報告我們接下來這個 Sprint 要做那些 Story，話說要在兩個會議之間趕快做好新的投影片還真是不容易。這時候我們可能突然收到來自行銷部門的新需求，像是下個月我們安排了一場大型的行銷活動，電視廣告時段、記者會時間場地都已經安排好了，為了配合行銷活動，我們必須馬上在產品上做出相對應的調整，時程呢，ASAP。

這時候其實可以凸顯出 Daily Standup Meeting 的好處，Scrum 教科書裡頭有很多東西是我們不要的，但這個會議是個好東西，提供了我們高速調整產品方向、修改產品規格的卓越機動性。 — 像 Retrospective Meeting 就味如嚼蠟，這個會議是在每個 Sprint 結束的時候，讓團隊成員提出問題，雖然這個會議可以讓我們有機會解決提出問題的人，但他們不該有問題才對。

回來說 Daily Stand-up Meeting。在這個所有成員都要參加的每日會議上，每個人都要報告昨天各自做了什麼，完成了什麼，工程師報告的部份其實我們可以直接略過，反正我們都聽不懂，不重要。重點是我們的部份。

在週三早上的會議上，我們可以報告昨天跟老闆討論了什麼，老闆又指示了什麼，這時候團隊應該要馬上協助 PO 估算出所需的開發時間，回報什麼時候可以上線。

對了，其實昨天老闆有想到一個點子，其實這件事情不急，老闆指示回去想一下再慢慢討論，那我們下午也再來敲個會議，討論看看可以怎麼做吧！

一直以來你都覺得工程師是一種奇怪的生物，我們都是非不得已，才會找工程師加入必要的會議，但是他們居然都還在抱怨一直都在開會、都在討論，沒有時間寫程式，這明明就是很簡單就能解決的事情，只要加班就好啦，為什麼不配合加班呢？說什麼工作的時候一直被打斷、一直 context switch 很花成本，晚上就不會有人打擾你啊？台灣從來就沒有過勞死的問題，如果有，那也是本來就有病。

我們都要加班才能把企劃書、規格書、投影片做出來，為什麼你們不該留下來加班寫程式？

才這麼一點會議就拒絕配合，這樣團隊要怎麼充分討論，凝聚共識？你們知道我們要開多少會嗎？你們知道光是四個 PO 之間要討論資源分配，就要花上多少時間嗎？

有時候老闆也會關心 Scrum Team 的狀況，照理說他應該要去問 Scrum Master 才對，因為 Scrum Master 才是確實從旁觀察團隊狀況的角色，不過，差點忘了我們沒有 Scrum Master，那就只能問你了。

你能怎麼回答？你只能說好啊！頭都已經洗下去了，不然你導入 Scrum 的價值何在？你對 Scrum 的詮釋權怎麼辦？你的績效怎麼辦？

你要說，不同部門之間的隔閡被消除了，討論更熱烈了，每件工作要怎麼做，都有一個經過團隊討論過的結果。不過千萬別告訴老闆：團隊討論出來的這個結果，每每都被你推翻；你剛剛推翻的，就是團隊討論出來的成果。

在一番混搭之後，有時候你都搞不清楚這到底是怎樣的團隊了，你甚至在想是不是應該要說這個團隊是個 Scrum Team，但做人一定要莫忘初衷，你還是要記得你是為了什麼導入 Scrum，不管選擇幾次，你都要選擇導入 Scrum，而且馬上就要。

不管這樣的團隊最後變成怎樣的團隊，被稱作什麼名字，你要記得你是 PO。你不是舊時代的 PM，你是新世界的 PO。

我們有很多地方跟書本講的不一樣，但做事不應該墨守教條，每個團隊都應該要摸索出一套適應自己的方式，這就是我們的方式。

這就是我們的 Scrum。

延遲（Latency）一直是直播市場拓展網紅經濟上的一大難題。因為網路傳輸的緣故，當直播主說了什麼話，唱了什麼歌，做了什麼動作，觀眾要過了好一段時間才能夠接收到，觀眾也得要過了一段時間才能對直播主做出反應。

這是一種非常糟糕的使用者體驗，直播的目的在於讓直播主與觀眾不管相隔多遠，都可以在同一個虛擬空間中齊樂融融，甚至進入人類學家所說的 communitas 的狀態。但延遲完全破壞了這種體驗，進而影響直播平台與使用者之間的 engagement，以及新會員 acquantance。

要創造從直播主到觀眾之間完全零延遲的網路直播，我們首先就要了解延遲究竟從何而來。

造成延遲的原因

首先是取樣的問題。時間是一種沒有絕對最小單位的存在，而對電腦而言，聲音與影片是離散的數位訊號，通常的規格是我們每秒鐘會將聲音採樣成 44100 的訊號，而影片則可能會是每秒鐘 30 格、60 格…等規格，這邊採樣的單位都叫做「格」（frame）。所以，在不考慮壓縮的狀況下，直播主必須至少花 1/44100 秒，才能夠錄製第一個聲音訊號，聽眾也必須要得到 1/44100 秒，才能得到第一個訊號。影片也是同樣的道理。

但實際上，直播的訊號會經過壓縮，目前常見會使用 AAC、Vorbis 等格式傳輸聲音，用 H.264、H.265、VP8 …等格式傳輸影片。以 AAC 格式來說，會累積 1024 個 frame 組成一個封包，壓縮後傳送，所以 AAC 封包的單位就是 1024/44100，大概 0.023 秒，直播主獎了話之後要這樣的時間，才會產生第一個 AAC 封包。

至於影片，如果我們將拍攝的每一格都傳出去，是種不怎麼經濟的作法。在一部影片中，往往前一格與下一格之前的差異不怎麼大，如果是一段有個人在揮手的影片，你會發現每格畫面中，就只有手的位置不太一樣，其他像是人物、背景，全是相同的，所以我們會將其中一格當做關鍵影格，要表達其他幾格的畫面的內容，只要記錄與關鍵影格的差異即可，以降低傳輸過程中需要的資料量。但這麼做，就是得累積一定數量的畫面，而不能一拿到一個畫面就送出。

由於每個封包都對人類的感官來說都不大，如果封包與封包之間出現了傳輸不穩定的狀況，就畫面來說會出現卡頓，對聲音來說，不連續、中間出現空白的訊號聽起來則是噪音，所以媒體播放器往往要累積到一定大小的封包之後，才會開始播放，這個過程我們叫做緩衝（Buffering）。

在舉行網路直播的時候，一定會遇到量的問題：同時有多少人、多少終端在觀看你的直播？一台主機無法負荷超過上限的連線，引此需要將連線分散在大量的主機上。目前直播技術大量使用 HTTP 技術，我們會透過 media server，將直播訊源中的影音每隔幾秒鐘切成一個小檔案，然後將眾多個小檔案佈署在 CDN 上。

Media server 還要負擔轉檔的任務，因為不是每個平台都能支援某種影音檔案格式，或是對某種格式最佳化，或是因為每個用戶的網路頻寬不同，有些人的頻寬可以觀看高品質的影片，有些人不然，media server 就得轉換出不同格式、不同品質的檔案。轉檔也要花時間。

從直播訊源傳輸到 media server，從 media server 到 CDN，從 CDN 到用戶的裝置上，中間還有傳輸的過程，就算全程都用光纖，傳輸也需要時間。光速每秒行進 299792458 公尺，所以，如果我們是從美國紐約送出訊號，要送到台北，地表直線距離是 12550 公里，光速需要 0.04 秒，穿越地球內部則是 10627 公里，光速需要 0.035 秒。

要達成完全零延遲的網路直播，就是要去除掉所有取樣、傳輸、緩衝所需要的時間，甚至，我們要去除的是「因為直播主說了一句話，才被觀眾看到」這種因果律，我們要打破事物之間的先後關係。所以，可行的方式，就只有想辦法抵消掉這些時間。也就是說，我們必須要在直播主還沒說某句話之前，就要把這句話傳送給觀眾。

透過人工智慧實現完全零延遲

在直播業界常見的作法是，在直播主還沒說某句話之前，就讓直播系統當中的人工智慧，透過對直播主平時一舉一動的大數據進行深度機器學習，以及當下直播主腦內活動的動態分析，事先預估直播主接下來會講什麼話、會有什麼舉動，接著，預先透過電腦影像以及音聲合成技術產生直播的內容，傳送到觀眾端。

例如，我們預估在直播主與觀眾之間，會有大約三十秒左右的延遲，人工智慧系統就要提早預測直播主三十秒之後會講什麼話，提早發送。

這麼做的技術難度在於如何提昇人工智慧預估的準確度，讓系統可以完全準確預測直播主會講什麼話，要提昇準確度，一方面需要強大的運算效能，所以，現在直播平台執行運算基本上都得使用量子電腦；另一方面就是要提供人工智慧更多可觀的資料，一般的聲音辨識、動作捕捉甚至表情偵測所蒐集的資料，應用在預測直播主行為時，準確度以及預測速度都有限。

所以現在愈來愈多直播平台採取的作法是在直播主的大腦中植入晶片，讓電腦可以直接讀取直播主的腦內活動，如果直播主可以做全身義體化改造的話，效果更佳。有時候直播主在進行戶外直播時，直播平台還會需要出動像是攻殼車這樣的直播設備。

而最近的趨勢是，直播平台發現，既然直播主在大腦中都已經植入晶片了，其實可以讓人工智慧接管直播主的大腦，人工智慧先送出合成的畫面、讓觀眾接收之後，再發出指令，控制直播主發言。而從最近的一些數據成果顯示，直播平台在改變思維與作法之後，人工智慧與直播主之間的同步率獲得了飛躍式的提升。

有些人主張，既然觀眾所收看的其實都是人工智慧合成出來的畫面，那麼直播主還有存在的必要嗎？未必如此，如果你直播的是現場演唱會活動，我們還是需要歌手、樂團在台上表演，而使用人工智慧控制歌手的大腦，其實也同時解決了歌手在表演時走音、忘詞的問題。

改寫直播時間的定義

這樣的作法，其實引起了另外一派具備社會及哲學關懷的工程師的非議。這一派工程師主張，使用人工智慧控制直播主的大腦，其實已經悖離了直播的本意，直播主作為人的人格、能動性及主體性，不應該被外部的系統所掌控，直播主應該要是直播的主角，但是最後卻變成直播的奴隸 — 怎麼可以這樣對待直播主呢？這應該是工程師的專屬待遇啊！

因此，這一派工程師另闢蹊徑，直播的問題，其實既是時間的問題，而既然是時間的問題，就要從時間的本質下手。人類所可以觀測、感知的時間流逝速度，是光的移動，根據愛因斯坦的狹義相對論，質量會造成時空的扭曲，而光就會按照扭曲後的路徑前進。也就是，就是改變直播傳遞的速度，就是要從改變宇宙當中的質量。

地球上的光基本上就會受到地球本身質量的捕捉，所以，如果我們想讓地球上的直播速度變快，我們不妨可以把地球炸掉，這樣就會因為時間整體變快，而讓直播的速度變快。但是，由於我們自己的時間也變快了，因此我們還是會感受到直播的延遲。

所以，要實現零延遲的直播，我們應該要反過來增加物體的質量，當物體的質量大到一定程度後，會造成時空的坍塔，也就是俗稱的黑洞，時空的坍塔會連結到另外一個時空，最終兩個時空會連結在一起，也就是所謂的蟲洞。工程師採取的作法就是，把直播訊號送往蟲洞，讓直播訊號穿越奇異點，如果我們預估直播訊號會延遲三十秒，我們就會先把直播訊號送往黑洞，通過黑洞之後，送到另外一個三十秒之前的時空。

原理說起來簡單，但是當中需要大量精密的計算，我們還得考慮地球與蟲洞之間的距離，如果我們跟蟲洞的出入口之間距離五十億光年，那麼，我們就要對準五十億年又三十秒之前的平行宇宙，這樣才能夠讓直播訊號在通過蟲洞後，再花五十億年傳回地球，在剛好抵達地球的時候，抵消這三十秒的延遲。

「念念不忘，終有迴響」 — 只要我們抱持著對使用者體驗的堅持，沒有什麼技術上、科學上不能克服的問題。沒有什麼做不到。

在 1111 人力銀行搶搭 1111 光棍節列車的捷運車廂廣告上，我們首先可以看到的是野心勃勃的精確行銷。1111 人力銀行目標不但鎖定在原本的求職族群，更是跳脫原本的舒適圈，直指購物族群，打出特惠購物狂歡。

如我們一般的凡夫俗子一定會滿頭霧水，想著，有錢可以狂歡購物的人還需要找工作嗎？要找工作的人會有錢有心思狂歡購物嗎？如何將原本互斥的元素做巧妙的安排，這就是 1111 的行銷與產品規劃的高明之處。

— 如果你有錢，你又繼續你狂歡購物，你就會想要更有錢，這時候你就會想要找收入更高的工作，如果你沒錢，看到這麼多購物宣傳你卻只能徒呼負負，你是不是會更想要找工作？

在整個畫面中，行銷武器如潮水般湧來，讓人目不暇給。又有「限時搶購」的飢餓行銷，又有 iPhone X 的蘋果品牌光環加持，加上時下最熱門的網紅經濟，還有「揪好友、加入新會員、送紅包」這種我們知道叫做 member-get-member 的 growth hacking 手法。

這則廣告不單只是傳遞活動消息，更要 call to action，召喚大眾發起行動，拿出你的手機掃描畫面上的 QRcode，而這個召喚力道更是猛烈地讓人無法招架，不但有 QRcode，還一次給你兩個 QRcode。

看到這麼多的元素，如我們一般的凡夫俗子，大概就會思索表面上這些元素彼此之間的相互關係。到底要怎樣才可以抽 iPhone X 呢？是要去參加會員獨享的限時搶購？還是要揪好友加入新會員？看網紅的直播？還是要在即日起在 1111 找到工作，才可以抽 iPhone X？ — 而如果從上下文來看，又有點像是，你要抽到 iPhone X 之後，才有辦法在 1111 找到工作。

看來更多的資訊，只能夠透過掃描 QRcode 之後了解了。一個 QRcode 讓你下載「找工作、找人才 app」、另一個則是進入活動官網：感覺有點像，我們從活動官網可能沒辦法下載 1111 的 app，下載了 app 之後，從 app 裡頭也不會出現這個活動的內容，因此必須設計成兩個入口。

可是，到底從哪個入口進去，可以讓我抽到 iPhone X 呢？是的，一開始，我們只會有怎樣才能抽 iPhone X 這種膚淺的想法。但是身為軟體產業的一員，我們看到一則廣告，要想到的是在廣告背後那眾多無名的勞動身影，想到在茶水間、在吸菸區裡頭日復一日的牢騷與幹話。

你可以想像，後面大概需要人力銀行與網購業者、甚至電子商務系統之間的跨界合作洽談，異質系統橋接與整合，一套要知道哪個會員邀請了多少會員的帳號系統，要有專人接洽網紅，要有人下廣告、召開記者會，你可以想像當中的兵荒馬亂，有好幾個不同的團隊焦頭爛額，中間有無數個沈悶漫長的討論會議，才能完成一套滿滿都是 buzzword 的企劃，而這一切的一切，在第一天就押下了 deadline。

最後做出來的成果還是讓人看不懂到底怎樣才能抽 iPhone X，我不確定這則車廂廣告最後達成多少成效，但想來背後一定有無數的績效。

不過，對我來說，我還真的被這則廣告打動，看了 1111 特惠購物狂歡的官網，才知道是找到了新工作，才有機會抽 iPhone X。話說為了可以抽 iPhone X 換個新工作，好像還頂吸引人的。

身為軟體工程師，你應該要盡量寫出無法維護的程式碼，而且絕對不寫測試。

你應該要知道：在績效管理下，你愈是認真負責，愈是做到符合專業倫理的要求，你反而看起來績效愈差。而你大概會有 87% 的比例，會遇到這種績效管理。

舉個例子，假如你是警察，你決定要認真抓小偷，於是上個月在你的管區破獲了五十起竊盜案，這個月因為你的努力，破獲的案件增長到一百件 — 這代表什麼呢？這代表看起來你的管區治安變差了，而你應該要為治安變差負責，你才是應該被檢討的對象。於是你知道，警察好像應該要想辦法破案，但實際上，你的績效並不是來自破案，而是吃案。

如果你花了半年時間，抽絲剝繭理清了複雜的商業邏輯，建立了清爽明確的抽象層，並且預先額外設想了其他的使用情境，最後開發了一套易於擴充的軟體架構，讓一個大學剛畢業的新人，都可以在你的架構上不到一個星期就可以開發出新功能。這代表什麼呢？這代表你的績效很差 — 你的管理者只會看到，你花了半年才做了一件事清，一個新人剛來，卻只需要花上一個星期就可以完成一件事，那還要你來做什麼呢？

至於可以輕鬆開發出新功能的新人，他會怎麼看呢？可以這麼快開發出新功能，當然是因為他自己的功能啊！跟你有什麼關係呢？真的要了解你到底做了什麼，其實只有一個辦法，就是要閱讀你的程式碼，但，放心好了，不會有人會去讀的。

你要做的事情就是：管理者設定了什麼績效，你就想辦法達成什麼績效。如果管理者設定的指標是你修好了多少 bug，那麼你就要想辦法一開始就在你的程式中製造許多 bug，免得日後需要修 bug 的時候沒有 bug 可以修。如果管理者的目標是加速開發，你就應該要不計後果加速開發新功能，明知道是加速邁向毀滅，你也要加速開發。

事實上，身為軟體工程師，你也根本不用考慮後續維護的問題。如果你在一家公司寫了一大堆完全不考慮耦合關係、程式邏輯糾纏不清、命名混亂、使用大量 anti-pattern、到處都是怪氣味、效能極差而且宛若天書的程式碼，而你開始為了繼續維護這樣的技術負債感到痛苦的時候，其實只代表一件事情：你已經在這家公司獃得太久，而且還沒有升上去當主管。

這個時候你就會知道加速開發的好。你完成了這麼多項功能，於是在你想要換工作得時候，你可以寫出洋洋灑灑的履歷表 — 反之，你會把你寫了幾條單元測試、達成多高的覆蓋率這種數字放進履歷表裡頭嗎？把力氣放在測試這種無助於發展事業的事情上，完全就是在浪費你的時間。

你也同時應該感謝 — 不曉得是誰想出來軟體產業園區這種德政，原本製造業的產業園區是讓上中下游供應鏈可以集中在一起，降低運輸成本，但軟體這一行又沒有供應鏈這種事情，成立園區只是讓相互競爭的軟體公司其中在一起，唯一降低的就是人員流動的成本，換工作都不用搬家。多好啊你看。

如果你有機會高升，開始擔任主管（你績效這麼好，怎麼可以不選你當主管呢？），你就會知道，當初寫下的那些無法維護的 legacy code，其實更有助於你擔任主管的管理工作。

擔任主管最重要的工作，不是別的，就是一邊把持住自己的位子一邊想辦法繼續往上爬，所以主管絕對不可以讓部屬表現得比自己更優秀，而你當初寫的程式碼，就是部屬事業道路上最好的絆腳石。你除了可以一邊抱怨為什麼新功能開發愈來愈慢，一邊說嘴當年你只花了多短的時間就寫了多少程式碼，果然只有你有資格擔任大家的主管。

而到了這個時候，你還會發現，程式碼到底是什麼品質，已經跟你的績效無關了。怎樣盡可能的接觸老闆，參與更多會議，讓老闆三不五時看到你，才是你現在的績效。

當然，總有一天技術負債會大到你的部門什麼東西都做不出來，你的公司什麼服務都拿不出來賣，但是這一點都不會影響你找新工作，你瞧，現在，你的履歷表上面，可寫著你當過主管呢！拿著這份履歷表，你更有機會去別的地方，空降擔任更高階的主管。

技術負債從來就不是什麼問題。誰說你製造了技術負債之後，你就得要自己還債？怎樣欠債不還，才是工程師最偉大的藝術。

在你的人生中，你不需要要為其他人而活，也不是為了程式碼這種死物而活，你真正應該要負責的對象只有你自己；而你知道人是經濟而自私的動物，既然你的本性就是貪婪，你就應該成就貪婪。管理者想要這種工程師文化，你就提供這種工程師文化。

你要捨棄專業才能成就事業，你應該要把握當下的績效，而不要為了可能不存在的悲劇結果恓恓惶惶，你每天都應該充滿正能量，還有什麼可以比利己主義帶來更多正能量？凱因斯不就曾經說過：「In the long run, we are all dead」？

身為軟體工程師，你應該放心大膽地創造技術負債。這麼做唯一的風險，就只有在你換工作的時候，也會接手一大筆前人留下來的技術負債。不過，這種事情反正也早就已經發生了。