《最後期限：專案管理101個成功法則》筆記

一. 優質管理

1.讓正確的人去做正確的事。這就是優秀與平庸管理這間的區別

2.優質管理四大要素：
（1）選擇對的人
（2）為他們分配對的工作
（3）讓他們保持積極
（4）幫助團隊凝聚起來並維持團隊的凝聚力

3.除非感到安全，否則人們不可能去迎接變化

4.在所有成功的專案中，變化都是基本的要素之一

5.逃避風險是致命的錯誤，這會讓你也得不到與風險同在的利益

6.威脅不是提高績效最好的方法

7.領導者的特質：
（1）正確、有遠見的直覺
（2）用心領導
（3）建立起團隊的靈魂
（4）能辨別謊言

8.設計半匿名的互動體制，因為絕大多數的組織中，缺少一個能向老闆傳遞真正資訊的隱蔽途徑

9.在戰爭開始的時候，管理者真正的工作已經完成了，接下來只是靜靜地看著，確保它按照計畫發展。如果情況有一點偏差，你就應插手修正




二. 面試和徵才

1.對於新的雇員，交給他們的專案最好難度不超過他們曾成功過的專案，並把有挑戰性的目標延到下一次

2.你最想用的那個人可能還知道其他很好的人選

3.多聽，少說

4.先把材料整理好，所有事情都會進行得更好

5.你必須去控制的那些風險是原因，是可能造成最後失敗的東西，是需多根源性的小風險，反而不是最後幾個的大風險

6.在風險真正變成一個問題前，總會有一些跡象，你要先斷定這些早期跡象是什麼，並且去尋找它們




三. 生產力的提高

1.沒有「短期生產力提高」這樣的東西

2.生產力提高是來自長期的投資

3.透過控制風險來管理專案

4.為每個專案建立並維護一份風險統計表

5.評估每種風險具體化的機率，和可能造成的成本

6.對於每種風險，找出其具體化的初期徵兆

7.任命一位風險控制人員，這個人不能有組織內部「我能行」的態度

8.建立簡單的管道，讓壞消息能傳遞到高層

9.你必須以衡量自己控制錯誤的能力有多強，自己砍掉失敗的工作有多快，來評價自己的工作




四. 防止失敗

1.控制失敗比優化成功更能提高你的整體績效

2.除非必要，否則不要自己去組成一個團隊。去找一個已經成形的團隊來用

3.把凝聚在一起的團隊－準備充分、也願意接受新的工作挑戰－當成是專案的收穫之一

4.專案開始時浪費的一天和最後階段浪費的一天，對專案造成的傷害是一樣的

5.有無數種方法可以浪費一天的時間，但是沒有任何方法可以拿回一天的時間

6.團隊中的人越多，人與人之間的互動就越多，所以浪費的時間也越多




五. 開發過程的建構和模擬

1.以你認為工作是如何完成的直覺為基礎，建立一套模型

2.在和同事的互動中使用這些模型，以便交流、提煉關於專案如何運作的想法

3.用模型來模擬專案的結果

4.根據實際的結果來調整模型

5.每一天，你都必須準備拿自己的工作去當賭注




六. 度量

1.度量每個產品的規模

2.不要執著於單位－在客觀度量的時候，先用你自己的主觀單位

3.從所有能得到的原始資料中(一些可計算的軟體特性)，自己建立度量單位

4.從已完成的專案中蒐集原始資料，以導出生產力趨勢線

5.不斷修正你的度量方程式，直到它的計算結果與原始資料庫中的專案工作量有最好的對應關係

6.借助資料庫畫一條趨勢線，把預期的工作量表示為人造度量單位的函數值

7.現在，針對每個待評估的專案，計算出人造度量單位值，並根據這個值在趨勢線上找到預期工作量的值

8.用生產力趨勢線周圍的噪音水平，來反映預測的允差範圍




七. 流程和流程改善

1.好的流程和持續的流程改善是很好的目標

2.正式的流程改善計畫需要花錢、花時間；特定的流程改善工作還會延遲專案進度。儘管最終會看到生產力上的改善，它們也不可能抵銷花在流程上的時間

3.但是，專案的確可能從「單一的」、謹慎選擇的方法改善中得到足夠的收益，並抵銷為這次改善付出的時間和金錢

4.在專案進行中，不要希望在超過一個方法的範圍內實施改善。多種技術的改善計畫很可能使得專案比不實施改善更晚完成

5.標準流程的危險就在於人們可能失去重要的走捷徑機會

6.特別是對於人員超編的專案，標準流程看起來很嚴謹，因為他們製造出了足夠的工作(有用的和無用的)，讓所有的人都忙個不停




八. 設計與除錯

1.如果不大幅度減少除錯的時間，就沒辦法讓專案大幅度提前完成

2.用更多的時間做設計，就能大幅度減少除錯的時間




九. 壓力的效果

1.壓力之下的人思考不會變快

2.增加加班時間只會降低生產力

3.短期的壓力甚至加班可能是有用的策略，它們能使員工集中精力，並且讓他們感到工作的重要性。但長期肯定是錯誤的

4.經理之所以會施加那麼多的壓力，也許是因為他們不知道該怎麼做，或者因為其他辦法的困難而感到畏縮

5.如果經理使用辱罵的方法來刺激員工，表現出的是經理的無能，而不是員工的無能




十. 規格文件

1.每個規格應具有兩個部分：
（1）有一組策略(policy)表明系統怎樣回應事件
（2）需要一組輸入和輸出，讓事件和回應能銜接起來

2.如果一個系統真的很複雜，那麼所有的複雜應該都在策略中

3.這些策略決定了輸入怎樣轉換成輸出

4.如果規格文件有任何價值，它就必須精確地告訴你系統介面的特性

5.每份規格文件至少都必須有完整的輸入輸出統計，還須給每個輸入輸出一個名稱，並顯示它的成份

6.規格文件中的含糊，意味著不同的系統參與者之間存在著利害關係的衝突




十一. 衝突

1.調解必須由不涉及衝突的第三方來幫助雙方達成共識，且第三方應是沒有權力的

2.要在衝突完全形成之前就去調解

3.只要在開發過程中有多個參與者，就一定會有衝突存在

4.建立、安裝系統的工作中特別容易出現衝突

5.絕大多數的系統開發舔都缺乏解決衝突的能力

6.記住「我們都是站在同一邊；跟我們對立的，是我們要解決的問題」

7.第一步需先徵求衝突雙方的同意「我能幫你們調解一下嗎」，才可進行調解




十二. 人類的錯誤

1.置你於死地的，不是你不知道的東西，而正是你「知道」決不會置你於死地的東西

2.人們的注意力總集中在發現未知的事物，而不是重新思考已知的事物




十三. 人員安排

1.設計是將「整體」劃分為「部分」的關鍵，須完成後才得以將小塊的工作分配給下面的人
2.最初的粗分，其實是設計的核心

3.大多數的專案小組只注重早期的團隊建立，並做一些隱瞞真正核心設計的工作

4.不管什麼時候，只要專案的時間安排得太緊，它們就會失敗

5.在早期，人員超編會迫使專案跳過關鍵的設計階段

6.如果在設計完成之前，工作先被分給許多人，那們人與人之間、工作小組之間的介面就會很複雜

7.在專案的大部分時間理由小型核心團隊來設計工作，在最後的開發階段(時間安排的最後1/6)加入大量的人手

8.時間安排緊迫的專案，與時間安排較為合理的專案比起來，完成的時間反而會更長




十四. 專案社會學

1.每個會議都要有公開的議程

2.每個會議都要盡量短，讓他們可以根據需要，選擇參加哪一部份

3.會議要嚴格按照議程進行，這樣人們就不用擔心自己沒參加的會上有與他相關的主題

4.在工作中，憤怒都是因為恐懼




十五. 精簡

1.精簡是失敗的公司使用的辦法，它讓員工承擔失敗的責任

2.精簡的弦外之音:失敗和恐嚇