台灣電商首次外包工程師：90 天交付 SOP 完整流程

第一次外包工程師的台灣電商，建議用 90 天分四階段執行：前 2 週寫出可驗收的職缺規格與試做題、第 1–10 天完成環境與權限交付、第 11–60 天以雙週里程碑驗收、第 61–90 天完成移交與知識資產化。每階段都要有書面 DoD（完成定義）。

這篇是操作手冊，不是觀念文。以下每個步驟都附上可以直接複製的設定檔、指令與驗收腳本。適用對象是年營收約新台幣 3,000 萬到 5 億、內部沒有專職 CTO、第一次把工程工作交給外部團隊或個人接案者的台灣電商（Shopify、91APP、Cyberbiz、WooCommerce 或自建站皆適用）。

開始前：你必須先備妥的 6 件事

沒有這 6 項，90 天一定會延期。請先做完再開始找人。

1. 一位有決策權的內部窗口（Product Owner）。不需要會寫程式，但必須能在 24 小時內回答「這個需求要不要做」。外包失敗最常見的原因不是工程師能力，是需求在公司內部卡住。
2. 原始碼與主機的所有權清單。誰持有網域註冊商帳號、誰是 Shopify store owner、誰是雲端主機付款人。若這些目前在前一個接案者手上，先取回再談。
3. 一個乾淨的 Git 儲存庫。不接受「壓縮檔傳來傳去」。GitHub 或 GitLab 皆可。
4. 一套 staging（測試）環境。正式站不能是唯一環境。
5. 書面的資料處理規範。台灣《個人資料保護法》對蒐集、處理、利用個資有明確限制，外部工程師若會接觸訂單與會員資料，委外關係必須以契約約定監督義務（條文可在法務部全國法規資料庫查閱）。
6. 一筆預留的第 4 個月預算。90 天是交付第一個可運作版本的週期，不是永遠結束。

這份 SOP 的 90 天結構

• Day -14 ~ Day 0：規格化職缺、篩選、試做題、簽約
• Day 1 ~ Day 10：環境交付、權限、第一次 commit 上 staging
• Day 11 ~ Day 60：四個雙週里程碑，每個都有獨立驗收
• Day 61 ~ Day 90：壓測、資安檢查、文件移交、上線與觀察期

為什麼是 90 天，而不是 30 天或一年？

90 天剛好涵蓋一次完整的「建置 → 上線 → 觀察」循環，而且短到足以在成本失控前喊停。

Google Cloud 的 DORA（DevOps Research and Assessment）研究長期以四項指標衡量交付效能：部署頻率、變更前置時間、變更失敗率、服務復原時間。這四項指標的共同點是——都需要至少幾十次部署才會出現有意義的數據。一個月的合作期通常只會累積個位數次部署，你無從判斷這個團隊的穩定性；一年期的合約則讓你在第 45 天就發現不對勁時，失去談判籌碼。

另一個現實理由：台灣電商的季節性極強。雙 11、雙 12 到農曆年是一個完整週期。90 天讓你有機會在真實流量壓力下驗收，而不是只在後台看功能有沒有跑出來。

Day -14 ~ Day 0：把職缺寫成可驗收的規格

步驟 1：用 YAML 寫職缺，不要用形容詞

把需求寫成結構化文件，之後可以直接轉成合約附件與驗收基準。

1# role-spec.yaml
2role: Senior Full-stack Engineer (Contract, 90 days)
3engagement: 每週 30 小時，台北時間 10:00-18:00 需有 4 小時重疊
4stack_required:
5  - Shopify Liquid + Storefront API (2024-10 或更新版本)
6  - Node.js 20 LTS
7  - TypeScript 5.x
8stack_nice_to_have:
9  - 綠界 ECPay / 藍新 NewebPay 金流串接經驗
10  - 黑貓宅配、7-ELEVEN 超商取貨 API
11  - LINE Messaging API / LINE LIFF
12deliverables_90d:
13  - D1: 會員積點系統（前後台 + 對帳報表）
14  - D2: 訂單匯出至 ERP 的排程任務（每日 02:00）
15  - D3: 商品頁 LCP < 2.5s（行動版，4G 模擬）
16out_of_scope:
17  - 視覺設計、文案、廣告投放
18acceptance_owner: 電商部經理（單一決策人）

為什麼要列 out_of_scope：範圍蔓延是外包糾紛的第一名成因。明確寫下「不包含」比寫一百條「包含」有效。

步驟 2：設計一題 3 小時內能完成的試做題

不要出演算法題。出一題跟你實際業務同構、但不含機密資料的題目。

1## 試做題（限時 3 小時，可使用 AI 工具，但需說明如何使用）
2
3給定附檔 orders.csv（1,000 筆假資料，欄位：order_id, member_id,
4sku, qty, unit_price, created_at, channel）：
5
61. 寫一支 Node.js CLI，輸出每位會員的「近 90 天消費金額」與
7   「首購通路」，結果存成 SQLite。
82. 加一個 `--dry-run` 參數，只印統計不寫檔。
93. 附上至少 3 個單元測試。
104. 在 README 說明：若資料量成長到 500 萬筆，你會改哪裡。

第 4 題才是真正的篩選點。能回答「我會改成 streaming 讀取並批次寫入」的人，和只會把整個檔案讀進記憶體的人，差距會在你的訂單量成長到一定規模時全部爆發。

明確允許使用 AI 工具。根據 Stack Overflow 年度開發者調查（survey.stackoverflow.co），使用 AI 編碼工具的開發者比例已成為業界常態指標之一。假裝禁止只會讓候選人隱瞞，不如要求他說明「哪一段是 Copilot 產生、你怎麼驗證它」——這個回答比程式碼本身更能看出判斷力。

步驟 3：合約必備的 5 個條款

• 智慧財產權歸屬：明確寫明所有交付物（含尚未上線的分支）著作權歸委託方。
• 保密與個資：引用《個人資料保護法》的委外監督義務，約定測試環境一律使用去識別化資料。
• 驗收方式：以 DoD 清單逐項打勾，非「甲方滿意為止」。
• 移交義務：合約結束前 10 天須完成文件與帳號移交，付款尾款與此掛鉤。
• 終止條款：任一雙週里程碑連續兩次未通過驗收，得無責終止。

Day 1 ~ Day 10：環境、權限與第一次 commit

目標很單純：第 10 天結束前，外部工程師要能獨立把一行改動推上 staging 並看到結果。做不到，就是你的環境有問題，不是他的能力問題。

步驟 4：用最小權限原則發放存取

1# Shopify：建立獨立的 collaborator 帳號，不要共用 store owner
2# Partner Dashboard > Stores > Manage collaborators
3# 勾選：Themes, Apps, Orders (View only), Products
4# 不勾選：Settings > Payment providers, Finances
5
6# GitHub：用 team 而非個人授權
7gh api -X PUT /orgs/YOUR_ORG/teams/contractors/repos/YOUR_ORG/storefront \
8  -f permission='push'
9
10# 保護 main 分支
11gh api -X PUT /repos/YOUR_ORG/storefront/branches/main/protection \
12  -F required_pull_request_reviews.required_approving_review_count=1 \
13  -F enforce_admins=true \
14  -F required_status_checks.strict=true \
15  -F 'required_status_checks.contexts[]=ci/build'

預期輸出：外部工程師無法直接 push 到 main，只能開 PR；正式站的金流設定與財務報表他看不到。

步驟 5：把環境變數規格化

1# .env.example（進版控，真實值永不進版控）
2SHOPIFY_STORE_DOMAIN=your-store.myshopify.com
3SHOPIFY_STOREFRONT_TOKEN=          # Storefront API, 唯讀
4SHOPIFY_ADMIN_TOKEN=               # Admin API, staging 專用 app
5ECPAY_MERCHANT_ID=                 # 綠界測試商店代號
6ECPAY_HASH_KEY=
7ECPAY_HASH_IV=
8LINE_CHANNEL_SECRET=
9DATABASE_URL=postgres://app:app@localhost:5432/app_dev
10LOG_LEVEL=debug

真實憑證用 1Password、Bitwarden 或 Doppler 發放，不要用 LINE 或 Email 傳。

步驟 6：一行指令就能跑起來的本機環境

1# docker-compose.yml
2services:
3  db:
4    image: postgres:16-alpine
5    environment:
6      POSTGRES_USER: app
7      POSTGRES_PASSWORD: app
8      POSTGRES_DB: app_dev
9    ports: ["5432:5432"]
10    healthcheck:
11      test: ["CMD-SHELL", "pg_isready -U app"]
12      interval: 5s
13      retries: 10
14  redis:
15    image: redis:7-alpine
16    ports: ["6379:6379"]

1docker compose up -d && npm ci && npm run db:migrate && npm run dev
2# 預期輸出：
3# ✔ db healthy
4# ✔ 12 migrations applied
5# ➜ Local: http://localhost:3000

如果這段超過 15 分鐘跑不起來，先修環境，不要先開功能票。Docker 官方文件的 Compose 章節有完整的 healthcheck 與 depends_on 語法參考。

步驟 7：CI 從第一天就存在

1# .github/workflows/ci.yml
2name: ci
3on:
4  pull_request:
5    branches: [main]
6jobs:
7  build:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v4
11      - uses: actions/setup-node@v4
12        with:
13          node-version: '20'
14          cache: 'npm'
15      - run: npm ci
16      - run: npm run lint
17      - run: npm run typecheck
18      - run: npm test -- --coverage
19      - name: Block secrets
20        run: |
21          if git diff --name-only origin/main...HEAD | xargs grep -lE \
22            '(sk_live|shpat_|HASH_IV=[A-Za-z0-9]{8,})' 2>/dev/null; then
23            echo "::error::疑似憑證進入版控"; exit 1
24          fi

GitHub Actions 的官方文件（docs.github.com/actions）有完整的 secret scanning 與 environment protection 設定說明，建議一併啟用 push protection。

Day 10 驗收點

• [ ] 外部工程師已獨立開出第一個 PR 並通過 CI
• [ ] staging 網址可由內部窗口自行開啟確認
• [ ] 所有憑證由密碼管理工具發放，無任何一組經由即時通訊軟體傳遞
• [ ] 有一份 ARCHITECTURE.md，由工程師撰寫、內部窗口讀得懂

Day 11 ~ Day 60：雙週里程碑與 AI 輔助的產出放大

步驟 8：每個里程碑都要有 DoD

把「完成」寫成清單，不要寫成感覺。

1## M2 DoD：會員積點系統（Day 25-38）
2- [ ] 積點規則可由後台設定（消費金額 / 檔期倍率 / 有效期）
3- [ ] 退貨時自動扣回對應積點，並寫入 audit log
4- [ ] 與現有會員 ID 一對一綁定，無孤兒紀錄
5  驗證：SELECT COUNT(*) FROM points WHERE member_id NOT IN
6        (SELECT id FROM members); 必須 = 0
7- [ ] API p95 延遲 < 300ms（1,000 筆併發，見 k6 腳本）
8- [ ] 單元測試涵蓋率 ≥ 70%，積點計算模組 ≥ 90%
9- [ ] 後台操作手冊（含截圖）已交付客服主管

最後一項最常被跳過，也最常在工程師離開後造成災難。

步驟 9：用腳本驗收，不要用肉眼

1// load/points.js — k6 壓測
2import http from 'k6/http';
3import { check } from 'k6';
4
5export const options = {
6  stages: [
7    { duration: '30s', target: 100 },
8    { duration: '1m', target: 1000 },
9    { duration: '30s', target: 0 },
10  ],
11  thresholds: {
12    http_req_duration: ['p(95)<300'],
13    http_req_failed: ['rate<0.01'],
14  },
15};
16
17export default function () {
18  const res = http.get(`${__ENV.BASE_URL}/api/members/1001/points`);
19  check(res, { 'status 200': (r) => r.status === 200 });
20}

1k6 run -e BASE_URL=https://staging.example.com load/points.js
2# 預期輸出（節錄）：
3# ✓ http_req_duration..: p(95)=214ms
4# ✓ http_req_failed....: 0.12%

門檻沒過就是沒過。這比在會議上爭論「有點慢」有效率得多。

步驟 10：把 AI 工具納入流程，而不是假裝它不存在

2026 年的現實是：一位外包工程師的產出，很大一部分來自他如何調度 LLM。與其禁止，不如規範。

可以要求納入合約的三條規則：

• 禁止把客戶原始碼或個資貼進公開 LLM。使用企業版（如 GitHub Copilot Business 或自架模型）並關閉訓練回饋。
• AI 產生的程式碼必須通過同一套 CI 與 code review，不因來源不同而降低標準。
• PR 描述需註明 AI 輔助範圍，例如「測試案例由 LLM 草擬、邏輯由人工修正」。

這件事的價值在於：當你下一次要評估「要不要增加人力」時，你會知道現有產出有多少來自流程效率、多少來自真實工時。

1<!-- .github/pull_request_template.md -->
2## 改動內容
3
4## 對應 DoD 項目
5
6## 測試方式（請寫出可重現的指令）
7
8## AI 輔助說明
9- [ ] 無
10- [ ] 部分：____________（說明驗證方式）
11
12## 風險與 rollback 方案

步驟 11：固定的溝通節奏

• 每日：非同步文字站會（Slack / Teams），三行：昨天、今天、卡點。不開視訊。
• 每週一次 30 分鐘：只討論卡點與決策，不做進度報告。
• 每雙週一次 60 分鐘：里程碑驗收會，帶著 DoD 清單逐項打勾。

若你的團隊橫跨台灣、越南與菲律賓，台北時間 10:00–18:00 對河內（UTC+7）與馬尼拉（UTC+8）都在正常工時內，重疊窗口幾乎完整；加上澳洲（AEDT）可再往後延兩小時做夜間值班交接。這是亞太團隊結構相對歐美外包的實際優勢——不是成本，是時區連續性。

Day 61 ~ Day 90：驗收、移交與知識資產化

步驟 12：跑完整的上線前檢查

1# 1. 效能
2npx @lhci/cli autorun --collect.url=https://staging.example.com/products/demo \
3  --assert.preset=lighthouse:recommended
4
5# 2. 相依套件漏洞
6npm audit --audit-level=high
7
8# 3. 資安基準：對照 OWASP Top 10
9#    重點檢查：存取控制失效、注入、安全設定錯誤
10
11# 4. 備份還原演練（最常被跳過的一項）
12pg_dump $PROD_URL | psql $RESTORE_TEST_URL
13psql $RESTORE_TEST_URL -c "SELECT COUNT(*) FROM orders;"

OWASP Top 10 是國際公認的 Web 應用風險清單（owasp.org），對電商而言「存取控制失效」特別關鍵——會員能不能改網址參數看到別人的訂單，請務必手動測一次。

步驟 13：移交清單（尾款掛鉤）

• [ ] README.md：本機啟動步驟，新人照做 30 分鐘內可跑起來
• [ ] ARCHITECTURE.md：系統圖、外部服務清單、資料流
• [ ] RUNBOOK.md：常見故障排除（金流 callback 失敗、排程沒跑、快取沒清）
• [ ] 所有雲端服務、第三方 API 的帳號已轉為公司信箱持有
• [ ] 螢幕錄影 3 支，各 10 分鐘以內：部署流程、資料庫維運、後台操作
• [ ] 已知技術債清單（TECH_DEBT.md），含優先順序建議

步驟 14：保留 14 天觀察期

上線不等於交付完成。合約設計上，把最後 10–14 天留作觀察期：工程師不再開發新功能，只修上線後發現的問題。這段期間的缺陷數量，是你決定要不要續約最誠實的數據。

常見問題排查

第 10 天環境還跑不起來

通常不是工程師的問題。 檢查：Node 版本是否鎖定（加 .nvmrc）、資料庫種子資料是否存在、是否有某個只在某人電腦上的隱形相依。解法：把環境建置寫成 Dockerfile，讓它可重現。

里程碑一直「差一點就好了」

這是 DoD 寫得不夠具體的症狀。把「效能要好」改成「p95 < 300ms，用這支 k6 腳本量」。無法用指令驗證的 DoD 項目，都應該重寫。

工程師人間蒸發

預防重於治療：從第一天就要求所有程式碼進 Git、所有決策寫進 PR 描述。若真的發生，你至少擁有完整的 commit 歷史與可運作的 CI，接手者的成本會低很多。這也是為什麼「壓縮檔交付」絕不可接受。

正式站改壞了

分支保護 + 需要 review 的 PR + staging 先行，三者缺一不可。另外建議所有功能都用 feature flag 包起來：

1if (await flags.isEnabled('points_v2', { memberId })) {
2  return newPointsEngine(member);
3}
4return legacyPointsEngine(member);

出事時關掉旗標，比緊急回滾部署安全。

對方要求先付全額

以里程碑分段付款，每段對應一次 DoD 驗收。尾款綁移交清單。這對雙方都公平：工程師有明確的完成定義，你有明確的檢核點。

亞太跨境協作的三個實務考量

時區連續性比工時單價更值錢。 台灣（UTC+8）與新加坡、馬來西亞、香港同時區，與越南、印尼相差一小時，與澳洲東岸相差二至三小時。一個以台北為核心、搭配東南亞與澳洲的組合，可以做到接近 14 小時的有效協作窗口，而歐美客戶則能在他們下班後收到進度。

在地法規知識無法遠端補課。 台灣的電子發票（財政部電子發票整合服務平台）、超商取貨流程、《個人資料保護法》的委外監督義務，這些不是讀文件就能做對的事。跨境團隊的價值在於「有人真的做過台灣的金流串接」，而不是「時薪比較低」。

書面文化要先建立。 非同步協作的前提是決策留下文字紀錄。Branch8 在為一家台灣多品牌服飾電商規劃跨境工程團隊時，第一個導入的不是任何框架，而是強制所有技術決策寫成 ADR（Architecture Decision Record）進版控——因為當團隊分佈在三個城市，會議記憶不可靠，只有 repo 裡的東西才算數。

90 天結束後，你應該擁有什麼

• 一套可重現的環境與 CI
• 四次通過 DoD 驗收的交付紀錄
• 一份可讀的架構文件與 runbook
• 一份誠實的技術債清單
• 足夠的數據判斷要不要續約、要不要自建團隊

如果 90 天後你只拿到「網站可以動」，那你買到的是一次性專案，不是一個可延續的工程能力。這兩者的差距，會在第二次外包時全部顯現。

Branch8 總部位於香港，在台灣、新加坡、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，專長是協助電商品牌建立第一次可驗收的外部工程流程——從職缺規格、CI 建置到移交文件。若你正準備第一次外包工程工作，歡迎與我們談談你的 90 天計畫。

Sources

• Google Cloud — DevOps Research and Assessment (DORA)
• Stack Overflow — Annual Developer Survey
• OWASP — Top 10 Web Application Security Risks
• GitHub — GitHub Actions Documentation
• Shopify — Developer Documentation
• Docker — Compose Documentation
• Grafana — k6 Load Testing Documentation
• 法務部 — 全國法規資料庫（個人資料保護法）