通往智慧型的路啊，明白而簡單，
我們一錯再錯，一錯再錯，
但會越來越好，越來越好。
——派特.海恩
1)選擇正確的人
2)為他們分配正確的工作
3)保持他們的積極性
4)幫助團隊凝聚起來並保持團隊的凝聚力
1)除非感到安全，否則人們就不能去迎接變化
2)在所有成功的工程中(以及在絕大多數其他有價值的工作中)，變化都是基本的要素之一
3)安全感的缺乏會讓人們反對變化
4)逃避風險是致命的，因為這會讓你也得不到與風險同在的利益
5)人們可能會因為來自客觀世界的直接的恐嚇而覺得沒有安全感，但是如果覺察到管理者可能濫用權力來懲罰自己，他們也會覺得沒有安全感
1)管理涉及到心、腸胃、靈魂和鼻子
2)因此：
用心來領導，相信你的腸胃(相信你的預感)，構築團隊的靈魂，訓練乙個能嗅出謊言的鼻子。
在戰役開始的時候，管理者真正的工作已經完成了。
1)沒有「短期生產力提高」這樣的東西
2)生產力的提高是來自長期投資的
3)任何承諾立刻見效的東西都很可能是江湖遊醫所賣的萬靈藥
1)通過風險控制來管理專案
2)為每個專案建立並維護風險統計表
3)跟蹤根源性的風險，而不只是最後那討厭的結果
4)評估每種風險具體化的概率和可能造成的開銷
5)對於每種風險，**標誌其具體化的早期徵兆
6)任命乙個風險控制官，這個人不應該維護組織內部「我能行」的態度
7)建立簡單的(可能是匿名的)通道，讓壞訊息能傳遞到高層
1)壯士斷腕
2)控制住失敗比優化成功更能提公升你的全面成績
3)要有闖勁，盡早取消失敗的工作
4)除非必要，否則就不要自己去凝聚乙個團隊：出去找乙個已經成型的團隊來用
5)保持好的團隊在一起(只要他們自己願意)，以幫助你的繼任者避免團隊凝聚的慢或者不能凝聚的問題
6)把凝聚在一起的團隊——準備充分、並且也願意接受新的工作——作為專案的收穫之一
7)專案開始時浪費的一天和最後階段浪費的一天對專案造成的傷害是同等的
8)有無數種方法可以浪費一天的時間，但是沒有任何一種方法可以拿回一天的時間
1)將你關於完成工作的過程的直覺建模
2)在同事的交流中使用這些模型，以便交流、提煉關於專案運轉的思想
3)用模型來模擬專案的結果
4)根據實際的結果來調整模型
1)每一天，你都必須準備拿自己的工作去打賭
2)但是這也不能保證「病態的政治」不會影響你
3)「病態的政治」可能在任何地方出現，哪怕是在最健康的組織裡面
4)「病態的政治」的特徵：對個人權勢的渴望超過了組織本身的目標
5)即使這種不合理的目標與組織的目標背道而馳，它也可能出現
6)「病態的政治」最惡劣的***：它使精簡專案變得危險
7)別想**乙個病態的人
8)不要浪費時間，也不要因為嘗試**上司的病態而使自己受到威脅
9)有時候，你唯一的選擇就是等待，等問題本身自己解決，或者等乙個讓你繼續前進的機會
10)奇蹟是有可能發生的（但是千萬別去指望它）
1)度量每個產品的規模
2)不要執著於單位——在等待客觀度量的時候，先用你自己的主觀單位
3)從所有能得到的原始資料（可計算的軟體特性）自己構造度量單位
4)從已經完成的專案中收集原始資料，以推導出生產力趨勢
5)不斷完善你的度量方程式，直到它的計算結果與原始資料庫中的專案工作量有最好的對應關係
6)借助資料庫畫一條趨勢線，把預期工作量作為人造度量單位值的函式顯示出來
7)現在，針對每個要評估的專案，計算出人造度量單位值，並根據這個值在趨勢線上找到預期工作量值
8)用生產力趨勢周圍的干擾水平作為對映的公差指示
1)如果不大幅度減少除錯的時間，就沒有辦法讓專案大幅度提前完成
2)高速完成的專案用在除錯上的時間也成比例的少的多
3)高速完成的專案用在設計上的時間也成比例的多得多
4)如果你不關心別人，不照顧別人，就別想讓他們為你做一些不同尋常的事情。如果要讓他們改變，就必須去了解（變更讚賞）他們的過去。
1)壓力之下的人無法更快的思考
2)增加加班時間只會降低生產力
3)短期的壓力乃至加班可能是有用的策略，因為它們能使員工集中精力，並且讓他們感到工作的重要性。但是長期的壓力肯定是錯誤的。
4)經理之所以會施加那麼多的壓力，也許是因為他們不知道該做什麼，或者因為其它辦法的困難而感到氣餒。
5)最壞的猜測：使用壓力和加班的真正原因是為了在專案失敗的時候讓所有人看上去能好一點
1)規格文件中的含糊標誌著不同的系統參與者之間存在著未解決的衝突
2)如果乙份規格文件不包含完整的輸入輸出列表，那麼它就是毫無希望的：它根本就還沒有開始說明任何東西。
3)沒有人會告訴你乙份規格文件是不是糟糕。人們往往傾向於責備自己，而不是責備文件。
1)只要在開發過程中有多個參與者，就一定會有衝突存在
2)建立、安裝系統的業務中特別容易出現衝突
3)絕大多數系統開發團隊都缺乏解決衝突的能力
4)衝突應當引起重視。衝突並不是缺乏職業道德的行為。
5)應當提前宣告：所有人的『贏』都是受重視的。確保每個級別的人都能贏。
6)談判困難，調解容易
7)如果兩個人的利益是完全或者部分相斥的，預先做好安排，準備好請雙方通過調解來解決衝突
8)記住：我們都站在同一邊，跟我們對立的，是我們要解決的問題
1)有這樣一種催化劑式的人格。這樣的人會幫助團隊成型並凝聚，保持團隊的健康和生產力，從而對專案作出貢獻。就算「催化劑」別的什麼事情都不做（其實，通常他們還會幹很多別的事），這種催化劑的角色也是重要而有價值的。
2)調解是「催化劑」的一項特殊工作。調解是可以學習的，而且只需要很小的投資就能學會。
3)調解應該從乙個小小的儀式開始。「我能幫你們調解一下嗎？」在解決衝突的時候，這是必要的第乙個步驟
將你置於死地的，不是你不知道的東西……而正是你「知道」絕不會置你於死地的東西。
1）在早期，人員超編會迫使專案跨過關鍵的設計階段（這是為了讓所有人都有事可做）。
2）如果在設計完成之前，工作先被分給了許多人，那麼人與人之間、工作組之間的介面就會很複雜。
3）這會使團隊內部耦合度提高，會議時間、重複勞動和無效工作都會增加。
4）理想的人員安排是這樣的：在專案的大部分時間裡由小型核心團隊來做設計工作，在開發的最後階段（時間安排的最後1/6）加入大量的人手。
5）可怕的猜想：時間安排緊迫的專案，與時間安排比較合理的專案比起來，完成的時間反而會更長。
1)讓不必與會的人可以放心離開，從而保持會議的精簡。有乙份公開的議程，並嚴格執行，這是最簡單的辦法。
2)專案需要儀式
3)用小小的儀式來使人們注意專案的目標和理想狀態：小規模會議、零缺陷工作等等。
4)採取行動，防止人們隨便發怒
5)記住：風怒 = 恐懼。隨便對下級發怒的經理一定是因為恐懼才會這樣做的。
6)意見：如果所有人都懂得「憤怒 = 恐懼」這個道理，就能明顯的看出發怒的人是在害怕。由於無法再隱瞞自己的恐懼，他也就不會再生氣了。（這不能解決這些生氣的人的問題，但是肯定可以讓其他一些人好受一些）。
1)精兵簡政是失敗的公司使用的辦法，它讓員工負擔失敗的責任
2)公司的目標應該正好相反：興旺而人性化
3)當你聽到「精兵簡政」這個詞的時候，請牢記它的弦外之音：失敗和恐嚇。
1）專案既需要目標，也需要計畫
2）而且這兩者應該不同
mysql運維 讀書筆記 Mysql 讀書筆記
mysql儲存時間有兩種型別 datetime和timestamp。分別說一下兩者的區別。datetime，以8位元組儲存時間，理論上可以從0000年儲存到9999年。並且沒有時區的概念，它儲存的就是乙個時間點的概念。timestamp和datetime最主要的不同就是，它是以4個位元組儲存，由19...
struts in action讀書筆記
struts in action 學習筆記 一 struts的控制流 因為web 應用是動態的，所以很難表現 乙個真正固定的控制流 取決於環境，不同的方式下有很多不同的事情發生 特別是在web 應用中。但是事情仍然有乙個通用的秩序。如果你是個struts，應用框架，甚至web 應用的新手，這些流程剛...
中 斷（讀書筆記）
裝置的中斷會打斷核心中程序的正常排程和執行，系統對更高吞吐率的追求勢必要求中斷服務程式盡可能地短小精悍。但是這個良好的願望往往與現實並不吻合。在大多數的系統中，當中斷到來時，要完成的工作往往並不是短小的，它可能要求進行較大量的耗時處理。為了在中斷執行時間盡可能短和中斷處理需要完成大量工作之前找乙個平...