本地化語彙

每個地區經常都有一些各自的特殊慣用語，在生活習慣上也都有一些小差異。城鄉之間的差異也會造成生活習慣的不同。例如都會區裡的小餐館，常見要客人點完菜先付款，但城郊的小餐館通常你吃完要走再結帳，不急！

本來嘛，一群人在一個區域裡共同生活，本來就會逐漸發展出特有的互動方式，語言文字也是這樣逐漸產生。這個鄉可能大家在廟會時很熱情，隔壁鄉可能是在普渡時擴大慶祝。習慣也是會改變的，雖然現今法規規定車輛應等禮讓行人先行通行過斑馬線，在都會區裡，你行人可以比較放心的走，到了鄉下，你可得更加小心有無車輛。

至於語彙呢？想像我今天一早出門，遇上鄰居，「嘿，早安！」到了早餐店：「老闆，包子一個，米漿一杯，帶走。」到了公司，看見警衛：「早！」中午時，到了麥當勞：「我要一號餐，外帶。」 下午到了 7-Eleven 買咖啡：「中熱拿，不要糖！」傍晚口渴，到飲料店：「綠茶一杯，無糖，去冰。」這裡出現類似的語彙有「早安 / 早」、「帶走 / 外帶」、「不要糖 / 無糖」等等。這些用語都是當地慣用 / 通用的，所以不管你怎麼說，大家都很容易的可以懂。

如果你在路上遇見個路人，問你「請問，要到 101 ，打車過去快還是搭公車？」我告訴你，這路人八成是個大陸人，因為「打車」不是說去敲打車子，是叫一部計程車。在台灣也會用「打」字，例如「打電話」、「打卡」，為什麼你就不會懷疑這是在講要把電話打壞，要把卡片打壞？因為我們習慣那麼講。但我們不講「打車」！

「大口吃遍台灣」的主持人阿松，他在點小吃時，常常會錯用量詞，例如「老闆，那個湯，我要一個，裡面用。」雖然量詞本來就不好學，一個、一碗、一份、一杯、一瓶、一張、一箱、一桶........有時確實講「一個」最快，即使聽起來很奇怪。這就好像用英語你要說 one cup, one meal, one beer, one cloth....基本上大家都懂，你不太需要去執著什麼 one piece of xxxx 之類的。

語彙差異在網路遊戲上也造成一些小困擾，例如最近很熱門的星海爭霸，台灣伺服器上有很多來自中國大陸的玩家，於是就有台灣玩家指出兩邊語彙跟講法的不一樣，例如：

中國大陸用語	台灣用語
造房子	建房子
出2隊機槍兵	生2隊機槍兵
來2隊小狗	來2隊小蟲

從電腦效能瓶頸看問題核心

以前在維護網站的時代，採用 UNIX 系統，就特別針對效能瓶頸多加注意。當時遇上龐大的網站瀏覽需求以及網站服務使用需求，使得網站回應相當慢。老闆當然要求要盡快解決，也問過我是不是要換更好的機器，他再去找經費。

但是錢要花在刀口上，因為我們沒有無限的經費。當時的例子，效能瓶頸可能出現在下面幾個點：

• 網路
• WAN 還是 LAN ？
• 設備：是否既有網路設備不足以應付龐大的 session 或是流量，網卡要換還是 Switch / Router 要換？Layer 2 / Layer 4 Load Balance Switch 有沒有效？
• CPU
• 網站服務回應慢時，是否 CPU 呈現滿載狀況？
• 若 CPU 呈現滿載，是哪些程序佔用多數的 CPU 運算效能？
• 是 httpd 佔用較多效能？
• 還是網站程式佔用較多效能？
• 還是其他相關程式例如資料庫佔用較多效能？
• 硬碟 I/O
• 硬碟 I/O 是否滿載？

諸如此類，每個不同的環節都可能導致前端服務回應緩慢，解決方法也大大迥異。而往往真實狀況混雜著多種不同背景下產生類似的結果，例如當時某些特定族群的用戶，他們的對外網路頻寬本來就不太夠，多人同時使用時，瓶頸在於他們的對外頻寬；然而相近時間點，其他族群的使用者，網路頻寬都不是問題，那時真正的瓶頸在於伺服器端過載。

解法其實也很多元，除了一方面提升網路品質（即便這後來經證實不是主要瓶頸），一方面從硬體下手改善 CPU 運算以及採用更能應付多工運算的伺服器，硬碟也採高轉速、快速存取的高階硬碟陣列，另一方面也要從軟體下手，改進程式實作方式與檔案系統架構，減低不必要的 I/O 存取，善加利用記憶體暫存，還有把伺服器拆分成多個階層，外加採用多組伺服器做 Load Balance 。

其實改動了這麼多可能因素，一般而言，可能反而不太容易看到是否「錢花在刀口上」。不過當時因為多個環節處於先天不良的狀況之下，同時改善是必要的。

生活上的問題也可以試試採用類似方法加以分析，比方說一家餐飲店為什麼生意不好？

• 地點因素？
• 人員因素？
• 硬體設備因素？
• 餐點種類？
• 價格因素？
• 美味因素？
• 大環境因素？

專案管理 - 知道你自己在做什麼

最近聽到某個專案團隊詢問一個問題，問到說我們的問題追蹤系統能不能有個快速提交問題的表單，好讓外面的協力廠商或自由工作者可以比較簡單的在測試階段提交問題；或者說，能不能有匯入功能，例如透過 Excel 表單匯入問題到系統。

我覺得以工程師的角度去思考問題，大概會覺得這些都是功能面的問題，既有的提交問題程序對工程師來講不會很困難也不會很複雜，能不能有快速提交方式，要看系統擴充性，要不就要重新設計該專案的欄位；至於能不能透過 Excel 匯入，也是看系統本身支援與否，要不就要自己寫一個中介程式來加以處理。

雖說系統易用性對於工程師與其他非工程師來講，會有很大的落差。而若是提到產品開發，很多開發團隊對於產品的易用性往往不擅長，不過這已經是另外一個主題，在此不多做著墨。

是不是可以有快速提交表單，這可以藉由定義哪些欄位屬於必填欄位，哪些屬於選填欄位，然後看系統是否支援在建立新的問題記錄時，可以有機會選擇簡單表單或是完整表單，來看是否可行。

透過 Excel 匯入，我覺得我在解答可行或是不可行之前，我倒想提出個疑問。該專案決定使用這套系統作為問題追蹤系統的用意是什麼？一個專案可以選用任何的問題追蹤方式，不管是口頭回報、一個筆記本記錄、一個共用或非共用的 Excel 表單、SharePoint 表單、或是專門的問題追蹤系統，只要適用於多數專案成員，他就會是個不錯的方式或系統。

如果目前專案的狀況是專案團隊龐大、成員散布在多個國家地區以及不同時區、專案交付物龐雜等等，要求所有成員使用集中式的問題追蹤系統，好處除了狀態追蹤容易以外，還包含他可以是即時的，例如當一個問題產生，回報問題後，被指派的問題解決者會立即收到電子郵件通知。系統還可以快速的依照不同需求來篩選問題。

使用 Excel 表單來匯入問題，意味著提交問題的測試人員將會使用 Excel 來記錄問題？而開發人員依舊使用系統來追蹤問題！那麼接踵而來的問題，將會是後續的問題追蹤。試想，當開發人員與測試人員使用兩套不一樣的系統來記錄/追蹤問題，這兩個團隊以及這兩個系統之間如何溝通/同步？
Excel 表單匯入系統確實解決了從測試團隊回報的問題可以在系統內轉發給個別的開發人員，但是緊接著當問題逐一解決後，勢必要將這些更新的進度在匯出轉成 Excel 然後發給測試人員。然而，狀況不單這麼單純，在過程中還會發生許多往返，例如某問題描述不清，開發人員得要轉回給測試人員詢問更多細節，或是測試人員驗證問題時發現問題仍舊存在等等。這之間將會有很多的溝通會變得相當複雜。

所以，跳出來想一下，當初這專案並沒有使用 Excel 表單來作問題的追蹤，而採用問題追蹤系統，是為什麼？是希望藉由系統來輔助可能的龐雜溝通與追蹤問題？還是其實本來就是個很小的案子，要殺雞卻用了牛刀？

---

另一個故事是某專案使用了 SVN ，要求所有專案團隊都必須使用 SVN 來工作，包含收件與交件。單一一個可獨立的元件，在專案初期會由團隊 A 主要負責對應階段的工作，到了中後期，團隊 B 便會開始加入來進行其他的加工工程；期間團隊 A 將可能會需要對元近進行問題修正，團隊 B 得針對修正的部份也對應修正在相關的檔案上面。

換個角度來看， SVN 在專案裡相當於是個協同工作平台，好比在 File Server 上面建立一個共用工作目錄一樣，不同團隊都相當於在同一個工作目錄下工作；此外， SVN 本身還具有版本控管機制，每個專案成員完成一個修改後都必須將該修改的版本提交到伺服器，建立一個版本 (revision) 。

實際上各個團隊分散在世界各地，使用 SVN 其實也多少解決了一般 File Server 必須是在區網內同網段的限制。

然而，是不是所有專案成員都了解使用 SVN 的用意？當發現某些檔案怎麼用 FTP 甚至 email 夾檔在交換時，我就覺得不妙了！某階段的檔案，居然看到專案經理藉由 FTP 把檔案發給某團隊，然後要求該團隊也用 FTP 交回來；而該專案經理知道後端主要的開發團隊依舊使用 SVN ，所以專案經理會再把檔案提交到 SVN 。

有沒有覺得跟上面要求把 Excel 表單匯入問題追蹤系統的狀況很像？

專案經理究竟有沒有了解選用的系統的用意以及好處在哪？其實不是一定要使用哪一套系統，就好像切麵包、切水果、切肌肉、切牛肉，你說我通通用同一把刀子可不可以？當然可以！但是我們會從經驗學到，用切蘋果的小水果刀拿來切西瓜，真的很難切，所以我們發明了刀面很長的西瓜刀；同樣的，你說我拿西瓜刀來切蘋果可不可以？當然可以，只是不順手！

專案開始時，得視專案大小、專案交付物的複雜度、團隊數量與團隊成員數量、還有流程複雜度，來選用適合的流程與工具，不是盲目的選了一個，到底適不適用不知道！這就好比你已經買了一把西瓜刀要切西瓜，你究竟知不知道為什麼你買了西瓜刀？或是你究竟知不知道你要切的是西瓜，你究竟知不知道你要切什麼？結果實際要切西瓜，然後你卻又要求人家給你一把小水果刀，原因只是某專案成員小水果刀用很熟，西瓜刀不善用？

知道你自己在做什麼很重要，我一直對於那種搞不清楚狀況的專案經理很感冒。專案經理不是說你只要確保專案照進度走、成本控制在預算內、品質有合乎標準，這樣就行了。實際狀況是在專案進行中就是會有一堆意外，計畫趕不上變化，專案經理就是要扮演很吃重的溝通角色，你若身為一個專案經理，當有人跟你詢問可不可以用小水果刀這樣的問題，而在專案開始時批核採用西瓜刀的你，如果不知道這個決策的背後因素，我相信這專案經理只會花更多時間在溝通。

專案經理是不可能懂每一個專業，所以必要時要請教專家，但不是說專案經理就什麼專業都不用懂，因為你不可能每個小決策都詢問專家，除非你正在進行一個很龐大的專案，而你們另外有個 PMO ！

領土與統治權的個人看法

也許會是個很有爭議性的主題，不過至少說說我的想法。我也不是什麼有學問的學者，只要是理性的，我倒是樂於聽到不同的聲音。

我老是在想，中華人民共和國老是對全世界稱台灣是「中國」不可分割的領土之一，我到好奇這說法以什麼為本？有史以來，或者說從中國共產黨在中國建立中華人民共和國以來，這個政權從未統治過台灣。回顧台灣在那個年代以前的歷史，先是大清政權將台灣割讓給日本，從此喪失對台灣的主權。接著大清政權被孫中山為首的革命軍推翻，並成立新的中華民國政府。而直到二次大戰日本戰敗以前，中華民國這個政權也從未擁有過台灣的主權！

一些學者或是政治家認為台灣的主權是否歸屬中華民國，本身就已經是個問題，更不用提中華人民共和國。以我來看，當一個領地在過去已然割讓給另一個政權，即便割讓時是基於怎樣不平等的處境下，過去各種族各政權恃強凌弱似乎勢天經地義，除非有更強大的正義的一方出面「主持公道」！然而，當唯一有資格要回失物的這個原始政權（大清）都已然消失，後繼者（中華民國）也未追溯主權，再更後繼者（中華人民共和國）又哪有資格追溯！再者，當大清政府把台灣割讓出去那一刻，他就已然喪失主權。你能想像你祖父把一塊土地讓給別人，然後現在你卻想要去追討回來說那塊土地是你的嗎？

台灣會在二次大戰日本戰敗後被迫歸還（給誰？），個人鄙見認為僅僅是當時美國欲控制太平洋勢力，或者講好聽是要避免共產勢力大幅擴張，因此藉二次大戰，美軍分別在包含日本、韓國、台灣、菲律賓等地都設有軍事基地。

台灣以及澎湖列島在西太平洋確實是個很關鍵的區域，正好日本戰敗，盟軍（或說美軍？）要求日本放棄台灣主權，這身為戰敗國的日本能說不嗎？這就像甲午戰爭大清戰敗，不得已得要割讓台灣是一樣的道理。

我猜也許中共政權認為其為中華民國的後繼合法政權，因此認為當時盟軍同意將台灣歸為「中國」管轄，即便當時是指中華民國，但既然中共認為其為後繼的唯一合法「中國」政權，於是認為台灣應歸其所有？

我基本上不是學者，目前也沒多大興趣逐一考究個中緣由。但想想看，這像不像這樣的故事，祖父做生意失利，把名店讓給某甲，到了老爸那一代，家族的好友某乙因商場得意，恰逢某甲世家商場失利，所以把那名店低價買了回來，讓給了老爸。結果叔叔說祖父臨終前什麼都沒交代，只交代他未來有一天要把那店拿回來，所以就大聲嚷嚷說那個店該歸他所有！

故事當然不一樣，但是一樣可笑。

有興趣可以搜尋「台灣前途未定論」，或是「台灣地位未定論」。可以看到更多學者精闢的見論。

看倌若要辯論，請移駕那些學者的部落格或是論壇。

票選的方式與結果

想要利用票選來選出特定目的的目標物，例如說想要藉由委員會票選出年度傑出青年，這裡頭包含了目的（緣由）、手段、與結果。手段是工具，緣由是入物，結果是產出物。

我們都知道，工欲善其事必先利其器，現在想要畫一幅畫，你用炭筆、粉筆、原子筆、水彩筆，畫出來的結果都不一樣，如果你拿了炭筆卻想畫出印象派畫作，那恐怕有點困難。

票選也是這樣，票選的工具有很多，例如開放性投票（任何符合資格的標的物都可成為被票選目標、以及投票成員沒有限制，只要符合資格，例如會員，都可以投票）、封閉性投票（標的物是經過特定條件篩選或初步評選，符合資格後才進入候選資格，或是投票成員為評選委員等），加權性投票，簡易式投票等等。

像 SourceForge 近年來每年度會舉辦最佳專案票選，他是開放式票選，只要你是會員，你就可以投票，是不是任何專案都可以被投票我倒是有點忘了，印象中是。此外，票選還分很多個類別，例如最實用工具、最棒的設計、最有創意的設計等等。

在上面的專案，有些也許是很通俗的工具，好比說 MP3 播放器算是很通俗很廣泛被使用的工具，那麼某個專案也許會獲得相當多的選票，因為他有相當多的用戶會投票給他。

另外，有些專案是設計給特殊領域，他也許相當專門專業，但不是很易用，只有業界人士熟稔，但某個設計很棒的專案也許會被票選出來為最專業的設計專案。

想要藉由票選來選出特定指標目的時，真的要想清楚自己想要選的是什麼，以及需不需要有多個面向多個不同的獎項；要開放投票或是委員會評選，也是票選工具的選擇的關鍵要素之一。

一般而言，當開放所有人都可以投票時，這些人很難可以依照某特定專業評選標準來去做評選，例如票選出最佳烹調，我們不太可能請一百位評選，針對料理的食材類型選用、新鮮度、口感、成本、整體烹調設計等等來分別給分，若需要這樣評分，不如找專業評選委員。因此，一般讓所有人或是一些群眾來進行票選，其結果比較會偏向人氣、通俗。同樣的烹調，讓評選委員去評選出來最佳烹調，與群眾票選的結果，不一定一樣。群眾也許看得是外觀，吃口感，但不懂這烹調其實難或是簡單，但評選委員則是依照專業角度來去做評選，選出來的絕對是上乘作品，但不見得能被廣大群眾所接受，或不見得是最佳人氣。

還有，當想要開放所有人來做投票時，如果所謂的所有人其實是一群很小的個體，像是要選出最佳社員這種，也許就不適合採用開放性投票。因為，比方一個具有 50 個會員的社團，開放讓大家自由票選最佳社員，結果可能是有近半數的社員被票選，那麼也許有人就以 5 票當選最佳社員。