香港電商品牌首次外包工程師：30 天交付 SOP

香港電商品牌第一次外包工程師，成敗多數不在於找到誰，而在於頭 30 天有冇一套可驗收的交付流程。本文提供一套實戰 SOP：Day 0–3 定義驗收標準、Day 4–7 建立環境與 CI、Day 8–14 交付首個可上線增量、Day 15–30 建立節奏並完成知識移交。

為什麼第一次外包多數在第 21 天出事

觀察過不少首次外包的品牌，問題幾乎不是「工程師唔識做」，而是三件事在第三週同時爆發：需求口頭化、環境權限不齊、驗收標準模糊。頭兩週大家仲客氣，第三週開始趕上線，才發現「我以為你做咗」與「我以為唔使做」之間相差一個 sprint。

Google Cloud 的 DORA《State of DevOps》研究長期以四個指標（部署頻率、變更前置時間、變更失敗率、服務回復時間）衡量交付效能，其核心結論是：穩定與速度並非取捨，而是由流程與自動化同時決定。對首次外包的品牌而言，這代表一件事——你要交付的第一件產物不是功能，而是流程本身。

這套 SOP 適用於香港、台灣、新加坡的品牌，同樣適用於美國、英國、歐盟品牌把工程交付放在亞洲時區：當團隊分布在香港、台北、胡志明市、吉隆坡與悉尼，時區覆蓋是優勢，但前提是異步協作的規則寫得夠清楚。

開工前必須齊備的 6 項前置條件

未齊之前唔好開 Day 1。以下每項缺一，都會在第二週變成阻塞：

1. 單一決策人（Single Decision Maker）：一位有權拍板 scope 的品牌方負責人，並非委員會。
2. 平台管理員權限清單：Shopify / Magento / WooCommerce 後台、GitHub 或 GitLab 組織、DNS（多數香港品牌用 Cloudflare）、支付閘道（Stripe、PayMe for Business、Alipay HK）、以及 GA4 與 GTM。
3. 現存資產盤點：現有 theme repo、第三方 app 清單、自訂腳本、舊 agency 留低的 FTP 或 SFTP 存取。
4. 一條可量度的業務目標：例如「結帳流程手機版 LCP 降至 2.5 秒以內」。Google 的 web.dev 文件明確定義 Core Web Vitals 的 LCP「良好」門檻為 2.5 秒，INP 為 200 毫秒——用官方門檻做驗收，避免主觀爭拗。
5. 測試環境與測試資料：Shopify 用 development store，Magento 用 staging，並準備可重現的測試訂單。
6. 合約與資料處理條款：包括保密、IP 歸屬、個人資料處理範圍（詳見下文合規段落）。

一份可直接複製的權限交接表

用 repo 內的 docs/access.md 管理，而非 WhatsApp 訊息：

CODEBLOCK_MARKER_0 （如你的文件工具不支援表格，改用每個系統一個 bullet 區塊。）重點是每一項都有「回收日期」——外包結束後未回收的權限，是最常見的資安債。

Day 0–3：把需求翻譯成可驗收的工程語言

這三日唔寫 code。產出是三份文件。

1. Scope 一頁紙

列明 In Scope / Out of Scope / Assumptions。Out of Scope 至少要寫夠 5 項，因為爭議永遠發生在「無寫過但以為包咗」。

2. Definition of Done（DoD）

把 DoD 放入 repo，令每張工單都引用同一份標準：

1## Definition of Done
2- [ ] 功能在 staging 通過所有驗收條件（AC）
3- [ ] 手機版（iPhone SE 375px）與桌面版（1440px）視覺檢查完成
4- [ ] Lighthouse Performance ≥ 80（mobile, staging URL）
5- [ ] 無新增 console error；無新增 theme-check offense
6- [ ] 文件已更新（README 或 docs/）
7- [ ] PR 已由 CODEOWNERS 審核並 squash merge
8- [ ] 相關事件已在 GA4 / GTM 驗證觸發

3. 工單模板

Jira 或 Linear 都可以，重點是 AC 用 Given/When/Then 寫法：

1**User Story**: 作為手機用家，我希望在購物車直接調整數量，避免重新載入頁面。
2
3**Acceptance Criteria**
4- Given 購物車有 1 件商品
5- When 我按「+」
6- Then 小計以 AJAX 更新，且無整頁刷新
7- And 若庫存不足，顯示 inline error（不使用 alert）
8
9**Out of Scope**: 折扣碼邏輯、結帳頁改動

預期產出：Day 3 結束時，品牌方與外包團隊對「完成」有同一個定義，並且已切出 8–12 張可估算的工單。

Day 4–7：環境、權限與 CI 的最小可行設定

目標係 Day 7 前，任何一個工程師 clone repo 後 15 分鐘內可以跑起本機環境。

建議 repo 結構（以 Shopify Online Store 2.0 為例）

1.
2├── .github/
3│   ├── workflows/ci.yml
4│   ├── CODEOWNERS
5│   └── pull_request_template.md
6├── assets/
7├── config/
8├── layout/
9├── sections/
10├── snippets/
11├── templates/
12├── docs/
13│   ├── access.md
14│   ├── runbook.md
15│   └── decisions/    # ADR：每個技術決定一個檔案
16├── .env.example
17└── .theme-check.yml

本機啟動指令

Shopify CLI 3.x：

1npm install -g @shopify/cli @shopify/theme
2shopify theme dev --store your-dev-store.myshopify.com
3# 拉取線上版本做基線比對
4shopify theme pull --theme <THEME_ID> --path ./baseline

.env.example（永遠不要 commit .env）

1SHOPIFY_STORE_DOMAIN=your-dev-store.myshopify.com
2SHOPIFY_ADMIN_API_VERSION=2025-01
3SHOPIFY_ADMIN_TOKEN=
4SHOPIFY_WEBHOOK_SECRET=
5SENTRY_DSN=

Shopify 的 Admin API 採用季度版本發布並標示支援期限（見 shopify.dev 的 API versioning 文件），所以 API 版本必須寫死在設定檔而非散落於程式碼——否則外包團隊離場後，下一個人要翻遍整個 repo 先知你用緊邊個版本。

最小可行 CI

1# .github/workflows/ci.yml
2name: CI
3on:
4  pull_request:
5    branches: [main, develop]
6
7jobs:
8  quality:
9    runs-on: ubuntu-latest
10    steps:
11      - uses: actions/checkout@v4
12      - uses: ruby/setup-ruby@v1
13        with:
14          ruby-version: '3.2'
15      - name: Install Theme Check
16        run: gem install theme-check
17      - name: Run Theme Check
18        run: theme-check .
19      - uses: actions/setup-node@v4
20        with:
21          node-version: '20'
22      - name: Lint JS
23        run: npx eslint assets/*.js --max-warnings=0

分支保護（用 gh CLI，一次過設定）

1gh api -X PUT repos/:owner/:repo/branches/main/protection \
2  -F required_pull_request_reviews.required_approving_review_count=1 \
3  -F enforce_admins=true \
4  -F required_status_checks.strict=true \
5  -F 'required_status_checks.contexts[]=quality'

CODEOWNERS

1*                 @brand-tech-lead
2/templates/       @brand-tech-lead @vendor-lead
3/config/          @brand-tech-lead

Troubleshooting（Day 4–7 最常見）

• shopify theme dev 卡住：多數是 dev store 未授權該 collaborator 帳號，需在 Shopify admin 的 Users and permissions 重新發出 collaborator request。
• theme-check 一開始就有數百個 offense：不要一次過修。在 .theme-check.yml 先 disable 非關鍵規則，並建立一張技術債工單，逐步收窄。
• 無法取得 DNS 權限：先用 staging 子網域（例：stg.brand.com）並加上 X-Robots-Tag: noindex，不要為等 DNS 而停工。

Day 8–14：交付第一個可上線的垂直切片

第二週唯一目標：交付一個端到端的小功能（vertical slice），而非三個做咗一半的大功能。這是驗證整條交付管道（需求 → PR → review → staging → UAT → production）是否通暢的唯一方法。

選題原則：

1. 有真實業務價值（例如迷你購物車數量調整、尺碼表 drawer）
2. 觸及前端、後端或 API、以及數據追蹤三層
3. 可在 3–5 個工作天內完成

Webhook 驗證範例（常見於訂單同步需求）

1// verifyWebhook.js — Shopify HMAC 驗證
2import crypto from 'node:crypto';
3
4export function verifyShopifyWebhook(rawBody, hmacHeader, secret) {
5  const digest = crypto
6    .createHmac('sha256', secret)
7    .update(rawBody, 'utf8')
8    .digest('base64');
9  return crypto.timingSafeEqual(
10    Buffer.from(digest),
11    Buffer.from(hmacHeader)
12  );
13}

注意用 timingSafeEqual 而非 ===。這類細節正是你付費請專業工程師的原因，也應該寫入 code review checklist。

Day 14 的驗收會（45 分鐘，固定議程）

1. Demo on staging（15 分鐘，由工程師操作，品牌方不許只睇截圖）
2. 對照 DoD 逐項確認（10 分鐘）
3. 風險與阻塞（10 分鐘）
4. 下兩週 scope 確認（10 分鐘）

預期輸出：一個已合併到 main、可隨時上線的增量；一份更新過的風險清單。

Day 15–21：建立節奏、SLA 與跨時區協作規則

第三週是節奏成形期。跨境團隊尤其需要把「同步」與「異步」分清楚。

異步優先的溝通合約

• 每日站會以文字進行：每位成員在共用頻道發三行——昨日、今日、阻塞。香港與台北同時區，胡志明市 −1 小時，悉尼 +2/+3 小時，文字站會令四地都唔使就時間。
• 同步會議每週一次：固定在重疊時段（香港時間 15:00–17:00 通常同時覆蓋悉尼下午與東南亞下午）。
• 決策必須落地為 ADR：docs/decisions/0003-use-metaobjects-for-size-chart.md。

回應 SLA（寫入合約附件）

• P1 生產環境無法下單：30 分鐘內回應，4 小時內緩解
• P2 主要功能受損但有 workaround：下一個工作日回應
• P3 一般問題與需求澄清：2 個工作日內回應
• P4 改進建議：納入下次 backlog 檢視

P1 必須列明呼叫方式（電話或 on-call 輪值），而非只靠 Slack。

對於美國、英國、歐盟品牌的時區紅利

倫敦與香港相差 7–8 小時，紐約相差 12–13 小時。用得好，這是「日落交接」：倫敦團隊下班前提交需求與 PR 意見，亞洲團隊在對方睡覺時完成並部署到 staging，早上 review。用得差，就變成每個問題都要等 24 小時。分別在於文件密度——異步協作的成本，全部由文件品質決定。

Day 22–30：UAT、上線與知識移交

UAT 腳本（由品牌方執行，而非工程師自測）

1### UAT-07 手機結帳（iOS Safari）
21. 加入 2 件商品至購物車
32. 套用折扣碼 TEST10
43. 選擇順豐站自取
54. 以測試信用卡完成付款
6預期：訂單確認頁顯示折扣後金額；GA4 purchase 事件觸發一次（非兩次）
7實際：
8通過 / 失敗：

上線 Runbook

1## Release Runbook — v1.2.0
2**上線窗口**：香港時間週二 10:00（避開週末與晚間流量高峰）
3**前置**：staging UAT 全數通過；已備份現行 theme（`shopify theme pull`）
4
51. 於 Shopify admin 複製現行 live theme 作為 rollback-YYYYMMDD
62. `shopify theme push --theme <STAGING_THEME_ID>` → 預覽確認
73. Publish theme
84. 冒煙測試：首頁、PDP、加入購物車、結帳（真實小額訂單）
95. 觀察 30 分鐘：Sentry error rate、GA4 即時轉換
10
11**Rollback**：於 admin publish rollback-YYYYMMDD（預計 2 分鐘內完成）

知識移交的三份必備產物

1. Runbook：部署、回滾、常見故障處理
2. 架構決策紀錄（ADR）：解釋「點解咁做」，比程式註解更重要
3. 錄影 walkthrough：30–45 分鐘，涵蓋 repo 結構、關鍵模組、第三方整合

把移交安排在 Day 28 而非 Day 30——留兩日修補文件缺口。

權限回收

CODEBLOCK_MARKER_12 Shopify collaborator 帳號、Cloudflare、GA4、GTM、支付後台逐項對照 docs/access.md 回收，並記錄日期。

如何用 LLM 把小團隊的產出放大

2026 年的現實是：外包團隊規模細，但輸出可以唔成比例地大——前提係有規則。GitHub 的 Octoverse 報告指出，AI 相關專案與使用 AI 工具的開發者數量近年持續上升，已成為主流工作流一部分。實務上我們會這樣用：

• 規格轉工單：將會議記錄丟俾 LLM，產出 Given/When/Then 草稿，再由人類 tech lead 校訂。草稿由 AI 寫，判斷由人做。
• PR 首輪自檢：在 PR 模板加入 AI review checklist（N+1 查詢、未處理的 null、硬編碼 API 版本），人類 reviewer 專注業務邏輯。
• 測試資料生成：生成邊界個案的訂單資料（零元訂單、多幣別、部分退款）。
• 文件維護：每個 sprint 末由 AI 草擬 runbook 更新 diff，由工程師確認。

必須寫明的紅線：不得將客戶個人資料、API 金鑰、未公開的商業條款貼入任何第三方 LLM。把這條寫入合約與 repo 的 CONTRIBUTING.md，並在 CI 加入 secret scanning：

1      - name: Secret scan
2        uses: gitleaks/gitleaks-action@v2
3        env:
4          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

跨境外包的資料邊界與合規

香港《個人資料（私隱）條例》由私隱專員公署（PCPD）執行，設有六項保障資料原則，涵蓋收集目的、準確性、保留期、使用、保安及查閱權。當你的外包團隊分布於新加坡、越南或菲律賓，實務上要處理三件事：

1. 資料最小化：開發環境一律使用匿名化或合成訂單資料，不要把 production 資料庫直接複製到 staging。
2. 資料處理者條款：合約需列明處理範圍、轉交限制、事故通報時限。若你同時服務歐盟客戶，GDPR 的處理者條款（第 28 條）是實用範本。
3. 存取分層：工程師預設拿 staging 權限，production 存取採即時申請（just-in-time）並記錄。

新加坡的 PDPA、澳洲的 Privacy Act 各有差異，但共通邏輯一致：你外包的是工作，不是責任。

一個匿名化實例

我們曾為一家大中華區珠寶零售集團建立首次外包的交付流程。核心挑戰不是技術，而是門市系統與電商庫存的資料邊界——最終做法是在 staging 層以合成 SKU 與虛擬庫存映射取代真實會員資料，工程師全程未接觸 production 客戶資料，同時仍能完整測試庫存扣減邏輯。工具上以 GitHub Actions 跑 CI、Shopify CLI 3.x 管理 theme、Linear 管理工單。這種「資料隔離優先」的設計，在跨境團隊尤其值得前期投入。

常見故障排除速查

• 第二週開始收到大量「順便幫我改埋」：所有請求一律開工單，由單一決策人排序。口頭需求零例外。
• PR 堆積無人 review：設定 review SLA（24 小時內），並在 CODEOWNERS 指定後備審核人。
• staging 通過但 production 出錯：多數源於第三方 app 只裝在 production。在 docs/runbook.md 維護 app 清單與環境差異。
• GA4 事件重複觸發：檢查 theme 與 GTM 是否同時載入 purchase 事件；用 GA4 DebugView 逐一確認。
• 外包團隊估算永遠超時：改用相對估點（story points）並追蹤兩個 sprint 的實際速度，第三個 sprint 才用來承諾日期。
• 上線後無人負責：在 Day 30 前確認 hypercare 期（通常 2 週）的責任歸屬與計費方式。

30 天 SOP 檢查清單

1. Day 0–3：Scope 一頁紙、DoD、8–12 張工單
2. Day 4–7：repo、CI、分支保護、CODEOWNERS、docs/access.md
3. Day 8–14：第一個垂直切片上到 staging，Day 14 驗收會
4. Day 15–21：文字站會、每週同步會、SLA 生效、ADR 開始累積
5. Day 22–27：UAT 腳本執行、Release Runbook 定稿
6. Day 28：知識移交（文件 + 錄影 walkthrough）
7. Day 29–30：正式上線、冒煙測試、權限審計與回收

第一次外包的目標從來不是「做完所有嘢」，而是證明這條管道可以重複運作。做到這點，第二個 30 天就可以講速度。

如果你的品牌正準備第一次外包工程交付，Branch8 以香港為總部，並在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，可協助你設計並執行這套 30 天流程——包括環境建置、CI 設定、合規邊界與知識移交。歡迎與我們的團隊聯絡，一起把第一個 sprint 做對。

Sources

• Shopify — Shopify.dev Developer Documentation
• Google — web.dev Core Web Vitals
• GitHub — Octoverse Report
• GitHub — GitHub Docs: Protected Branches
• Google Cloud — DORA State of DevOps Research
• 香港個人資料私隱專員公署 — PCPD
• Personal Data Protection Commission Singapore — PDPA
• European Commission — GDPR Data Protection Rules