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

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

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

一般來說，產品的易用性 (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 打敗。

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

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

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

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

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