外包東南亞工程師試用期設計：30 天入職 SOP 與績效框架

香港公司外包東南亞工程師時，試用期應設計為 30 天結構化入職：第 1–3 天完成帳號與環境交付、第 4–10 天交付首個可上線 PR、第 11–20 天獨立負責一個模組、第 21–30 天以 DORA 指標與 Code Review 品質做評估決策。

跨境工程外包最常見的失敗，不是找錯人，而是前 30 天沒有可量度的節奏。招募端花了六週篩選越南或菲律賓的資深後端工程師，結果第一週卡在 VPN 權限、第二週卡在本地環境跑不起來、第三週才拿到第一個 ticket——到了第 30 天，你手上沒有任何足以判斷「留或不留」的證據，只剩下主觀印象。

本文提供一套可直接複製的 30 天入職 SOP，包含實際的環境檢查腳本、權限矩陣、Code Review 評分表，以及香港公司在僱用越南、馬來西亞、印尼、菲律賓工程師時必須留意的合約與合規差異。

開始前需要準備什麼？

在新人 Day 1 之前，以下項目必須已經就緒。缺少任何一項，30 天的時鐘實際上是從第 5 天才開始跑。

合約與法務前置

1. 確認僱用模式：是直接聘僱（需當地實體或 EOR）、承包商合約（Independent Contractor），還是透過供應商派遣。這三者在稅務、IP 歸屬、終止條款上完全不同。
2. IP 轉讓條款：香港公司與越南、菲律賓承包商簽約時，IP assignment 必須明文寫入合約主文，而非只放在 NDA。世界銀行 Doing Business 歷史資料顯示，東南亞各國在合約執行效率上差異顯著，因此書面明確性比在本地訴訟更重要。
3. 試用期條款：若走 EOR 路線，各地法定試用期上限不同。根據越南《勞動法》2019 年版（Labour Code No. 45/2019/QH14），管理職試用期最長 180 天，一般專業職為 60 天；菲律賓 Labor Code 則規定一般試用期為 6 個月。你的 30 天評估是「內部里程碑」，不等於法定試用期終點。
4. 資料處理：若工程師會接觸香港用戶個資，需符合《個人資料（私隱）條例》(PDPO) 第 33 條的跨境傳輸考量，以及若涉及歐盟用戶則需 GDPR 的 SCC 安排。

技術前置清單

• SSO 帳號（Google Workspace / Microsoft Entra ID）
• 版本控制存取（GitHub / GitLab，最小權限起步）
• Secrets 管理（1Password Teams、Doppler 或 AWS Secrets Manager）
• 開發環境映像（Dev Container 或 Docker Compose）
• 觀測平台唯讀權限（Datadog / Grafana / Sentry）
• 專案管理工具（Linear / Jira）與一個已寫好的 onboarding epic

一份權限矩陣，而不是臨時開通

把權限分成三層，寫進 IaC 或至少寫進 Notion，讓每次入職都是複製一份：

Tier 0（Day 1 即開）：郵件、聊天、文件、Git 唯讀、Staging 環境、Sentry 唯讀。

Tier 1（首個 PR merge 後開）：Git write（含 branch protection）、CI 觸發權、Staging 部署權。

Tier 2（第 20 天後、且需二人核准）：Production 唯讀資料庫、feature flag 控制台、客戶資料遮罩檢視。

這個分層不是不信任，而是讓「權限開通」本身成為績效里程碑的一部分——新人知道自己在哪一層，你也知道風險敞口有多大。

Day 0：把環境交付變成一條指令

跨時區入職最大的隱形成本，是新人在雅加達卡住、而唯一能解的人在香港已經下班。解法是把環境設定變成可驗證、可自我除錯的腳本。

用 Dev Container 消除「我這邊跑得起來」

在 repo 根目錄放 .devcontainer/devcontainer.json：

1{
2  "name": "api-service",
3  "dockerComposeFile": "../docker-compose.dev.yml",
4  "service": "app",
5  "workspaceFolder": "/workspace",
6  "features": {
7    "ghcr.io/devcontainers/features/node:1": { "version": "20" },
8    "ghcr.io/devcontainers/features/aws-cli:1": {}
9  },
10  "postCreateCommand": "make bootstrap && make verify-onboarding",
11  "customizations": {
12    "vscode": {
13      "extensions": ["dbaeumer.vscode-eslint", "ms-azuretools.vscode-docker"]
14    }
15  }
16}

寫一個 verify-onboarding 檢查腳本

這是整套 SOP 中投報率最高的 30 行程式碼。新人自己跑，輸出直接貼到 Slack channel。

1#!/usr/bin/env bash
2# scripts/verify-onboarding.sh
3set -uo pipefail
4FAIL=0
5
6check() {
7  printf "%-38s" "$1"
8  if eval "$2" > /dev/null 2>&1; then
9    echo "PASS"
10  else
11    echo "FAIL  -> $3"
12    FAIL=1
13  fi
14}
15
16check "Node 20.x"            "node -v | grep -q '^v20'"        "nvm install 20"
17check "Docker daemon"        "docker info"                      "start Docker Desktop"
18check "Git SSH to origin"    "ssh -T [email protected] 2>&1 | grep -q success" "add SSH key to GitHub"
19check "Secrets loaded"       "test -n \"\${DATABASE_URL:-}\""    "run: doppler setup"
20check "DB reachable"         "pg_isready -d \"\$DATABASE_URL\"" "docker compose up -d db"
21check "Unit tests"           "npm run test:unit -- --silent"    "see logs above"
22check "Staging API reachable" "curl -fsS https://staging.internal/healthz" "check VPN / Tailscale"
23
24if [ "$FAIL" -eq 0 ]; then
25  echo "\nAll checks passed. Post this output in #eng-onboarding."
26else
27  echo "\nSome checks failed. Tag @onboarding-buddy with this output."
28  exit 1
29fi

預期輸出（成功時）：

1Node 20.x                             PASS
2Docker daemon                         PASS
3Git SSH to origin                     PASS
4Secrets loaded                        PASS
5DB reachable                          PASS
6Unit tests                            PASS
7Staging API reachable                 PASS
8
9All checks passed. Post this output in #eng-onboarding.

排錯提示：東南亞新人最常在 Staging API reachable 這一項失敗。原因通常不是 VPN 設定錯誤，而是公司防火牆的地理封鎖規則只白名單了香港與新加坡出口 IP。用 Tailscale 或 Cloudflare WARP 建立 mesh 網路，比逐一加白名單可維護得多。

Day 1–3：讓第一天就有輸出

這三天的目標不是「學完整個系統」，而是完成一次端到端的交付循環：改一行程式 → 開 PR → 通過 CI → 被 review → merge → 看到它跑在 staging。

Day 1 議程（以 GMT+7 為基準排）

1. 09:00 當地時間：跑 verify-onboarding.sh，非同步進行，不需要香港同事在線。
2. 10:30：閱讀 docs/architecture/README.md 與 ADR（Architecture Decision Records）前五份。
3. 14:00 當地 / 15:00 HKT：與 onboarding buddy 做 60 分鐘視訊，走一次系統圖與部署流程。這是唯一必須同步的時段。
4. 16:00：領取 good-first-issue 標籤的 ticket。

預先準備 3 個 good-first-issue

這些 issue 必須符合三個條件：真實會上線、影響範圍可控、需要碰到至少兩個子系統。典型例子：

• 為既有 API endpoint 補上結構化日誌欄位
• 修正一個在 Sentry 上有紀錄但低頻的 null 例外
• 把某個硬編碼設定移到 feature flag

避免給「更新 README 錯字」這類任務——它不產生任何可評估的訊號。

時區重疊是資產，不是障礙

香港（GMT+8）與越南、印尼西部、泰國（GMT+7）只差一小時，與菲律賓、馬來西亞、新加坡、台灣、澳洲西部完全同區或差兩小時內。對倫敦或紐約總部而言，這代表一個香港協調 + 東南亞交付的組合可以覆蓋歐洲早晨與美西傍晚。根據 Google、Temasek 與 Bain 的 e-Conomy SEA 報告，東南亞數位經濟持續為區域內累積工程人才密度，這使得「亞洲時區內組隊」在人才供給上愈來愈實際。

Day 4–10：第一個有意義的 PR

用 Code Review 當作結構化評估工具

不要只留「LGTM」。在這十天內，每個 PR 的 review 都應該對照四個面向留下可追溯的評語。建立一個 PR template：

1## What & Why
2
3## Reviewer scoring (internal, onboarding only)
4- [ ] Correctness — edge cases, null handling, idempotency
5- [ ] Codebase fit — follows existing patterns / ADRs
6- [ ] Testability — tests added, meaningful assertions
7- [ ] Communication — PR description, self-review comments
8
9Score 1-4 each. Record in Linear issue `ONB-<name>`.

觀察「提問品質」而非「提問次數」

遠距工程師常被誤判為「不主動」。實際上更有診斷力的指標是提問的形狀：

• 弱訊號：「這個跑不起來，可以幫忙嗎？」
• 強訊號：「OrderSyncJob 在 staging retry 三次後就靜默失敗。我看 Sentry 沒有事件，懷疑 catch block 吞掉例外。我打算加結構化日誌先確認，需要 15 分鐘，還是你們已知這個行為？」

第二種在第一週就出現，通常是很強的預測指標。把這個標準寫進評估表，讓 reviewer 有共同語言。

AI 輔助的門檻設定

2026 年的現實是：新人幾乎必然使用 GitHub Copilot、Claude Code 或 Cursor。與其禁止，不如在 Day 1 就把規則寫清楚。GitHub 官方文件說明 Copilot 的內容排除（content exclusion）可以在 repository 或 organization 層級設定，避免特定路徑被送入模型上下文：

1# .github/copilot/content_exclusion.yml 概念示意
2# 實際設定位置在 GitHub 組織設定介面
3"*":
4  - "/infra/secrets/**"
5  - "/**/*.pem"
6  - "/data/pii-samples/**"

評估重點不是「有沒有用 AI」，而是：他能否解釋 AI 生成程式碼的每一行？他有沒有為 AI 生成的部分補測試？在 review 中被問到邊界情況時，答得出來嗎？這在 30 天評估表中應該是獨立一欄。

Day 11–20：交出一個模組的所有權

第二階段的判斷點是：能不能獨立負責一個有邊界的功能，從需求釐清到上線。

設定可量測的交付指標

採用 DORA 四項指標的個人版本。DORA 的 Accelerate State of DevOps 研究長期將部署頻率、變更前置時間、變更失敗率、還原時間作為交付效能的核心量測。對新人做 30 天評估時，可以這樣落地：

• 變更前置時間：從第一次 commit 到 merge 的中位數。第 11–20 天目標：低於 48 小時。
• PR 大小：中位數低於 400 行變更。過大的 PR 通常代表沒有拆解需求。
• CI 首次通過率：目標 70% 以上。持續低於 40% 代表本地驗證習慣未建立。
• 變更失敗率：merge 後 7 天內需 hotfix 的比例。

用 GitHub CLI 直接拉數據，不需要買工具：

1# 取出該工程師近 14 天所有已 merge 的 PR，計算 additions/deletions 與週期
2gh pr list \
3  --repo your-org/api-service \
4  --author "engineer-github-handle" \
5  --state merged \
6  --search "merged:>=2026-01-11" \
7  --json number,title,createdAt,mergedAt,additions,deletions,reviews \
8  --limit 100 > onboarding-prs.json
9
10# 計算平均 lead time（小時）
11jq '[.[] | (( (.mergedAt|fromdateiso8601) - (.createdAt|fromdateiso8601) ) / 3600)]
12    | add / length' onboarding-prs.json

預期輸出範例：

131.4

排錯提示：如果 lead time 異常高，先排除「review 等待時間」再下判斷。跨時區團隊中，PR 停留 20 小時經常是香港 reviewer 的排程問題，不是工程師的問題。把 reviews[0].submittedAt 拆出來單獨計算，才看得到真實責任歸屬。

每週非同步 checkpoint

用固定格式的書面回報取代會議，這對 GMT+7 與 GMT+8 之間的協作特別有效：

1### Week N — <name>
2**Shipped:** (PR links)
3**In progress:** (with % and blocker)
4**Blocked by:** (person / decision / access)
5**Learned about the codebase:** (2 bullets)
6**Question I could not answer alone:** (1 item)

最後一項是刻意設計的——它讓「不懂」變成預期輸出而非失敗訊號，在階層文化較強的市場（越南、印尼、菲律賓部分團隊）尤其重要。

Day 21–30：做出留任決策

三軸評分框架

把主觀印象轉成三個軸，各自獨立評分，避免月暈效應。

軸一：技術交付（權重 40%）

• 程式正確性與邊界處理
• 測試覆蓋的意圖性（不是覆蓋率數字，是有沒有測到會壞的地方）
• 對既有架構模式的遵循度
• 除錯能力：能否從日誌與追蹤自行定位問題

軸二：非同步協作（權重 35%）

• 書面表達的清晰度（PR 描述、issue 更新、事故紀錄）
• 主動揭露阻塞的速度——理想是遇阻 4 小時內書面說明
• 對 review 意見的回應方式：接受、辯護、還是沉默改掉
• 文件貢獻：入職 30 天內至少修正或新增一份文件

軸三：系統理解（權重 25%）

• 能否畫出所負責模組的上下游依賴
• 能否指出一處他認為的技術債並說明取捨
• 對業務語境的掌握：知道這個功能服務哪類客戶

決策矩陣

用四個結果取代二元的「過 / 不過」：

1. 續約並擴大範圍：三軸皆 3 分以上（滿分 4），且軸二不低於 3。
2. 續約但維持現有範圍：總分達標但單軸偏弱，附上明確的 60 天改善目標與複評日期。
3. 延長觀察 30 天：技術軸強但協作軸弱。這種情況多半是入職設計問題而非人的問題——先檢查你有沒有給過非同步協作的明確範例。
4. 終止：軸二連續四週無改善，或出現誠信問題（例如無法解釋自己提交的程式碼）。

終止決策必須提前對照合約條款。若透過 EOR 僱用越南工程師，越南《勞動法》規定試用期內雙方可隨時終止且無需補償，但仍須支付已工作期間薪資；菲律賓的 regular employment 一旦成立則需 just cause 與 due process。跨市場一致的做法是：把 30 天評估寫成書面紀錄，無論法域都能作為佐證。

常見失敗模式與修正方式

失敗模式一：把外包工程師當成「多出來的手」

只丟零碎 ticket，永遠不給模組所有權。結果是 30 天後你只知道他會不會改 bug，不知道他能不能設計。修正：Day 11 起必須指派一個有邊界的模組，即使很小。

失敗模式二：Review 全部由同一人負責

單一 reviewer 的評分無法交叉驗證，也讓新人只學到一種風格。修正：30 天內至少三位不同 reviewer，其中一位來自另一個時區。

失敗模式三：把時區差當作藉口

「他在越南所以溝通慢」——實際上香港與越南只差一小時。真正的問題通常是流程沒有非同步化。修正：檢查是否有任何決策必須等香港上班才能推進；有的話，那是流程缺陷。

失敗模式四：權限開通排在最後

第 25 天才拿到 staging 部署權，等於前面三週的「獨立交付」評估全部失真。修正：把權限層級綁定里程碑，並自動化。

一個實作觀察

Branch8 曾為一家香港的多品牌零售集團建立跨境工程協作流程，交付端分佈在越南與菲律賓。當時把 verify-onboarding.sh 與 Dev Container 一併放進每個 repo，並以 Linear 的 onboarding template 追蹤三軸評分。最有效的單一改動不是任何工具，而是把「權限開通」從 IT 工單改為與 PR 里程碑綁定——新人不再需要在 Day 1 等待跨部門回覆，而工程主管也第一次能在第 10 天就說出具體的觀察，而不是「感覺還可以」。

把這套 SOP 擴展到多市場團隊

當你同時在越南、馬來西亞、印尼、菲律賓有工程師時，SOP 的價值在於一致性。幾個擴展建議：

1. 統一入職 repo：把 SOP、腳本、評分表放在一個 engineering-onboarding repo，用 PR 修改，有版本紀錄。
2. 本地化文化補充，不本地化標準：技術標準與評分軸全區一致；但補充各市場的節慶行事曆（例如越南 Tết、印尼 Idul Fitri、菲律賓 Holy Week）到共用日曆，避免把長假誤讀為投入度下降。
3. 合規分層：資料存取權限依市場而非依職級設定。若某市場尚未完成資料處理協議，該市場工程師停在 Tier 1。
4. 以香港為協調層：香港在時區、法制與跨境合約經驗上適合作為歐美總部與東南亞交付端之間的協調節點。這不是中間商，而是把合約風險、驗收標準與付款節奏集中管理。

對美國、英國、歐盟企業而言，這種「香港協調 + 東南亞交付」的結構帶來的是可預期性：一份適用普通法的合約、一套統一的驗收標準、覆蓋亞洲與歐洲工作時間的交付視窗。

如果你正在規劃跨境工程團隊，或想把現有的東南亞外包關係從「按小時買時間」升級成有 SOP、有指標、有交付責任的協作結構，Branch8 在香港、新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲的團隊可以協助你設計並落地這套流程——歡迎與我們談談你的具體情境。

Sources

• DORA — DevOps Research and Assessment
• GitHub Docs — GitHub Copilot content exclusion
• Development Containers — Specification and reference
• Google, Temasek & Bain — e-Conomy SEA report
• Hong Kong PCPD — Personal Data (Privacy) Ordinance
• ILO — NATLEX national labour law database
• GitHub CLI Manual — gh pr list
• Tailscale Documentation