微軟老兵看軟體開發#5：破壞式創新、技術進步對組織造成的變革動力／葉光釗
講到「破壞式創新」這個詞，一般人多半想到商業上的競爭案例，這在IT界隨地都是；微軟既是受益者，也是受害者，現在則正在努力生存當中。
而在工程管理這方面的領域中，「破壞式創新」的案例反而比較不明顯；但至少在微軟內部，顛覆既有工法工序，可說是無時無刻不斷激烈進行的過程，也是每個工程師絞盡腦汁想要實現的目標。
魔鬼卡在細節裡
話說台灣微軟的工程團隊，早期有一段時間的重要任務，是軟體以及手冊的中文化。這個工作當然不僅是一般所認為的翻譯工作而已，還有很多技術層面很深的面向。
不過不可否認的是，將英文的求助內容翻譯成中文，在整個專案的成本與時程中還是佔了最大的比例，而且每個版本所要翻譯的字數，是以十萬字為最小單位；而新版本所要翻譯的字數，又是以級數成長。
這是個典型的成本導向控制專案，而對微軟這樣的商業公司而言，最直接的KPI自然是最低成本與差強人意的品質。更機車的是，即使每個版本字數都會變多，公司卻將目標設定為總成本要比前一個版本低。
當時我們常常自我調侃：按公司的期望，理論上總有一天，這個工作會從花錢專案變成賺錢專案；因為成本會變成負的。
以為很完美的流程，實作時總會發現卡在細節裡的魔鬼。
產品組就這樣認輸了嗎？ 當然不可能。要讓成本巨幅下降，無窮盡的降低單位成本是不行的，非靠技術變革不可。
在很早期，我們嘗試過機器翻譯，但是當時的技術很不成熟，翻譯出來的成品品質難以接受；即使到現在，機器翻譯對長段落文章的翻譯也還是不行，只能用在一些特殊領域的內容。
後來經內部討論，比較可行的方式，是先在以較低的成本把翻譯工作外包給中國，讓他們先翻譯成簡體中文，再以簡繁轉換的技術轉為繁體；最後再用本地人力校對修正。初步估計這樣可以省去三分之一的成本。
這樣聽起來好像很完美，但魔鬼總是卡在細節裡。試了一個版本後，這種做法就繼續不下去了，因為有幾個基本問題難以解決：一是專案程序過於繁複，幾乎沒辦法規劃備案，而且只要當中有一個環節出問題，整個專案時程就卡住了。其二，簡體翻譯雖然是以人工進行，但是品質參差不齊，事後校正的成本反而更高，時間拖得更長。
不過老實說，這樣的實地試驗的收穫也是很寶貴的，至少發現幾個重要的瓶頸；再經過團隊的事後檢討，也規劃出配套的改進方案。另外更重要的是，後續之所以沒有再用這種方法進行中文化，倒不是因為改進方案不夠好，而是因為出現了更好更低成本的新技術，顛覆了既有的流程。
新技術取代舊做法
取代簡繁轉換的新技術，是一種稱為「回收利用」（recycling）的方法。觀念很簡單：將原始內容以及相對的翻譯，以句子為單位存入資料庫中；當有新的版本要翻譯時，先將原始文句跟資料庫比對，一致或相似度高到一定地步的內容，就直接調用相對應的翻譯出來，貼入輸出的內容，剩下的部分再進行人工翻譯即可。
其實這種技術很早就應用在翻譯上，只是如果重複的內容不多，效益就不明顯；多半用在提供翻譯者輔助用的參考內容。但是當像Office這樣的軟體，到了中後期的版本，雖然每個版本需要翻譯的總字數都會增加，但是跟前一版本重複的內容，比例也越來越高。在這種情況下，回收利用的效益就愈來愈高。
筆者自己做了分析，以當時的單價成本，只要重複的部分超過總字數的45%，回收利用工法的成本就會低於簡繁轉換；而且程序的複雜度比簡繁轉換低很多。
由於數據非常確切，即使簡繁轉換已經使用了一個版本，筆者還是說服管理階層捨棄不用，改採回收利用法。
新技術造成的組織變革
不過，筆者想在這裡談的觀念，不只是技術的更迭而已，更重要的是，這些更迭所帶來的「破壞」。
在微軟，每當發生這種技術的大改變，伴隨而來的就是組織的變化；多半都是團隊解散。在上面的例子中，如果簡繁轉換的流程成功了，代表的就是台灣團隊不需要存在；至少不需要同等規模的人力，而其任務性質也會有很大的改變。
個人和團隊在組織中必須隨時保持危機意識，才能保有一席之地。
在許多的例子中，受影響的團隊多半拒絕變革，或是盡量拖延變革；不過老實說，到目前為止筆者在微軟中看過的例子，任何抗拒改變的團隊，最後都是以悲劇收場，因為從整體組織的角度來看，變革往往是不得不進行的。
長期歷練下來，聰明的微軟工程師也發展出一個新觀念：如果管理階層要求技術大轉換，工程團隊就要想盡辦法徹底精進這種技術，而且最好發展出不同的新技術，顛覆舊做法。也就是說，唯有隨時保持危機意識，才能提高個人與團隊的價值，在組織中保有一席之地。
台灣的開發團隊經過這番轉折，不但保住了團隊，規模沒有縮水，更以此為契機，將僅僅負責中文化的工作內容，全面轉換為以功能開發為導向的組織結構；但其中的點點滴滴，說來又是另一部血淚史。
回顧種種歷程，對筆者來說，這真的是畢生僅見的難得經歷。