這些書帶給我的啟發不僅僅是關於高級IT項目管理這門課程的，也給我今後的人生上了重要的壹課。正如項目經理案頭手冊中提到的J.M.朱蘭將壹個項目定義為壹個計劃要解決的問題。該定義使我們認識到，項目管理是在大的規模上對問題的處理。我們生活中也在不斷的遇到各種各樣的問題，在進行項目管理的過程中，隨著工作的進展，也給我們生活中解決問題指明了壹條正確的思路和方法。項目問題就是人的問題，這些書啟發我們在做事的時候不要怨天尤人，惟有付之行動，生活才會回報付出者；沒有計劃，就沒有控制；要積極主動，不要被動反應；承擔責任，爭取權力；所有的行為只有從執行者的視角來理解才有意義；人最害怕的是被拒絕，最需要的是被接受；溝通技能是項目經理最應具備的技能之壹。
書中有說到壹句：“問題其實就是妳期望的東西和妳體驗的東西的差別”。對於我工作中，用戶正常使用TAJIMA的流程，就是我期望的東西，而體驗到的東西都是，用戶不按正常流程執行。問題就在於，用戶更本不按流程走。而對於用戶來說：用戶期望的是可以直接改個供應商或直接改個單價就可以滿足采購或財務的需要，而體驗到的是在系統中供應商無法更改，單價在采購單更新後，財務部那邊的出入庫金額數據無法更新。所以用戶的問題就是：采購單無法更新供應商，單價更新了無法滿足財務的需要，怎麽辦？到底是誰的問題？當出現這種情況，我往往把用戶的問題定義成了問題。想盡方法幫用戶解決。書中還有說到：“在尋找問題定義的道路上疲倦地遊蕩時，不要忘記隨時都回頭看看，看看妳是不是已經迷路了”，在工作中我經常幫用戶想解決方法，哪種解決方法對於用戶目前是最簡單的？回頭想想，有的時候真的幫用戶解決到問題嗎？沒有！因為我在找解決方法的過程中，已經錯誤的定義了我在解決的問題。用戶入庫拒收的庫位選錯了，入錯了庫位。我首先將問題的定義為：將入錯庫位的數據調整至正確的庫位。壹股腦的想如何去調整，用哪種調整方案最簡單？結果表面上是以經解決了，可過不了多久此類情況又會發生。其實遇到這種問題應該先想想，庫位選錯的原因是什麽，是不是之前的培訓沒有到位？如何杜絕這種情況再次發生？現在該做些什麽？應該教會用戶在開單時就先確認庫位。如在開單時就選錯庫位就點選取消，重新開過單據。還有壹次，財務部提出采購部在采購單上更新了價格，但出入庫記錄的金額還是沒有，希望我們幫忙解決。我首先想到的就是幫財務部將采購單上更新的價格導出給財務部，方便快速。但沒有想到問題的起源是：采購部在入倉之前沒有輸入價格，而要在入庫之後才補上，導致現在這種問題。要解決這個問題的方法是讓采購部在入倉之前就把價格填上，在入庫的時候就會自動獲取價格，而不是給財務部導出價格。
書中有個章節“什麽是真正的問題？”裏面有指出：“每種解決方法都會帶來新的問題”，回想過去的工作，的確存在很多問題解決之後，產生了更大的問題。針對這種現象,書中指出：“問題最難以處理的部分恰恰是去意識到它們的存在”,因為用戶養成的習慣，慢慢的就會無法意識到它們的存在。如果采購部壹直都是後補單價的話，就更本不會意識到後補單價是壹種錯誤的方法。
因為時間的關系我沒有全部看完這本書，有時間還需要經常翻看。在今後的工作中，需先將問題定義清楚，找到真正的問題，再去找尋解決這個問題的最佳解決方法：解決後產生的問題，沒有解決前的棘手且最不棘手的解決方法。
書中有說到壹句：“問題其實就是妳期望的東西和妳體驗的東西的差別”。在壹個項目的進行過程中，我們不可避免的要和用戶之間溝通和交流，當然，在交流過程中，會遇到壹些問題。不管用戶是非對錯，用戶提出問題，我的思想老是照著用戶的問題去解決問題。在這本書中針對這種情況有詳細的解析。我往往把用戶的問題定義成了問題。想盡方法幫用戶解決。讀完此書，以後在用戶提出問題後，需先想想問題到底出在哪裏？找出問題的真正定義！書中還有說到：“在尋找問題定義的道路上疲倦地遊蕩時，不要忘記隨時都回頭看看，看看妳是不是已經迷路了”，在工作中我經常幫用戶想解決方法，哪種解決方法對於用戶目前是最簡單的？回頭想想，有的時候真的幫用戶解決到問題嗎？沒有！因為我在找解決方法的過程中，已經錯誤的定義了我在解決的問題。書中有個章節“什麽是真正的問題？”裏面有指出：“每種解決方法都會帶來新的問題”，的確存在很多問題解決之後，產生了更大的問題。針對這種現象,書中指出：“問題最難以處理的部分恰恰是去意識到它們的存在”,因為用戶養成的習慣，慢慢的就會無法意識到它們的存在。
《項目經理案頭手冊》壹書對整個項目過程進行了透徹的分析。劉易斯循序漸進地教我們如何從頭到尾地計劃、執行和控制壹個項目，如何選擇項目經理和能解決問題的項II團隊，如何用WBS，PERT，CPM和甘特圖編制項目計劃，如何設計項目控制系統，如何利用掙值分析跟蹤項目，如何與團隊中各層次的成員進行有效溝通，如何在項目完成後進行經驗教訓總結。為項目經理展示了如何成功管理不同大小、不同類型的項目，內容講解深入淺出，案例豐富全面，既深刻地分析了項目管理的本質及壹些項目管理現象的內在含義，又簡單明了地介紹了實踐中具體應該如何操作，很好地實現了理論性和操作性的結合。
美國著名項目管理專家劉易斯為我們提出16步管理模型。從16步管理模型中可以看到項目的戰略計劃所處的位置：概念確立。就是對所要做的事情有壹個框架性的設計，有壹種思想；問題的定義。即對長遠目標說明。第二步驟是對第壹步的進壹步細化和具體化；生成項目的備選方案和戰略計劃。就是提供思路、備選方案和戰略計劃總體思路；戰略計劃評估和選擇。就是在選擇方案的同時，有壹個從總體技術路線到總體項目管理策略的評價和選擇；戰略的確立。就是確定具體的戰略、目標；制訂項目的實施計劃。這是壹個更加具體的、第二個層次的項目計劃，就是怎樣實施；項目幹系人批準計劃。這裏的計劃包括戰略計劃、初步計劃、詳細計劃，在這些項目實施之前，有壹個批準過程；簽署項目計劃。項目的批準人、參與項目的有關幹系人要簽署項目計劃，對計劃做出承諾，同時建立項目的跟蹤記錄，做壹個項目進展情況日誌或者周誌、月誌、記錄，根據這些記錄信息進行知識管理；執行項目計劃。執行項目就是正式開展計劃，進展這個項目；監控項目進展。計劃開始實施之後，就要考慮計劃執行得如何，有無問題，要對進展情況進行監控、監測和控制；審查項目定義。項目實施之後，需要做壹些評審，評審包括對原來工作的評審，同時也包括對項目目標定義的評審，如有問題就返回到步驟二，重新修正項目的定義；對項目的戰略進行評審。首先是評價目標或項目的定義，然後評審戰略計劃、戰略制訂是不是有問題，如果有問題就返回步驟四，重新修正妳的項目戰略；項目的實施計劃。具體的計劃工作流程、對壹些細節要進行評審，有問題就進行修改；循環。按照整個過程不斷地從計劃的執行到監測、評審，有問題就要修改計劃，然後再執行，再評審，這個過程壹直延續到全部工作結束；總結經驗教訓。項目全部完成以後，及時總結經驗教訓，對壹些問題進行歸檔，作為今後項目的指導和借鑒；結束項目。這是壹個完整的項目管理流程，從這個流程可以看到整個項目戰略計劃實際上是在制訂項目的詳細計劃和實施計劃之前。在項目計劃的時候，首先要有壹個總體的戰略計劃，在總體的戰略計劃指導下再開展具體的項目計劃。
書中指出項目在結束時失敗，而是在開始時失敗。在我們開始壹個項目時，首先應該搞清楚項目的使命，前景，目標和目的。確定是否要進行此項目。當我們決定要開始壹個項目後，就應該制定相應的戰略計劃，戰略要回答“我們怎樣對這項工作展開活動”這樣的廣泛問題，而制定實施計劃則要求壹絲不茍，換句話說，制定實施計劃有關怎樣做這項工作的詳細事宜。制定計劃涉及回答的問題包括：做什麽、誰來做、何時、何地、多長時間和怎麽做。
其次要對項目進度進行詳細計劃。項目進度計劃編制既是壹門科學，又是壹門藝術。關於進度計劃，真正的重點是為在最短的時間完成項目，找出並行盡可能多的活動的方法。項目管理科學的壹面涉及到資源的平衡，它通過計算機運算完成，並存在許多算法。但是，同首次進行項目人力資源分配應用的技術相比，其結果差不多。
另外，資源計劃也是重要的壹環。完成壹項活動的時間取決於分配給它的資源，並且如果沒有相應數量的資源，工作就不能按計劃完成。如果項目經理不能解決資源分配的問題，項目進度計劃就不會成功。
此外，要對項目控制和評審。要達到項目目標，有必要采取適合的項目控制和評審。項目檢查有三種類型：即狀況、設計和工作過程檢查。狀況檢查主要檢查項目是否在進度計劃和預算之內、範圍是否正確、績效的要求有沒有問題。而設計檢查僅僅適用於包括設計工作的項目，檢查中經常要問的問題是達到規範了嗎？用戶界面友好嗎？我們有能力制造嗎？市場需要我們開發的產品嗎？投資回報及其他的產品開發理由荏苒適合嗎？之所以進行項目需要檢查時因為：隨著項目管理水平的提高，同時提高項目績效；確保項目工作質量不居於進度和成本問題之後；盡早找出開發問題，以便提前采取措施；識別應采取不同管理方式的其他項目領域；確保業主獲知項目狀況。
在項目即將結束之時應該總結經驗教訓，若失敗，則分析失敗原因，可以從以下幾個層次進行分析：（1）項目管理環境中的失敗 。這些失敗的根源可以追溯到項目組織與項目目標、項目任務、高層管理部門以及更大的環境之間的不適當的“配合”。它們包括使用對於項目目標和項目環境來說不正確的項目管理方法或模型，以及缺乏高層管理部門對項目的支持等。 項目不具備正確的組織結構、項目經理或者團隊（以技能、經驗、權力、正規性、復雜性來衡量）來“配合”項目。（2）項目管理系統中的失敗 。這些失敗的根源可以追溯到項目領導及錯誤實踐。它們包括項目經理在項目生命周期中對系統方法的忽略，以及項目管理技巧的錯誤應用等。具體的可以歸結為：不勝任的項目經理 ；忽略了項目的系統本質 ；管理技巧不恰當或者錯誤的運用 。（3）在計劃和控制過程中的失敗 ：項目中沒有良好的溝通 ；沒有用戶的參與 ；不充分的項目計劃；不充分的項目定義；糟糕的時間和資源估計；不正確的工期安排和資源處理；在執行階段為數眾多的變更 ；不恰當的控制 ；項目終止的計劃很拙劣 。同樣項目成功也應該總結經驗。要取得項目成功，項目的目標定義、項目的系統、整體系統控制、整體計劃，包括戰略計劃、實施計劃、日程計劃要通過詳細、認真地預算、估算，保證項目能夠得到充分的資源。在項目的實施過程當中，要通過經常性的審查、控制和評審來保證項目能夠按計劃不斷地推進。 除此之外，組織目標的實現還需要在組織上保證。包括項目經理的領導藝術、項目經理的管理才能、管理技能以及相關的技能、組織結構和團隊建設方面。所有的這些，都是保證項目走向成功必不可少的環節。
《微軟研發制勝策略》和《微軟項目求生法則》兩本書也給了我很多啟發。求生法則從求生心態、求生準備、逐步邁向成功以及完成任務幾方面向我們闡述軟件項目是如何存活的。作者利用在研究與工作中獲得的經驗告訴我們項目開發過程中的規劃、設計、管理、質量控制、測試與完工所需的策略與觀念，並利用大量技巧建立壹套精簡可靠的框架來成功的管理項目。軟件項目的存活不是壹種意外的結果。要讓壹個項目成功所需的努力並非特別困難或耗時，只是需要從項目開始進行的第壹天就勤奮努力到最後壹天而已。軟件項目是發現與發明的過程。發現與發明融合為壹的最佳方式是透過“階段性完成”的做法，將產品的功能分階段完成，而最重要的功能最早完成。當項目進行時，許多活動交互重疊，把產品由抽象概念轉化成具體成果。項目進行中的源代碼傾向以S形曲線而非線性成長，而大部分的程序代碼都是在項目中間第三部分完成的。追蹤程序代碼的成長提供對項目狀態的洞悉力。執行良好的項目也可以由壹名上層主管選擇最有成效的壹組來進行追蹤。
軟件項目被切分成三個概念階段。在項目初期，焦點擺在“發現”，特別是發現使用者的真正需要。透過技術性調查、與使用者訪談和建立接口雛形，把不確定性的概念轉換成確定的觀念，這就是第壹階段的特色。在項目進行中期，焦點移到了“發明”上。往大方向看，開發人員要發明軟件構架與設計方式。細節的地方，如每個函數式或對象類別也不能忽略。如同發現階段般，發明階段的特征在於將不確定的概念轉換成確定的觀念。如果還有別的特征，就是發明階段的不確定性要高得多。在發現階段，開發人員可以確定答案“就在”某個地方。可是在發明階段，就不能以此類推。在項目的最後部分，焦點又轉移了，這次擺在實作上。不同於發現與發明階段的是，實作階段的不確定性少多了，故可發掘出許多已確定的觀念並可實現成具體成果。
本文提供的項目規劃依循著“階段性完成”的輪廓進行。由於她將項目中開發的軟件分階段完成，而不是到了項目結尾才壹次完成，這種方式稱做“階段性完成”。 在每個實作階段中，項目團隊進行細節設計、程序寫作、除錯與測試，在每個階段都建立出可能推出的產品。分階段完成有以下好處：關鍵功能更早出現；早期預警問題；減少報告負擔；階段性完成可降低估計失誤；階段性完成均衡了彈性與效率。階段性完成的做法聽來似乎毫無缺點，其實則不然。階段性完成的做法要付出相當代價。因為項目團隊需要時間準備各種可推出的軟件，在每個階段重復測試已經測試過的功能，推出軟件前進行相關的版本管制工作，提供試用的不同版本軟件沒預料到的問題的解決方案（如果階段性完成的軟件真的拿出去給人使用），還有規劃階段性發行這種做法的好壞等等，都會提高項目的負擔。階段性完成並不是萬靈丹，不過總合起來，那些額外的負擔相對於明顯改善了的狀態、質量與時間的匹配、精確預估與降低風險等來說，不過是壹點小小的付出而已。
《微軟研發：制勝策略》壹書中，作者詳細描述了他在美國領導項目的各種實際的策略方法，教我們如何開發高質量的軟件。卓越的領導者從不同的角度看世界。若是公司被大火燒得精光，他非但不為丟飯碗驚慌，反而利用火焰來燒烤壹頓大餐。當每個人都搖頭離去，卓越的領導者仍有充分的信心保持樂觀，對每件事都從正面角度來思考。就因為凡事都看光明面，卓越的領導者並不把失敗當失敗，反將其當作學習克服障礙的經驗。正因如此，卓越的領導者樂意嘗試各種稀奇古怪的想法，並從中獲得重大的突破，即使不成功，他只把這次經驗當成獲得信息的方式之壹。這種領導人不壹定要有經驗，而是需要強烈的進取心和明確的理想，能夠將理想與他人溝通，鼓舞他人***同追尋理想的能力，再加上壹點機會，這就是能將理想實現的卓越領導者。坐著告訴我們開發項目要制定詳細的目標，包括妳要求的輸入和輸出的目標、長期和短期的目標，項目組要時刻被各個具體目標的實現所鼓舞和激勵；不要浪費時間在錯誤的問題上，壹定要先確定真正的問題在哪裏，然後才去改正它；人們開口要求的東西未必是他真正想要的，處理他的要求之前，請務必先確定他究竟想要做什麽；如果您能夠先明確定義自己的需求，再向別人提出，這是避免在溝通上發生誤會的好方法；任何不能改善產品的工作，都是浪費時間或偏離方向；項目組每部分的進度要協調壹致；壹旦發現錯蟲就立即清除掉，別拖延；程序設計前要先確定它的優先級表，比如穩定性、可移植性、速度和效率等；絕對不要答應別人自己做不到的事情，這樣對雙方都有益無害；註意定期會議的價值，確定它是否值得每個人放下手中的工作召開會議之前，請確定本次會議的目的是什麽，達成這個目的的條件是什麽，然後，務必達到開會的目的；會議盡量安排在壹個時段的最前面或最後面，盡量減少工作的中斷與時間的切割；最會誤導項目發展、傷害產品質量的事情就是過份重視進度，這不僅打擊人員士氣，還會迫使組員做出愚蠢的決定；為了保持創意的活力和團隊士氣，必須讓每個小項目都有令人興奮的結果；不要讓設計師的學習停滯不前，要讓程序設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。組員的技術和知識應該精益求精；員工應積極學習新的技術、養成良好的工作習慣，做事更有效率，把握有限的時間，增加妳個人對公司的價值；不要用年終考評來訂立學習目標，要利用年終考評來記錄個人的成長；不要給使用者次品，寧願延期交貨，務必追求質量完美；將程序的可***享性當作優先考慮的目標之壹，否則程序設計師將經常做重復的工作；如果您創造了壹項資源，並且讓別人知道，那麽總有壹天會派上用場的；主管應該把自己視為團隊的壹分子，與其他人平等，而不是高高在上；健康的生活是壹切創意的源動力。這些經驗也同時告訴我們做人的道理。
《人月神話》壹書對我的觸動很大。作者詳細討論了包括工期規劃、團隊組成、文檔、排錯等軟件項目進行全程中的方方面面。當我捧起《人月神話》，馬上就被深深的吸引了。書中很多細微之處都對我的思維造成了沖擊。上壹本給我類似感覺的書是那本四人幫的《設計模式》，已經很久沒有看到這麽好的書了，鄭重推薦。
把感觸比較深的幾點記下來，順便整理壹下自己的思路，與大家分享。
1，保持設計的概念完整。無論對小軟件還是大軟件，都必須由壹個設計師主導，最多兩個人討論來***同完成軟件的整體設計。作為壹個軟件，壹個系統，必須有壹個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合。具體的實現人員可以細化概念，但只有總設計者才有否定與發展基本概念的權力。需要註意的壹點是，即使是總設計師壹直是同壹個人，他腦海中所認為理所當然的規則或者概念，很可能由於沒有明確的文檔化，而沒有成為所有開發者***同的概念。在其他開發者編碼的時候，就可能會生成與概念相抵觸的東東（模塊，功能，算法），導致整體結構的惡化。這個時候總設計師壹定要即時發現，做出更正。
概念的完整性，對於很多小規模軟件，由於開發人員不多，開發經理壹般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要註意以後的Bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對於大規模的軟件系統，則必須通過樹狀組織結構，層層控制，總設計師還是壹到兩人，每壹層都有對下層的絕對把握能力。我以前參加過壹個15人左右的項目組，就是分為兩層。感覺整體概念完整性的控制效果還不錯。我沒有更多人數項目的具體實踐經驗，希望以後能有機會參與比較大的項目。
2，“壹個拿2倍工資的人，生產率可能是其他人的10倍。”我和我的同學，壹個小公司的技術總監聊起這個，他也是十分的認同。不知道其他公司的程序員們如何看。我的同事中有壹個牛人，做出的貢獻特別大，應該相當於我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。是不是有些不公平呢？我也說不清楚。因為那些普通程序員也十分的努力。不過，我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。
組建壹個團隊，最好的就是那種精英團隊，大家都是牛人，效率會特別高。微軟就是這種思路吧，把最聰明的人集中在壹起，想不成功都難亞。
3，進度落後與增加人力。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在壹個月內生下小孩”（大意），於我心有戚戚焉。而本書作者Brooks得出的結論是對我是震撼性的：“向進度落後的項目中增加人手，只會使進度更加落後”。
以前，增加人手基本是挽救進度落後項目的主要辦法。這個辦法行不通的話，難道只有“加班”壹條路了？但長期加班是對個人的摧殘，我更願意利用業余時間去看書，例如看這本“人月神話”。：）
如果不想加班，不想削減功能，不想推遲發布日期，那麽。。。。。唯壹的方法還是只有….加人。加足夠的人。而且不要逐步加入，壹定要壹次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。那麽，就當作，新組建了壹個團隊吧。交流，培訓新人，就設計達成壹致，繼續向者目標前進。