最後期限

*安全和變化

除非感到安全感，不然人們不能去迎接變化

在全部的工程中，變化都是最基本的要素之一

安全感的缺少會讓人們反對變化

逃避風險是致命的，由於這會得不到與風險同在的利益

人們可能由於來自客觀世界的直接的恐嚇而沒有安全感，可是覺察到管理者可能濫用權力來懲罰本身，它們也會以爲沒有安全感

 

*負面效應

威脅不是提升業績最好的方法

若是分配的時間一開始就不夠，無論威脅有多麼嚇人，工做也沒法按時完成

更糟糕的是，若是目標沒有實現，你就必須兌現你的威脅

 

*管理者必需的身體部位

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

所以。。。

  用心來領導，

  相信你的腸胃(相信你的預感)

  構築團隊的靈魂，

  訓練一個能嗅出謊話的鼻子

 

*用指揮戰爭來做爲管理者的一個比喻

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

 

*面試和招聘

招聘涉及到全部與管理相關的省體部位:心，靈魂，鼻子和腸胃

不要試圖單獨去招聘

對於新的僱員，讓他們承擔與之前曾經成功過的一樣難度的項目，把有挑戰性的目標推遲到下一次

徵求提示:你最可能僱的那我的可能還知道其餘很好的人選

多聽，少說

若是先把材料整理好，那麼全部的事情會進行得更好

 

*成產力的提升

沒有短時間生產力提升 這樣東西

生產力的提升是來自長期投資的

任何承諾馬上見效的東西都極可能是江湖遊醫所賣的萬靈藥

 

*風險控制

經過控制風險來控制項目

爲每一個項目建立並維護風險統計表

跟蹤根源性的風險，而不僅是最後討厭的結果

評估每種風險具體化的機率和可能形成的開銷

對於每種風險，預測標誌其具體化的早期徵兆

任命一個風險控制官，這我的不該該維護組織內部「我能行」的態度

創建簡單的通道，讓壞消息傳遞到高層

 

*防止失敗

壯士斷腕

控制住失敗比優化成功更能提升你全面的成績

要有闖進，儘早取消失敗的工做

除非必要，不然就不要去凝聚一個團隊:找出一個已經成型的團隊來用

保持好的團隊在一塊兒，以幫助你的繼任者避免團隊凝聚得慢或者不能凝聚的問題

把凝聚在一塊兒的團隊-- 準備好，而且也願意接受新的工做--做爲項目收穫之一

項目開始時浪費的一天喝最後一天對項目形成的傷害是同等的

有無數種方法能夠浪費一天的時間。。。可是沒有任何一種方法能夠拿回一天的時間

 

*開發過程當中的建模和模擬

將你關於完成工做的直覺建模

在同事的交流中使用這些模型，以便交流，提煉關於項目運轉的思想

用模型來模擬項目的結果

根據實際的結果來調整模擬

 

*病態的政治

每一天，你都必須拿本身的工做打賭

可是這也不能保證 病態政治  影響你

病態政治 可能出如今任何地方，哪怕是在最健康的組織裏面

病態政治的特徵：對我的權勢的渴望超過了組織自己的過程

即便這種不合理的目標與組織目標背道而馳，它可能出現

病態政治最惡劣的反作用  它精簡項目變得危險

 

*度量

度量每一個產品的規模

不要執着於單位，在等待客觀度量的時候，先用你本身的主觀單位

從全部能獲得的原始數據本身構造度量單位

從已經完成的項目中收集原始數據，以推導出生產趨勢向

藉助數據庫畫一條輔助線，把預期工做量做爲人造度量值的函數顯示出來

如今，針對每一個評估的項目，計算出人造度量單位值，並根據這個值在趨勢線上找到預期工做量

用生產力趨勢周圍的干擾水平做爲映射的標示

 

*過程和過程改進

好的過程改進和持續的過程改進是絕好的目標

它們也是很是天然的目標：優秀的技術工做者必定會關注它們，無論你是否告訴他們

正式的過程改進程序須要花錢，花時間；特定的改進過程拖延項目進度。儘管最終會體現生產力的收穫，它們也不可能抵消花在過程改進上的時間

可是，項目有但願從單個的，正確選擇的方法改進中獲得足夠的收益，並贏回爲此次改進付出的時間和金錢

在項目的進行過程當中，不要但願在超過一個方法的範圍內實施改進。多種技術的改進程序(好比說提升整整一個CMM等級)極可能讓項目比不上實施這些程序完成更晚

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

特別是對於人員超編的項目，標準過程看山去很嚴謹，由於它們製造出了足夠的工做，讓全部人忙碌不停

 

*改變完成工做的方式

若是不大幅度減小調試的時間，就沒辦法讓項目大幅度提早完成

高速完成的項目用在調試的時間也成比例地少得多

高速完成的項目用在設計上的時間也成比例地多得多

若是你不關心別人，不照顧別人，就想讓他們爲你作一些不日常的事情。若是讓他們改變，就必須去了解他們的過去

 

*壓力的效果

壓力之下沒法更快地思考

增長加班時間只會下降生產力

短時間的壓力哪至於加班多是有用的策略，由於它們能使員工集中精力，而且讓他們感到工做的重要性。可是長期壓力確定是錯誤的

經理之因此會施加壓力，也許是由於他們不知道該作什麼，或者由於其餘辦法的困難而感到氣餒

最壞的猜想：是用壓力和加班的真正緣由是爲了在項目失敗的時候讓全部人好看一點

 

*含糊的規格文檔

規格文檔中的含糊隱含着不一樣系統參與者之間未解決的衝突

若是一份規格文檔不包含完整的輸入輸出列表，那麼它是毫無但願的，它根本就還沒開始說明任何東西

沒有人會告訴你一份規格文檔是否是糟糕。人們每每傾向於責備本身，而不是文檔

 

*衝突

在要在開發過程當中有多個參與者，就必定會有衝突存在

建立，安裝系統的業務中特別容易出現衝突

絕大多數系統開發團隊缺少解決衝突的能力

衝突應當引發重視。衝突並非缺少職業道德的行爲

應當提高聲明:全部人的贏都應該受到重視。確保每一個人在每一個級別上都能贏

談判容易；調解困難

若是兩我的的利益是徹底或者部分相斥的，預先作好安排，準備好請雙方經過調解來解決衝突

記住：咱們都站在同一邊；跟咱們對立的，是咱們要解決的問題

 

*人類的錯誤

將你置於死地的，不是你不知道的東西。。。而正是你 知道  毫不會置你於死地的東西

 

*人員安排

在早期，人員超編迫使項目跨過關鍵的設計階段

若是在設計完成以前，工做被分給了不少人，那麼人與人之間，工做組之間的接口就會很亂

這會迫使團隊內部耦合度提升，會議時間，重複勞動和無效工做都會增長

理想的人員安排是這樣的:在項目的大部分時間裏由小型核心團隊來作設計安排，在開發的最後階段加入大量的人手

可拍的猜測：時間安排緊迫的項目，與時間安排比較合理的項目比起來，完成的時間反而更長

 

*項目社會學

讓沒必要與會的人放心離開，從而保證會議的精簡。有一份公開的議程，並嚴格執行，這是最簡單的方法

項目須要儀式

用小小的儀式來令人們注意項目的目標和理想狀態：小規模會議，零缺陷工做等等

採起行動，防止人們隨便發怒

記住：憤怒=恐懼。隨便對下級發怒的經理必定是由於恐懼才這樣作的

意見：若是全部人懂得 憤怒=恐懼 這個道理，就能明顯地看出發怒的人是在懼怕。因爲沒法再隱藏本身的恐懼，他也就不會再生氣了

 

*病態的政治

別想根治一個病態的人

不要浪費時間，也不要由於嘗試治療上司的病態而使本身受到威脅

有時候，你惟一的選擇就是等待，等待問題的解決，或者等待一個讓你繼續前進的機會

奇蹟時有可能發生，可是不要期望它

 

*精兵簡政

精兵簡政是失敗的公司使用的辦法。它讓員工負擔失敗的責任

公司的目標應該正好相反：興旺而人性化

當你聽到精兵簡政這個詞的時候，請記住它的弦外之音：失敗和恐嚇