CH4
P.046
優質管理的四大要素
‧選擇對的人.
‧為他們分配對的工作.
‧讓他們保持積極.
‧幫助團隊凝聚起來維持團隊的凝聚力.
(其他一切都只是文案)
P.053
安全感和變化
‧除非感到安全, 否則人們不可能去迎接變化.
‧在所有成功的專案中(以及在絕大多數其他有價值的工作中), 變化都是基本的要素之一.
‧缺乏安全感會讓人們反對變化.
‧逃避風險是致命的錯誤,因為這樣會讓你也得不到與風險同在的利益.
‧人們可能會因為來自客觀世界的直接威脅而覺得没有安全感, 但是如果發現管理者可能濫用權力來懲罰自己, 他們一樣會覺得没有安全感.
CH5
P.065
負面效應
‧威脅不是提高績效最好的方法.
‧如果分配的時間一開始就不夠, 不管威脅有多麼嚇人, 工作也無法按時完成.
‧更糟糕的是, 如果目標没有實現, 你就必須兌現你的威脅.
CH6
P.080
管理理者重要的身體部位
‧管理牽涉到心、腸胃、靈魂和鼻子.
‧因此...
用心來領導,
相信你的腸胃(相信你的預感),
建立起團隊的靈魂,
訓練一個能嗅出謊言的鼻子.
CH7
P.090
用指揮戰爭來比喻管理
‧在戰爭開始的時候, 管理者真正的工作已經完成了.
P.091
面試和徵才
‧徵才牽涉到所有與管理有關的身體部份：心、靈魂、鼻子和腸胃(但主要是腸胃)
‧不要獨自進行─兩副腸胃遠比一副腸胃要好兩倍以上.
‧對於新的雇員, 交給他們的專案最好難度不超過他們曾成功過的專案；把有挑戰性的目標延到下一次.
‧尋求建議：你最想用的那個人可能還知道其他很好的人選.
‧多聽, 少說.
P.092
‧如果先把材料整理好, 那麼所有的事都會進行得更好.
CH8
P.105
生產力的提高
‧没有「短期生產力提高」這樣的東西.
‧生產力的提高是來自長期的投資.
‧任何承諾立刻見效的東西，無異於江湖術士在賣膏藥.
P.106
風險管理
‧透過控制風險來管理專案.
‧為每個專案建立一個並維護一份風險統計表.
‧去追蹤根源性的風險, 而不只是哀歎最後的不良結果.
‧評估每種風險具體化的機率, 和可能造成的成本.
‧對於每種風險, 找出其具體化的最早期徵兆.
‧任命一位風險控制人員, 這個人不能有組織內部「我能行」的態度.
‧建立簡單的(可能是匿名的)管道, 讓壞消息能傳遞到高層.
CH9
P.115
防止失敗
‧壯士斷腕.
‧控制失敗比優化成功更能提高你的整體績效.
‧除非必要, 否則不要自已去組成一個團隊, 去找一個已經成形的團隊來用.
‧維持好一個團隊(如果他們願意的話), 也幫助你的繼任者避免團隊凝聚過慢或無法凝聚的問題.
‧把凝聚在一起的團隊-準備充分、也願意接受新的工作挑戰-當成是專案的收穫之一.
‧專案開始時浪費的一天和最後階段浪費的一天, 對專案造成的傷害是一樣的.
P.116
‧有無數種方法可以浪費一天的時間....但是沒有任何的方法可以拿回一天的時間.
CH10
P.140
開發過程的建模和模擬
• 以你認為工作是如何完成的直覺為基礎，建立一套模型。
• 在和同事的互動中使用這些模型，以便交流、提煉關於專案如何運作的想法。
• 用模型來模擬專案的成果。
• 根據實際的結果來調整模型。
CH11
P.158
病態的政治
• 每一天，你都必須準備拿自己的工作去當賭注……
• ……但是這也不能保證「病態的政治」不會影響你。
• 「病態的政治」可能在任何地方出現，哪怕是在最健全的組織裡面。
• 「病態的政治」的特徵：對個人權勢的渴望超過了組織本身的目標。
• 即使這種不合理的目標與組織的目標完全相反，它也可能出現。
• 「病態的政治」最惡劣的副作用是：人事精簡的專案可能會受到壓力。
CH12
P.178
度量
• 度量每個產品的規模。
• 不要執著於單位––在等待客觀度量的時候，先用你自己的主觀單位。
• 從所有能得到的原始資料（一些可計算的軟體特性）自己建立度量單位。
• 從已經完成的專案中蒐集原始資料，以推導出生產力趨勢線。
• 不斷修正你的度量方程式，真到它的計算結果和原始資料庫中的專工作量有最好的對應關係。
• 借助資料庫畫一條趨勢線，把預期的工作量表示為人造度量單位的函數值。
• 現在，針對每個待評估的專案，計算出人造度量單位值，並根據這個值在趨勢線上找到預期工作量的值。
• 用生產力趨勢線周圍的噪音水平，來反映預測的允差範圍。
CH13
P.191
流程和流程改善
• 好的流程和持續的流程改善是很好的目標。它們也是非常自然的目標：優秀的技術工作者一定會關心這個，不管你有沒有告訴他們。
• 正式的流程改善計畫需要花錢、花時間；特定的流程改善工作還會延遲專案進度。儘管最終會看到生產力上的改善，它們也不可能抵銷花在流程改善上的時間。
• 但是，專案的確可能從「單一的」、謹慎選擇的方法改善中得到足夠的收益，並抵銷為這次改善付出的時間和金錢。
• 專案進行中，不要希望在超個一個方法的範圍內實施改善。多種技術的改善計畫（比如說提高整整一個CMM等級）很可能使得專案比不實施改善更晚完成。
• 標準流程的危險就在於人們可能會失去重要的走捷徑的機會。
• 特別是對於人員超編的專案，標準流程看起來很嚴謹，因為它們製造出了足夠的工作（有用的和沒有用的），讓所有的人都忙個不停。
CH14
P.210
改變完成工作的方式
• 如果不大幅減少除錯的時間，就沒辦法讓專案大幅度提前完成。
• 高速完成的專案花在除錯上的時間，相對來說少很多。
• 高速完成的專案花在設計上的時間，相對來說多很多。
• 如果你不關心別人，不照顧別人，就別想讓他們為你做一些非凡的事情。如果要讓他們改變，就必須去了解（並讚賞）他們的一切。
CH15
P.232
壓力的效果
• 壓力之下的人思考不會變快。
• 增加加班時間只會降低生產力。
• 短期的壓力甚至加班可能是有用的策略，因為它們能使員工集中精力，並且讓他們感到工作的重要性。但是長期的壓力肯定是錯誤的。
• 經理之所以會施加那麼多的壓力，也許是因為他們不知道該怎麼做，或是因為其他辦法的困難而感到畏縮。
• 最壞的可能性：使用壓力和加班的真正原因是為了在專案失敗時，證明大家並非沒有努力。
CH16
P.243
憤怒的經理
• 管理中的憤怒和羞辱是會傳染的。如果高階管理者喜歡罵人，低階管理者也會有樣學樣（就像經常被罵的小孩很容易變成愛罵人的父母）
• 管理中的辱罵常被認為是一種刺激，可以讓員工提高效率。在「胡蘿蔔加大棒」(carrot-and-stick，就是軟硬兼施)的管理策略中，辱罵是最常見的「大棒」。但是，哪有人被辱罵之後還能做得更好呢？
• 如果經理使用辱罵的方法來刺激員工，表現出的是經理的無能，而不是員工的無能。
P.249
含糊的規格文件
• 規格文件中的含糊，意味著不同的系統參與者之間存在著未解決的衝突。
• 如果一份規格文件不包含完整的輸入輸出列表，那麼它就什麼都不是；它根本還沒開始。
• 沒有人會告訴你一份規格文件是不是很糟糕。人們往往傾向責備自己，而不是責備文件。
CH17
P.259
衝突
• 只要在開發過程中有多個參與者，就一定會有衝突存在。
• 建立、安裝系統的工作中特別容易出現衝突。
• 絕大多數的系統開發團體都缺乏解決衝突的能力。
• 衝突應當被重視。衝突不是缺乏職業道德的行為。
• 應當事先聲明：每一個人的「贏」都很重要。確保每個級別的人都能贏。
• 如果兩個人的利益是完全或是部分相斥的，預先安排好，讓雙方透過調解來解決衝突。
• 記住：我們都站在同一邊；跟我們對立的，是我們要解決的問題。
CH18
P.272
催化劑的角色
• 有一種人具有催化劑的效果。這樣的人會幫助團隊成形並凝聚起來，保持團隊的健康和生產力，從而對專案有所貢獻。就算催化劑什麼事都不做（其實通常他們還會做很多事），這種催化劑的角色也是重要而有價值的。
• 調解是催化劑的一項特殊工作。調解是可以學的，而且只需要很小的投資就能學會。
• 調解應該從一個小小的儀式開始。「我能幫你們調解一下嗎？」在解決衝突的時候，這是必要的第一個步驟。
間奏
P.280
人類的錯誤
• 置你於死地的，不是你不知道的東西……而正是你「知道」絕對不會置你於死地的東西。
CH19
P.294
人員安排
• 在早期，人員超編會迫使專案跳過關鍵的設計階段（這是為了讓所有的人都有事可做）。
• 如果在設計完成之前，工作先被分給許多人，那麼人與人之間、工作小組之間的介面就會很複雜。
• 這會使團隊內部更互相依賴，會議時間、重複工作和無效的工作都會增加。
• 理想的人員安排是這樣：在專案大部分時間裡由小型核心團隊來計工作，在開發的最後階段（時間安排的最後1/6）加入大量的人手。
• 很糟糕的猜測：時間安排緊迫的專案，與時間安排較為合理的專案比起來，完成的時間反而會更長。
CH20
P.311
專案社會學
• 讓不必與會的人可以放心離開，而保持會的精簡。有一份公開的議程，並嚴格執行，這是最簡單的辦法。
• 專案需要儀式。
• 用小小的儀式來使人們注意專案的目標和理想狀態：
小規模會議、零缺陷工作等等。
• 採取行動，防止人們隨便發怒。
• 記住：憤怒 = 恐懼。隨便對屬下發怒的經理一定是因為恐懼才會這樣做。
• 意見：如果所有的人都懂得「憤怒 = 恐懼」這個道理，就能明顯地看出發怒的人是在害怕；由於人們傾向於不顯露恐懼，他們不得不藉由憤怒來發洩情緒。（了解這一點，並不能解決這些生氣的人的問題，但是一定可以讓其他人好過一點。）
CH21
P.326
病態的政治（再一次）
• 別想根治一個病態的人。
• 不要浪費時間，也不要因為嘗試治療上司的病態而使自己受到威脅。
• 有時候，你唯一的選擇就是等待，等問題自己解決，或是等一個讓你繼續前進的機會。
• 奇蹟是有可能發生的（但是千萬別指望它）。
CH22
P.338
精簡
• 精簡是失敗的公司使用的辦法，它讓員工承擔失敗的責任。
• 公司的目標應該正好相反：要發展而人性化。
• 當你聽到「精簡」這個詞的時候，請記住它的弦外之音：失敗和恐嚇。
CH23
P.342
基本常識
• 專案既需要目標，也需要計畫。
• 而且這兩者應該不同。
