商業分析師的英文求職信怎麼寫

一封商業分析師求職信的四段

每段一個任務，四段結束。讀信的專案經理手上還有二十封，第五段不會被讀。

1. 1
   第一段之前：主旨行

   一個大型變革專案常常同時開三、四個 BA 缺，收件夾靠主旨分流。寫「Application for Senior Business Analyst — 你的名字」，職缺有編號就補上編號。主旨寫「Job application」的信，會被歸到不知道哪一個 req 底下，然後在裡面排隊。

2. 2
   第一段：職缺要的交付物 × 你交付過的

   第一句複述職缺要人做到哪裡（從訪談到 go-live），第二句給履歷上同形狀的上線成果並附 [N]，第三句說這就是他們要的。不寫自我介紹。

3. 3
   第二段：兩個對上對方專案的成果

   挑履歷上和對方專案最像的兩條：一條通過 UAT 沒被改的需求、一個被拿掉的流程步驟。點名對方公開過的東西（年報、案例、文章），證明你查過。

4. 4
   第三段：你的工作方法

   方法寫成動作：規格凍結前先走查、每條需求先有 owner 再進開發。最後留一個職缺沒說清楚的問題，例如變更控制會在 UAT 前還是後開。

5. 5
   第四段：何時到職、跟誰談

   到職時間、想談的對象與時段、履歷附上。兩句。不再重複感謝。

6. 6
   四段之外：留給履歷的三件事

   工具清單、證照縮寫、方法論名稱都不進信裡。Jira、Confluence、Visio、BPMN、CBAP 在履歷的 Skills 和 Certifications 已經被讀過一次，信裡再列一次，是用一整段換零新資訊。四段的每一段都該裝履歷放不下的東西：那個取捨、那次衝突、那個你想問的問題。

逐段看這封信在做什麼

哪一句承擔什麼任務，哪一句刻意沒寫。

1. 1

   The Senior Business Analyst role you have posted needs someone who can carry a customer-onboarding platform from the first stakeholder interview to a signed-off go-live. At a retail bank in Warsaw I delivered the payments-onboarding launch that processed [N] million transactions in its first quarter, with [N] change requests raised after sign-off, and I led the user acceptance testing across [N] business units and [N] thousand test cases that closed every severity-one defect before the go-live date. Your posting describes that launch almost line for line.

   第一句把職缺的範圍講出來：從第一場訪談到簽核上線。第二句給的是履歷上那次 payments-onboarding launch 的兩個數字：交易量、簽核後的變更單數。沒有「我對貴公司很有興趣」。

2. 2

   Two results from the same bank match the account-opening rebuild your annual report sets out for the coming year. Of the [N] requirements I defined for the replacement of a branch account-opening system, [N] passed user acceptance testing unchanged. Mapping the as-is mortgage pre-approval flow with branch staff let me remove [N] of its [N] steps and cut turnaround from [N] days to [N], which is the shorter onboarding time the report commits to.

   兩個成果各對上對方年報裡的一件事：account-opening 系統換置對上通過 UAT 沒被改的需求，縮短 onboarding 時間對上拿掉的流程步驟。「your annual report」是查過資料的證據。

3. 3

   The method behind those figures is older than the bank. At an IT services firm in Kraków I built the traceability matrix that linked [N] business requirements to their functional specifications and test cases, so no requirement reached development without an owner, and I introduced structured walkthroughs with the client before each specification was frozen, which halved rework on a policy-administration rollout. Both would come with me on the first day. One thing the posting leaves open: does your change-control board meet before UAT entry, or only after it?

   方法寫成兩個動作：追溯矩陣讓每條需求進開發前有 owner；規格凍結前跟客戶走查，返工減半。這兩條都在履歷的 IT services firm 那段。結尾的問題是真的想知道的：變更控制會在 UAT 前還是後。

4. 4

   I could join [N] weeks after an offer and am free for a conversation with the programme lead at whatever hour suits your office. My resume is attached, and every claim above can be traced to a line on it.

   只有兩件事：幾週後能到、跟誰談。「every claim above can be traced to a line on it」把讀者送回履歷，用的是 BA 自己的語言：追溯。

第一句的七種寫法

第一句要讓專案經理相信你懂他的專案。七種切入，都不用「I am writing」。

• Your posting asks for a business analyst who can carry an onboarding platform from the first stakeholder interview to a signed-off go-live; that is the release I delivered at a retail bank.

  職缺範圍 → 你做完的那次上線。適合職缺把交付範圍寫得很清楚的公司。

• The account-opening rebuild in your annual report has the same shape as the replacement I wrote the requirements for, so I will start with what survived UAT.

  從對方公開文件切入，證明做過功課。適合年報或案例研究裡有明說專案的公司。

• Of the [N] requirements I defined for a branch account-opening system, [N] passed user acceptance testing unchanged, which is the requirement quality your programme is hiring for.

  單一成果 → 對方開缺的原因。適合職缺只圍繞一個系統換置的情況。

• [Name] on your payments team mentioned that the onboarding release has been re-scoped twice since the vendor was selected; re-scoping mid-programme is what I was brought in to do at a retail bank.

  內推的第一句要用只有內部人知道的細節，再把它接到你做過的同一件事。少了那個細節，內推等於沒有發生過。

• I have spent [N] years writing requirements for account opening and KYC, which is usually the part of an onboarding programme that decides the release date.

  領域切入：先講你熟的那個模組，再說它為什麼壓在專案的關鍵路徑上。適合職缺寫得含糊、只說 core banking transformation 的公司。

• Onboarding programmes slip in UAT more often than in build, and holding that date is what my last two releases were judged on.

  從這類專案真正會出事的地方切入。讀信的專案經理正在擔心同一件事，第一句就落在他的焦慮上，而不是落在你的履歷上。

• I handled claims for [N] years before I started writing the requirements for the system that handled them, so I have been the person the analyst interviews as well as the analyst.

  從鄰近職位轉進來的寫法：把領域年資寫成 BA 的資產，而不是寫成需要解釋的轉彎。適合保險理賠、分行櫃檯、後台作業出身的人。

這封信會落在誰手上，他在確認什麼

招募那一關看的是履歷關鍵字。信通常要到第二關才被真的打開，而打開它的人，手上有一個已經在滑的期程。

1. 1
   交付主管：你熟的系統跟他要換的那個有多像

   領域上手時間是他最貴的成本。寫過 KYC 與開戶需求的人，第一週就問得出對的問題；沒寫過的人得先花掉一段誰都不想付的學習期，才知道哪些欄位是法規在管的。所以第二段要挑領域最近的兩個成果，不是數字最大的兩個。

2. 2
   每一個讀它的人：這封信本身就是你的寫作樣本

   BA 的交付物是散文。一個指涉不明的 it、一句話塞進兩條需求、連著四個沒有主詞的被動句——這些出現在信裡，他就預期它們也會出現在你的規格裡，而規格的歧義要到 UAT 才會爆開。這是他在錄取你之前唯一讀得到的長句子。

3. 3
   Lead BA：你站在交付鏈的哪一格

   supported UAT、participated in workshops 描述的是一個房間，不是一個人。他要知道訪談是誰開的、規格是誰寫的、簽核那一頁上是誰的名字。範例第二段用 I defined、I ran，不用 I was involved in，原因就是這個。

4. 4
   專案經理：你擋不擋得住需求

   一個跟所有利害關係人都相處愉快的 BA，交出來的範圍做不出來。他在信裡找的是一次拒絕：兩個部門要的東西互斥時你怎麼收斂、凍結之後插進來的需求你怎麼處理。幾乎沒有人寫這一段，寫了的人會被問一整場。

5. 5
   業務端 sponsor：你聽不聽得懂他的話

   他不讀功能規格。他要的是有人能把分行櫃檯講的話翻成工程做得出來的東西，再翻回來給他簽名。一封通篇方法論名詞的信，只會讓他確定你平常只跟 IT 講話。

6. 6
   治理：你在受監管的環境待不待得住

   銀行與保險的變更帶著簽核鏈、稽核軌跡和退版計畫。信裡出現變更控制會、UAT 出口條件、追溯矩陣這些字，對方就知道你進來不必被教這一套。反過來，一封只提得出「快」的信，會讓他先想到你第一次遇上稽核的樣子。

什麼時候它就不是同一封信了

同一個職稱，不同的雇主在買不同的人。以下六種情況要換掉的是第二段的證據，不是換一個形容詞。

• 受監管的大型機構，對上產品公司

  銀行、保險、電信的變革專案買的是可追溯與可簽核：第二段寫通過 UAT 沒被改的需求、簽核後才進來的變更單、你怎麼守住那個凍結點。產品公司或 SaaS 的 BA 常常靠近營運與數據：第二段要寫你回答了什麼商業問題、用哪份資料回答、之後哪個決定跟著動了。兩邊都寫得出來的人，也只能挑一邊寫。

• 顧問或 IT 服務公司，對上甲方 in-house

  顧問端買的是上手速度與客戶關係：寫你被丟進一個沒做過的領域、幾週內交出第一份規格，以及客戶反覆重開範圍時你用什麼收住。甲方買的是 go-live 之後：寫第二次、第三次改版，寫變更單怎麼分流，寫你跟同一個業務單位一版一版做下來的關係。顧問背景投甲方，最常漏掉的正是上線之後那一段。

• 職缺掛 BA，內容其實是報表分析

  看工具清單。列 SQL、Power BI、dashboard、KPI 的，要的是用資料回答問題的人：第二段換成一個你回答過的商業問題、誰在問、之後改了什麼決定；UAT 簽核在這種缺上不加分。列 BRD、user story、驗收條件、流程圖、利害關係人的，才是交付型 BA。判斷錯的信會寫得很漂亮，然後完全沒對上。

• 職缺掛 BA，內容其實是半個 product owner

  職缺出現 backlog、優先序、sprint planning、roadmap，對方要的是會做選擇的人。第二段就不能只寫需求品質，要寫一次取捨：你延後了什麼、代價是什麼、後來證明對還是錯。在這種缺上只寫「所有需求都通過 UAT」，讀起來像一個從來不必選的人。

• 公開職缺，對上內推

  公開職缺只能用公開材料重建對方的專案：年報寫的系統換置、背後的法規期限、系統商發的新聞稿、職缺自己列出的整合對象。內推可以直接寫只有內部人知道的細節——哪個里程碑滑了、供應商最後選了誰——也可以問一個更尖的問題。內推信最常見的錯，是開頭寫了誰推薦你，接著照抄公開版。

• 從鄰近職位轉進來

  從測試轉：你已經懂驗收條件與缺陷分級，缺的是引導，所以要寫你「寫」條件的那一次，不是你執行了幾輪。從業務單位轉：你本來就是 BA 訪談的對象，寫一個你熟到能重畫的流程。從開發轉：你讀得懂資料模型，對方擔心的是你太早跳進解法，所以寫一次你把需求擋在解法之外、直到業務端說清楚它到底是什麼。

商業分析師求職信最常見的錯

• 把職責當成果

  「gathered requirements and facilitated workshops」是職稱定義。信裡要的是需求的下場：幾條通過 UAT、幾條被退、上線後開了幾張變更單。

• 用內部代號稱呼系統

  Project Phoenix 在對方公司沒有意義。用功能描述：the account-opening system、a claims platform，讀的人才知道規模和領域。

• 沒對上對方的專案

  對方的年報、案例研究、職缺描述寫著他們正在換哪個系統。信裡的兩個成果如果和那個系統無關，再漂亮也是別人的故事。

• 把方法論當論證

  Agile、BPMN、CBAP 放在信裡不是證據。讀的人要看你用它們留下了什麼：追溯矩陣連了幾條需求、走查省了多少返工。

• 結尾沒有問題

  一封沒有問題的信，對方沒有回信的理由。問一件職缺沒說清楚的事：變更控制的時點、UAT 的出口條件、誰簽 scope。

• 把利害關係人寫成一團和氣

  worked closely with stakeholders 沒有任何訊息。寫一次衝突：哪兩個單位要的東西互斥、你用什麼把它收斂成一條需求。每個專案都有這種事，一封沒有衝突的信只證明你沒有真的站在中間。

• 信自己的句子就有歧義

  這是對方在錄取前唯一讀得到的長句子。一個指涉不明的 it、一句話塞兩條需求、通篇被動語態，他會直接拿來推論你的規格長什麼樣。寫完念一次，每個代名詞都問一遍它指的是誰。

• 把工具清單搬進第二段

  Jira、Confluence、Visio、SQL、BPMN 在履歷的 Skills 已經出現過。信裡再列一次，是用一整段換零新資訊，而那一段本來可以拿去寫你怎麼守住凍結點。

• 沒判斷對方要的是哪一種 BA

  職缺列 SQL 和 dashboard，你寫 UAT 簽核；職缺列 backlog 和優先序，你寫需求全數通過。信再乾淨也是答錯題。動筆前先看工具清單和交付物清單，那兩張清單會直接告訴你第二段該放什麼。

• 用「參與」保護自己

  participated in、involved in、supported 是為了不誇大而寫的，結果讀起來像沒做過。誠實的作法是縮小範圍，不是模糊動詞：寫你名下那一份 BRD、那一段流程、那一輪 UAT，動詞照樣用 wrote、ran、owned。

常見問題

銀行或 IT 服務公司的 BA 職缺，求職信誰在讀？

第一輪是招募，看的是履歷關鍵字。信是給第二輪的人讀的：專案經理、業務端 sponsor、或帶你的 lead BA。他們讀得很細，因為信裡每個數字他們都能追問。

所以信要短、每句要有下場、要對上他們的專案。

我的系統有保密義務，信裡可以寫多少？

系統用功能描述，數字用量級或 [N]。「the account-opening system」「[N] million transactions」是履歷語言；客戶名單、金額、內部代號留在公司裡。範例的寫法就是這樣。

轉職或年資淺，沒有一次完整的上線可以寫，怎麼辦？

寫你名下的一份交付物和它的下場：一份 BRD 的 UAT 通過率、一條被採納的 SOP、一張被拿去當標準的流程圖。範圍小但有下場，比範圍大但寫 participated 可信。數字照樣留 [N]。

信要多長？

四段，200 到 300 個英文字。範例旁的信件檢查會印出實際字數。超過 320 字引擎會提醒，因為專案經理不會讀第二頁。

職缺標題寫 Business Analyst，但列的是 SQL 和 Power BI，信要怎麼改？

那是一個報表與分析的缺。第二段改寫成一個你回答過的商業問題：誰在問、你用哪份資料回答、之後哪個決定跟著改。需求與 UAT 的成果留在履歷上就好，硬放進信裡只會把答案稀釋掉。

判斷方法是看交付物清單。出現 dashboard、KPI、ad hoc 分析，就是分析缺；出現 BRD、user story、驗收條件、流程圖，才是交付型 BA。

我沒有 CBAP，要在信裡解釋嗎？

不用。證照缺席不需要道歉，多寫一句解釋反而把讀者的目光帶到那裡。如果職缺把證照寫成必要條件而你已經報名，就在信末用一行事實寫出考試日期，不加形容詞。

證照本來就不是這封信的證據來源。同樣的字數拿去寫一條通過 UAT 沒被改的需求，說服力高得多。

對方的年報查不到專案，第二段要對上什麼？

退而求其次的公開來源有四個：職缺自己列出的系統與整合對象、對方所屬產業正在趕的法規期限、系統商或供應商發的新聞稿、以及徵才頁上寫的團隊組成與匯報線。

任何一個都好過空對空。第二段要的不是內幕，是證明你把這個職缺讀到最後一行，而且知道它為什麼是現在被開出來的。

相關指南

• STAR：用證據回答行為面試
• 外商面試每一輪在測什麼
• 英文面試的準備方法