微軟老兵看軟體開發#3：全球化、國際觀、在地化的糾葛／葉光釗
最近「國際觀」這個詞常常被拿出來討論，這一篇也來湊個熱鬧。
跟許多IT界的巨擘一樣，微軟是一家總部設在美國的公司，而且大部分研發能量也在美國；也因為如此，微軟所研發出來的軟體，總是會受到「從美國看天下」的批評，無法脫離美國強勢文化的負面觀感。
針對這一點，微軟長期以來都是重視的。原因很簡單：微軟在美國以外地區的獲利，很早就超過北美許多倍；尤其是在亞洲的中國以及日本。而在技術面，隨著Unicode在各個平台的成熟度以及接受度的提升，在地化的門檻和成本也都逐漸降低；除了Complex Script系的語言[footnote]在此指的是複雜書寫規則的語系，例如泰文、Hindi文等等；以及從右向左書寫的語系，例如希伯來文、阿拉伯文等等。[/footnote]需要比較複雜的處理之外，主流平台對多國文字的處理的功能愈來愈豐富，對應用程式也愈來愈友善。
全球各地使用者的需求，已經不僅是文字與翻譯要正確，而是功能優先順序的不同，甚至是衝突。
照這麼說，各家軟體大廠對全球各區域的在地化功能要求，應該能夠處理得愈來愈好？
事實正好相反，軟體全球化、在地化的問題反而愈來愈複雜。為什麼？因為全球各地使用者的需求，已經不再只僅僅是文字和翻譯的正確性，已經提升到了軟體功能優先順序的不同，甚至是需求的衝突。
不同文化認知，造成決策盲點
照例又要來一段公案，講講故事，幫助大家明瞭實際的情況。
有一次，微軟的台灣團隊，在開發以手機瀏覽Office文件的功能時，碰到一個必須的決策：當遇到一些較罕見的例外處理情況，例如文件結構異常時，程式總是要顯示錯誤訊息給使用者看。
對大部分的語言（包含亞洲語系）來說問題原本不大，但是早期手機上的瀏覽器，對Complex Script的支援是很有限的。如果當時決定要以complex script在例外處理中顯示錯誤訊息，勢必要多花許多工夫去寫一些額外的程式碼。
如果你是身處台灣的PM，你的決定會是做還是不做？為什麼？
在公布當初的決定之前，先介紹一下微軟內部國際化功能（internationalization， 簡稱「i18n」）的決策流程。在早期國際化相關功能還不太多的時代，每一個產品小組多半會指定一個Intl PM，負責蒐集以及彙整和i18n有關的開發需求；而幾個主要的市場如日本、韓國、中國、台灣、英國、歐洲等等，也都有在地的PM提供相關的市場價值資訊，以及功能的驗證等等。
這樣的體系雖然完整，但是決策時間過於複雜而且費時；當產品版本日漸演進，功能愈來愈多時，這種體系就漸漸跟不上開發進度的需求。後來導入遙測，很自然的決策就開始依賴資料和數字，人的介入也就愈來愈低。有些不同的問題就此浮現出來。
光靠數字無法做出正確決策
回到我們的之前的故事。
當時，台灣的開發團隊一開始也是照表操課，先檢驗錯誤訊息的出現頻率等基本資訊；由於數據顯示這類錯誤訊息的出現頻率並不高，所以他們在第一時間就決定「不處理」（won’t fix），也就是Complex Script語系的使用者，只會看到英文的錯誤訊息。
但是當研發進程到了中段，因為進度超前，功能小組有了一點時間回頭來看這個題目，才赫然發現整個產品組對這類問題設定為「不處理」的比例非常高；仔細檢討下來，他們發現犯了倒果為因的錯誤：因為程式對Complex Script的處理原本就不好，所以才造成使用頻率偏低的結果。如果照這樣的數據來做決策，相關問題就永遠沒有機會修正。
為了避免只看數據造成國際化決策錯誤，微軟也發展出內部跨國諮詢社群，以補不足。
功能小組於是進一步詢問了在地銷售部門，了解相關市場的反應，這才發現在地市場對這類的問題積怨已久，即使只是稍加改善，也能挽回不少滿意度。
雖然當時基於其他的工程理由，仍舊維持原議不予處理；但大家還是學到了一個教訓：對著硬梆梆的數字，要對自己不瞭解的遠方客戶做出可能造成影響的決策時，要盡可能地抱持同理心，以受影響的人的出發點來著眼，不然非常容易倒因為果，形成更深的衝突。
廣納各族群意見，彌補數據的不足
基於這樣的認知，日後微軟內部也漸漸地發展出相關的跨國諮詢社群（global community），透過更多不同文化人群的參與，彌補數據決策的不足。
由於技術的進步，使用各式IT系統和數據進行決策的程度會愈來愈高；但是在此同時，明顯或隱藏的陷阱也會愈來愈多，全球化產品規劃就是一個最好的例子，很值得所有在跨國公司進行產品開發的朋友列為參考。