《最後期限》（The Dead Line）是我看的第一本關於項目管理的書，更重要的是這本書屬於科普讀物，通俗易懂，書並不厚，不過我看了好幾天，因爲我邊看邊思考，結合我的經歷，我想這樣才能真正對我起到指導作用。下面我抓住我體會最深刻的一些要點，寫出來供大家參考。
一、管理的核心是人，不涉及到人的管理，最多隻能稱得上是文檔工作，文檔本身不會產生價值，價值只能通過人來創造，人是最重要的。
書的一開始就說明了這個觀點，其實不光是軟件項目了，任何項目都如此，必須重視人的管理，作爲一個經理，就必須學會和團隊其他成員交流，調動他們的積極性，保持團隊的凝聚力。回想我這些年的工作經歷，沒有了解到這個觀點，或者說沒有貫徹這個觀點的經理，太多了。我曾經在一個做對日外包的公司工作，那裏有時候很忙，有時候很閒，忙的時候有事情做也無所謂，閒的時候就找不着北，有段時間我連續幾個星期見不到經理，我不知道我在那個公司是一種什麼角色，不知道這樣下去還有沒有發展。後來我才知道其實經理一直在忙，忙什麼？忙她的“設計”，設計沒有完成，就不好安排我們任務，這個我也同意，但無論多忙，她都不應該中斷和我們的交流，她沒有給我們任何安排，沒有調動我們的積極性，更加無所謂保持“團隊凝聚力”，這做法導致我想離開那家公司，而且我確實這樣幹了。管事不管人的經理要麼就是根本沒有權力，要麼就是水平很糟，這樣的經理帶出來的項目也肯定好不去哪裏，只有人能創造價值是這條法則的根本原因，好的公司都非常重視“人性化的管理”，管理也是以人爲本的。著名的經理人餘世維曾說過，當他還是一個部門經理的時候，每個月都會拿出自己收入的10%來給他的手下提供便利，當然他因此所得到的認可與回報也是非常可觀的。
二、除非感到安全，否則人們就不能去迎接變化，但變化在成功的項目中幾乎是一定的，所以一定不要給手下施加太多的壓力，這些壓力能形成危機感，讓他們不樂於接受任何變化。
和第一條“總則”一樣，這條也是關於人的管理，算是細化，其實你會發現之後的法則都和人有關。軟件開發是高度依賴於腦力的工作，不管是誰，心理承受力總是有限的，而目前的情況就是經理喜歡“逼”手下儘快完成任務，如果完不成任務，就……這算是一種威脅，有了這種威脅，手下就不可能會有安全感，於是匆匆忙忙設計，匆匆忙忙編碼，再匆匆忙忙測試。一旦客戶需求有變動，就十分不樂意接受，因爲變動就意味着延期，更糟糕的是有些延期難以估算，那會導致無法按時完成項目，然後就受到……
三、危脅手下也不是提高業績的好辦法，如果分配的時間已開始就不夠，不管威脅有多嚇人，工作還是無法按時完成。
我完全同意這點，並有深刻體會。我懂得一個軟件工程的“經驗公式”，用這個經驗公司可以比較準確地估算出一個項目需要多長時間完成，公式是這樣描述的：靜下心來，想想這個項目如果在進行當中沒有遇到什麼技術難題，沒有什麼意外人員流動，沒有多少需求變更，當然資金也沒有問題，再排除大小會議所耗費的時間，那麼得出的這個時間基本上很準確，但！注意，把這個時間乘3，甚至乘4！這個經驗是《C++編程思想》的作者Bruce Eckell提出的，我可沒那麼偉大發明這個“公式”。我有次在進行一個Windows平臺的小型項目，經理問我需要多長時間完成，我說兩個月，他馬上反駁說：“太長了！最多隻能一個月。”經理說這樣，我也沒辦法，爲了快點把東西弄出來，我縮短了設計時間，幾天後就轉入了編碼，我確實在一個月後把東西交付了出來，可惜後來修修補補的時間加起來卻一點都不比前面我所說的“兩個月”少。另外說一下這個經理，有個毛病，每次徵求我的意見問我多少時間完成項目，他都不會同意我的觀點，於是我就學乖了，我估算出來需要30個工作日的項目我就跟他說“40個工作日”，他於是說：“這絕對不行，最多25個工作日了。”我和他一番討價還價之後確定30個工作日，哈哈，正中我的預期的目標，但這樣有意義嗎？
四、對於新的僱員，讓他們承擔與以前曾經成功過的同樣難度的項目，把有挑戰性的目標推遲到下一次。
我曾經遇到過這麼個問題：你認爲軟件開發者偏向於像科學家還是藝術家？外行人可能會回答像科學家，可幾乎所有的軟件人都會回答像藝術家。軟件開發過程可以看作一種創作的過程，其實我也是因爲喜歡創作，纔會從事這個行業，創作就意味着一種開拓與創新，而不是機械與重複，所有的軟件人都喜歡新鮮的項目，對新的技術十分推崇，而經理人也往往會因爲他們的熱情而把這些工作交給他們。但這種開拓沒有過往的經驗，是十分具有挑戰性的，風險也是很大的，作爲經理，不能打擊手下的積極性，而應該好好溝通，如要點所說，讓新僱員先着手去完成一個曾經成功過的同樣難度的項目，把有挑戰性的項目推遲到下一次，這樣風險會降低很多，並且不會太讓手下感到挫折。
五、沒有“短期生產力提高”這種東西，生產力的提高來自長期的積累，CMM往往會讓它本身變成目的，添加累贅，而起不到什麼提高的作用，這個世界根本沒有立杆見影的方法。
我對CMM是有所瞭解的，它的本意是好的，通過減少重複勞動來提高軟件生產力，通過嚴格的文檔控制來提高軟件可靠性，嗯，理論上確實可行，而實際上卻如標題所言，“CMM往往會讓它本身變成目的”，我在那家做對日外包的公司工作時候，有幸參加過CMM的培訓，豈是“枯燥”兩個字了得，文檔文檔還是文檔，文檔本身幾乎成了目的，我搞不懂那麼多的文檔對我們最底下人員的開發會有什麼幫助，而CMM是要求整個公司去實施的，也就是最底層的開發人員也需要產生相應的文檔，於是60%-70%的時間都迷失在文檔中，弄得怨聲四起……總的來說，CMM的代價是很昂貴的，收益是不確定的，改進的風險是巨大的，它根本不是提高軟件生產力的靈丹妙藥，如果你想說CMM也許對大公司來說是必需的，那我可以明確告訴你，Microsoft就沒把CMM放在眼裏。所以不要嘗試引進什麼方法來大幅度提高生產力，生產力來自自身的長期發展與積累。書中還有句稍微委婉點的話：“過程改進的出發點是好的，從理論上來說也是可行的，但特定的過程改進工作會拖延項目進度，最終體現在生產力上的提高恐怕也難以抵銷這個損失。”
六、進行風險評估很重要，不要以爲什麼都能很好地完成。最先知道危機存在的是底下的人，必須想辦法建立通道，讓壞消息及時傳遞上來。
國內普遍的情況是：風險不用評估，想辦法把東西做出來就是。不是我們不怕風險，而是評了也白評，項目擺在那裏，做也得做，不做也得做。所以要說這個風險評估有用，那就是我們用它考慮了所有我們可能會在項目進行過程中遇到的風險，並且我們準備好了一些對策。壕溝裏的戰士最瞭解戰局的情況，而不是在辦公室裏的將軍。報喜不報憂是種“中國特色”，你不見每次開會時候必說的話都是“取得了良好的成績”麼？要不是破產，我看成績從來就沒有過不“良好”，領導都說良好了，手下還能說不良好？於是種種危機就這樣徘徊在底下傳不到上層，某天發現項目出現了重大的問題，可調整已經來不及了，那可就遲了。
七、成型的團隊是寶貴的，不輕易拆散。
作者提到了許多公司喜歡在項目完成之後對項目組進行拆散重組，其實這等於破壞了這個團隊通過長期合作贏來的默契配合，好團隊的形成確實是不容易的，天時地利人和。根據我的經驗，如果一個團隊成立於公司剛成立之時，或一個大型項目剛啓動之時，這個團隊往往是很優秀的，而之後的團隊就感覺“一蟹不如一蟹”，拆散了成熟的團隊，又得再花大量時間來培養一個團隊，成本是很高的。公司併購在軟件業不是什麼新鮮事，而併購過程中往往出現人員流失，使得本來優秀的團隊變得缺乏戰鬥力，沒有以前的團隊，花大價錢買回來的代碼也就成了廢品。
八、項目開始時浪費一天和最後階段浪費一天對項目造成的傷害是同等的。有無數種方法可以浪費一天時間，但沒有任何一種方法可以拿回一天的時間。
“有無數種方法可以浪費一天時間，但沒有任何一種方法可以拿回一天的時間。”這句話就出現在這本書中，並且廣爲人知。時間是寶貴的，不展開了，人都應該知道。
九、團隊中的人數和產出不成正比。指望靠增加團隊人數來提高生產力，是錯誤的。
項目讓一個人來做需要花費100天，如果讓兩個人來做呢？三個呢？單純增加人數根本不能縮短軟件的生產時間，爲什麼？1、新增加的成員要適應工作，得花費時間；2、要融入團隊，需要花費時間；3、成員間交流需要花費時間；4、成員間衝突會浪費一部分時間；5、人員過多的情況下根本無法進行軟件設計。可能還有別的原因，但我想這5個肯定是重要原因。這也是這本書的一個核心觀點。軟件設計的隊伍必須非常精簡，100人的項目，只需要4-5個人參與設計，如果讓這100人全部參與，我想那就跟菜市場差不多，亂哄哄了，一個人一個意見，設計根本無法進行。而當設計完成，轉入編碼階段，纔是全部需要這100人的時候。我們傳統的認爲從頭到尾都需要給他們參與進來的觀點其實是不對的，一個項目從頭到尾所需要的人員數目不是一致的。所以書中的主人公讓那些沒有參與到設計的人去做一些軟件外包的工作，而不是讓他們全部擠到設計組去。
十、“病態的政治”對項目威脅很大，但又不得不經常面對它，它的特徵是對個人權勢的渴望超過了組織本身的目標。
舉個例子吧，十九世紀的時候，沙俄工程師設計了一條鐵路準備修建，爲了表示對國王的尊重，就把設計圖拿給了國王過目，國王一看大爲惱怒：“你畫的這條鐵路彎彎曲曲，這樣要多浪費多少資金材料？不行，必須改爲這樣。”國王拿起筆把始點終點用直線連了起來。國王的命令，不敢不聽，但這樣的鐵路如何修建？直線就意味着要穿過高山，要跨過窪地，技術根本達不到，項目最後流產。四個字形容這種“病態的政治”再恰當不過——“剛愎自用”，這種威脅來自上級，遺憾的是我們往往沒有什麼對策，除了我們自己被迫離開這個鬼地方。
十一、要學會對工作量進行評估，用自己的單位即可，比如“功能點”，憑直覺對項目進行量化。
軟件項目的工作量很難用什麼尺度來衡量，所以我們需要因地制宜建立自己的標準，把這個單位命名爲“功能點”，這樣就便於任務劃分了，當然“功能點”也是很主觀的，不可能是精準的，但它卻十分有效。比如有“數據庫設計”這麼個任務，我們把它細化，對一個表的設計算一個功能點，有些表很大，算兩個功能點，表之間的約束，關聯，算五個功能點，這樣的一個任務，算下來一共16個功能點，如果做八個功能點一天，那麼這個任務需要兩天。
十二、標準的過程的危險就在於人們可能失去重要的走捷徑的機會。
團隊合作就需要一些規範，一些標準，但過多的標準，就會讓人厭煩，而這些規範也會變成團隊的絆腳石，真可謂作繭自縛。我曾經負責過公司編碼規範的制訂，我考慮到了過多的規範難以記憶與實施，於是對規範一再精煉，只制訂了3頁不到的“規範”，其中還包括一些範例，但整篇“規範”條條有理，非常容易記憶，後來的實踐證明了我的“規範”還是成功的，大家基本上都按照上面所說的去做了，而且這個規範足夠讓我們的代碼看起來很賞心悅目，這是一個避開繁瑣的標準與規範，走捷徑的例子。試想想看，對一個小型項目，如果完全依循軟件工程的那些方法，需求，需求分析，概要設計，詳細設計，編碼……其中需要產生多少文檔？文檔有文檔的規範，整理一篇有水準的文檔絕對不是件容易的事情，那又需要耗費多少時間？而這些開銷，對這麼個項目來說都是划不來的。有時候我們必須要走捷徑。
十三、對程序的調試往往會佔據相當長的時間，減少調試時間是項目成功的一個關鍵，那就是把更好的設計拿出來，在編碼前反覆推敲分析，當編碼完成時，產品也基本上完成。
理論上是這麼說，我還沒有對這個觀點有什麼深刻的體驗。根據作者的意思，設計所花費的時間是最長的，佔全部時間的2/3，而編碼調試，僅僅花費了1/6不到的時間，看來我的水平還太低，沒怎麼理解這點。
十四、壓力下人不能更快地思考，增加加班時間會降低生產力，所以加班通常都不是讓項目及時完成的好辦法，偶爾加班是可以的，但長期加班絕對不行。
又是一個敏感話題，加班。這個觀點上面寫得已經夠明確了，加班不是辦法！相反作者提出了一個非常新穎的辦法，那就是向員工提出要求：你們要完成這些項目，嚴禁加班。嗯，沒錯，是嚴禁，下班時間一到，就開始趕人，這樣一來，員工就不會在寶貴的上班時間裏開小差去做別的事情，拖沓的習慣也就能改掉，更重要的是沒有了加班，員工得到更充足的休息時間，便於開展第二天的工作。這個由不得我去實踐，但無疑加班是下策的下策，而我們的經理人又有幾個會意識到這點？
十五、回到人的管理，列舉幾條法則：
1、如果你不關心別人，不照顧別人，就不要指望他們會爲你做一些不同尋常的事情，如果要讓他們改變，就必須瞭解並讚賞他們的過去。
2、憤怒和恥辱是會傳染的，如果高層管理者喜歡罵人，低層管理者也會有樣學樣。辱罵員工並不能提高其工作效率。用辱罵方式刺激員工的經理是無能的經理。
3、衝突一定會存在，承認衝突，並確信衝突並非缺乏職業道德引起，談判困難，調解容易。
4、存在一種員工，業務水平一般，人緣卻非常好，對整個團隊起到很好的調節作用，讓團隊保持健康和生產力，這種“催化劑”式的員工是可貴的。