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

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

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

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

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

工作上的危機管理

危機管理，其實在日常生活當中都會發生，有些事情相當小，談不上什麼危機，就只是單純的下決策，例如本來你想拿剪刀剪開某商品的外包裝，臨時找不到，於是用刀片替代；稍微大一點的事情，例如家中用了近十年的熱水器突然在半夜壞了，天氣已涼，一家老小不太可能冒著 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.