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

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

未完全進入狀況的溝通窗口

通常當一個專案從進行的前期到後期，對外的窗口通常有兩個，一個是 Sales ，一個是 Project Manager 。前者理論上在 Project Initial 階段，以及付款階段（視合約狀況，看是先付款或是後付款）會出現，後者在 Project Execution 跟 Project Closing 階段會出現。

當專案類型很多樣性時，這些人不見得足以深入了解每個專案的細節，畢竟專業分工之下，各有專精與專職，於是 Sales 專注於推銷公司的服務、對外的形象、收付款的溝通等；PM 專注於專案團隊的管理，包含時程、成本、品質、溝通等。

通常 PM 是對外溝通的窗口，因此 PM 的一個重要特質包含了溝通能力必須很不錯，這包含了口頭上與電子郵件往來，端視專案形態與客戶傾向。

不過時常有個狀況會發生，就是這些溝通窗口未能完全進入狀況。通常團隊成員會定期或是不定期的向 PM 會報專案狀況，包含一些突發狀況或是客戶反應的一些問題的因素，匯報包含了口頭上的陳述，或是文字上的（e-mail）。團隊成員不見的善於溝通，也就是說用字譴詞不見得妥當，特別是對客戶的溝通時，包含用語夠不夠精準、夠不夠婉轉等。於是 PM 往往必須要在匯集成員的匯報之後加以重新整理、條列，然後向客戶表達。

這裡「重新整理」、「條列」就可能出了問題。例如說工程師匯報了「客戶給的程式是 64-bit 的版本，我們需要 32-bit 的版本，因為 64-bit 的程式在我們既有的 Virtual PC 上不能安裝，這是因為 Virtual PC 目前只支援安裝 32-bit 的作業系統」，而 PM 對客戶講的可能是「您先前所提供的程式，我們工程師反應無法安裝在我們既有的環境上，可否請您提供 32-bit 的版本」。顯然的 PM 刪掉了某些訊息，也許是 PM 覺得不需要講的那麼詳細，也許是 PM 只聽懂「不能安裝、需要 32-bit」。客戶的反應也許很簡單的就提供了 32-bit 版本的程式，但客戶也可能回答說「我的工程師告訴我不應該無法安裝，實際上你只要找一台 Vista 64-bit 版本就可以安裝了」。那麼這樣一來一往的溝通不知道要耗掉多少時間，特別是跨時區合作時，一天過一天，然後又再一天又一天。

為什麼 PM 不把工程師講的完整轉述？也許 PM 覺得客戶應該懂，因此只要抓出關鍵的資訊跟客戶溝通即可，那麼客戶為什麼不了解為什麼問題所在（這裡假設使用 Virtual PC 為環境是客戶所要求的，或是雙方溝通過後的結果），也許客戶太忙，也許客戶自己也沒有完全進入狀況，要知道有時客戶本身不是個專業的 PM ，或者不是技術背景出身，總之客戶的窗口即便他在專案里的角色算是個 PM ，但種種因素導致他可能未能及時了解我們的訊息真正的意義。

如果說 PM 的溝通出了問題，有可能導致最後要求專案團隊改用實體機器安裝 64-bit Vista 然後安裝客戶提供的 64-bit 程式。這也不是不可行的辦法，但如果一開始溝通順利，客戶就提供了 32-bit 版本的程式，那麼是不是可以省卻很多麻煩？

有時候 PM 對外聯繫時不會把專案成員放在 CC 裡，考量有很多種，也許避免內部成員曝光，也許避免專案成員接受太多不必要的資訊，也許有時信件往來裡會有保密資訊，總總考量使得 PM 不見得會在與客戶的溝通往來裡把團隊成員放在 CC 裡。

那麼如何改善這種溝通不良的窘境？

1. 建議 PM 當要對客戶溝通比較技術細節的內容時，可以在寄出信件前請團隊成員協助檢閱，查看有無錯誤或是疏漏
2. 如果溝通內容無涉及需保密的資訊，建議何妨將團隊成員放在 CC 裡
3. 團隊成員盡量以 PM 較能懂得方式陳述或表達，避免溝通的障礙發生（團隊成員也需要學習溝通技巧）
   

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

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

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

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

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

Some more thought about Quality-Cost-Delivery

Quality, Cost, and Delivery (Schedule), the three most important elements for a project, become a triangle force form inside a circle.

Ideally the full-balance force form looks like below:

Imagine cost is not an issue, quality is the most important, and the schedule is flexible. Then the force form become below:

But normally client is pushing the deliver date, or client delay the handoff but still want the package to be handed-back at the same time. Which means the delivery date is not negotiable. Then how worse the project could be? Add more resource to ensure the quality? Keep the same resource but loss some part of quality?

工程師在專案開始前該提供什麼協助

最近一個新的專案要開始之時，管理階層指派了一位未曾執行過該類型專案的管理者來負責該專案。幾位熟稔該類型專案的工程師被指派協助分析該專案的預期工作量。

這專案與過去做過的專案類似，因此沒有新專案的不明確性，但它又不是完全與過去專案一模一樣的專案，因此也有些不明元件必須被分析與了解。

工程師該提供什麼資訊？

1. 元件類型總表：詳列各種不同類型的元件，並說明這些元件屬性
2. 各元件的產品總數
3. 某些特殊元件下各個項目所具有的子元件數及總數
4. 各種不同元件的預期產能（平均每人每小時可以產出多少單位的元件）
   
5. 如果時間允許，列出所有特殊元件的問題，以使專案團隊了解所有不確定性以及風險

基本上1~4點一定樣詳盡，第五點通常不宜太早進行，除非該專案已經篤定會進行，並且離專案真正開始還有足夠的時間。

然而，偶爾我會見到某些工程師過於執著於提供第五點的資訊，第1~4的資訊卻未能及時完整的提供，導致專案的明確度不能提早確定，於是專案團隊對於所給定的時間是否合理，應該投入多少設備與人力來進行，遲遲無法有信心的完成分析與規劃配置，想要添購設備或招募人力，也無法及早進行。

被指派協助分析的工程師，應該要有一種體認，了解自己的角色是什麼，了解專案團隊在哪些時刻需要的資訊是什麼。在此刻，工程師就好比業務跑客戶端推銷業務時所搭配的 pre-sales 一般，是來輔助專案團隊及管理者，補足專案管理者在技術細節上的弱點，提供完整且可信的資訊與數據，好讓專案的分析與規劃能夠儘早且正確的被完成。

何謂專案

有些人對於專案的定義不是很清楚，甚至容易與常態性的管理事物混淆在一起。簡單的說，專案是指在一定時間內，為了完成特定目標的組織活動。好比說一家做進出口貿易的中小企業，如果老闆擬定了一個目標，要業務與相關行銷人員針對年終至隔年農曆過年期間進行某一產品的進口促銷方案，這就可以被當作一個專案來看待。

因此，專案包含了以下的幾個特性：

1. 明確的目標
2. 特定的時間（明確的開始與結束時間）
3. 非重複性（非日常例行姓事務）
4. 特定的人員
   

視應用的領域不同，專案的複雜度與組成要素也會有不同。小至學校裏的各班可自由發揮的校慶園遊會，雖比較像個活動事件，但也可用專案的角度來加以管理；大至一項新產品的開發至成品產出，或是一棟摩天大樓的規劃至完工，都可用專案管理的方式加以有效率的管控。

哪些事務不屬於專案管理的範疇？例行性事務，例如公司總務或行政人員每日每日的例行性事務，發放薪水、三節禮金、勞健保管理等；系統管理員每日的系統維運工作；學校老師年覆一年的教學工作等。簡言之，屬於重複的例行性工作事務並不屬於專案管理的範疇。

如果看一個產品的某一版本，他的規劃直至產出的過程是一個專案；但如果把焦點放在這個產品線是會持續延續下去，例如 2.0 版開發將至最後完工階段，便會開始研發下一個 3.0 的新版，那麼這個產品線本身應屬於一個計畫（Program）而不是專案。

Triangle of project QCD

When a project is running, what will you do to balance the triangle of QCD?
Q=Quality, C=Cost, and D=Delivery

We all know we wanna make more money from a project. But if the quality is too bad, you probably won't get any money.

When the project is phasing into another stage, you probably find out you'd better to add some more human resources or hardware resources. But it will bring more cost.

If you can not add more resource, but also need to remain the higher quality, then it might bring some impacts on the delivery date.


For a project management, there are many phases and tasks need to be take care. But the most simple way is to balance the QCD triangle.

What do you think about that?

建設性的言論

在跟客戶的協同合作開發軟體的過程當中，因為團隊成員的疏失，造成客戶方的不便，甚至是客戶的原定時程受到影響，身為廠商(vendor)的一方，認錯是必要的。但是除了認錯之外，提供建設性的言論更是相對的重要。

單純的認錯道歉與補救，對於團隊形象與公司形象並沒有幫助。認錯、道歉、補救，只是最基本應該要做到的，在此之外，適度的檢討本身團隊的疏失在哪，並告訴 客戶我們有注意到這些問題，希望能夠提供一些改善方案，或是找出團隊出錯的癥結所在，跟客戶一同討論，看是否有改善空間，類似這樣比較具有建設性的言論， 是比較妥當的做法。

當客戶方有錯，可是自己這方也有錯時呢？例如問題出在於客戶未給予正確版本，或是未充分告知異動；但是自己的團隊並未很嚴謹的去檢視每一項工作，以致於未 及早發現客戶的疏失，像這樣的狀況，正所謂「嚴以律己」。身為廠商，雖不必要一味的矮化、委屈自己，但是更不能隨意的指責客戶本身的疏失，必須用更高的標 準去要求自己的團隊。正因為自己應當是要很嚴謹、很專業，客戶才會放心跟著自己協同合作來開發同一套軟體。

類似這樣的狀況，更是要提供具有建設性的言論，及早告知客戶，我們發現他們哪些地方有些疏忽，導致我們這邊哪些工作受到影響，以及時程受到影響；接著檢討 我們未能及時發現這樣的狀況，然後認真的提供一些可行的改善方案，以及可能的影響，甚至分析各個方案的優劣，提供給客戶作為參考，並請他們做出決定。

怎麼樣準確評估團隊效率

如果想要精確的評估團隊的效率，我想，正確的分析資料是最主要關鍵，其次是正確的分析觀點。

先歸納手上所有可用來作為分析的資料類型，接著找齊這些資料。

至於分析觀點，在分析初期，不妨試著用不同的角度去分析，取出某一類型的資料作為主軸，再取出另一個想要對比的資料來作為資料軸。

例如，若要分析每個人的產能（效率），以人作為主軸，以產量作為資料軸。
這樣可以很快做出第一張分析表，記得為它套上圖表。

不過，很快的，你應該會發現，光是這樣的分析表，並不足夠。因為每個人所負責的事務並不盡相同，有些任務比較艱難，需要花比較多的時間；有的工作必須等待其他人的結果，就像生產線那樣，你必須等待產線前端完成後你才能進行你的工作。

所以，如果分析表只是很單純的考慮人與產量這樣兩個類型的資料，並不見的能夠精確的反應實際的效能。

這應該是說這樣的分析觀點並不夠客觀。

The Killing Point of a Project

Joseph Philips, the Director of Education for Project Seminars, has an interesting description for the project phase deliverables and examing the project status and project advancement. He said, "The idea of killing a project at phases is why phase completion is also called a kill point."

Well, I do think it's quite interesting. The point to kill a project, project team, or the project manager?