行萬里路...向前邁進

最後期限：專案管理101個成功法則 The Deadline: A Novel About Project Management 作者／湯姆‧狄馬克/著 譯者／UMLChina翻譯組 出版社／經濟新潮社 ISBN／9867889169

「尋找適合的人。然後，不管你之後做錯了什麼，他們都會拯救你。這就是管理。」

優質管理的四大要素：

• 選擇對的人。
• 為他們分配對的工作。
• 對他們保持積極。
• 幫助團隊凝聚起來並維持團隊的凝聚力。
  (其他一切都只是「文案」)

安全感和變化：

• 除非感到安全，否則人們不可能去迎接變化。
• 在所有成功的專案中(以及在絕大多數其他有價值的工作中)，變化都是基本的要素之一。
• 逃避風險是致命的錯誤，因為這會讓你也得不到與風險同在的利益。
• 人們可能會因為來自客觀世界的直接威脅而覺得沒有安全感，但是如果發現管理者可能濫用權力來懲罰自己，他們一樣會覺得沒有安全感。

負面效應

• 威脅不是提高業績最好的辦法
• 如果分配的時間已開始就不夠，不管威脅有多麼嚇人，工作也無法按時完成
• 更糟糕的是，如果目標沒有實現，你就必須兌現你的威脅

管理者必需的身體部位

• 管理涉及到心、腸胃、靈魂和鼻子

     因此……

• 用心來領導
• 相信你的腸胃（相信自己的預感）
• 構築團隊的靈魂
• 訓練一個能嗅出謊言的鼻子

用指揮戰爭來作為管理的一個比喻

• 在戰役開始的時候，管理者的真正工作已經完成了

面試和招聘

• 招聘涉及到所有者與管理者相關的身體部位：心、靈魂、鼻子和腸胃（但是主要是腸胃）
• 不要試圖單獨去招聘——兩副腸胃遠比一副腸胃的兩倍要強
• 對於新的雇員，讓他們承擔與以前曾經成功過的同樣難度的專案，把有挑戰性的目標推遲到下一次
• 徵求提示：你最希望股的那個人可能還知道其他很好的人選
• 多聽，少說
• 如果先把材料整理好，那麼所有的事情就會進行的很好

生產力的提高

• 沒有“短期生產力提高”這樣的東西
• 生產力的提高是來自長期投資的
• 任何承諾立刻見效的東西都可能是江湖遊醫賣的萬靈油

風險控制

• 通過控制風險來管理專案
• 為每個項目創建並維護風險統計表
• 跟蹤根源性的風險，而不止是最後那討厭的結果
• 評估每種風險具體化的概率和可能造成的開銷
• 對於每種風險，預測標誌其具體化的早期徵兆
• 任命一個風險控制官，這個人不應該維護內部“我能行”的態度
• 簡歷簡單的（可能是匿名的）通道，讓壞消息能傳遞到高層

防止失敗

• 壯士斷腕
• 控制住失敗比優化成功更能提高你的全面成績
• 要有闖勁，儘早取消失敗的工作
• 除非必要，否則就不要自己去凝聚一個團隊：出去找一個已經成型的團隊來用
• 保持好的團隊在一起（只要他們呢自己願意），以幫助你的繼任者避免團隊凝聚得慢或者不能凝聚的問題
• 把凝聚在一起的團隊－－－準備充分、並且也願意接受新的工作－－－作為專案的收穫之一
• 專案開始時浪費的一天和最後階段浪費的一天對專案造成的損失是同等的
• 有無數種方法可以浪費一天的時間……但是卻沒有一種方法可以拿回一天的時間

開發過程的建模和模擬

• 將你關於完成工作過程的直覺建模
• 在同事的交流中使用這些模型，以便交流、提煉關於項目運轉的思想
• 用模型來類比專案的結果
• 根據實際的結果來調整模型

“病態的政治”

• 每一天，你都必須準備拿自己的工作去打賭……
• ……但是這也不能保證“病態的政治”不會影響你
• “病態的政治”可能在任何地方出現，哪怕是在最健康的組織裏面
• “病態的政治”的特徵：對個人的權勢的渴望超過了組織本身的目標
• 即使這種不合理的目標與組織的目標背道而馳，它也可能出現
• “病態的政治”最惡劣的副作用：它使精簡項目變得危險

度量

• 度量每個產品的規模
• 不要執著於單位，在等待客觀的度量的時候，先用你自己的主觀單位
• 從所有能得到的原始資料（可計算的軟體特性）自己構造度量單位
• 從已經完成的專案中收集原始資料，以推導出生產力趨向
• 不斷完善你的度量方式，直到它的計算結果與原始資料庫中的專案工作量有最好的對應關係
• 借助資料庫畫一條趨勢線，把預期工作量作為人造度量單位值的函數顯示出來
• 現在，針對每個要評估的專案，計算出人造度量單位值，並根據這個值的趨勢線上找到預期工作量值
• 用生產力趨勢周圍的干擾水準作為映射的公差指示

過程和過程改進

• 好的過程和持續的過程改進是絕好的目標
• 它們也是非常自然的目標：優秀的技術工作者一定會關注它們，不管你是否告訴他們
• 正式的過程改進程式需要花錢、花時間；特定的過程改進工作還會延遲專案的進度。儘管最終會體現出生產力上的收穫，它們也不可能抵消花在過程改進上的時間
• 但是，項目有希望從單個的、正確的選擇的方法改進中得到足夠的收益，並贏回這次改變付出的時間和金錢
• 在項目進行的過程中，不要希望在超過一個方法的範圍內實施改進。多種技術的改進程式（比如說提高整整一個CMM等級）很可能讓專案比不實施這些程式完成得更晚
• 標準過程的危險就在於人們可能失去重要的走捷徑的機會
• 特別是對於人員超編的專案，標準過程看上去會很嚴重，因為它們製造出了足夠的工作（有用的和無用的），讓所有人都忙碌不停

改變完成工作的方式

• 如果不大幅度減少調試的時間，就沒辦法讓項目大幅度提前完成
• 高速完成的項目用在調試上的時間也成比例的少得多
• 高速完成的項目用在設計上的時間也成比例的多得多
• 如果你不關心別人，不能照顧別人，就別想讓它們為你做一些不同尋常的事情。如果要他們改變，就必須去瞭解（並讚賞）他們的過去

壓力得效果

• 壓力之下的人無法更快的思考
• 增加加班的時間只會降低生產力
• 短期的壓力乃至於加班可能是有用的策略，因為它們能是員工集中注意力，並且讓它們感到工作的重要性。但是長期的壓力肯定是錯誤的
• 經理之所以會施加那麼多的壓力，也許是因為他們不知道該做什麼，或者因為其他辦法的困難而感到沮喪
• 最壞的猜測：使用壓力和加班的真正原因是為了在項目失敗的時候讓所有人看上去能好一點

憤怒的經理

• 管理中的憤怒和羞辱是會傳染的。如果高層管理者喜歡罵人，很低級的管理者也會有樣學樣（就像經常被罵的小孩很容易編程很愛罵人的父母）
• 管理中的辱駡常被認為是一種刺激，可以讓員工提高效率。在“胡蘿蔔加大棒”的管理策略中，辱駡是最常見的“大棒”。但是，哪有人被辱駡之後還能做得更好的？
• 如果經理使用辱駡的方法來刺激員工，這就表現出經理的無能，而不是員工的無能。

含糊的規格文檔

• 規格文檔中的含糊標誌著不同的系統之間存在著未解決的衝突
• 如果一份規格文檔不能包含完整的輸入輸出列表，那麼它就是毫無希望的：它根本就還沒有開始說明任何東西
• 沒有人會告訴你一份規格文檔是不是糟糕。人們往往傾向於責備自己，而不是責備文檔

衝突

• 只要在開發過程中有多個參與者，就一定會有衝突存在
• 創建、安裝系統的業務中特別容易出現衝突
• 絕大多數系統開發團體都缺乏解決衝突的能力
• 衝突應當引起重視。衝突並不是缺乏職業道德的行為
• 應當提前聲明：所有人的“贏”都是受重視的。確保每個級別的人都能贏
• 談判困難；調解容易
• 如果兩個人的利益是完全或者部分相斥的，預先做好安排，準備好請雙方通過調解來解決衝突
• 記住：我們都站在同一邊；跟我們對立的，是我們要解決的問題

催化劑的角色

• 有這樣的一種催化劑式的人格。這樣的人會幫助團隊成型並凝聚，保持團隊的健康和生產力，從而對項目做出貢獻。就算“催化劑”別的什麼事都不幹（其實，通常它們還會幹很多別的事），這種催化劑的角色也是重要而有價值的
• 調解是“催化劑”的一項特殊工作。調解是可以學的，而且只需要很小的投資就能學會
• 調解應該從一個小小的儀式開始。“我能幫你門調解一下嗎？”在解決衝突的時候，這是必要的第一個步驟

人類的錯誤

• 將你置於死地的，不是你不知道的東西……而正是你“知道”絕不會置你於死地的東西

人員安排

• 在早期，人員超編會迫使專案跨過關鍵的設計階段（這是為了讓所有的人都有事可做）
• 如果在設計完成之前，工作先被分給了許多人，那麼人與人之間、工作於工作之間的介面就會很複雜
• 這會使團隊內部耦合度提高，會議時間、重複勞動和無效工作都會增加
• 理想的人員安排是這樣的：在專案的大部分時間裏由小型核心團隊來做設計工作，在開發的最後階段（時間安排的最後1/6）加入大量的人手
• 可怕的猜想：時間安排緊迫的項目，於時間安排比較合理的項目比起來，完成的時間反而會更長

專案的社會學

• 讓不必與會的人可以放心離開，從而保持會議的精簡。有一份公開的議程，並嚴格執行，這是最簡單的辦法
• 專案需要儀式
• 用小小的儀式來使人們注意專案的目標和理想狀態：小規模會議、零缺陷的工作等
• 採取行動，防止人隨便發怒
• 記住：憤怒＝恐懼。即便對下級發怒的經理一定是因為恐懼才會這樣做的
• 意見：如果所有人都懂得“憤怒＝恐懼”這個道理，就能明顯的看出發怒的人是在害怕。由於無法再隱瞞自己的恐懼，他也就不會再生氣了。（這不能解決這些生氣的人的問題，但是肯定可以讓其他人好受一些）

“病態的政治”（舊話重提）

• 別想根治一個病態的人
• 不要浪費時間，也不要因為嘗試治療上司的病態而使自己收到威脅
• 有時候，你唯一的選擇就是等待，等問題自己解決，或者等一個你繼續前進的機會
• 奇跡是有可能發生的（但是千萬別去指望它）

精兵簡政

• 精兵簡政是失敗的公司使用的辦法，它讓員工負擔失敗的責任
• 公司的目標應該正好相反：興旺而人性化
• 當你聽到“精兵簡政”這個詞的時候，請記住它的弦外之音：失敗和恐嚇

基本常識

• 專案既需要目標，也需要計畫
• 而且這兩者應該不同

http://www.kenming.idv.tw/a_ayfa_ca_aola_the_deadline_a_af_a_e_if

將生硬的專案管理理論以寓言、奇幻的方式寫成小說的型態，作者的文筆及功力真是了不起！

湯普金斯被 “綁架” 至一個奇境的國家(摩羅維亞)擔任專案經理，管理著 1500 人的軟體開發人員，分為六個產品線開發，約 710 個工作天時程；結果又被上面的 “豬頭” 執行長壓榨再將時程縮短 5 個月之多。這種不可能的任務，湯普金斯該如何完成？

這本書道盡了現實軟體專案開發理想與現實的難點：如何達成成本、品質、時程、規模之間的平衡？
軟體公司內永遠都會有個 “豬頭” 執行長，他只管成本與時程。

不能說他完全不對，但專案開發是需要從許多面的 “構面” 來衡量的；不只”財務”的構面，還包括了 “人力資源” 、 “資訊” 、 “組織” 等構面的整體考量，尤其，專案管理的本質仍在於 “無形” 的價值，即在於 “人性” 上的關懷。

由於執行長會量化，而 “財務” 、 “人力成本” 等是容易被量化的，至於無形的資產，因為不容易被量化，所以很容易就被忽略掉了。絕大部分軟體專案的失敗，亦源自於此：忽視掉了 “人本”。

本書裡面提到了許多專案管理方面的 技巧及觀念，例如:

• 如何將專案經理的 “直覺” 量化，成為可以計量的 “因子”，而得以建立模型與模擬。書中提到的 iThink 工具，其實就是 “系統思考(System Thinking)” 的模擬工具。
• 內文提到的 “CMMI”，沒有人對它會有興趣(除了執行長)。不是沒有幫助，而是太容易浮濫，往表面功夫來做文章。深得我心！！
• 少做表面功夫，思考如何減少無效會議。
• “簡單設計” 與 “除錯”。這是 XP(Extreme Programming)的實務精髓。
  尤其小說內的產品時程估算從原始的計算程式碼行數，至修正為改以 “功能點(Functional Point)” 來估算。務實又有效！
  至於如何才叫做 “完成功能點” 的開發？利用 “驗收測試(Acceptance Test)” 測試功能點，是最直接、且最不容易有糾紛的方法；內文也談到了 “單元測試”，嘿嘿，很有趣，基於時程，專案經理認為有些可以略過，與我原來的想法可說是不謀而合。:D

稍微有點可惜的，本書並沒有著墨太多在軟體設計的 “系統內部”，如，軟體系統的結構及整體架構設計考量等。畢竟，該書並非為軟體設計類的專書。

另外，有趣的是，作者還蠻有幽默感的，他所設定的虛構國家元首這個角色，設為 “比爾(Bill)” — 用股票交換然後買了這個國家。