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

以前在維護網站的時代，採用 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 票當選最佳社員。

產品的易用性通常決定了他的成敗

一般來說，產品的易用性 (usability) 決定了他的成敗。排除特殊專門用途或是特殊冷門軟體不談，設計給一般廣大而普遍的使用者使用的軟體，如果在易用性上面表現不好，那麼這個軟體至少不會太成功。

程式設計師往往僅專注於達成軟體的功能設計需求，並確保該能運作正常，但多數的程式設計師往往不懂該產品。例如設計財會倉儲管理系統的程式設計師很少會懂財會或是倉儲，設計人事管理的設計師也不懂人事管理，因為這些領域往往過於專業，即使在團隊裡有系統設計師，有架構設計師，這兩個角色或多或少會在程式開發以及目標用戶之間扮演一些溝通的角色，但多半這兩個角色也不可能對軟體的目標領域有深入了解。

某一定程度的軟體的易用性，認真或是稍加投入的程式設計師還是可以達成一定程度的改善。舉例來說，當某個功能操作環節中有一個步驟要從清單中選取一個使用者自訂的項目類別，這個清單欄位被設計成10行高並且當選項超過10個時會出現垂直捲軸。稍加投入的設計師也許會發覺這個選項清單在多數的使用者一定時間的使用之後，選項多達百位數應該很常見，於是一定程度的增進快速選到想要的選項是必要的。例如在點選清單內任一選項後，快速輸入所想要選的選項值的前幾個字幕將會自動選取到符合的項目上，就類似檔案總管具備的特性那般。

然而，類似這種操作細節往往不會在功能設計需求上加以規範或多所著墨。系統設計師或是架構工程師往往也不管這些細節！如果不是開發團隊的主管乃至大老闆重視產品的易用性，有時即便某個程式設計師具有產品易用性的敏感度，大概也會因為專案時程的壓力而被迫妥協。

從另外的角度來看，程式開發團隊往往不容易發現產品的易用性相當糟糕。程式開發過程中，開發團隊確實會對程式進行單元測試與基本的功能整合測試，但多半是喂給程式很簡單的資料，或是經過特殊設計的資料，只為驗證經過程式運作後會得出預期的結果。例如錄製一個聲音檔，將這個聲音檔交給程式，程式自動將其轉檔成 MP3 格式，在轉檔前或是之後，為這 MP3 檔案加上標籤與自訂類別與評分，然後測試在播放界面打入類別字串，確認該檔案能被正確搜尋出來，然後結束。

很多時候產品易用性的意見反餽往往是品保測試部門提出較多，因為品保部門相較於開發部門而言較貼近使用者的角度，在產品測試時也較會由使用者的角度出發，來測試與驗證這個產品。如果測試時間充裕，品保部門多會建立較多且具有多元性的的資料，然後加以測試。其原意本非針對易用性進行測試，而是為了避免有任何疏漏未能測試到，但往往也同時發現易用性的問題。

嚴格來說，品保部門也不是合適的產品易用性檢驗單位。事實上易用性本身也是門學問，也有專家學者整理出來意用性的特質與特性。比方我們來想想，什麼叫做易用性？ Donald A. Norman 提出產品的易用應具備：Easy to discover, easy to learn, easy to use。

我們可以回想看看自己周遭的各種產品，它們的易用性如何，即便我們已經很熟悉的產品，例如自己的手機或是家裡的飲水機。想想看你天天搭乘的捷運，模擬你第一次搭乘，當你在捷運站附近時，捷運站入口是不是容易辨識？走進捷運站後，買票怎麼買，找售票口還是找售票機？在售票機前，如果你完全不看上面的文字，只看符號，是否容易懂得怎樣購票？買到票了，前往驗票閘門，你是否容易知道怎樣驗票？（特別是台北捷運單程票改為硬幣式，這在國外也很少見）通過驗票口後，月台方向指示是否清楚？到了月台後，欲搭乘的車輛在那個方向的月台，是否容易辨識？

當模擬自己是個對該產品極度不熟也不具備相關背景知識時，就越容易發現該產品的易用性做的好不好。這就好比請個鄉下人初次進都市搭乘捷運那般，或是找個外國人首次訪台。當然經過一定的訓練，或是對易用性具備足夠的敏感度，就越不需要刻意做情境模擬，就能發現易用性的問題。

最後，產品的易用性為什麼決定了它的成敗？試想，即使你的產品沒有功能瑕疵，而且你的產品也大賣，但是使用者緊接著發現產品不易使用，即使看了說明書依舊感到迷惑，那麼就會有越來越多的使用者撥電話到你的公司詢問產品問題，你的員工或是客服人員就會忙著解答這些使用上的問題，並且問題的數量會隨著你產品賣越多而跟著增長。我想沒有人會認為需要為了使用 PDA 手機而報名一堂需要繳費的課程來學習它，這並不是像學一套複雜的 PhotoShop 一樣。如果你的產品目標是廣泛且龐大的使用者，那麼它就是要具備足夠的易用性。此外，如果一個產品的易用性太低，好比說你有很多很強大的功能，但是藏的很深，很多人不知道怎麼用，那麼大概多數的人會因為根本沒發覺那些功能而覺得你的產品並沒想像中那麼好，價格功能比偏低，這些顧客會逐漸的流失。

iPhone 為什麼賣的那麼好，裡頭很大的因素之一在於它的易用。我相信有相當比例的人買了 iPhone 回來，說明書根本沒打開過，或是僅翻了幾頁，從此就沒再見過說明書了。 HTC 為什麼賣的比其他 PDA 手機來的好，因為 HTC 也客製操作界面，大大改善 PDA 手機的操作方式與習慣，大幅提升產品的易用性。其他未經客製的 Windows Mobile 手機就失敗在於這微軟原廠內建的界面並不符合手機群 "Smart" 的期望，因為它原先的設計是給 PDA 用的，拿著觸控筆想像你在操作一台微型電腦，設計的角度並非從 "Smart Phone" 出發，因此很輕易的就被後起的 iPhone 與 Android 打敗。