失敗的本地化項目案例和失敗的項目經理
“你明白我的意思……”
輕率地下結論、想當然地處理事情——我們都犯過類似的毛病。而本地化項目失敗的原因常常就是因為溝通不準確或不清楚，尤其是談到交付物（你需要把HTML文件編譯成一個chm文件嗎？）和服務（你希望由誰來開發這個軟件？）的時候。
在和客戶交談中抽取出真正的項目需求，并在項目過程中管理好客戶期望，是所有本地化項目經理的重要任務。下面是一些有關項目需求的例子：
1．中期交付物和最終交付物是什么？清晰地描述項目所有的中期交付物和最終交付物至關重要。項目交付物包括所有的產品交付物，外加項目特定的組成項，例如進度報告、缺陷報告、已完成的檢查清單、翻譯記憶庫、術語庫等等。
2．各交付物的時間表如何？最后期限如何分類：是如你所愿的，還是很緊急的？有時候我們要處理像貿易展會這樣“規定得很死的”期限，這無疑會增加項目風險。
3．項目的預算是多少？如何處理預算差異？這是一個“依耗時和材料而定價”的項目呢，還是一個“成本固定的”項目？項目預算還應對項目變更單有一個清晰的期望。
4．客戶對最終交付物的質量期望是怎樣的？在項目初始階段建立質量標準可以極大地幫助客戶設定正確的期望。對于本地化工作來說質量標準的制定不是一件容易的事，因為風格和術語的處理都囊括了太多的主觀性。
5．客戶對于他/她在項目中承擔的責任有何認識？我們都至少遇到過一次由于客戶更新或審查源文件而無法在交付期間內完成任務的情況。客戶需要理解這些延誤對進度和預算的含義。應該在項目的規劃階段就確定這些期望，而不是等到這些延誤成為不可更改的現實后。
需要溝通的不止這些。在項目執行過程中還需要溝通清楚每位團隊成員需要做什么，這一點很重要。如果事先沒有溝通清楚，就會導致重工、未分配的任務以及團隊成員間普遍的受挫感。這讓我們想到另一個話題。
缺少規劃時間……
你已經把大部分時間用來談判需求、預算以及交期。現在交易談妥了。但是供應商和客戶都希望繼續項目并開始翻譯活動。多數情況下，你的交付期限已經很緊了。最不愿意做的事情就是花時間做規劃。立即開始投入翻譯工作非常具有誘惑力，但是了解下面這點也許能幫助你三思而后行：導致多數項目失敗的兩大原因是：（一）誤解客戶需求；（二）缺少規劃。
現在，是時候完成規劃了，它包括項目方法、資源分配、所有中期交付物的交付期限、風險管理等等。最好做一份詳細的、可以滿足多種用途的項目規劃：
作為項目相關人員（尤其是利益相關人）的指示圖。項目規劃將會概述項目的各階段，并闡明各階段內的活動和里程碑之間的依賴關系。此外，它會將所有交付物的交付期限記錄在案。
能夠清晰地描述每位利益相關者的責任。我個人喜歡使用線性職責表（LRC），這個表的左列各欄清楚地列出了所有的項目交付物，其它各列則是相關聯的利益相關者。二者的交叉點上詳細列出了某個項目交付物的每位利益相關人須履行的一下責任中的一項或多項：創建、審查、批注或不適用。
作為項目在進度、開支和質量各方面績效的測量標準。甘特圖樣式的基準進度表為比較計劃績效和實際績效提供了一種簡單易行的方法。累計預算和實際成本相比較為財務績效提供了很好的指示器。
我聽見你說：“我可沒時間寫一個50頁的項目規劃”，你說得對。項目規劃的詳細程度取決于很多因素：
利益相關人的個數，尤其是團隊大小；
項目和產品的復雜程度；
客戶方本地化的成熟度；
交付物的數量；
是否使用新技術；
對于多數本地化項目來說，一個考慮周詳的MSProject進度表，包括資源分配、交付物描述記錄、限制條件、以及所有的預算信息就足夠了。
此外，在規劃階段，你可以完成一些并行的活動：例如翻譯術語、準備翻譯套件，為初始的客戶審核會作進度規劃等。
當你理解了需求并完成了規劃，你或許以為前面的工作就會一帆風順了。然而，在接下來的話題中，我們就會談到其它一些可能讓你船沉大海的暗礁。
失誤偷偷潛入……
作為一個本地化供應商的項目經理，你有很多相互矛盾的目標：
在交付期限、質量和預算方面達到客戶的期望，讓客戶高興；
在每個項目的毛利和所有項目的產出方面，又要讓自己公司的管理層高興；
讓客戶高興的最容易辦法就是接受任何以及所有的項目變更——面帶微笑，擺出一副“我們可以做到”的態度。然而，照這個邏輯推理下去，你很快會受到懲罰：項目范圍蔓延。結果是你要面對“錯過的交付期限”、“降低的毛利”、“來自你的客戶以及你自己公司管理層的不滿”。
怎樣才能在保持一個“我們可以做到”的態度的同時還控制好項目的范圍呢？如果你的需求定義得很好，初始項目規劃也做得很好，那么你的項目至少在開始的時候是有一個明確的范圍的。但是，控制住這個初始范圍需要有正式的審批流程——任何對原項目范圍的變更都需要審批；不這樣做的結果只能是自嘗失敗苦果。
本地化項目的范圍控制包括：
在立項階段和規劃階段，詳細討論如何通過項目變更單來管理變更。
對于每一次范圍變更，應及時地生成一個項目變更單。這里關鍵是要及時：范圍變更的需求一提出，而不是等到項目結束。
對每一個項目變更單進行溝通、討論、和審批，基于它對項目目標的影響（進度、預算、功能和質量）。
使用版本控制軟件和翻譯記憶庫來跟蹤源文件和本地化后的文件版本。
使用工具（例如，MSProjectServer）來管理各個項目的資源分配，幫助你獲取項目變更對你自己的項目和其它項目的影響。
最常見的范圍變更包含更新源文件、增加區域，增加交付物。在有些情況下，最好把變更請求當場一個新的項目，而不是更改項目變更單，特別是這個請求包含新的交付物的時候。
有一條很好的規則，值得牢記心中，即：項目范圍應該包含達到項目目標必須的每件事，但是不包含不必須的任何事。
審校員：偽裝的叛徒？
我們最后的失敗原因是本地化項目所特有的：客戶方審校員的角色，以及他們對項目的潛在影響。對于多數本地化項目，最后一個項目里程碑是客戶正式接受產品交付物。一般每個產品的本地化版本會有一位或多位的審校員。
與軟件開發項目不同，由于自然語言的本質，本地化和翻譯項目的質量要求比較主觀。尤其是術語和風格，大多由客戶審校員的偏好來決定。
正確地抓住客戶方審校員認同的術語和風格需求至關重要。在項目早期的時候就這樣做，之后則對客戶審校員的期望進行管理。
在項目規劃階段，你需要確認客戶方審校員是誰。你應該和他們建立互信關系。通常情況下，和你打交道的是一位背上審校責任并以此為主要任務的國內銷售人員或營銷人員。
有些審校員在產品本地化上不接受“公司控制”，這對你的項目是個極大的危險。這類審校員不會喜歡你的本地化產品。他們對英文原版沒有發言權，而他們又覺得自己的市場需要超過公司管理層愿意支付的更大程度上的區域適應。這種情況特別容易出現在（線上或線下的）營銷和培訓資料。作為一位本地化項目經理，你也許發現自己闖進了一個公司雷區，而本地化質量則成為客戶公司各部門之間爭奪控制權的武器。
想要從這種失敗情況中恢復過來，非常困難。因此，在規劃階段，應投入足夠的時間來定義審校員的角色。避免潛在雷區的最好辦法就是：清晰地定義審校過程并保證審校員的盡早參與。如有可能，在決定術語和風格的時候也將他們包含在內。
最后……
本地化項目管理需要一種非常積極的“我們可以做到”的態度，以及很強的分析能力。本地化項目管理的復雜任務在下面這幅圖中得到了很好的闡述。
原文鏈接：http://chenleix.cn/?post=56
【編輯推薦】
