台灣 B2B 製造業外包工程團隊：90 天踩坑紀錄

第一次外包工程團隊的 90 天，失敗通常不是技術問題，而是需求定義、驗收標準與資料權限沒談清楚。本文以台灣 B2B 製造業的典型情境，拆解從首次招聘到首次交付的三個階段、七個常見坑，以及可直接複用的檢查清單。

為什麼台灣 B2B 製造業開始外包工程團隊

製造業在台灣經濟中的比重長期偏高——依行政院主計總處（DGBAS）的國民所得統計，製造業約占台灣 GDP 三成以上，是主要出口與產值來源。這代表大量中大型 B2B 製造商手上握有豐富的產品、規格、經銷與售服資料，但內部 IT 編制往往仍以 ERP 維運、網管與資安為主，缺乏產品端的軟體工程能量。

當客戶開始要求線上型錄、規格選型器、報價入口、經銷商後台、或把 CAD 圖檔與料號綁在一起的自助下載區時，內部團隊很快撞牆。招募自建團隊是選項之一，但根據 Stack Overflow 2024 年開發者調查，開發者對 AI 工具的採用率已達七成以上（使用中或計畫使用），意味著工程工作的形態正在快速改變——招一個三年綁約的資深前端，風險並不比外包低。

於是「先外包一個小隊，跑一個 90 天的專案驗證合作模式」成為常見起手式。以下紀錄以 Branch8 在亞太區承接過的一類專案為原型：一家透過經銷商網路銷售工業設備的台灣製造商，需要把紙本型錄與 Excel 報價流程搬上線，並與既有 ERP 對接。細節已去識別化，不涉及任何客戶名稱、金額或未經驗證的成效數字。

Day 0–14：招聘與範圍定義，第一個坑就在這裡

坑一：把「找人」當成「找團隊」

多數製造業第一次外包時，發出的需求是「我要兩個工程師」。這是用內部人力思維買外部交付能力，結果是：對方派來兩位很會寫程式的人，但沒有人負責需求釐清、沒有人負責測試、沒有人負責上線。

外包工程團隊的最小可行編制通常是「1 + 2 + 0.5」：

1. 一位對接窗口（Delivery Lead / BA）——負責把製造業的語言翻成工程規格。
2. 兩位工程師——至少一位能同時處理前端與 API 整合。
3. 半個 QA 或 DevOps 分攤——共享資源，不需要全職。

把預算配置從「人頭數」改成「角色覆蓋率」，是第一個要修正的心智模型。

坑二：規格用會議記錄代替文件

台灣製造業的隱性知識密度很高：料號規則、選型邏輯、經銷商折扣階層、哪些規格書不能對外。這些東西通常存在資深業務的腦袋裡，而不是文件裡。

前兩週最該做的事，不是開發，而是把「決策規則」寫成可測試的敘述。例如把「A 系列產品只有華南經銷商可以看到含稅價」寫成驗收條件：

1Feature: 經銷商價格可見性
2
3  Scenario: 華南經銷商查看 A 系列產品
4    Given 使用者角色為 "dealer" 且區域為 "south-china"
5    And 產品線為 "A-series"
6    When 開啟產品詳情頁
7    Then 顯示含稅價欄位
8    And 顯示折扣階層 "tier-2"
9
10  Scenario: 其他區域經銷商查看 A 系列產品
11    Given 使用者角色為 "dealer" 且區域不為 "south-china"
12    When 開啟產品詳情頁
13    Then 隱藏含稅價欄位
14    And 顯示 "請聯繫業務窗口"

這種格式的價值不在於「敏捷儀式感」，而在於它同時是規格、測試案例與驗收單。跨時區協作時，一份能自動驗證的規則勝過三場視訊會議。

坑三：沒有人負責帳號與權限

90 天專案最常見的第一週卡點：GitHub 組織沒建、ERP 測試環境沒開、AD 帳號要走三層簽核、VPN 只給正式員工。

實務建議：在合約生效日之前，就把以下清單列為前置條件（Prerequisite），並指定一位內部 IT 負責人具名。

• 原始碼託管與 CI 權限（GitHub / GitLab 組織帳號）
• 非生產環境的 ERP 或 PIM 讀取權限，含測試資料集
• 網域與 DNS 管理權（或明確的變更流程與 SLA）
• 設計素材、字型授權、產品照片的實際來源與授權範圍
• 資安政策文件：哪些資料不能離境、哪些必須留在台灣機房

最後一項對跨境團隊尤其關鍵。台灣個人資料保護法（PDPA）對個資的國際傳輸有主管機關限制條款，若專案涉及經銷商聯絡人資料，權限邊界必須在動工前釐清，而不是在資安稽核時才發現。

Day 15–30：交接與上線期的節奏設計

坑四：週會變成唯一的溝通介面

第一次外包的公司常把「每週一次進度會議」當成管理手段。跨境團隊的問題是：如果週三卡住，等到下週一才講，就損失了四個工作日。

有效的替代方案是「非同步為主、同步為輔」：

• 每日文字站會（Slack / Teams 頻道，固定三行格式：昨天做了什麼、今天要做什麼、被什麼卡住）
• 每週一次 45 分鐘決策會——只處理需要老闆點頭的取捨，不報進度
• 每兩週一次可操作的 Demo——在真實環境上點得動，不是投影片

亞太時區在這裡是結構性優勢。台灣、香港、新加坡幾乎同時區（UTC+8），越南只差一小時（UTC+7），澳洲東岸領先 2–3 小時。這代表台灣製造商的工程團隊可以有 6–8 小時的實時重疊，而不是像使用歐美團隊那樣只能靠隔夜交接。反過來，對美國或歐洲的採購方而言，把亞太作為交付基地能取得「下班後仍在推進」的日夜接續，這是 IDC 在其亞太數位服務市場分析中反覆指出的區域優勢之一。

坑五：CI/CD 留到最後才做

製造業內部 IT 習慣「開發完再上線」，因為 ERP 的部署節奏本來就慢。但外包專案如果沒有第一週就把管線建起來，第 80 天的上線會變成災難。

最小可用的管線不需要複雜。以下是一個常見的 GitHub Actions 起點，涵蓋型別檢查、測試與預覽環境：

1name: ci
2on:
3  pull_request:
4    branches: [main]
5  push:
6    branches: [main]
7
8jobs:
9  verify:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: actions/checkout@v4
13      - uses: actions/setup-node@v4
14        with:
15          node-version: '20'
16          cache: 'pnpm'
17      - run: corepack enable
18      - run: pnpm install --frozen-lockfile
19      - run: pnpm typecheck
20      - run: pnpm test -- --run
21      - run: pnpm build
22
23  preview:
24    needs: verify
25    if: github.event_name == 'pull_request'
26    runs-on: ubuntu-latest
27    steps:
28      - uses: actions/checkout@v4
29      - name: Deploy preview
30        run: npx vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

重點不是工具選擇，而是「每一個 PR 都要產出一個內部人員點得動的網址」。在製造業，決策者往往是業務副總或產品經理，他們不會看 Figma，但會點連結。GitHub 在其 Octoverse 年度報告中持續觀察到自動化工作流程的採用擴散，而其中最直接的商業價值就是縮短回饋迴圈。

一段去識別化的實作觀察

Branch8 曾為一家透過經銷商網路銷售的亞太製造商建置線上選型與報價流程。專案初期最耗時的不是開發，而是把散落在多份 Excel 的選型規則轉成可版控的 JSON schema，並用 Playwright 為每條規則建立回歸測試。這裡的機制價值很明確：規則一旦進入版控，業務單位改一個折扣條件就能立刻看到哪些頁面與報價會受影響——這種可追溯性是紙本流程完全提供不了的。我們不宣稱具體百分比成效，因為那取決於客戶原有流程的成熟度。

Day 31–60：交付進入穩定期後才浮現的坑

坑六：ERP 整合被低估三倍

這是製造業外包專案最常見的排程殺手。內部認為「ERP 有 API」，實際情況通常是：

• API 是十年前的 SOAP 介面，文件已失聯
• 只有讀取權限，寫入必須走中介表
• 料號欄位有三套命名並存（舊系統、新系統、業務手動）
• 測試環境的資料是三年前的快照

處理方式是把整合層明確切開，不讓前端直接依賴 ERP。建立一個中介的資料契約，先用固定資料跑通，再逐步接真實來源：

1# 先用 contract 測試把介面凍結，再談實作
2npx openapi-typescript ./contracts/erp-product.yaml -o ./src/types/erp.ts
3npx prism mock ./contracts/erp-product.yaml --port 4010

這樣即使 ERP 端還在等資訊部門排程，前端與商業邏輯的開發仍能推進。代價是多一層維護成本——這是必須誠實承認的取捨，不是免費的架構美學。

坑七：驗收標準在最後兩週才被討論

如果「完成」的定義沒有在第 30 天前寫下來，第 85 天一定會有人說「這不是我想的那樣」。

建議把 Definition of Done 拆成三層，並在合約附件中列明：

1. 功能層：Gherkin 場景全數通過，含權限與空狀態。
2. 非功能層：核心頁面在 4G 網速下的載入指標、無障礙基本檢查、瀏覽器支援矩陣（製造業客戶常有 IE 模式的 legacy 需求，必須提早問）。
3. 移交層：README、環境變數清單、部署手冊、資料備援程序、以及一場錄影的知識移交會議。

第三層最常被跳過，卻是外包能否轉為長期合作的關鍵。沒有移交文件的專案，等於在第 91 天把客戶鎖進單一供應商——短期對供應商有利，長期會摧毀信任。

AI 增強如何改變 90 天的產出結構

2026 年談外包工程團隊，不能忽略 LLM 對交付結構的改變。麥肯錫（McKinsey）在其生成式 AI 經濟潛力研究中估算，生成式 AI 每年可能為全球經濟增加 2.6 兆至 4.4 兆美元的價值，而軟體工程是其中受影響最直接的職能之一。實務上，這對製造業外包專案的意義有三個具體面向：

規格轉譯的加速

製造業的規格文件經常是 PDF 型錄、掃描件與 Excel 混雜。用 LLM 做首輪結構化抽取（再由人工校驗），能把原本兩週的資料整理壓縮成幾天。關鍵是「抽取後必須有驗證步驟」——料號錯一碼，在工業設備的情境下是實質商業風險。

測試覆蓋率的補齊

小型外包團隊最容易犧牲的就是測試。用 AI 輔助生成回歸測試骨架，再由工程師修正斷言，能讓 2–3 人的團隊維持接近中型團隊的覆蓋率。這是「不用等比例增加人頭就放大產出」的最實際案例。

多語內容與跨境擴張

台灣製造商的出口市場通常橫跨東南亞、日本與歐美。傳統做法是英文先上、其他語言半年後補。用 AI 生成初稿 + 當地母語人員審校的流程，可以讓繁中、英、越、印尼、日語版本同步上線。Branch8 在越南、馬來西亞、印尼與菲律賓都有交付人員，這種在地審校的可及性，決定了 AI 譯稿能不能真的上線。

必須提醒的取捨：AI 增強會提高「產出速度」，但同時提高「審查負擔」。如果客戶端沒有人有能力做最終確認，速度只會讓錯誤更快擴散。

跨境團隊配置的四種常見組合

全台灣在地團隊

適合：涉及大量現場走訪、與工廠端頻繁互動、資料完全不得離境的專案。 代價：台灣資深工程師人才競爭激烈，排期彈性最低。

台灣 + 香港/新加坡

適合：需要跨境法遵、多幣別、國際客戶對接的 B2B 平台。香港與新加坡在跨境金流與英語商務文件上的熟練度較高。 代價：成本結構偏高，需要明確的工作切分避免重複。

台灣 + 越南/菲律賓

適合：需要規模化的實作量能（前端、QA、資料整理），時區僅差 0–1 小時。 代價：需要更強的規格文件紀律，模糊需求的溝通成本會被放大。

亞太團隊 + 歐美客戶端

適合：美國、英國、歐洲品牌想以亞洲為營運樞紐，取得日夜接續與區域市場知識。 代價：需要一位跨時區的 Delivery Lead 吸收會議負擔，這個角色不能省。

對台灣製造商而言，第二與第三種組合最常見：把需要理解製造業語言的角色放在台灣或香港，把可規格化的實作量能放在東南亞。這不是「找便宜勞力」，而是把不同市場的專長對應到不同工作類型。

90 天外包專案檢查清單

Day -14 至 0（合約前）

1. 指定一位內部具名決策者，具備核准設計與範圍變更的權限。
2. 完成帳號與環境權限清單，列為合約前置條件。
3. 書面確認資料出境與資安邊界。

Day 1–14

4. 產出可測試的驗收場景（Gherkin 或等效格式），涵蓋權限規則。
5. 建立 CI 管線與 PR 預覽環境。
6. 完成 ERP / PIM 的介面契約（OpenAPI），先用 mock 跑通。

Day 15–60

7. 每日文字站會 + 每兩週可操作 Demo。
8. 三層 Definition of Done 於 Day 30 前簽署。
9. 建立變更紀錄：每一次範圍調整都要有書面影響評估。

Day 61–90

10. 上線前完成非功能檢查（效能、無障礙、瀏覽器矩陣）。
11. 完成移交包：文件、環境變數、部署手冊、錄影知識移轉。
12. 排定第 91–120 天的保固與維運範圍，避免交付後真空期。

第一次外包最該修正的三個觀念

1. 外包買的是交付能力，不是工時。用角色覆蓋率而非人頭數來配置預算。
2. 文件密度決定跨境協作的成敗。製造業的隱性知識必須外顯化，否則時區優勢會被溝通成本吃掉。
3. AI 放大產出，也放大錯誤。速度提升的前提是客戶端保有審查能力。

90 天不足以完成一個完整的數位轉型，但足以驗證一個合作模式能不能長期運作。把這 90 天當成「建立協作介面」而非「衝一個功能」，第二個 90 天的效率會完全不同。

如果你正在評估第一次外包工程團隊，或想把既有的委外關係從「發案」升級為「持續交付」，歡迎與 Branch8 聊聊——我們在香港設有總部，並在台灣、新加坡、越南、馬來西亞、印尼、菲律賓與澳洲部署交付人員，熟悉製造業從 ERP 整合到經銷商入口的實作路徑。

Sources

• 行政院主計總處 — 國民所得及經濟成長統計
• Stack Overflow — 2024 Developer Survey
• GitHub — Octoverse 年度開發者報告
• McKinsey — The economic potential of generative AI
• IDC — Asia/Pacific Research and Insights
• GitHub Docs — GitHub Actions 文件
• 國家發展委員會個人資料保護專區
• Stoplight Prism — OpenAPI mock server 文件