策略執行與藍圖
這系列文章以 FSAE（學生方程式賽車）的車隊經驗為起點，將車隊文化中的實戰心得轉化為系統化的管理觀點。內容涵蓋了策略定位（選擇做與不做）、資源分配（完賽與爭冠的抉擇）、戰術執行（計畫拆解），到深層的職人精神（穩定性與品質），並結合了平衡計分卡（BSC）的財務與客戶維度，讓讀者由淺到深了解工程師如何超越純技術層面，從管理視角達成團隊的共贏目標。

系列前言：當扳手遇上議事槌——為什麼賽車手應該更懂管理？
這一系列文章整理的是一套從 FSAE (學生方程式賽車) 車隊經驗延伸出來的管理觀點。過去在企業決策與技術開發現場累積的經驗反覆證明，真正有價值的工程師，往往不只是在螢幕前或陰暗工廠深處默默努力的人，而是能在資源有限、壓力極高的情境下，仍然做出正確判斷的人。 
 若把車隊視為一個縮小版的企業組織，車庫裡的每一小時其實都在模擬真實專案管理：資源要配置、風險要判斷、資訊要傳遞、成果要交付。這也是本系列希望整理出來的核心脈絡。 
 核心概念：為什麼我們需要這套框架？ 
 工程師的養成教育中，我們很習慣處理「確定性」的問題：給定物理參數，計算出力矩；給定需求，寫出對應的函式。然而，在真實的挑戰中，你面對的往往是一堆的「不確定性」： 
 
 經費突然被縮減（財務管理）。 
 贊助商想要一個他自己都說不清楚的功能（客戶需求）。 
 關鍵組件在比賽前一天斷裂（風險控管）。 
 核心成員畢業了，沒人知道那段程式碼在寫什麼（知識傳承）。 
 
 這就是為什麼我希望在車隊引入 平衡計分卡 (Balanced Scorecard, BSC) 與 戰略、戰術、戰技 的三層思考模型。這不只是管理學教科書上的名詞，而是能讓你在混亂中保持冷靜的「導航系統」。 
 賽車隊實例應用：這不只是比賽，是模擬經營 
 在 FSAE 車隊中，以隊長為首的幹部們其實就是一間「微型公司」的部門經理。 
 
 戰略層面 ：我們今年是要追求「穩定完賽」還是「衝擊前三」？這個決定影響了所有的研發方向。 
 戰術層面 ：為了達成戰略，我們如何安排設計審查（DR）？如何確保採購零件不會卡在海關？ 
 戰技層面 ：你的碳纖維鋪層是否均勻？扭力手感是否標準？這是最底層的職人尊嚴。 
 
 若只關注戰技層面的執行，團隊容易停留在單點技術優化；當視角提升到戰略層面，才有機會形成完整的專案領導能力。 
 職場轉化建議：給初入職場工程師的備忘錄 
 許多工程師進入職場後會感到挫折，覺得「為什麼公司要開這麼多無聊的會？」或「為什麼那個技術明明比較好，主管卻不採用？」 
 原因通常在於：你只用了「技術視角」在看問題。
當你學會用 財務面、客戶面、內部流程、學習成長 (BSC 四大構面) 來分析現狀時，許多看似抽象的「政治」或「管理問題」，本質上仍然是多目標條件下的優化問題（Optimization Problem）。 
 本系列文章的目標 
 我希望利用短短的這 10 篇文章帶著你，從設定年度願景開始，一路走到風險應變與職涯規劃。每一篇，我都希望你想像自己正站在賽車區（Pit Lane）的耳機旁，看著車子進站，也看著你的團隊加速起跑。 
 繫好安全帶，速度第一，安全第二 ! 
 
 補充註記： 
專案管理是一門很深的學問，每個成功的經理人往往都有自己獨到的看法，在此僅是個人觀點供學習，並非絕對正確。 
管理能力的養成跟打磨零件一樣，需要耐心多聽多學。我們下一篇見。

第一篇：策略藍圖——為什麼你的賽車需要導航系統？
在車隊討論初期，常見的疑問是：「目標不就是把車做快、把成績拉高，為什麼還需要策略藍圖？」實際上，若沒有明確的方向，即使團隊執行速度很快，也可能只是更快地偏離目標。 
 核心概念：策略是「選擇不做什麼」的藝術 
 在企業管理中， 策略藍圖 (Strategy Blueprint) 是為了解決一個核心痛點： 資源永遠有限 。 
 工程師的天性是追求極致。如果你給一個懸吊組工程師無限的時間，他會想用鈦合金打造每一個連桿；如果你給電控組工程師無限的預算，他會想在車上裝滿噴射機等級的感測器。但現實是：你只有六個月的時間，以及一筆剛好夠買一組電池和輪胎的預算。 
 而 策略（Strategy） 的本質，就是決定你的資源要投在哪裡。在平衡計分卡 (BSC) 的邏輯中，這叫「戰略的一致性」。你不能在財務面上捉襟見肘，卻在學習成長面要求團隊開發一套前所未見的自動駕駛系統。 
 賽車隊實例應用：高馬力 vs. 高可靠性 
 讓我們來假設一個 FSAE 的模擬情境。 
 車隊在年初必須做一個重大策略選擇： 
 
 方案 A (激進策略) ：研發全新的空力套件與四驅電控系統。目標：衝擊單圈最快紀錄。風險：系統不穩定，可能在耐久賽（Endurance）中途退賽。 
 方案 B (保守策略) ：延用去年的底盤，但將重心放在「減重」與「大量場地測試」。目標：確保完賽，拿滿耐久賽的分數。風險：速度可能平庸，無法驚艷評審。 
 
 如果你的車隊沒有「策略藍圖」，結果通常是：動力組在搞方案 A，底盤組在搞方案 B。最後車子拼湊起來時，馬達太重導致重心偏移，而底盤為了減重沒預留散熱空間。這就是典型的「戰略失調」。 
 一個好的策略藍圖會明確告訴大家： 「今年我們的核心戰略是『極致的完賽率』。」 
有了這個策略，電控組就知道他們的首要任務是確保線束的防水與耐震，而不是開發新的啟動控制演算法。 
 職場轉化建議：看懂你公司的「導航系統」 
 當你進入公司後，你會聽到主管不斷提到 OKR (目標與關鍵結果) 或 KPI (關鍵績效指標)。很多工程師覺得這些是來束縛自己的「枷鎖」。 
 但換個角度想，這是公司的導航系統。 
 
 理解大局觀 ：如果公司今年的策略是「擴大市佔率」，你的程式碼寫得再優美、節省再多運算成本，可能都比不上「快速交付新功能」來得重要。 
 向上管理的工具 ：當主管丟給你一個新任務時，你可以問：「這個任務如何幫助我們達成今年的策略目標？」如果對不上，這就是你討論優先順序的最好理由。 
 避免技術自嗨 ：不要為了學習新技術而把專案搞複雜。在職場上，能達成公司戰略目標的技術，才是「好技術」。 
 
 實務補充：畫出自己的戰略地圖 
 一個可行的起點，是先畫出四個框框： 
 
 最上方 (成果) ：今年比賽我們要拿第幾名？ 
 中間 (客戶/評審) ：我們要給評審看什麼樣的設計文件？ 
 下方 (內部流程) ：我們每週要跑幾次測試？ 
 最底層 (學習成長) ：每個人要學會什麼軟體？ 
 
 當這四個框框能連成一條線時，團隊的賽車導航系統就真正開始發揮作用。 
 
 延伸閱讀： 
有了導航，下一步就是決定「油門踩多深」。 第二篇：戰略層次——決定「完賽」還是「爭冠」的關鍵決策 ，會進一步整理資源配置的取捨方式。

第二篇：戰略層次——決定「完賽」還是「爭冠」的關鍵決策
常見的想法是：「只要經費足夠，目標當然是拿冠軍。」但真正的問題不在於願望大小，而在於資源是否能支撐相應的範疇。如果戰略目標設定為「爭冠」，資源卻只足以支撐「完賽」，那就不是策略，而是判斷失準。 
 核心概念：資源配置是殘酷的取捨 
 在專案管理中，有一個非常有名的 「黃金三角」 ： 
 
 範疇 (Scope) ：你要做多少功能、車速要多快。 
 時間 (Time) ：離比賽（或產品上市）還有多久。 
 成本 (Cost) ：你有多少預算、多少人力。 
 
 這三者是連動的。如果你想增加範疇（比如研發新的電子差速器），你就必須增加預算（成本），或者延後測試時間（時間）。 
 戰略（Strategy） 的最高層次，就是根據現有的「三角」，決定你的定位： 
 
 爭冠模式 ：在範疇上推到極限。這需要極高的預算支持與精確到「小時」的時間管理。 
 穩健模式 ：縮小範疇，專注於提高可靠性。這適合預算有限或團隊成員較新（人力成本）的情況。 
 
 賽車隊實例應用：那根斷掉的連桿 
 假設有一個非常有能力的車隊，他們在戰略上選擇了「極致輕量化」以衝擊冠軍。
他們將懸吊連桿的壁厚減到了極限，計算結果顯示安全係數剛好在 1.1。結果呢？在賽前的最後一次全負載測試中，連桿應聲斷裂。 
 因為這根連桿，他們不僅損失了更換零件的費用（成本），更慘的是錯過了最後三天的調教時間（時間）。在正式比賽中，因為缺乏調教，車子跑得比去年的舊車還慢，勉強完賽。 
 這就是經典的 「戰略錯誤」 ：他們在預算與時間都不充裕的情況下，選擇了「爭冠級別的範疇」。
如果當時他們選擇「穩健模式」，稍微增加 200 克的重量換取絕對的穩定，他們或許能拿到更好的名次。 
 職場轉化建議：給工程師的「選擇力」 
 
 認清你的「資源池」 ：當你接到一個新專案，先別急著開 CAD。先問主管：「我們有多少人？測試場地借到什麼時候？預算上限是多少？」 
 區分「Must-have」與「Nice-to-have」 ：在爭冠策略下，很多功能是必要的；但在完賽（生存）策略下，有些花俏的技術其實是可以捨棄的。 
 提案時提供「方案組合」 ：身為專業的專案經理，你應該給老闆兩個選擇：
 
 「方案 A：追求極致效能，但需要額外兩位研發人力，且風險較高。」 
 「方案 B：保證系統穩定，現有資源即可完成，但效能比競爭對手低 10%。」
 能給出這種分析的工程師，在老闆眼中就是具備戰略思維的高級人才。 
 
 
 
 實務補充：問自己一個靈魂拷問 
 如果明天就是比賽，而你現在只能完成一個功能，你會選哪一個？那個答案，就是你的戰略核心。 
 
 延伸閱讀： 
決定了要「完賽」還是「爭冠」，接下來我們要談談如何把這個偉大的願景拆解成一張張「待辦清單」。
 第三篇：戰術執行——如何將年度計畫拆解成每週的進度表。

第三篇：戰術執行——如何將年度計畫拆解成每週的進度表
除了我們，保守來說全台灣車隊都曾遇過同一種情況：待辦清單、甘特圖明明存在，到了比賽前一個月，仍然要靠大量 Redbull、加班、瘋狂加工、日出計畫收尾。問題通常不在於是否有列清單，而在於戰術層面的拆解與排程是否足夠細緻。戰略像導航，戰術則像變速箱；若執行系統無法接住方向設定，再好的戰略也難以落地。 
 核心概念：WBS 與 CPM 的戰術組合拳 
 要把年度目標變成每週進度，你需要兩個管理利器： 
 
 
 工作分解結構 (WBS, Work Breakdown Structure) ：
不要只寫「造車」。要拆成「底盤」、「動力」、「車身」。再把底盤拆成「懸吊」、「架構」、「制動」。拆到最後，會出現像「購買 4 顆 M10 螺絲」這種明確、可指派、可追蹤的 Task。
 記住：不能被量化的任務，就無法被管理。 
 
 
 關鍵路徑法 (CPM, Critical Path Method) ：
有些任務可以並行（比如電控寫程式與底盤焊架子），但有些任務必須按順序（沒焊好架子，電控就沒地方裝線束）。
那一串「絕對不能延誤，一旦延誤整個專案就完蛋」的任務鏈，就叫做 關鍵路徑 。 
 
 
 賽車隊實例應用：消失的採購件 
 很多賽車隊的進度延誤，不是因為「手腳慢」，而是因為「等零件」。 
 想像一下：你的戰術計畫表寫著「第 10 週：組裝發動機」。
但你沒注意到「立柱送件」的加工時間 (Lead Time) 需要 8 週。如果你在第 9 週才下單，你的發動機組裝進度就直接卡死 7 週。 
 一個成熟的車隊經理（或專案經理），會使用 甘特圖 來分析關鍵路徑。他會發現：
「採購活塞」是關鍵路徑上的地雷。所以他的戰術動作是在第 1 週就完成採購清單，而不是等到設計完全定稿。這就是「提前預防」大於「事後救火」。 
 管理具體建議：從「我會做」到「我能控制進度」 
 
 建立你的「看板（Kanban）」 ：不管是 Trello、Notion 還是公司內部的系統。將任務分為「待處理」、「進行中」、「測試中」、「已完成」。視覺化你的工作流。 
 掌握前置量 (Buffer) ：永遠不要預設一切都會準時。關鍵路徑上的任務，請預留 20% 的時間作為緩衝。 
 學會「拆解」複雜問題 ：
主管說：「這個系統報表太慢，去優化它。」
如果你只回「好」，你通常會超時。
正確的做法是拆解：
 
 第一步：性能測試與瓶頸定位 (2 天) 
 第二步：資料庫索引優化 (3 天) 
 第三步：程式碼重構與單元測試 (5 天)
當你給出這個 WBS 時，你就不再是一個「被動接受指令的碼農」，而是一個「掌握進度的專案管理工程師」。 
 
 
 
 實務補充：每週五的「賽後檢討」 
 在車隊裡，每週五晚上開一次進度會，不是為了檢討誰沒做完，而是為了問： 「下週有誰會卡住？我能幫什麼忙？」 這種「預判障礙」的能力，就是戰術執行的最高境界。 
 
 延伸閱讀： 
計畫定好了，拆解也完成了，接下來我們要聊聊那些握著扳手或寫著代碼的「職人精神」。
 第四篇：戰技磨練——碳纖維與電路板背後的職人精神。

第四篇：戰技磨練——碳纖維與電路板背後的職人精神
工廠製程常見一種說法：電路板雖然焊接得不夠漂亮，但功能測試已經通過，似乎就可以先接受。然而在長週期專案裡，「能跑」通常只是最低門檻；真正決定成果上限的，是穩定性、可維護性與可追溯性。 
 核心概念：品質管理 (QA/QC) 與標準化 
 在工業界，我們區分 QA (Quality Assurance, 品質保證) 與 QC (Quality Control, 品質控制) 。 
 
 QA 是設計一套「正確的流程」，確保東西做出來不會錯。 
 QC 是在東西做出來後，進行「檢查與測試」，挑出錯誤。 
 
 工程師的職人精神，就在於你對「標準化流程 (SOP)」的執著。
為什麼波音飛機的零件不能隨便換一顆螺絲？因為那一顆螺絲背後，代表著經過驗證的材料規格、扭力標準與生命安全。當你開始尊重「規格書 (Datasheet)」而非憑感覺做事時，你的戰技才算真正入門。 
 賽車隊實例應用：扭力板手的尊嚴 
 我曾見過一屆的底盤組組長。他對車子極度了解，但他有個壞習慣：鎖螺絲不愛用扭力板手。他總說：「我這隻手就是板手，感覺對了就對了。」 
 結果在一次場地測試中，後懸吊立柱的一個螺栓因為疲勞斷裂——那是因為他鎖得「太緊」，導致材料預應力過大。
雖然那一刻他很帥，但結果是整個團隊停工兩天，還要重新訂做昂貴的立柱。 
 真正的職人戰技，是每一顆螺絲都嚴格按照手冊上的「扭力規範」鎖緊，並在上面畫上「漆筆標記 (Torque Mark)」以便檢查。
 這不是因為你手感不好，而是因為你尊重系統。 
 具體該怎麼做?：從「我會寫」到「我寫的是工業級產品」 
 
 重視文件 (Documentation) ：
在公司裡，你寫的程式碼或設計的圖檔，未來會有別人來接手。
一份亂七八糟、沒有註解、沒有規格說明的文件，就是一種「技術債」。職人的尊嚴，在於讓接手的人能一眼看懂你的思路。 
 遵循業界標準 (Standards) ：
不要隨便發明輪子。如果你在設計電路，請遵循 IPC 標準；如果你在寫軟體，請遵循 Clean Code 原則。
 標準化，是為了讓速度更快。 
 對「細節」的病態執著 ：
在賽車場，一點點氣泡都可能導致碳纖維失效；在職場，一個未處理的例外狀況 (Exception) 可能導致系統崩潰。
養成「自我查核表 (Checklist)」的習慣，這是區分「初級工程師」與「資深經理」的分水嶺。 
 
 實務補充：想像你的作品會被評審「拆開來看」 
 如果你知道這台賽車的每一個焊點都會被世界級的工程專家用顯微鏡檢查，你還會隨便焊嗎？在職場上，你的每一份報表、每一行程式碼，都是你的名片。 
 
 延伸閱讀： 
磨練完技術，我們要來談談最現實的問題：錢。
 第五篇：BSC 財務面——沒錢萬萬不能，賽車隊的預算管理學。

第五篇：BSC 財務面——沒錢萬萬不能，賽車隊的預算管理學
工程成員常把預算視為隊長或財務負責人的工作，但在實務上，技術決策與財務配置從來無法完全分開。這也是 平衡計分卡 (BSC) 第一個維度，也就是 財務面 (Financial) ，特別值得工程團隊理解的原因。 
 核心概念：預算、成本與投資報酬率 (ROI) 
 在商場上，所有技術行為的背後，都必須有一個財務邏輯。 
 
 預算管理 ：不是你有多少錢，而是你如何分配。 
 成本中心 (Cost Center) ：純支出，通常被要求儘量節省（例如：一般的行政部門）。 
 利潤中心 (Profit Center) ：能創造收益（例如：業務部）。 
 
 身為工程師，你的任務是把自己的技術專案，從「純支出」轉化為「投資」。
你需要理解什麼叫 ROI (Return on Investment) ：如果我投入 100 萬研發這項技術，它能幫公司多賺 200 萬？還是能省下 50 萬的維護成本？ 
 賽車隊實例應用：每一分錢都是贊助商的血汗錢 
 學生方程式賽車的財務來源通常是贊助。這是一個極佳的財務管理訓練場。 
 想像你有 20 萬台幣的贊助款。 
 
 研發組 想買一套昂貴的流體力學分析軟體 (CFD)。 
 公關組 想花錢做一套漂亮的隊服與贊助商背板。 
 測試組 想多租幾天場地進行路測。 
 
 這就是 財務權衡 。
如果你是隊長（或組長），你怎麼決定？
成熟的決策者會看「目標的一致性」。如果今年的戰略是「穩定完賽」，那麼「場地路測」的財務優先級應該大於「分析軟體」。
 每一筆採購都必須附帶一個說明：這筆錢如何幫助我們贏得比賽？ 如果說不清楚，這筆預算就不該過。 
 隊員具體建議：看懂車隊的「錢包筆記」 
 
 學會報帳與專案成本核算 ：
在公司，你用的每一顆零件、每一小時的加班，都是成本。
學會精確預估成本，不要讓你的專案在進行到一半時，才發現預算見底。 
 用「錢」跟老闆說話 ：
不要跟老闆說：「這套系統效能提升了 20%。」
老闆聽不懂，也不在乎。
你應該說：「這套系統提升 20% 效能後，每年可以幫公司節省 5 萬美金的伺服器成本。」
 這就是「財務意識」。 
 理解「機會成本 (Opportunity Cost)」 ：
如果你花一個月自己開發一套開源工具，雖然不用買軟體，但你的工資（人力成本）可能遠超過買軟體的錢。
學會分析「買 (Buy)」還是「做 (Make)」，這是高階主管必備的財務眼光。 
 
 實務補充：養成「記帳」的職業病 
 建議統計你開發一個小功能花了多少小時、用了多少零件。將其轉化為台幣。當你開始對「技術背後的價格」有感覺時，你就擁有了管理者的視角。 
 
 延伸閱讀： 
搞定了錢，我們來談談「人」。
 第六篇：BSC 客戶面——如何讓贊助商與評審對你刮目相看。

第六篇：BSC 客戶面——如何讓贊助商與評審對你刮目相看
工程團隊很容易把「性能表現」直接等同於「價值」。但在 平衡計分卡 (BSC) 的框架中， 客戶面 (Customer) 談的不是單一性能指標，而是團隊究竟向誰交付價值，以及對方如何理解這份價值。 
 核心概念：利益相關者 (Stakeholders) 與價值主張 
 在車隊中，你的「客戶」不一定是付錢買產品的人，還包括你的老闆、跨部門的隊員、甚至是你的供應商。 
 
 價值主張 (Value Proposition) ：不是你「有什麼」，而是你能「幫客戶解決什麼問題」。 
 利益相關者管理 ：識別出誰能影響你的專案成敗，並了解他們的需求。 
 
 如果你只顧著「把車造快」，卻忘了「讓贊助商覺得投資這台車對他的品牌有幫助」，或者是「讓賽事評審看懂你的設計邏輯」，那你的專案就是失敗的。 
 賽車隊實例應用：評審眼中的「完美賽車」 
 在 FSAE 比賽中，有一個非常重要的環節叫「設計報告 (Design Report)」。
很多車隊的車跑得飛快，但設計評分卻很低。為什麼？
因為評審問：「為什麼你選這個懸吊幾何？」
隊員答：「因為我參考某某名車的設計，它跑很快。」
評審搖頭。這不是他要的答案。 
 評審（也就是你的客戶）要的價值是： 「你如何運用工程科學的方法，去推論出最適合你的車隊資源的設計方案？」 
如果你能拿出完整的數據分析報告、詳細的採購邏輯、以及故障排除紀錄 (FMEA)，即使車子單圈慢一點，評審也會給你高分。因為你交付了「工程決策的透明度與專業性」。 
 職場轉化建議：把你的主管當成「客戶」 
 
 對齊期望值 (Expectation Management) ：
不要等專案做完才給主管看結果。每週同步進度，問主管：「目前的進度是否符合你對這個季度的期望？」 
 翻譯技術語言 (Tech to Biz) ：
面對業務部或行銷部時，不要說「我們優化了資料庫的併發處理」。
你應該說：「我們現在可以同時支援 10,000 個使用者同時在線，這將幫助我們在雙 11 促銷時不會當機。」 
 解決痛點 (Pain Points) ：
觀察你的主管或客戶最煩惱什麼？如果他煩惱進度不透明，你就主動提供一份漂亮的自動化看板，這就是交付價值。 
 
 實務補充：畫一張「利害關係人地圖」 
 列出所有能影響你專案的人。 
 
 誰要你的進度報告？（主管） 
 誰要用你的程式介面？（前端同事） 
 誰在等你的零件下單？（採購）
給他們每個人一個「價值承諾」。當你讓身邊的人都成功時，你的專案就成功了一半。 
 
 
 延伸閱讀： 
價值定好了，接下來我們要談談如何「有效率地」生產這些價值。
 第七篇：BSC 內部流程——標準化作業（SOP）是為了更快的速度。

第七篇：BSC 內部流程——標準化作業（SOP）是為了更快的速度
在工程文化裡，SOP 常被誤解為限制創意的文件，彷彿只有生產線才需要它。但從 平衡計分卡 (BSC) 的 內部流程 (Internal Process) 角度來看，標準化作業 (SOP) 的目的其實是把可預期的重複工作穩定下來，讓團隊把注意力留給真正需要判斷的問題。 
 核心概念：流程卓越與精實管理 (Lean) 
 卓越的團隊，不是靠「英雄式」的加班來達成目標，而是靠「穩定且可預測」的流程。 
 
 精實管理 (Lean) ：核心是「消除浪費」。 
 SOP (Standard Operating Procedure) ：將重複性的、容易出錯的過程標準化。 
 
 如果每次換胎都要重新找扳手，或者每次部署程式碼都要手動設定環境，這就是「流程浪費」。 
 賽車隊實例應用：維修區的換胎流程 
 F1 賽車進站換胎只要 2 秒，這是怎麼做到的？
那絕對不是靠技師「臨時發揮創意」。那是經過無數次的拆解動作、分配位置、以及上千次的練習，最終形成的一套極致 SOP。 
 在 FSAE 車隊中，我們也需要 SOP： 
 
 加工 SOP ：確保每個人操作銑床的步驟都一樣，減少零件報廢率。 
 程式部署 SOP ：確保新寫好的電控程式碼在燒錄進 ECU 前，都經過了一套標準測試流程 (Unit Test)，防止燒壞昂貴的硬體。 
 
 如果你沒有 SOP，每次出錯你都要「重新找原因」；如果你有 SOP，出錯了你只需要「修正 SOP」。 這種修正流程的能力，就是組織進步的關鍵。 
 工作經驗建議：把自己變成一個「自動化系統」 
 
 建立個人工作流 (Personal Workflow) ：
當你重複做一件事情三次時，你就應該寫一個腳本或文件來自動化它。 
 流程視覺化 ：
在團隊中，使用「流程圖 (Flowchart)」來定義權責。
例如：Bug 發生時，回報給誰？誰負責審核？誰負責修復？誰負責驗證？
清清楚楚的流程，可以省下 80% 的通訊與推諉成本。 
 持續改進 (Kaizen) ：
SOP 不是死板的法律。每個月檢視一次：目前的流程有沒有哪裡太慢？有沒有多餘的會議？
 減少摩擦力，就是增加加速度。 
 
 實務補充：試著寫一份「防呆手冊」(Checklist) 
 當你在做一個高風險操作時（例如：更新資料庫、組裝昂貴零件），試著寫下一份「給笨蛋看的檢查清單」。如果你能讓一個不懂技術的人照著做也不會出錯，那你就是流程管理的大師了。 
 
 延伸閱讀： 
流程建好了，但人會走、技術會過時，我們該如何傳承？
 第八篇：BSC 學習成長——傳承的力量，如何建立車隊知識庫。

第八篇：BSC 學習成長——傳承的力量，如何建立車隊知識庫
車隊知識傳承失靈時，常見的狀況是只留下幾張模糊照片、零散檔案，或幾行幾乎無法理解的程式碼。這種斷層會直接拖慢新成員的上手速度，也正說明了 平衡計分卡 (BSC) 最底層、同時也是根基的 學習與成長 (Learning and Growth) 為什麼重要。 
 核心概念：知識管理與「不要重複發明輪子」 
 在企業中，最重要的資產不是機器，而是「知識」。 
 
 顯性知識 (Explicit Knowledge) ：可以寫下來的 SOP、設計圖、程式碼。 
 隱性知識 (Tacit Knowledge) ：老師傅的「手感」、解決問題的直覺。 
 
 知識管理 (KM) 的目的，就是把隱性知識轉化為顯性知識。如果你離開了公司，而你的專案因此就卡死了，這不是因為你太厲害，而是因為你的「知識轉化」做得太差。一個真正的高階人才，會建立一套系統，讓自己變得很強，但同時讓團隊「不依賴他」。 
 賽車隊實例應用：那本「失敗經驗簿」 
 我見過的車隊中，有一個非常特別的經驗，他們有一套屬於自己的 設計規範 (Design Spec) 。
當新成員加入時，他不是先去碰扳手，而是先讀完前三年的「失敗報告」。 
 
 為什麼前年的懸吊會斷？因為某個應力集中點沒處理。 
 為什麼去年的電控系統會熱當？因為散熱鰭片位置不對。 
 
 這種「知識傳承」的力量非常驚人。當別的車隊每年都在重複踩同樣的坑時，這個車隊已經在往更深層的技術前進了。
 記住：你的傳承做得越好，你的後輩就能站得越高，幫你把車隊的榮光延續下去。 
 團隊成長建議：把自己變成一個「可擴充的知識節點」 
 
 建立個人知識庫 (Second Brain) ：
不要相信你的腦袋，它很健忘。使用 Notion、Bookstack 或簡單的 Markdown 筆記。記錄下你解決的每一個 Bug、你研究出的每一個演算法流程。 
 寫「好讀」的文件 ：
在職場上，最好的工程師會寫一份「即便我離職了，新人照著做也能在三天內上手」的文件。這不會讓你被取代，反而會讓主管覺得你有極高的「管理潛力」，願意把你升上去帶人。 
 分享即成長 ：
主動在團隊內部舉辦技術分享會 (Tech Talk)。當你能把一個複雜的技術講到讓不同部門的人都聽懂時，你的「管理力」與「溝通力」就得到了最好的鍛鍊。 
 
 實務補充：問問自己，如果今天你中樂透休學了，專案會崩潰嗎？ 
 如果會，那你現在就該開始寫文件了。 一個好的工程師開發產品，一個偉大的工程師開發系統。 
 
 延伸閱讀： 
計畫、財務、流程、學習都到位了，但如果老天不賞臉呢？
 第九篇：風險控管——當車在場上起火時，你該有的專案 B 計畫。

第九篇：風險控管——當車在比賽前起火時，你該有的「 B 計畫」
在專案管理裡，最危險的不是風險本身，而是「沒事啦」的假設。只要系統由人、設備、供應鏈與時間壓力組成，就不存在真正的零風險，只有不同的機率分布與應變準備程度。 
 核心概念：風險矩陣與應變計畫 (Contingency Plan) 
 工程師最常見的心理病灶叫「樂觀偏誤 (Optimism Bias)」。我們總是假設環境是完美的、零件是耐用的。
專業的 PM 會使用 風險矩陣 (Risk Matrix) 來評估： 
 
 發生機率 (Probability) ：這件事發生的機會多高？ 
 影響程度 (Impact) ：如果發生了，後果多嚴重？ 
 
 針對高風險（高機率或高影響）的事情，我們必須準備 B 計畫 (Contingency Plan) 。
這不代表你對自己的設計沒信心，這代表你對你的團隊負責任。 
 賽車隊實例應用：比賽當天的那場大雨 
 試想一下，你們準備了一整年的乾地胎與高速調教。結果，決賽前十分鐘，天空突然烏雲密佈。 
 
 業餘團隊 ：手忙腳亂，找不到雨胎的胎壓數據，忘記調整懸吊設定，全員陷入恐慌。 
 職業團隊 ：隊長冷靜地喊出「雨天 Plan B」。底盤組取出早已準備好的雨胎，調校組拿出預設的雨地參數清單，車手換上防水裝備。 
 
 這就是風險控管的價值。
在設計車輛時，你就要考慮： 
 
 如果電池起火了，滅火器的配置是否能在 3 秒內啟動？ 
 如果主車架加工失敗了，我們有沒有備用的材料供應商？
 真正的強大，不是永遠不出錯，而是出錯後能以最快的速度恢復。 
 
 工程實作建議：給工程師的「避震系統」 
 
 學會評估「單點失效 (Single Point of Failure)」 ：
在系統架構中，如果某個零件壞掉會導致整個專案停擺，這就是你的頭號風險。並建立備援系統 (Redundancy)。 
 提前告知風險，而不是事後道歉 ：
當你預期進度可能會因為某個外部零件延誤時，應在第一時間告知主管：「目前有 30% 的機率會延誤，我的 B 計畫是...」。
 主管不怕你遇到問題，主管怕你「瞞著問題不說」。 
 冷靜的危機處理 (Crisis Management) ：
當災難真的發生時（例如：伺服器當機、重大 Bug 曝光），不要找藉口，先找「止血方案」。
先讓系統恢復運作，再進行「賽後分析 (Post-mortem)」。這種「大將之風」，是你在職場晉升的關鍵門票。 
 
 實務補充：養成「悲觀思考，樂觀執行」的習慣 
 在設計時，假設每個零件都會壞；在執行時，用最強大的意志力去確保它不壞。當你能把風險量化並納入管理時，你就掌控了全局。 
 
 延伸閱讀： 
我們走過了十萬八千里，從車庫走到了企業。
 第十篇：總結——從車庫走向企業：工程師的職涯藍圖。

第十篇：總結——從車庫走向企業：工程師的職涯藍圖
我再回頭整理車隊經驗時，時常心中會出現一個疑問：投入大量時間在賽車、測試與維修，和其他同學相比，這段歷程究竟累積了什麼？如果前九篇談到的方法確實在車隊內被實踐過，那麼留下來的就不只是造車技術，而是一套可以轉用到企業環境的管理作業系統。 
 核心概念：打造「T 型人才」 
 在職場上，最強的人叫 T 型人才 ： 
 
 垂直的一豎 (Deep Skill) ：你的專業技術。不管是寫 Code、設計電路還是計算力學，這是你的立身之本。 
 水平的一橫 (Broad Management) ：你的管理與策略力。這包含我們聊過的財務意識、流程管理、客戶價值以及風險控管。 
 
 如果你只有「一豎」，你很容易遇到職涯天花板，變成一個容易被取代的工具人。如果你加上了「一橫」，你就是那個能帶領團隊攻城掠地的專案經理或資深技術長。 
 賽車隊實例應用：那張「不只是造車」的成績單 
 當你去面試台積電、Google 或任何一間世界級企業時，不要只跟面試官說：「我參與過 FSAE 賽車設計。」
你應該拿出一張 「自我 BSC 成績單」 ： 
 
 財務面 ：我曾管理 50 萬的年度贊助預算，並透過成本分析將零件採購成本降低了 15%。 
 客戶面 ：我負責對接 5 家企業贊助商，並在比賽中獲得靜態賽評審的高度評價，因為我交付了高品質的技術文件。 
 內部流程 ：我建立了車隊的加工 SOP 與版本控制系統，縮短了 20% 的測試迴圈時間。 
 學習成長 ：我建立了車隊的失敗分析知識庫，確保技術在學長畢業後能無縫傳承。 
 
 當履歷與面談能這樣整理車隊經驗時，外界看到的就不只是學生身分，而是已經具備企業思維與專案判斷能力的工程人才。 
 真實職場建議：你的未來 5 年策略地圖 
 
 第一年：磨練戰技 ：
在職涯初期，專注於「專業技術」的職人精神。把每一行程式碼、每一份報告做到最好。這是建立信用 (Credit) 的階段。 
 第三年：掌握戰術 ：
開始爭取帶領小專案 (Task Force)。練習使用 WBS、CPM 控管進度。學習如何跨部門協作（對接你的客戶面）。 
 第五年：佈局戰略 ：
站在主管的高度看問題。思考公司的獲利模式 (財務面)，優化團隊的傳承系統 (學習成長面)。這時候，你已經準備好成為真正的「管理職」或「技術專家」。 
 
 隊長最後的真心叮嚀：不要熄滅那股火焰 
 在賽車場上，我們追求的是那一秒鐘的速度。在職場上，我們追求的是長期的影響力。
管理不是要把你變成一個官僚，管理是為了讓你的夢想「更有成功的勝算」。 
 當你以後在企業的會議室裡，面對混亂的專案、見底的預算、以及暴怒的老闆時，請閉上眼，想像一下我當初在車庫裡，面對那台還不會動的賽車、一群的菜鳥、老人欠的一屁股債，需要且必要的一份冷靜。 
 如果你能搞定一台在賽場上狂飆的賽車以及背後的龜毛工程師，你就能搞定這世上大部分的難題。 
 恭喜畢業。未來我們職場相見。 
 
 補充註記： 
這十篇文章只是拋磚引玉。真正的比賽，現在才剛開始。加油！