破壞式創新

講到這個詞，一般人多半想到商業上的競爭案例，這在 IT 界隨地都是；M社既是受益者，也是受害者，現在則正在努力生存當中。而在工程管理這方面的領域中，反而比較不明顯。殊不知至少在 M 社中，顛覆既有工法工序是無時無刻不斷的激烈進行，也是每個工程師絞盡腦汁想發生的事情。

話說台灣的工程團隊，早期有一段時間的重要任務，是完成軟體以及手冊的中文化。這個工作當然不僅是一般所認為的翻譯工作，還有很多技術層面很深的面向；不過不可否認的是，將英文的求助內容翻譯成中文，還是在成本與時程中佔了最大的比例 - 每一個版本所要翻譯的字數，是以100K為最小單位；而新的版本所要翻的字數，又是以級數成長。這是一個典型的成本導向控制專案，對 M 社這樣的商業公司而言，最直接的 KPI 自然是最低的成本與差強人意的品質。更機車的是，即使每個版本的字數是上升的，公司卻將目標設定為總成本要比前一個版本低。當時我們常常自我調侃: 按公司的期望，有一天這個工作會從花錢專案變成賺錢專案，因為成本會變成負的 :-)

產品組就這認輸了嗎? 當然不可能。要將成本做巨幅的下降，無窮盡的降低單位成本是不行的，非靠技術的變革不可。很早期做過機器翻譯的嘗試，但是成果很不成熟，即使到現在 machine translation 對長段落的翻譯也還是不行，只能用在一些特殊 domain 的地方。後來經內部討論，比較可行的規劃方式，是先在大陸以較低的成本先做簡體的翻譯，再用簡繁轉換的技術，將結果轉為繁體，再用本地的人力做事後校對，初步的估計，這樣可以省去三分之一的成本。

聽起來好像很完美? 魔鬼總是藏在細節裡。這樣的做法試了一個版本就繼續不下去了，幾個基本的問題: 一是專案程序過於繁複，幾乎沒辦法規劃備用方案；其中只要有一個環節出問題，整個時程就卡住了。其二，當時簡體的翻譯，雖然是人工進行，但是品質參差不齊，事後校正反而花了更高的成本，時間拉更長。不過老實說，這樣的實地試驗的收穫也是很寶貴的，至少檢驗出重要的瓶頸，經過團隊的事後檢討 (postmortem) ，也規劃出配套的改進方案。

後續之所以沒有進行，倒不是改進方案不夠好，而是出現了更好更低成本的技術顛覆。下一篇再來揭曉: 是如何的神奇技術勝過了簡繁轉換，而在這之前，有興趣的朋友也可以推論看看。