只有一階段的測試，但沒有驗證測試的專案

原則上我認為這是個專案團隊在專案初始規劃時的一個嚴重錯誤。規劃人員礙於經費相當有限，於是只安排一個階段的測試工作，並未安排第二階段的驗證、回歸測試。

其實原本開發人員本來就應該針對自己交付的成品的品質負責（程式開發階段的單元測試，以及錯誤改正的基本驗證），例如嘗試重製該錯誤，確認錯誤不會再發生，才能結束該項錯誤修正的工作。但品管人員應再一次的為之前所記錄的產品瑕疵再次驗證，做最後把關動作。

當第二次的回歸測試被取消了，其實即使開發人員有做基本的驗證，但畢竟開發人員不是專業的品管測試人員，產品經理或是產品團隊甚至是開發人員在最後要將成品交付客戶時，為了為品管把關，結果還是要多花一些時間再次驗證產品品質，那麼事實上不做第二次的回歸測試，只是把成本轉嫁到產品團隊身上，而當產品團隊本身不具備品管與測試專業時，可能會花更多時間在做最後把關，這樣弄到最後，看似成本省了，但實際上團隊超時工作的成本卻被忽略了。

各行各業都有各自的專精，開發人員善於開發，不見得善於測試；同樣的，有擅長於測試的人員與團隊，通常當開發流程成熟後，將測試工作轉交給專業的測試團隊，對於整個專案來說是最省開銷的做法，同時又可兼顧品管。試想，讓你做你所不熟悉的領域的工作，例如讓一個程式開發人員來作測試，是不是通常會花費更多的時間，甚或是得不到理想預期的結果？

工作上的危機管理

危機管理，其實在日常生活當中都會發生，有些事情相當小，談不上什麼危機，就只是單純的下決策，例如本來你想拿剪刀剪開某商品的外包裝，臨時找不到，於是用刀片替代；稍微大一點的事情，例如家中用了近十年的熱水器突然在半夜壞了，天氣已涼，一家老小不太可能冒著 20 度左右的水溫洗冷水澡，怎樣用最短的時間讓家裡的熱水可以重新供應；再更大一點的事件，例如突然接到電話，得知老家的長輩有狀況，怎樣用最短的時間趕回遠在百公里遠的老家等。

工作場合，由於商業上的考量，總是希望能用更好的管理方式來為公司賺錢，因此諸如危機管理、風險管理、時間管理、決策管理等等管理方法廣違被談論或是運用。

每一項管理的背後都有很多道理，但我覺得其實他們都是相似相通的。例如上次我舉例到飲料店怎樣利用閒置時間以加速商品的交付，概念其實是可以應用到很多場合。

有時候感覺共事的人會說幹嘛想那麼多，一副認為天不會塌下來似的，但俗話說「不怕一萬，只怕萬一」，職場上很多時候一個小錯誤可能導致某個合約便成違約，賠償下來是可能讓公司面臨財務困境的。

我一向認為，可以的話在一個專案開始的階段，就盡量的列出各種可能導致專案失敗的可能，要討論機率那是之後的事情，商場上有時確實要賭一下，但就看賭的對或不對。

舉例來說，會不會因為硬碟故障甚至損毀，導致專案的檔案全數毀壞？那麼是不是要有檔案備份的機制？在 921 地震發生之前多數人做的備份是磁碟陣列或是磁帶備份， 921 之後大家開始思考異地備份，不管是即時的或是非即時的，例如每週定期將一份磁帶送去辦公大樓以外的另外一個地點儲存，那麼要是辦公室發生意外導致設備全毀，至少前一週的檔案還可以取的回來。

其實工作上的危機天天都在發生，只是事小或是事大罷了。小的可以是例如原定今天要完成某專案工作項目A，然後明天開始工作項目B，但是因為前一個案子被客戶打回票，今天緊急要做處理，那麼當下的專案的工作項目受了影響，勢必往後延，那麼該怎麼處理，本身就算是危機的處理。

危機或是風險的管理，並不是只有專案的經理，或是部門經理要去注意的，每一個工作者都應該要學會認識這些以及處理這些問題。不能來一個任務指派就只單單看該任務，然後就隨意應允交期。答應了的交期，因為其他內在或是外在的因素而產生的危機，就要學會面對與處理。

Call me Taiwan

Please call me Taiwan, not Chinese Taipei and even not China Taipei either.

To argue that we are "Republic of China" or "Taiwan" now seems to be meaningless. 20 years ago the "Republic of China (R.O.C)" is well known country and is one of the core member of UN. But now it's not, "People's Republic of China (P.R.C)" has replaced R.O.C to be the core UN member. Fine, since the government of R.R.C did not rule the mainland China. However, the government of P.R.C has NEVER ruled Taiwan.

One of my friend in Ireland told me that when he was a child, his image to Taiwan was almost all of his toys were "Made in Taiwan". However, recently, he was just refresh his image to Taiwan due to most of the IT high-tech products are made in Taiwan or designed in Taiwan.

It's sad that now more and more people are brainwashing by P.R.C and become to think that Taiwan is one of China's province. Well, it WAS, when China was ruled by R.O.C. But Taiwan is NEVER one of the P.R.C's province. And it will NEVER be.

Please, friends from worldwide, wherever you are, call me Taiwan. And please learn that we are not part of China.

工程師的輕重緩急如何拿捏

我常簡單的把人的腦袋與 CPU 做類比，每個人只有一個腦袋瓜，你可能以為你同時間只能做一件事，也許你很訝異為什麼有人可以同時做很多事情，或是對於日理萬機的大老闆感到好奇。有的人神經緊張，工作時沒有辦法聽音樂，也不能容忍旁邊同事一直再講電話；有的人你跑去找他問事情，他正在寫電子郵件，他請你繼續講，你邊講時他邊一直在打字，但你發現你講完他居然可以立即回應你，怎麼他可以一心多用？

一心多用是個好比喻，對於單核心時代的 CPU 其實他也只是一個核心可以多用。但是如果把時間放大到每一秒，甚至是每 0.5 秒、每 0.1 秒、每 1 毫秒....你將會發現事實上在那麼小的單位時間裡，CPU只能處理一個運算單元，而能一心多用的人其實也只是在思考一件事情。在打字的那位同事，仔細觀察一下，發現在跟他講話之前他的打字速度大概是每分鐘 60 字，當你在講話時，他打字速度些微減慢了，變成每分鐘 40 字，其實他是切割出來一些時間聽你講話，再切割出來一些時間思考你講的是情。

換個比喻，假設你是飲料店的資深員工，店裡所有的飲料你都熟知如何製作，有的商品很耗時，例如咖啡要比預先泡好的綠茶耗時，而現炸西瓜汁看似時間短，步驟卻比咖啡更複雜些。
一早開店後來了個客人點了綠茶，從茶壺裡倒出來然後上蓋拿給他只要 10 秒鐘。接著的客人點了杯咖啡，按下咖啡機的暖機加壓鍵，將咖啡粉倒進濾杯然後壓實，旋進咖啡機裡，到這裡花了15秒，等候咖啡機暖機完成壓力到位，又等了20秒，按下沖煮鍵，等咖啡沖煮完畢，加水稀釋、加糖、加奶、上蓋，拿給客人，客人前前後後等了 60 秒。下一位客人點了西瓜汁，真是難得，有人一早就喝西瓜汁，西瓜先前已經每顆切四份然後上保鮮膜已保新鮮，要榨前要再略微切小塊些，切西瓜花了 10 秒，丟進榨汁機，加些許水，開啟榨汁鍵，等候 5 秒，關機，倒出榨好的西瓜汁，但要過濾過粗的渣，這比較花時間，等待過濾需要約 10 秒，過濾完畢，上蓋，交給客人，總共 30 秒。

於是，三種主要飲料花費的時間為：

種類	總製作時間	分段時間	總閒置時間
綠茶	10 秒	10 秒	0 秒
咖啡	60 秒	15 秒 + 20 秒 + 25 秒	20 秒
西瓜汁	35 秒	10 秒 + 5 秒 + 10 秒 + 10秒	15 秒

如果說接著來的四位客人依序點了咖啡、綠茶、咖啡、西瓜汁，照 FIFO (First In, First Out) 的方式依序製作這些飲料的話，那麼共需費時60 + 10 + 60 + 35 = 165 秒。但更聰明的方式可以只花費 120 秒，其步驟如下：


也許還能有更短的時間，但是讓先點餐的客人等待太久也是不太好。

在現實的辦公場合理，其實也常常遇到類似狀況，原本在處理的一個大案子，總的得花四小時才能處理完畢，但中間其實有些等待時間，有些狀況是必須連貫的處理四小時。然而，臨時主管來了個小任務，有新案子要評估，需要你確認一下該案子的類型與預期的工時，這大概會花你 30 分鐘，你是要讓主管等 4 + 0.5 小時後你才給他報告，還是你在前面的任務裡稍微中斷一下挪出 30 分鐘完成分析報告，於是主管只需等待 2.5 小時？

類似上面綠茶的例子，綠茶明明只需要 10 秒鐘就可以完成，甚至可能更快，如果先前的作業有閒置時間，那麼其實可以先做綠茶，就算先前的作業完全沒有閒置時間，但若是時間相當常，假設客人點了個需要花 2 分鐘才能完成的飲品，在這 120 秒鐘打斷個 10 秒鐘先做綠茶會不會比較好？也許有些人會認為讓先到的客人額外多等 10 秒鐘是不道德的，這就另外在討論了。

工作場合上，有時前項任務的截止時間其實還早，例如下班前要完成，那麼在下班前四小時就交付，與下班前三小時交付，其實某種角度來說意義是一樣的，也就是說有些狀況之下，某些任務會變得較不緊急（略低的優先度），即使他的重要性很高；有些重要度高並且也緊急的自然應該先處理。

有更多時候實際狀況更加複雜，同時好幾項任務在進行中，並且都在不同階段。某項任務是專案的前期分析，因此所有的疑點與問題必須儘早發現並提出討論與確認；某項任務是專案的執行階段，雖近似於例行姓事務，但必須確保交期；某項任務則是在發包階段，下游廠商正等著發包。

輕重緩急，對應著簡單 / 複雜；短時間可處理 / 需較長時間完成；尚有相當多餘裕 / 必須儘早完成。要說是二維的思考也好、三維的思考也好，總之很多時候其實可以將時間稍加切割，可以更加靈活的運用時間，而不必拘泥於 FIFO 的刻板思惟。

Schedule a meeting across several time zones

I am assuming that most of the people who are working with world wide clients, vendors, and colleagues must have the knowledge of time zone and time difference.

Now let's have a quick view on how to pick a proper time to schedule a meeting across several time zones.

The first thing you need to know is which time zone each attender is located. I am in GMT+8, Mumbai is in GMT+5.5, Luton is in GMT, Bellevue is in PST (GMT-8).

Then, prepare a timing sheet like below:

And pick a proper time for the meeting.
The cells with red background mean they are pretty bad timing for the people located there. So if I pick up the time 21:00~22:00 in Taipei time, it probably is the best time to have all the people to meet together. Some of them need to get up earlier, and some need to rest later.

In this case, guys in US Washington state need to join the meeting at 6 AM, guys in Japan will have the meeting at 10 PM to 11 PM.

最好的方法與最有效率的方法

處理同樣一件事，可以有很多方法來進行。

案例一：
要自行組裝一個四格簡易書櫃，你可以拿一把十字螺絲起子，慢慢的把總共 16 根螺絲鎖起來，時間花費也許要 32 分鐘（假定鎖一根螺絲要 2 分鐘）；你也可以拿電動螺絲起子，花費約 8 分鐘鎖完 16 根螺絲，速度上快了四倍。

後者應是最有效率的方法，但不見得是最好的方法，因為你不見得有電動起子，跑去工具行得花個至少五六百元買一把，來回可能就一小時了，而鎖完這個書櫃後，大概一年半載內不會在用到這把電動起子。

案例二：
你有沒有想過，當每年快要接近報稅的時候，公司的行政人員是不是開始跟你確認你的戶籍地址有無錯誤，你回想一下他們都是怎麼進行的，是由專人逐一到每位員工座位那，一一的確認地址，還是利用電子郵件確認？

過去我曾待過兩家員工在 100 人以下的公司，前一家是行政人員將所有人的戶籍地址印出來，然後拿著逐一去跟員工確認，公司員工人數不算很多時看起來還是可行的辦法；後一家選擇了一個很有效率的方式，但是犯了一個嚴重的錯誤，行政人員將所有人的戶籍地址整理到 Excel 表單裡，然後新增一個「確認」欄位，接著將表單放到公司內部公開的檔案伺服器上，發信請每個人去確認表單裡自己的資料有無錯誤，無誤就標記為 OK ，有誤則請直接更正。

後者的方式確實很有效率，需求發出去，行政人員不必親自逐一向每位員工進行確認，緊接著他可以繼續進行其他事務，只要等到預定的底限到了，再將檔案回收即可，嚴格算起來花費的時間也許只有 5~10 分鐘。前者因為需要逐一親自拜訪並確認，確認完同樣的員工人數，可能花費了 30 分鐘，「效率」相差近六倍。

案例三：
有天我在對一個專案的各個子目錄逐一進行壓縮，準備要將專案歸檔備份，為了使歸檔後，未來有需要參照的人能夠較為易於找尋他想找的資料，因此我決定每個子目錄個別壓縮成一個檔案，這會比起整個類別目錄（例如所有測試相關的目錄）全部被壓承擔一的一個壓縮檔來的好一些。

但這動作大概接連做了十來次之後，我就開始感到不耐煩，礙於壓縮軟體功能的限制，我所想要的壓縮選項都必須透過多達五、六個操作才可以進行，每一個目錄都是進行相同的操作，我很概略的估算一下，應該至少還得重複個幾十次也許會超過一百次。這樣每個目錄大概會花費我五～時秒的操作才能依照我的要求來進行壓縮，五～十秒看似很短，但重複個 100 次那也快逼近 15 分鐘了。15 分鐘也許也可以算是短，但是一般人有個很大的弱點，就是不適合做重複性的動作太多次，特別是沒有像生產線上的作業員一樣受過專業的訓練的話，即使只是約五個步驟的操作，可能在重複個二十次之後不小心就會產生錯誤，遺漏某個步驟，或是做錯哪個步驟。

我心裡估量著，我花個三分鐘測試一下用一些輔助方式來改進，三分鐘後完成，之後我只要透過幾組的輔助步驟，便可以半自動的批次完成重複的步驟。若以原本全手動需要約 15 分鐘來算，我大概也沒省到多少時間，但是藉由輔助的工具，至少可以大幅避免重複性的工作產生的錯誤風險，算是值得。

全都做完後，我檢討了一下，也許以後可以把輔助工具改進成近乎全自動，但是先擱著吧，真要做到全自動，開發要花時間，驗證功能更要花時間。

討論：
不是什麼方式都絕對是最有效率並且同時是最好的方式，對於一個職業組裝工人來說，裝配傢具是他每日的工作，投資自動工具以達到至少四倍的效率提升，顯然是相當值得並且也是必要的投資，對於一般人也許一年才會自行組裝一次傢具的人來說，添購自動工具便顯得不太實際（當然近來有商家推出自動工具出租，這會是另一種值得評估的方案）。

但我也不是要全面否決追求效率的想法。檢討每一件事情有沒有採取較有效率的方式進行，時常是未來改進的重要參考。對於日常的工作而言，我們經常是在進行重複性或是同質性相當高的工作，因此，當某些事情並沒有採取較有效率的方式進行，意味著我們會投入較多的人力與時間成本，對於需要以營收來支撐的公司而言是不利的狀況。

添購工具以達到高倍的效率提升，並且衡量工具的採購成本對比傳統方式的相對工時成本付出，就可以大概有個底，知道投資值得與否。

好比製麵商家，用傳統方式，得聘請兩個全職員工負責製麵，才能達到預期的產量，當產量需求增加兩倍時，意味著至少得要再追加兩名員工（假定每人月薪為 3 萬，兩人一年的年薪則為 72 萬）。

若買進某自動化加工機器，得花 100 萬元，但只要對既有員工稍加訓練，使其能夠操作該機器，則兩倍產量便可輕鬆滿足。機器一次買進花費 100 萬元，雖然有每年折舊以及機器耗損風險與定期養護支出，但對比增加員工每年都得額外花費 72 萬元，何者較為划算，就很值得討論了。

==========

今天看到某 3C 賣場的廣告，「夏季家電最終特價」的標語居然已經打出來了，是的，將要進入九月了，秋季已然接近。對於事事要檢討有無效率的公司而言，六月時員工投訴辦公室室溫長時間過高的問題，居然耗了將近整整兩個月仍在「評估」中，同事們私下笑著說，待哪天總算加裝好新的冷氣時，大概時節已邁入涼爽的秋季，那台新裝的冷氣應該要等到明年才派的上用場吧。

事實上也不僅僅才兩個月，辦公室室溫過高，就有空調無法負荷，這不是今年才發生的事情，早在幾年前便已逐步惡化了。機具會老化是合理的現象，當老化時，即使再怎麼加以維修保養，終有不切實際的一天。老家客廳的冷氣，在服役了近十年後，老媽在我的建議下，換裝了時下最流行的變頻冷氣，並且買了目前評價最高且冷房效益最好的Ｘ金冷氣。結果新的機器在服役滿兩個月家裡收到台電的電費帳單時，電費對比去年同時足足省了近六千元。

我心裡只是納悶著，連老媽只是個國小畢業的家庭主婦，什麼事情值得投資（Ｘ金冷氣大噸位的買起來要比他牌貴上兩三萬），什麼開銷該節省，都可以拿捏的很準確。怎麼以營利為主的公司，事事要檢討效率，卻在行政事務上每每讓我覺得不是用了很糟的方式，就是用了很沒有效綠的方式。我甚至碰巧聽到行政人員講到「可是Ｘ金冷氣很貴！」的對話，是的，他確實貴，但是否值得？公司內人多機器多相對的發熱源很多的狀況，加以冷氣每天至少得開個近十小時的狀況來看，變頻冷氣理想上最高可省近 40% 的電費，是不是短短幾年內就可將價差給追回來了。

我認為事情的衡量準則不是絕對的，就像前面幾個例子看到的，看人看狀況，該有不同的選擇。我自己家裡幾個月前也添購了冷氣，我想很多人跟我會有類似的考量，約三四坪左右的房間若是裝個非變頻的分離式冷氣，約要一萬五，要想選擇變頻，則馬上貴上一萬。多這一萬，究竟要不要花下去？對於我們一般這種小老百姓，看老闆眼色吃飯的，一萬說多部多，說少也不少呀。最後多這一萬還是花下去了，因為估算自己在家時冷氣應該常常會開著的。但是去年老婆娘家添購冷氣實則選擇了非變頻機種，原因是因為丈母娘很節儉，平日很少會開冷氣，那麼即使變頻電費較省，但因用量低，反倒變成不是很值得投資。

當每年公司管理階層都會對我們這些小員工進行績效稽核時，我不禁想問，這些管理階層是不是也該讓我們來評評分數。

為什麼多語言軟體要做偽本地化(Pesudo-Localization)

即使軟體的國際化、全球化、本地化已經提倡了相當多年，產業的分分合合（在決定自己做、到決定外包、到再次的決定拿回來自己做）也發生了幾次，但是依舊有為數不少的新加入者，或是從未涉足這塊領域的公司，對於軟體的多語化一問三不知，於是，其軟體的多語化，依舊是十年前的土法煉鋼。

為什麼將要進行多語化的軟體產品，建議要做偽本地化(Pseudo-Localization)？一個大學同學最近問了我這個問題，我想了想，我大概有近三年沒有回答過這類的問題了。不過，事實上我也驚覺我現今周遭的同事似乎有不少人也不了解這問題的答案，更有甚者，對於何謂偽本地化全然不知。或許也難免，當分工過於精細時，如果沒有機會碰觸到這一塊的領域，相當大的機會不會聽過這個詞，也自然不會知道其為何謂。

偽本地化其實是希望能夠解決以下幾件事情：
1. 驗證產品的 UI 確實有被適度的拉寬長度以適合語彙較長的語言，例如德文或是挪威文
2. 藉由偽本地化的技術，順勢驗證產品的各個控制元件是否可以正常顯示歐語的延伸字元（例如：ä ü ö é 等）、東亞（中、日、韓）、以及中東語係文字等。
3. 驗證產品是否會因為過度翻譯，或是因為翻譯的不一致，卻導致產品功能無法正常運作
4. 驗證是否尚有未抽取出的字串因而導致未完全的翻譯

同學問我，那翻譯後不就也知道上述的問題了嗎？理論上是沒錯，但是其實往往為時已晚。很多的狀況下，產品開始進行翻譯時，也就是程式以進入功能異動的凍結時期，甚至產品以進入 beta 或是 RC 階段了，若是此時才發現因為翻譯導致產品功能錯誤，其結果往往是部份的翻譯回復為英文不進行翻譯，然後使用者便拿到一份中英混雜的產品。

不過話說回來，有進行偽本地化的軟體商或是軟體專案，似乎仍舊是相當稀少。
看來幾個強調可以為軟體進行偽本地化工程的翻譯工具，還真難從這些軟體廠商身上賺到錢，也難怪接連的被併購....

Talk about "Ready for Localization?" again

Recently my colleague from UK ask me (and our team) for a favor. They encounter a problem that they thought they have localized everything, but the result is many text still show in English. I guess he is a guy who only have a limited knowledge of codes, but he has tried his best to dig into the deeper level of the materials. The localization project seems did not involve any engineer, I would said the project was under estimated.

There are several reasons which result in the fact that many text are still in English. It's pretty bad. The material seems never being examined if it's I18N ready or G11N ready. Not to mention to have a pseudo localization test.

The main product is a set of flash files. Ideally all the front end presented text are stored in the back-end database. The ActionScripts codes will then pull out the text from database and generate several XML in run-time, and then the flash will refer to those XML to present the text.

I saw one of the common problem which most of the UI designer may also make the same mistake. Normally when a UI designer create a new object like a button or a lable (a text field), s/he will also put a default string with it. For example, when creating a cancel button, you might put the "Cancel" in the button's text field, and then in design mode it will just look like what it will be in the run-time mode. It seems to be fine, but actually it's not. It will be hard to detect which object has not yet been externalized or linked with external text source. Because you will think everything "looks fine" in your testing.

A UI designer may not have enough knowledge in I18N or G11N area. In some cases, it's fine. But they'd better learn more from these areas.

A simple way to improve the process and prevent from the problem is to use code-like text. For example, use "_CANCEL_" to be the default text for the button.

Since the product will be localized into many languages, never thinking about to leave the English text to be the default text. Treat English as another language. Load all the English text from external text source just like what you plan to do for all the other languages.

In this way, it will be easier to localize this product and less problem will be.

跨時區協同合作 - 2

在我的觀念裡，只要是需要過國合作，不管對方是廠商、客戶、或是同事，要希望能夠有良好的互動，那麼隨時隨地記得夥伴的時區是很重要的，除非哪個案子真的時程很鬆。

過去曾和愛爾蘭客戶合作過，與台北時差八小時，他們一般九點上班，已是台北的下午五點，當時的合作狀況愉快，客戶也建議我們小組向公司申請工時往後憑移至少一小時，也就是一般人早上九點上班，下午六點下班，我們平移一個小時的話，晚上七點下班，那麼每天至少與愛爾蘭有兩小時重疊，可以藉著這兩小時密集的討論案子進程與遇到的問題。

過去也曾與美東客戶合作，每週定期要開進度會議，這次的合作經驗就不是挺愉快。美東在進入夏季日光節約時，與台北時差12小時，在喬會議時間時曾考慮美東早上九點 - 台北晚上九點，或是美東晚上五點 - 台北清晨五點，自然是決定在雙方的九點開會。專案持續邁入十月份，日光節約時間結束，當時重新提起開會時間，由於美東早上九點將是台北的晚上十點，於是我們試圖建議客戶改成美東晚上六點，台北早上七點，這樣的狀況下是雙方都有犧牲，客戶比須晚點下班，而我們則必須早上七點前作好開會準備。

兩個案子拿來作比對，在與愛爾蘭合作的例子當中，曾有幾次我在晚上12點（愛爾蘭的下午四點）還在回覆客戶的信件，客戶很訝異但也很迅速的回信過來，請我不要工作的太晚。與美東合作的例子當中，在結案時的 PPR 會議當中，我們很訝異的聽到了客戶的專案主管在很不悅的提到「我們的員工也都是有家庭的，要我們為了與你們開會而必須加班，NO WAY！」很顯然的「客戶最大」的心態浮現了，該公司是比較不加班的公司，但當必須與時差多達 12 小時的城市合作時，即使每週只是聚在一起半個小時開個進度會議，只會想到自己不樂意延後半小時下班，卻沒想到事實上我們是提早兩個小時（早上七點）準備會議，或者是必須延後四個小時（晚上十點）來開進度會議。當初在日光節約時差調整結束時，確實我們是試探性的看看客戶是否願意晚個半小時下班，事實上客戶在當時也沒有反對。

與美東客戶合作的例子其實也有令我們很訝異的，曾經有次有個新的案子，客戶的產品因為屬性相當特殊，我們請客戶給予我們一些產品教育訓練，後續又在請他們協助 trouble-shooting ，結果有次一連搞了兩天，第一天我們是在公司等到晚上十點，美東九點了，雙方開始進行電話會談，以進行問題的排除，一路弄到台北已經半夜一點了，尚未搞定，只好先擱著，隔天繼續。第二天一早我們九點進公司，客戶還在，於是再次進行電話會談，延續前一晚（八小時前）的進度，約略三小時候尚未搞定，美東已經晚上十一點了，客戶說要先回家休息了。第二次到了晚上十點，美東九點，雙方第三度搭上線，再次針對先前的問題進行排除，總算辛苦沒有白費，約略兩小時候，問題搞定，雙方一陣喝采，然後我們在半夜十二點多離開公司回家休息。

舉出這例子，我覺得是個挺有趣的狀況，雙方在時差 11 個小時的狀況之下，可以說是針對一個問題，在將近完完整整的 24 小時內片刻沒有空白的銜接起來，並且雙方皆有在進入深夜前回家休息。這次的合作經驗裡就會感覺的雙方彼此像是個團隊，有著共同的目標，因此都願意做某些程度的犧牲。

我認為，跨時區合作時，應該是要善用時間的差異來補足對方的非上班時間。最近的一個合作案例裡，與美國加州同事合作，該是對方要進入深夜的時間，卻還看到 PM 上線來討論事情，為的是希望在他入睡之前知道我們的進度與遇到的狀況，好在他隔天上班後可以進行處理。也有次有個英國同事 on-site 到美國客戶那，由於在客戶端網路存取受限的關係，他深夜回到飯店後上線與我討論問題細節，然後跟我確認三個小時候是不是我們台北時間的大約下午三點，然後他就去睡了，三小時候他再次上線，確認一下我們的進度，然後再睡回籠覺（事實上他那裡天還沒亮）。

不過我也見過同事似乎沒有時差的體認，明明某陣子密集的同時與美中和印度合作兩個不同的案子，早上卻是十點後才會出現，但即使出現了，由於他手上尚有其他本地的幾個案子，也許他考量到在這個同樣的時區裡他不早些將事情確認好交辦出去，那會耽擱了其他人的時間，聽來也對。但是在我來看，幾封從美中過來的相當重要的問題詢問與事情交辦的信件，雖然我不知道發信人在忙什麼，為什麼在他的晚上七點甚至八點了還在公司，但可惜的，直到他晚上九點下班後（台北上午11點）仍然沒有收到回信。信件後來下午回覆了，結果還需要美中同事再確認過之後，我們才能開始進行某些工作，結果，一天就浪費掉了。

如果你也有跨時區協同合作的經驗，那麼你可以思考看看，你、以及對方的合作模式是怎樣的，彼此的合作是否有感覺到像是同一個團隊的感覺？

跨時區協同合作-1

跨時區協同合作是很辛苦的一件事，特別在時間很緊迫時，希望不要讓時差而拖慢時程，每個城市的人都要追著時區跑。且看下面這張圖：


粗體標示以台北時間為主軸，表格內數字為時刻，黑色數字為今日時間，灰色數字為昨日時間，藍色數字為明日時間。黃底為正常工作區間（早上九點～下午六點）。

假設台北只跟東京同時合作，由於時差僅一小時，重疊相當多，只需記得當台北下午五點時，已是東京下午六點，要下班了。因此所有要連絡的事項必須在台北下午五點前完成。

假設與巴黎（或多數西歐城市）合作，那就有點辛苦了，必須等到下午五點，巴黎才開始上班，工時僅重疊一個小時。所有要交辦並且希望得到即刻回應的事項，必須盡量條理清楚，以及明白表示優先，好讓巴黎的同事可以在這兩小時內回覆你。但是就算回覆了，也到了你的下班時間，事情又得延到隔天繼續了。

若與美國西部城市例如舊金山一起合作，那麼也是重疊一個小時，但要注意是到了台北早上十點，已是舊金山的下班時間下午六點。所有來自美東的詢問，若可以的話盡量集中在一早第一優先回覆，特別是希望美西再回覆的事項。否則，一旦過了十點，甚至十一點，美西那邊下班了，那你只好等他們隔天上班再回覆你，但你今天等於一整天沒有辦法做事。

與美東城市例如紐約合作，是最辛苦的，因為工作區間完全不重疊，台北早上九點已經是美東晚上八點，特別是到了夏季有日光節約時間的因素，時差12小時，也就是台北早上九點，是美東晚上九點，除非美東同事加班到晚上十點，才會跟我們有至少一小時的重疊時間。這樣的狀況之下，一般就只好等隔天才能收到回覆，立即性的對話幾乎是不可能的。

那麼當同時間這些不同時區的城市都得要能夠聚在一起同時開會呢？那就更加辛苦了，一種狀況如下：

比較不可能的是巴黎得要凌晨 1 點開到 2 點。但即使提早一個小時，對於孟買來說是早上 5:30 ，太早，而對巴黎來說也還是太晚。
比較好的時間可能會是像下面這樣：

美西早上六點（夏季為早上七點）、孟買晚上七點半、東京晚上十一點。時區差異較大的往往經常要有所犧牲，要嘛是得要相當早起，要嘛是得要工作到相當晚。

個人覺得比較重要的是每個人都必須有這時差的觀念，哪些事情我得要儘早處理儘早回覆，才能在對方已經是加班狀況下即刻收到回覆並確認，我才好進行下一步驟；哪些事情我必須在我下班離開前交辦得清清楚楚，好讓另一個時區的同事可以在他的「當日」把事情做最大程度的完成；哪些事情對方可能得花上 2~3 小時，為了讓我能在下班前收到結果，我應該在哪時就要交辦給他？

對等的，其他城市的同事也得要有相類似的觀念，例如知道你今天必須完成什麼事情，因此下班後從家裡連上公司或是即時通訊，跟你再做簡短的確認之類的；或是早一點上線，好跟你能即時溝通上，問清楚你那有哪些要交辦給他的。

跨時區工作，如果可以把每個環節都緊密銜接好，那麼理想上是可以更加的縮短時差上所造成的時程冗長。

節能 - 從政府單位開始

近幾個月，全球原油售價一直攀升，台灣這由於過去政府政策關係，凍結了油價隨市場機制上漲的行為，但長期的凍結油價上漲，事實上是全民買單，用納稅人的錢去貼補中油的虧損。

今日起油價總算上漲，但從新聞媒體裡看到一些政府官員的呼籲，卻感到有些不對勁。好幾位政府官員，呼籲節能要從全民做起，這是不對的。並不是說不該呼籲全民節約能源，而是喊話的人，自己有沒有身體力行？真正苦哈哈的民眾，你可以從很多小地方看出他們在節約開銷，像是有些機車騎士會在等紅綠燈的路口熄火，有些人開始檢討中午用餐後不要買飲料改喝辦公室的開水，有些開車族開始搭大眾運輸工具或是改騎機車，有些開大車的車主改換小車，有些人家裡冷氣不再開那麼冷......那麼喊話的官員們呢，做到些什麼？上班或開會穿著厚重的西裝還戴個領帶，除非這官員超耐熱，不然室內必然是很強勁的冷氣吹著。只要那麼一個小地方就可以知道官員們有心沒心，要求別人做改變，有沒有感同身受從自己出發？

更晚些時候總算看到新聞播報馬總統響應節能，脫下西裝外套拿下領帶。雖然我並不很喜歡馬先生，但不論他是否作秀，作為一個官員，作為一個全民的總統，至少身體力行是最基本的。

日本的消費真的貴嗎

有時媒體報導日本的物價，或是國人窺探日本的消費，往往忘記把國民所得納入考慮。幾次進出日本幾個城市例如大阪、名古屋、京都等，一直有個感受，就是在日本的消費其實不高，甚至算是很低。舉例來說，在一般的店裡，吃個普通的拉麵，大概 600 元日幣可以搞定，以 1:0.3 的匯率來算，相當於台幣 180 元，看似不便宜（但其實在台灣吃碗拉麵不也要 150 台幣上下？），但若是以平均每人年國民所得來比較（日本約為台灣的三倍），那是不是說 180 元台幣的拉麵其實相當於 60 元而已？

換個說法就是假設以平均收入來說，若是你把整個月的薪水通通拿來買拉麵，可以買幾碗，而日本人的平均收入拿來買拉麵，又可以買幾碗。當然這是種很概略的比較法，所得稅、城鄉差距、住屋租金、水電瓦斯費率等並沒有考慮進去，但至少是一個比較的參考。我也很想了解正確的比較法應該是如何。

還有件我注意到的事，在書店翻了翻汽車雜誌，目前 Toyota Wish 2.0L 最頂級款約 250 萬日圓，換算台幣約是 75 萬台幣！難道說用國民所得的比例再去換算一遍，一台車相當於 25 萬元？

用亞洲萬里通里數兌換日航機票

前陣子用亞洲萬里通里數申請兌換日航機票，真是一波三折。先是在大約4/10從網上送出，等了幾天沒消息，打電話過去，客服說系統裡沒資料，馬上幫我登錄航班，告知我最遲在出發前10天一定要開票。後來在大約4/16打電話過去確認要開票，於是開始漫長的等開票作業，大概在4/24撥電話過去，客服告知票很多，應該快排到了，要我再等候；大約在4/30又再撥電話過去，客服說應該當週會收到電子機票；結果到了5/05已經離出發不到一週，依舊沒收到機票，從網上發查詢，詢問進度，隔天收到香港打來的電話告知票開好啦。

可以讓有意使用里數兌換免費機票的朋友們當一個參考，兌換免費機票最好還是儘早完成開票作業，免得天天心裡七上八下的，生怕最後票沒開出來。

此外，呼應有使用信用卡習慣的朋友們，如果也有興趣出國自助旅行，盡量把消費集中在可以用紅利兌換里數的卡片上，然後不要急著兌換，等紅利快過期再兌換。

以每多少消費金額可兌換紅利點數一點，以及多少紅利點數可以兌換里程一里來看，各卡別有所不同，網上有些資訊可以參考：
刷卡累積里程排名大地震 花旗紅利白金後來居上：http://www.billy.com.tw/finance_article.php?permalink=3760
累積飛行里程(2) ─ 信用卡紅利換里程：http://blog.pixnet.net/SweetMemory99/post/15662533

Ready for Localization?

Is your software or document ready for localization?
It usually is not that simple to localize anything. Giving you "Hello world" and ask you to localized it into several languages might already have some problems to be resolved first before localizing it.

People who speak English may not be aware of that the nouns have gender in several languages. People who wrote technical document in German might not be aware of that other people might not be able to know how to translate it properly due to it's too specific in a particular area.

Imagine if you receive this word "Entropy", how should you translate it properly if there is not enough context to be reference?
"Entropy" is a physic term and widely used in physics, thermodynamic, and some other fancy area such as image processing.
If you are familiar with PhotoShop, then you probably know the term "entropy" appeared there. Translator will need to look up many different areas' dictionaries and might also need to consult some professors in order to translate it properly.

Imagine I now send you "%s Power" and then ask you to translate it into French, the translated result may not be good due to I did not give you enough information. See below examples (translated results from Google Translate):
Maximum Power ==> La puissance d'attaque
Minimum Power ==> Moins d'énergie
Efficient Power ==> Puissance efficace

So, how can you translate it properly if I only give you "%s Power"? If I only give you that, that means it's not ready to be localized. Actually it's an I18N issue that the codes are trying to manipulate strings, which should not happen if you are going to localize it into several languages.

專業的配音品質

過去在作一些專案是必須要將原本英文的語音配錄各國翻譯後的語音，事前的講稿翻譯與審搞自然是必要的，翻譯完成之後的講稿轉給各個國家的錄音室進行錄音，錄音完成之後仍必須有審閱的動作，確保配音員有照著講稿念，以及腔調與一些特定用語的發音方式是正確的（例如「2007年」應該念成「貳零零七年」或是「兩千零七年」必須要統一）。

其中難免因為一些區域性差異或是偶有不慎某些詞語漏了，重新錄音便將會不可避免的。然而，整個語音有相當多的段落，在實際播放時這些段落是一個接著一個的，其中錯了某個部份，第二次錄音可能已經離第一次錄音相隔了好幾天，為了避免因不同時間進行錄製，有時必須要整個聲音稿全部重新錄製。

但過去合作的日本公司，我告知他們為了避免聲音的差異性，請他們整段重錄，該公司交回來的卻只有錯誤的那一個段落，而非整個重新錄製。然而，我前後重複聽了相當多次，卻怎麼也感覺不出來這是不同時間錄製的語音。

這是個很有趣的經驗，專業的配音應該要達到這樣的水準。

愚民政策

十多年前台灣還是個有黨禁、有報禁、電視台節目必須送審、廣播電台不能自由申請設立、連歌曲的歌詞都可能因為很荒謬的理由（例如太過背情）而禁止出版的年代。在那時候，從大眾媒體上看到什麼，大概就信以為真。

猶記小學時學校教育還教導過所謂對岸的人民生活在水深火熱的困境中，說很多窮苦的人因沒飯吃只能野外雜草樹枝亂吃一通，弄的肚子奇異的大之類的。若干年後兩岸交流較為開放後，才聽說原來對岸也曾經這樣教育過說在台灣的人民生活是多麼的困苦。

最近發生軍隊鎮壓西藏的事件，國際社會與媒體的看法普遍支持西藏獨立，斥責中國政府與軍隊暴力與冷血的打壓；但中國官方的說法卻是兩極的另一端，指稱西藏本是中國的一部份，不容切割之類，並說明中國軍隊均是盡量的和平處理，反而是西藏不法份子肆意作亂。

由於中國的媒體不是自由的，前些時候中國政府甚至禁止國外媒體進入西藏，所有消息均只有官方消息。這樣的結果是什麼？在連網際網路都可以管制的國家，於是，看到在對岸的朋友打出的口號是：「抵制法國連鎖超市家樂福」，理由竟是「該公司支持達賴喇嘛」。理由甚至包括「除了資助達賴，法國人還在巴黎火炬傳遞過程中同西藏分離勢力站在一起，因此決不能買法國東西，讓法國人賺錢」。不知道如果新聞自由後，當眾人知道真相之後，是否想法就跟著改觀？

言論自由受到嚴格的管控，這只能說是愚民政策吧。

UN for Taiwan

An old news from BBC:

---

Tuesday, 24 July 2007

UN rejects Taiwan membership bid

Taiwan's bid to join the United Nations for the first time under the name Taiwan, rather than the official title Republic of China, has been rejected.

A UN spokesman said the application had been rejected in line with a 1971 resolution, under which the UN switched recognition from Taiwan to China.

Taiwan, which has tried to join the UN more than 14 times, said it deeply regretted the world body's decision.

China views Taiwan as a breakaway province of the mainland.

Though both have been governed separately since the civil war in 1949, China has vowed to use force if it ever moves towards independence.

The Chinese foreign ministry last week said Taiwan's UN bid was "doomed to failure".

Referendum plans

Taiwanese President Chen Shui-bian submitted a letter of application to the UN Secretary General last week, arguing that Taiwan, as the world's 18th largest economy and seventh largest investor, should not be excluded from the body.

Rejecting the application on Tuesday, the UN cited its adherence to the One China policy agreed under the 1971 resolution, which acknowledges Taiwan is a part of China.



Until 1971, the government in Taipei held the UN seat for China rather than Beijing.

Taiwanese Foreign Ministry spokesman David Wang said the government regretted the UN move, saying it had been blocked "for political reasons".

"The 1971 resolution should be reviewed, as it fails to address the question of the right of representation and participation by the Taiwanese people," he said.

The decision to apply to the UN under the title Taiwan for the first time rather than the Republic of China reflects efforts by the independence-leaning President Chen to stress the island's distinctiveness from mainland China, the BBC's Caroline Gluck in Taipei says.

Despite the setback, the government still plans to push ahead with a referendum on joining the UN alongside presidential and legislation elections next year, despite concerns from Washington and Beijing, our correspondent adds.

Doing L10N Testing, Asking If It's I18N Ready?

Still, some vendors are not aware of the localization industry, or maybe some vendors' employees are not actually familiar with that, but doing the tasks.

I saw some project team members including the PM and the testers are not aware what they are testing. They thought they are doing software L10N testing, but are they? And are they sure the software is I18N ready?

If you are doing L10N testing, please ask yourself first, do you think the software is I18N ready? Are you really very sure what you are asked to perform the testing is part of L10N testing?

Are you spending too much time on checking the functionalities are working fine or not in localized version? And do you discover many functional defects which are reproducible in more than one localized version or even the English version?

Some more thought about Quality-Cost-Delivery

Quality, Cost, and Delivery (Schedule), the three most important elements for a project, become a triangle force form inside a circle.

Ideally the full-balance force form looks like below:

Imagine cost is not an issue, quality is the most important, and the schedule is flexible. Then the force form become below:

But normally client is pushing the deliver date, or client delay the handoff but still want the package to be handed-back at the same time. Which means the delivery date is not negotiable. Then how worse the project could be? Add more resource to ensure the quality? Keep the same resource but loss some part of quality?

工程師在專案開始前該提供什麼協助

最近一個新的專案要開始之時，管理階層指派了一位未曾執行過該類型專案的管理者來負責該專案。幾位熟稔該類型專案的工程師被指派協助分析該專案的預期工作量。

這專案與過去做過的專案類似，因此沒有新專案的不明確性，但它又不是完全與過去專案一模一樣的專案，因此也有些不明元件必須被分析與了解。

工程師該提供什麼資訊？

1. 元件類型總表：詳列各種不同類型的元件，並說明這些元件屬性
2. 各元件的產品總數
3. 某些特殊元件下各個項目所具有的子元件數及總數
4. 各種不同元件的預期產能（平均每人每小時可以產出多少單位的元件）
   
5. 如果時間允許，列出所有特殊元件的問題，以使專案團隊了解所有不確定性以及風險

基本上1~4點一定樣詳盡，第五點通常不宜太早進行，除非該專案已經篤定會進行，並且離專案真正開始還有足夠的時間。

然而，偶爾我會見到某些工程師過於執著於提供第五點的資訊，第1~4的資訊卻未能及時完整的提供，導致專案的明確度不能提早確定，於是專案團隊對於所給定的時間是否合理，應該投入多少設備與人力來進行，遲遲無法有信心的完成分析與規劃配置，想要添購設備或招募人力，也無法及早進行。

被指派協助分析的工程師，應該要有一種體認，了解自己的角色是什麼，了解專案團隊在哪些時刻需要的資訊是什麼。在此刻，工程師就好比業務跑客戶端推銷業務時所搭配的 pre-sales 一般，是來輔助專案團隊及管理者，補足專案管理者在技術細節上的弱點，提供完整且可信的資訊與數據，好讓專案的分析與規劃能夠儘早且正確的被完成。