obrienb41的部落格

如果管理的專案不如預想般順利進行，《專案管理人應該知道的97件事》將能為你提供無價的知識，書中的珍貴知識是經由多年的嘗試與試誤中所得。本書包含97則簡短又極為實際的小訣竅 － 無論用於軟體或非IT類專案 － 訣竅的提供者是一群世上最有經驗的專案經理人與軟體開發師。讀者將能從中學習專家處理大小諸事的技巧，包括管理團隊與應付專案的利害關係人、超出控制的會議等等。

雖然本書以軟體專案為主，但其中所涵蓋的原理可適用於各種產業各類專案的專案管理原則。讀者可逐章閱讀，也可以單獨挑選特別適用於自己的章節。本書既是很有用的參考工具書，也是刺激想法的泉源。

在本書的97則訣竅中，各位將可看到的精闢見解，如：
* 精巧的程式碼很難維護（David Wood，Zepheira合伙人）
* 每位專案經理人都是契約管理者（Fabio Teixeira de Melo，Construtora Norberto Odebrecht規劃管理師）
* 回報內容中可否兼容實獲值與速度？（Barbee Davis，Davis Consulting總裁）
* 如何定義「大功告成」？（Brian Sam-Bodden，作家、軟體架構師）
* 最佳估計人選：負責工作的人（Joe Zenevitch，ThoughWorks資深專案經理人）
* 如何慧眼識出優秀IT開發人員（James Graham，獨立管理顧問）
* 一項交付標的，一個人負責（Alan Greenblatt，Sciova CEO）

Barbee Davis，MA、PHR、PMP，為PMI的《Community Post》撰寫半月刊載的專欄。她擁有一間Davis Consulting公司，提供訓練與開發工作室及諮詢服務。

在 IT 專案管理中 管理人際因素
James Graham, PMP
Ta’ l-Ibrag, Malta

身為軟體專案經理人，我們對於時程表的細節吹毛求疵。我們對著數 據奮戰，試著從分配到的預算中，壓榨出專案交付標的。但我們經常 沒看到、或忽略了造成專案失敗的最普遍因素：人。

從錯誤、意外、乃至於完全沒有效能，人為失敗的出現通常能與我們 重複過往行為的傾向聯繫起來；我們有種心態：『如果這個方法成功過， 應該也能再度成功』。有句俗諺：「對於槌子來說，每個問題都是個 釘子。」心理研究證明，人類在壓力的影響下，有可能回復到槌子式 的學習或經驗，因為過去曾透過某種方式取得成功。還有什麼環境比 一個新的軟體專案更有壓力？

因為大多數專案的目標都是建立新產品、服務或解決方案，心智與工 作風格的敏捷性與靈活性才是我們鼓勵的重要積極行為，而不是重複 過去的動作。遵循舊有的程序，在面對新的不同挑戰時，反而可能產 生不良後果。

試想有一位產業分析師， 他對某種舊有的軟體專案管理方法很有經 驗。理智上來說，當他的開發人員解釋一種更為敏捷的軟體開發方式 更為合理的原因時，他應該會同意這些解釋。但在他面對危及專案的 時間壓力時，卻可能退縮而改用曾經良好運作的技術；他的依據是一 段與軟體無關的經驗。

銀行的主管回報說顛倒數字是種常見的錯誤，尤其在員工因為工作或 私人相關的壓力而無法專心一致時。瞭解人性的傾向後，聰明的專案 管理者將仔細於評估、預算與其他文件中，檢查此類不小心、但反映 人性的錯誤。

有哪些事可能對專案團隊形成壓力？可能是私人的事，例如出門上班 前跟另一半吵架了、 或是家裡有經濟壓力， 又或許是擔心家人的健 康、擔心小孩等等。

工作上遇到的事也可能引發壓力。可能是些小事，例如在重大股東會 議時遲到、忘記攜帶重要文件、也可能是對於工作安全性的顧慮，甚 至是憂心專案的編程與測試無法如期完成目標等等。

壓力導致行為退縮，使我們不會積極尋求解決問題的行動。身為軟體 專案經理，注意這些導致團隊成員退回過往行為的壓力癥狀，我們責 無旁貸。透過與成員積極對話，仔細經營工作的環境，即可避免壓力 的影響，或有助於把影響降到最低。

人都擁有人性，工作場所自然也會看到人性人情。但只有人才能開發 軟體，所以在監控與保護非人的資源時，也請小心培育與管理手邊的 人性資本。

保有自己的洞察力
James Graham, PMP
Ta’ l-Ibrag, Malta


向使用者收集業務需求時，經常聽他們反應「系統太慢」、「應用程 式不可靠而且會當掉」、「程式做的都是我不需要的事，都不做我需 要的事」、「明明是個簡單任務卻要按好幾個鍵」。

大部分軟體專案經理人都會同情使用者。我們試著提出似乎能消除痛 苦的方案，試著讓使用者覺得好過一點。但我覺得，雖然出發點可能 是基於好意，本質上卻是錯誤的；更糟的是，還會進一步降低專案成 功結束的可能性。

有些人說，收集業務需求的重點，在於提供量身訂做的解決方案，據 以減輕終端使用者的失望感。我同意這是個值得奮鬥的目標；不過， 專案經理人如果基於「想讓使用者覺得好過一點」的心情來決定最佳 方案，將會出現致命的缺陷。實際上，這樣的專案經理人可能缺乏保 持洞察力（perspective）及不偏不倚的自我訓練。

洞察力，表示要尋找最佳方案，而不是「感覺上對使用者好」的修正 方式。請記得，使用者對於自己的產業領域有著深刻的瞭解，藉由分 享這些知識也能對專案做出極大的貢獻；但我們該如何運用使用者提 供的知識？

當我在一家倫敦的管理顧問公司工作時，經驗豐富的同事們曾指導過 拒絕的重要性。他們的智慧建議是根據老套的事實：大多數專家喜歡 炫耀自己的聰明，但其實應該花時間有技巧地詢問正確問題，以解決 根本的病源。如果不揭開真正的病因，所有嘗試解決的方式只會更加 刺激症狀。

我們都處在趨從於這種錯誤的危險中。最近，我接到為一家大公司設 計一個管理開發程式的需求。我當時的衝動就是趕快動手處理造成問 題的地方，並建議客戶先看一個我做好的程式。我知道那個程式可以 輕易調整，從而治療讓客戶痛苦不已的問題。

幸好，自我克制及時發揮作用。我跟資深經理深談一個小時，瞭解真 正的挑戰。當我後退一步，傾聽業務上的問題，而不只是終端使用者 的抱怨（這指向不恰當的問題），我推薦的是完全不同的解決方式。 這樣更能切合他們的需要，並解決核心的問題。

下次遇到沮喪失望的使用者，深呼吸一口氣。先讓他們宣洩對於日常 遭遇的表面症狀的不滿 － 這些惱人的事情都真實存在。然後對使用 者詢問一連串問題，找出沮喪下的真正根源。請迴避提供快速修正方 式、快速滿足使用者的誘惑。只有在規劃專案的解決軌跡前，先確定 瞄準了正確的目標，才是對使用者最好的做法。