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

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

如何清楚的陳述問題

如果是在專門的測試專案裡工作，多半會學到一些測試方法與規範。這裡先保留不提工作上的測試相關工作。先來談平常生活中所遇到的問題。

試想，如果說你上週買了一台冷氣，用了不到一週，今天他突然不會運轉了，於是你撥電話給該公司客服，你會怎麼陳述問題？
「我的冷氣不會動了！」
是這樣的嗎？

其實有這樣客服與顧客之間的對話實際發生過：
「我的電視不能看了，我上週才剛買的！」顧客反應這麼說著
『昨天還能看嗎？』客服問道
「昨天還能看，今天就突然不能看了」
『可以說明一下是怎樣不能看嗎？』
「就我拿遙控器對著電視按電源鍵，但電視就沒反應啊！」
『可以確認一下遙控器是不是還有電嗎？或是你換一組新的電池看看，按遙控器時看上面的發送燈號有沒有亮。』
「我試過了，換新電池後，按遙控器時確認發送燈有亮，但電視就是沒反應！」
『不知道遙控器會不會摔壞了，這樣好了，你走到電視前，從電視的面板上按電源鍵看看！』
「等我一下喔....還是沒反應耶！」
『嗯....可以麻煩你看一下電視的插座有插上嗎？』
「我看看喔....啊沒有插上....」

類似這樣的交談流程會分常冗長，有些公司就會開始利用一些方法教導顧客先做基本的障礙排除，然後在顧客找客服支援前，會再適度的教導顧客要準備哪些資料，例如在產品說明書上就印好一個空白表單，讓顧客準備好問題的背景資訊，以便跟客服接洽時可以較有條理的反應問題。
以上面的例子，在說明書上的基本障礙排除就會先列上諸多檢查項目，諸如檢查電源插座、遙控器、電池等等。針對問題的描述則會請顧客描述故障的種類與細節，例如是開啟電源畫面完全是黑的，還是呈現雪花狀畫面。如果是呈現雪花狀畫面，是不是每個頻道都是如此，有無事先詢問有線電視業者訊號是否正常等等。

在開放的論壇上，也時常有網友詢問問題，類似那種「我的車子突然發不動了」、「我玩遊戲時感覺很卡」、「我的手機執行xx程式就會當掉」等等，千百種的問題，但很常見沒頭沒尾就冒出來一個問題，即使其他網友要協助也完全找不到下手處。

回過頭來看測試領域，通常在規範撰寫軟體錯誤報告時，會要求類似如下的資訊

作業系統版本與語言：
安裝的軟體清單與版本：
問題的重製步驟：
1.
2.
3.

產生的錯誤結果描述：
預期的正確結果描述：

其他附註：

但這是錯誤報告，如果現在是要與其他人溝通一個問題呢？其實我覺得原則是一樣的，當要反應一個問題，事先先要做背景的描述，然後針對問題儘可能的加以剖析，清楚的描述所發現的問題現象，以及敘述預期的正常結果。

好比說如果我想要對台北市政府反應交通問題，那麼也許我可以這麼說：

基隆路與忠孝東路交叉口，在路口西東南側，也就是沿基隆路往北然後右轉東向的忠孝東路這個方向，在上午九點半至十點之間，通常因為已過交通尖峰期，交通警察多半已在九點半之前便已撤離。因此這段時間便開始有很多計程車司機開始違規在路口紅線上，以及公車停靠區域，違規排班，導致公車進站、出站困難，進而造成交通堵塞。建議交警能夠加強此區段的違規取締，以改善交通紊亂狀況。

背景資訊是路段地點，重製步驟是地點加上時間，發現的問題是違規排班，預期的正常結果是加強取締並使交通紊亂獲得改善。

我發現有時有些人在溝通一個問題時，問題被轉了很多手，然後已我旁觀者來看我覺得問題已經失焦了，大概因為在轉手時，收到問題的人往往只花很短的時間看「重點」，然後又轉給下一個人，經常只附帶「客戶反應這個問題，麻煩你看一下」這類的訊息，這時這個信件本身已經很冗長了，如果加上處理人員沒有認真追蹤問題，或是反應問題時沒有提供足夠資訊，往往處理問題的人因為無法重製問題而草率結案。但問題並沒有解決，於是問題又再度透過層層關卡反應，到了最後處理的人員，這時可能已經過了一個月，他大概只有些許的印象，覺得這麼問題又來了，上次不是試過沒問題嗎，然後簡單試一下發現還是不能重製問題，又打了回票。

這樣的溝通就會顯得相當的浪費時間。我通常會建議當發現問題逐漸失焦時，最好是把問題的前因後果等細節重新描述一次，不花多少時間，卻可能讓問題可以快速回到焦點上並在短時間內獲得解決。

一個重點是，通常問題在被轉送時，訊息會逐步被短縮，所以有必要的話，最好每遇上一個新的處理人員，就跟他再描述一次問題。

學會 SMART

我們常希望工作夥伴們夠 Smart ，最好能舉一反三等等，但是怎樣叫做做事聰明一點，實在太模糊了。那麼來學學 SMART 吧。
所謂的 SMART 即是：

• Specific
• Measurable
• Attainable
• Realistic
• Timely

Specific
舉例來說，小朋友在被詢問將來想變成怎樣的人時，常會說「我將來想要變成很有錢」，其實對小朋友來說算是夠明確認，但我們學到更多知識後，會學到這不是個很明確的說法，好比說「將來」是指哪時？一分鐘以後也是將來，一年後或是十年後都是將來；有一百萬算不算很有錢？還是要有一億才算是很有錢？所以較明確的來說，例如「我希望在工作滿五年之前，我可以存到一百萬」。
通常可以從下面幾點來省視自己的陳述夠不夠明確：

• Who: Who is involved?
• What: What do I want to accomplish?
• Where: Identify a location.
• When: Establish a time frame.
• Which: Identify requirements and constraints.
• Why: Specific reasons, purpose or benefits of accomplishing the goal.

Measurable
上面的例子其實已經點到 Measurable 了，也就是指出「一百萬」，這部僅是明確的數字，並且他也是可以被量測的。可量測，通常比較容易，例如「我希望能夠更有錢」，那麼只要先計算出原先自己有多少錢，那麼下次在去比較就知道目的有沒有達到。
但有時我們不太容易讓自己的陳述或是希望變得容易量測（評估），例如「我希望生活能夠過的更好」，這例子在評斷是否可以量測之前，其實這陳述本身就不夠明確。不過還是可以嘗試用一些量化的手法來加以分析評估，例如：

• 原本每個月的收入有多少
• 原本每個月的支出有多少
• 有哪些期望性的開銷是暫時被延遲的（非必要性開銷）
• 平均每天的工作時間
• 平均每週的閒暇時間

技巧其實就是設法去量化，然後看量化數據的改變是否滿足期望。主要是因為可量化後較容易被客觀的評估。
有時候這還是很難實現，特別是關連不顯著時。

Attainable
Attainable 被解釋為「可達成的」，舉例來說，如果我現在體重 100 公斤，我希望以每個月減 2 公斤的速度減到 80 公斤，也就是預計花 10 個月總共減 20 公斤，這樣的計畫看起來便是可以達成的目標。計畫是否是可達成的，一個技巧是把更細節的步驟名列出來，而不是只有簡單的「我的短期目標是升到資深工程師」。

Realistic
目標是不是夠實際？這比較不是客觀的看法，比較是主觀的省思。你說「我希望今年可以賺一百萬」，如果現在你根本沒工作，看似這目標很不實際，但如果你其實有個計畫，例如你打算加盟某連鎖業，那麼也許這目標就很實際，很有可能達的到。
關鍵在於自我是否確切希望達成，並且也是能力所及。
如果一個小學沒畢業的 30 歲的人說他希望考上律師，只有他自己知道這目標實際與否。

Timely
一個目標必須要有明確的時間點，例如十年內，或是下個月的 1 號。


SMART 是個不錯的思考準則，用以輔助讓自己在訂定計畫時能夠更為明確、有計畫性的、實際的、易評估/量測的，在計畫開始之後也較容易隨時審視進度與達成率。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==========

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

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

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

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

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

方法論

3/3/2006

你在拖地時, 有沒有曾經想過, 為什麼你要先把地掃乾淨, 再拖? 如果地板實在太髒, 你每拖一小區域, 就要洗一下拖把. 真要拖很乾淨, 大概要拖二至三次, 才會很乾淨?

這問題很簡單, 但是, 如果是一個從來沒做過打掃工作的人, 他只看過你拖地, 你現在麻煩他幫你拖地, 或許他直接拿起拖把, 就開始拖地.

拖地前, 要先把地掃乾淨, 這對多數的人來說, 已經是生活常識了. 但是, 其實他也是一個方法.

以往, 我在擦家裡一樓那排落地窗時, 先撣灰塵, 再開始擦, 擦沒幾片玻璃, 抹布已經很髒了, 抹布得換一條. 後來, 我注意到大樓那種玻璃維幕的玻璃清洗功, 他們玻璃是用洗的, 洗過, 擦乾, 就好. 我也學下來, 家裡的落地窗, 外頭那一面, 用水洗, 再擦乾, 省下的時間約略有三四倍以上. 這是使用不同的方法來達成同一件目標.

法方, 是人去創造的, 有沒有效率的方法, 也有很有效率的方法. 在沒有想到新方法, 也沒有管道找到有效率的方法前, 我們常常是土法煉鋼, 用傳統的方式去達成我們想要達到的目標. 但是人類社群的知識經驗累積, 以及資訊傳達的便利, 全球幾十億的人口, 古今中外的人, 累積出來的經驗跟方法, 其實可以大大改進傳統的老方法所耗費的時間跟人力.

不過, 我不是很能理解的, 是為什麼當有很多有經驗的人提出的方法在那邊, 可是, 我們還是會選擇用我們自己認為比較喜愛的方法去試著達成我們的目標? 例如, 你知道有機器可以協助你打鐵練鋼, 可是你卻偏偏還是選擇自己手工去打鐵, 難道只為了享受揮灑汗水的快感?

有方法被提出, 也有很多人是著去驗證,並提出改進, 後進應該是要學著去利用這些方法, 而不是仍執著於既有的偏好. 您說是不?