前一篇寫了〈想出國工作，英文到底要有多好？會用到英文的場合有哪些？〉，當時預告會分享一些產品經理（Product Manager）在工作上常會用到的單字或句子，這篇就來寫這個主題吧，並依照使用情境作為主要分類。
希望英文老師或英文底子深厚的人們對此篇文章高抬貴手～標題已經強調「不正規」了，很多用法都是參考同事（有新加坡的英文母語同事，也有其他來自非中文也非英文的人），並非「正統」，只能說大家是習慣成自然、目前溝通無礙就是了。
各種會議
- orientation：培訓、新人到職訓練
- kick-off：產品完成 PRD 和 UI/UX 後、進入程式開發前的會議，主要會由 PM+dev+UI/UX 一起順一次功能邏輯與畫面。“kick-off” 好像比較少聽到中文翻譯，有時甚至簡稱為 KO。
- quick call / quick catch-up / sync / discussion：非正式的臨時會議，比如臨時要討論某個功能的進階邏輯、要確認彼此進度、要同步資訊等；如果是較正式且事先安排好的會議，一般都用 meeting。
工作到一半，最怕看到同事說 “could we have a quick call?” 通常就代表我又有漏掉的 spec 了…… - stand-up：有些團隊是每天開，有些則是每週，通常目的是為了讓同個產品線的團隊知道上週與接下來的進度，確保彼此對於排程與實作方向沒有問題。
- retro：有跑 scrum 的團隊對此應該不陌生，就是每個階段的開發完成後，團隊會召開 retro (=retrospective)， 一起回顧大家哪裡做得不錯、哪裡可以做得更好。有點像是氣氛不那麼嚴肅、對事不對人的檢討會吧。
- 1 on 1：通常用於跟小主管或大主管的一對一聊聊，有時是工作一段時間（比如一個月或三個月）後，主管會想知道組員們有沒有什麼心得或建議，有時也可以由組員自行召開，主動跟主管討論一些事情。
- weekly / monthly：團隊、專案或產品線等單位的組合，會在每周、每月或每季固定召開的會議。
- town hall：公司全員大會
一些常見的產品流程相關動詞
關於產品從開發到上線的流程，可以參考這篇文章〈產品上線管理：寫給 PM 的基本名詞解釋與工作流程〉。
但可能因為在工程師的世界裡，本來就是英文居多，所以即使在台灣本土公司工作，應該也很常聽到 deploy, release, rollback, rollout, master, branch 等專業用詞，對這些詞彙不至於太陌生。
因為現職公司對於上線流程界定得蠻清楚，通常就是：
- QA 在 test 環境測試後，若沒問題，就會發 report 給 PM
- PM 確認沒問題的話，就請工程師把這些內容推到 live 環境
- 如果發現有問題，團隊裡的人就開 bug 票或建議優化項目，並由 PM 安排順序
所以在這幾個階段，作為 PM 最常說的就是 “We are ready to go live / deploy it.”。
意思是「可以準備正式上線囉！」。這句通常是用於：
- 要回報進度給主管時
- 要徵求 PIC (Person In Charge，負責人) 同意上線時
意思就是「萬事俱備，只欠綠燈」，等主管或負責人確認後，工程師就可以把做好的需求推到正式機了；所以如果有時卡在「等待負責人確認」的關卡，就會說 “We are still waiting for xxx’s greenlight.”
等到確認後，PM 可以跟工程師說 “Plz help to deploy/push v1.1.2 to test/live env.”。意思是「請把某個版本推到某個環境吧」。為了打字效率，一句話裡面會有很多縮寫，比如 plz=please, v=version, env=environment
上線後，不管是開發新功能還是修 bug，仍有可能再出現對應的 bug。發現問題時，團隊可能會先經過討論，確認解法後，再指派對應的人去執行。所以當團隊有結論後，PM 通常就會以 “Let me create a ticket for it. / I will create a ticket (accordingly).” 作為結論，意思就是「好，那我會（依照上面討論的結論）去開票」。
回報 bug 的時候
- 如果還不太確定這是 bug 還是 feature，通常大家會用較不確定的語氣詢問 ：
- Does anyone else encounter this problem?
- Anyone else encounters this problem?
- Is it just me or ___ ? 中文翻譯就是「有人也遇到……嗎？」
- Is it a bug?
- 如果收到這樣的問題，但自己也不太確定的話（畢竟一個產品可能轉了好幾手，或者剛從同事那邊交接完畢，即使身為 PM，也不一定能記起所有邏輯嘛）
可以先回覆 “Let me check w ___. “（底線指的是人，通常可能是設計師或工程） - 如果是自己測出了 bug
通常會先說明遇到什麼錯誤，接著就會想說：「正常的話，這個功能應該是要……」，用英文就說 “By right, it should be ___.” - 如果測出了 bug，但大家怎麼樣都無法重現，而這個 bug 也不至於太嚴重、最後決定先不管它的話
可以說：
- nvm (never mind) 沒關係、算了
- Let’s just skip it. 就先不管這個問題吧
- I will close the ticket.（如果已經開票的話，就得把票取消或關掉）
- 如果原本測出了以為是 bug 的東西，最後發現是 feature 的話
在感到很糗之餘，也可以跟團隊說 “Sorry, false alarm.”（抱歉，大家虛驚一場了） - 如果測出了 bug，但要跟團隊討論是否能夠修復的話
可以詢問 “Can we fix it?” 我也問過同事 “Is it fixable?”，但後來查字典，雖然有 fixable 這個單字存在，但似乎不會說 “This bug is fixable”，但反正整個團隊都看得懂就是了。 - 最後，測出了 bug、也想了一些解法，想跟團隊確認是否可行的話
可以問 “Is it doable?” 或 “Is it feasible?
註：雖說 “doable” 跟 “feasible” 的中文翻譯都是「可行的」，但應用的情境有點差異。
根據專業字典網站 <https://www.merriam-webster.com/words-at-play/feasible-and-doable-word-history-usage> 所說，前者是用於具體的作法，後者是對於某種抽象的概念或想法。
不過若用上述「對於這個 bug 的解法是否可行」的情境，好像有點處於兩者之間（？），這兩個單字我都用過，團隊也都看得懂。
報告進度的時候
前兩三個月加入公司時，每週一早上的例會總是讓人害怕，週日晚上會睡不好、週一早上也會提早起床準備。隨著時間過去，可能終於習慣了，也可能是臉皮厚了（？），終於不再那麼畏懼這個「由 PM 主導、PM 得一人報告上週與這週進度」的會議。
既然是要報告進度，「進度」的狀態也就只有 3 種：落後、正常運作、超前，所以對應的英文用法也差不多是那些。
- 正在動工中：xxx (project) is in progress and on schedule.
- 進度超前：xxx (project) is ahead of schedule. 然後解釋原因
- 進度落後：xxx (project) is behind schedule. 然後解釋原因
- 要準備進到下個階段，可以說 “xxx (project) is expected to ___. “
比如：A product is expected to be launched on Jan 1st. - 已完成某個進度，但在等待下一步的話，可以說 “wait for someone’s green light”。
比如：We are still waiting for A’s green light to launch the product.
討論時程的時候
在規劃專案時，PM 通常要花很多時間規劃優先順序，畢竟人力與時間都有限嘛，凡是總得有個先來後到，所以就會有切階段（分階段上線）的解法出現，會出現的情境有：
- PM 可能常被問到：How should we prioritize these tasks?
- 若被問到，則可以說：I will discuss w xxx about the prioritization.
- 有了結果之後，則說：So we are going to split the project into X phases.
裝可憐的時候
要做事又要做人，PM 就是如此命苦（？），中文有很多表達謙虛或求人的句子，比如：不好意思、想請你幫個忙、可否幫我趕一下……，英文也是有，但可能我終究不是英文母語者，所以還是覺得中文比較能傳達這種裝可憐的語氣、態度和神情。
我目前會用的英文，似乎還處於「只能用單字來暗示『我也是不得已的』」的菜鳥階段：
- requester 需求端
so requesters asked us to… 暗示著「都是需求端叫我做的啦 ><」，當然有時候如果碰到較熟的同事，也會直接跟他說 boss said… - urgent 緊急的 / ad-hoc 臨時的
Sorry that I got an urgent / ad-hoc task that needs your help. 有個緊急任務需要幫忙 - could you / may I know 你可以…… / 我可以……
這兩個看似帶有謙卑感、實則可能帶有命令意味的問句，有很多應用的場景，比如：
想催進度，但又不敢太明目張膽的時候：
- May I know when we can test this function? 我們什麼時候能測試呢？
- Could you help to deploy this version? 你可以把這個版本推上線嗎？（東西都確認完，終於可以上線的時候）
- Could you help to update it in UI? 你可以去更新 UI 嗎？（有結論的時候，要請設計師去改畫面）
無法給出結論的時候
最後，PM 也得決定很多事情，比如要確定或更改規格、某個介面上的文案要怎麼寫、產品的排程等，有些事情可以自己決定，有些則需要找對應的人討論或給個 final call（最終決定），如果當下無法給出答案，可以說：
- Lemme get back to you later. (lemme = let me) 我等下回覆你
- I need to discuss / check it with someone. 我跟某人討論一下
- I will ask for someone’s confirmation. 我請某人確認一下
結論＆不負責任聲明
之前看到其他 PM 說，在新加坡待久了，雖然平時用英文溝通無礙，但總是不太確定自己的英文是退步還是進步。即使目前只在新加坡工作半年，我已有這感覺……
雖然我大致上聽得懂也看得懂同事在說什麼，同事通常也聽得懂或看得懂我要表達的意思，但可能自己仍對於 Singlish 有太多的未知與恐懼，所以時常會懷疑這些常用的英文到底「是否正統」。
不過最後又會想說，到底什麼叫做「正統」呢？作為中文母語者，我們跟朋友甚至同事溝通時，仍會出現欠揍注音文（不用ㄅ、可以ㄌ）、欠揍裝可愛縮寫（鼻要、就醬）、標點符號（好～、可以吧（？））等「非正統」方式，但這似乎也無礙彼此理解。
通常這樣一想之後，好像也就很順理成章地安慰自己了……。
不過，在「使用英文」這條路上，還有太多可以學、太多需要進步的地方，所以我也還在持續調整自己的字彙與用法，希望在接下來尚未看到終點的 WFH 日子裡，跟團隊的溝通也能越來越順暢。
如果你也在海外工作，或者正在準備前往海外的路上，歡迎分享你增強英文的方式和各種「非正統」但卻有奇效的用法！
