PM產品經理工作常用英文單字、句型不正規整理:海外工作5情境用法範例

出國擔任PM產品經歷,會用到哪些英文?回報bug或報告進度怎麼說?本文作者從台灣到新加坡工作,擔任PM產品經理,他以非英文母語的轉職親身經歷,整理產品經理工作上常用的英文單字或句子,並以情境做分類,提供給有意出國做PM工作的求職/轉職者參考。

文/MH

前一篇寫了〈想出國工作,英文到底要有多好?會用到英文的場合有哪些?〉,當時預告會分享一些產品經理(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 等專業用詞,對這些詞彙不至於太陌生。

因為現職公司對於上線流程界定得蠻清楚,通常就是:

  1. QA 在 test 環境測試後,若沒問題,就會發 report 給 PM
  2. PM 確認沒問題的話,就請工程師把這些內容推到 live 環境
  3. 如果發現有問題,團隊裡的人就開 bug 票或建議優化項目,並由 PM 安排順序

所以在這幾個階段,作為 PM 最常說的就是 “We are ready to go live / deploy it.”

意思是「可以準備正式上線囉!」。這句通常是用於:

  1. 要回報進度給主管時
  2. 要徵求 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 也不至於太嚴重、最後決定先不管它的話
    可以說:
    1. nvm (never mind) 沒關係、算了
    2. Let’s just skip it. 就先不管這個問題吧
    3. 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” 的中文翻譯都是「可行的」,但應用的情境有點差異。
根據專業字典網站所說,前者是用於具體的作法,後者是對於某種抽象的概念或想法。
不過若用上述「對於這個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 日子裡,跟團隊的溝通也能越來越順暢。

如果你也在海外工作,或者正在準備前往海外的路上,歡迎分享你增強英文的方式和各種「非正統」但卻有奇效的用法!

(原文標題:產品經理的不正規英文小辭典


你是搶手的數位人才嗎?104有超多寶藏職缺等你探索⮕

104數發人才專區

更多【產品經理】工作機會
PM產品經理
台北市松山區|待遇面議
PM 產品經理
台北市松山區|月薪50,000~80,000元

沒看到有興趣的職缺嗎?

推薦閱讀:

PMP 熱門職場證照資訊 <前往>