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