前陣子在幫產品經理整理從2019年的新產品研發專案零零總總將近30多個新產品，各產品究竟花了多少開發經費。這些資料四散各地。我大概花了20分鐘彙整給他。他非常驚訝怎麼有辦法在這麼短的時間內找齊這些資訊。我就回他「當在不同的專案，把類似的東西放在類似的地方，這件事情就很容易了」。我想分享我帶的專案都是如何系統化整理專案資料，讓往後查詢很方便。 大致上 …

最近公司在整理一些過往新產品研發的銷售成果與檢討。歸納出幾個很有趣以及我認為可以透過一些方式改善的點 首先來談談實體產品的困境我碰過的大致會有三種 開發時間很長 初期不確定性高，後期變更成本高 產品沒有受到當初預期的客戶迴響 我逐一來解釋這三項 實體產品研發從開案到正式發表所需時程少至半年，多至2年。實體產品通常需要經過好幾個階段的驗證。以我在的熱融膠產業來說，單是在實驗室階段要找到對的化學配方可能要花3個月至半年。再來還要經小批試產與大量試產又會花數個月。如果原物料是台灣自產的，交期時間還可以接受。但如果是國外進口，那時間就會驚人地疊加上去。如果產品方向沒有抓對，很有可能花了一年半載上市結果不是市場要的東西，這就會是一個失敗的產品專案。 多數產品專案在初期都是需求不確定性很高。很多時候客戶只是丟出一個很主觀感受的需求，例：要手感軟一點、更有彈性一點、更有質感一點，這類需求有時很難用數字或是特定測試方法去量化成果。或者面對一個需求，有很多種潛在解決方案但不知道哪個會是客戶在性能與成本上最終能接受的。而實體產品的研發另一個困難點在於規格特性有時環環相扣，如果是在很專案後期才提出變更，要付出的變更成本幾乎是等於整個打掉重練，回到實驗室階段。

這篇要來講講 PMBOK 翻譯專案是如何顧好翻譯品質。 由於志工來自四面八方，有人是在 N 年前取得 PMP 證照而有的是近期。為了要讓大家都回顧一下 PMBOK 的內容，以及作為小組剛組建磨合，需要先嘗試協作一點東西，在 6 月底專案剛開跑就安排了一系列的讀書會，指派各組負責不同章節彙整簡報內容向全部志工報告培訓。用這樣的方式幫大家找回對第六版的記憶。而第七版在 7 月上線後，針對自己未來要負責翻譯的章節，也做一次相同活動。這樣除了自己對負責的內容有初步了解，在聽取別組製作的簡報，也可對第七版整本書有大略了解。 PMBOK 第七版總共370頁，如果只交由一人翻譯的話或許要一年才能出版。但如果是由一個百人團隊來處理，4 個月便可搞定。但問題是一百個人翻譯，就會有一百種翻法，格式、用詞、標點符號都各做各的。這樣翻譯出的成品可能比看原文還更煎熬。 為了要讓百人團隊翻譯出來的東西看起來像一個人翻的，勢必要做很多規範讓整個團隊來遵守，以確保大家的產出不會偏差太多。因此在這專案裡，除了前一篇提到的 scrum 流程與自組織運作外，在翻譯內容也做了必要的規範。大致上分成3種：

這篇要來說明參與翻譯工作的翻譯小組、整合組和審委各自有什麼不同角色要扮演，也會談到整個團隊歷經塔克曼( Tuckman ) 團隊發展過程的紀錄。 翻譯小組一組會有 13 名成員大致上可分為三種角色: 組長 — 處理跨組事務及組內協調事項。負責主持上篇文章提到的scrum各項會議，也要確定組織用的文件格式。 翻譯成員 ( 9 員) — 將英文翻譯成中文的第一線工作人員，也要對其他成員的翻譯章節互相初步檢查。 品管與定稿品管 QA ( 3 員) — 擔任品管及定稿品管 QA 都有 TOEIC 800 等級的英文實力，故擔任產品內容的校閱潤飾。第一線翻譯人員互相檢查後，就會給品管再做一次審查，最後再給定稿品管(也就是我)看過。完成後就可以準備 Demo 交付。

這篇要來分享翻譯專案是如何管理的。先來講專案架構運作。這專案採用了大型敏捷管理法。 整個專案分為 6 個小組，5 個翻譯組與 1 個整合組，搭配 15 個專業審委檢視小組的交付成品內容。每個小組將負責頁數的原文翻譯成繁體中文，再由整合組整併順過完成一份完整內容一致的書籍。 書籍內容被拆解成約 5 等份，交由 5 個翻譯組進行，以每週 10~15 頁 …

這一個月來在忙碌的事情是我接了一個志工專案，負責將俗稱專案管理聖經 “PMBOK” 最新第七版的內容翻譯成繁體中文。在接下來幾篇文章我會一一詳述這整個翻譯專案如何運作，做為自己往後回顧的紀念。 首先先來談 PMBOK 到底是什麼。 PMBOK 全名是 Project Management Body of Knowledge，中文翻「專案管理知識體系指南」。是由總部在美國的國際專案管理學會 Project Management Institute (PMI) 所出版的。內容是集結專案管理領域的專家，撰寫一本適合當代商業環境，有效率管理專案的教科書。同時 PMI 也推出兩個專業證照 ，PMP 跟 CAMP 。取得這證照需要考試，而考試內容就是基於這本指南。 PMBOK 第一版是在1996年出版，大概4~5年會更新一次。而最新的第七版則是在2021年7月正式上線。PMI 授權在各國家的專案管理學會分會翻譯成當地的語言，而在台灣的專案管理學會分會 (PMI-TW)也在6月底正式啟動這個翻譯專案，號召了百位海內外的夥伴參與翻譯，以分組方式進行。

最近一個月呈現完全頹廢狀態。無意間看到了魔獸世界的廣告，就不小心回鍋了。大學時代曾經沉迷一陣子，後來當兵開始工作後生活上的忙碌讓我沒空可以沉浸在這虛擬幻想世界裏頭。 這次的回鍋讓我有機會慢慢思考這遊戲為何可以撐17年還有約480萬活躍玩家 (雖然每年以14萬人遞減)。 魔獸世界是在2004年爆雪娛樂推出大型線上角色扮演遊戲 (MMORPG)。內容建立在一連串史詩的故事內容與正邪的對抗。為何這遊戲可以這麼的長壽，我自己是覺得有以下三點: 沉浸式的故事敘述 在魔獸裏頭，每個任務的開始都會稍微描述一下故事背景，要請你做什麼事情，以及獎勵是什麼。

前陣子在公司碰到一個狀況。我們公司的 QC 部門一直比較薄弱。多數時間是在針對客訴做 troubleshooting 回應。前陣子 QC 部門進行改組，把原本分散各部門的 QC 人員整合成一個部門，也指派了一位新主管。但他們對於自己要擔任的職責範疇 (R&R) 仍在重新釐清。 前陣子我有兩個新產品開發專案準備收尾，正在進行最後規格定稿。基於禮貌下就拿給 QC 部門過目一下。開發過程中都有 QC 人員受邀開會，會議記錄也有 CC 他們，他們很少在會議中提出疑慮。所以我心想 QC 應該對產品開發內容皆核可沒問題。萬萬沒想到 QC 主管劈哩啪啦給了一堆質疑意見，有的意見甚至可能會動搖到規格而被迫延遲專案。我完全沒預期到 QC 主管如此突然的大反應。 對這問題一直百思不解，後來尋求了一些前輩的意見，才解了我的疑惑。原來雙方在意的區塊不同。我在意的是產品研發沒重大問題，讓新產品準時發表，專案如期結案。而 QC 主管他要確保的是產品萬無一失，最好零缺點，以避免往後客訴麻煩。我跟他聚焦的重點不同。在目標上的出入就會造成兩方似乎在互相扯後腿的現象。雖然從更高的角度看，兩邊都是在為公司好。

最近因為在台灣的一連串公衛事件發生，許多比較有英語能力的人就去爬文看他國的做法是什麼，然後反問台灣政府為何不能照做。下面的留言就會有一長串的留言在爭吵。其實這種現象很常發生在我們的身旁，小至為什麼隔壁王太太使用某個藥方治療她的症狀有效，怎麼我用就沒效。大至為什麼那家企業用這個策略方法成功，可是我公司用了問題反而更多。 很多時候我們在考量這些建議抉擇時只見到結果，但忘了去看背後還有很多要考量的因素。若是要考量別人的作法是否適合自己時，記得要先去考量兩個層面: 目的與條件 目的 目的顧名思義就是做這個抉擇想要得到什麼成果，為何要做這件事。每個人做其抉擇都有想要達到的目的。就算是同一個抉擇，不同人做也會帶著不同的目的。舉個例子，選擇去墾丁海邊玩。有的人目的是為了玩水，有的人是為了看海，有的人是為了看帥哥美女。當帶著不同目的時，雖然都是去海邊，獲取的東西會不同。 再舉一個比較生活的例子。都是買一隻台積電股票，每個人的目的就會不同。有人打算想放長期投資、有人看上它的穩定季配股息(雖然殖利率蠻低的)、有的是想炒短線。帶著不同目的投資時，就會需要用到不同的評估方式。而這可能是別人不會主動告訴你的。