項目管理工具箱觀後感

1. 項目管理讀後感

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

2. 項目管理工具箱的介紹

本書基本內容為「理論理解+管理實務+工作流程+工作模板+工具表單」，同專時具有工作指導書或項屬目管理實務手冊的特點，旨在為項目管理一線不同管理層次的專業管理人員提供對項目管理核心內容的理解與感悟，對項目管理實踐的指導與建議；提供在實際操作中可以借鑒的管理流程、工作規范、管理實務及以圖例表單為核心的手冊性內容，具有較強的實用性和可操作性。本書可供各級項目經理、項目管理人員、工程技術人員、相關研究人員和項目管理咨詢從業人員作為項目管理實務和咨詢工作案頭參考；也可作為項目管理評審員、評估師，企業高層管理者，政府、金融業、項目投資管理者考核、監督、評估項目管理水平與成效的參考資料；此書還可以作為項目管理專業研究生和項目管理工程碩士的選修教材。

3. 項目管理工具箱的書目

第1章項目管理知識體系
第2章項目生命周期
第3章項目管理過程概述
第4章項目啟動
第5章項目計劃
第6章項目實施
第7章項目監控
第8章項目收尾......

4. 項目經理一般都用哪些項目管理工具

現在常用的項目管理工具有：CORNERSTONE、Teambition、ones、tapd、zentao

最推薦的一種：CORNERSTONE項目管理工具

推薦理由：

CORNERSTONE能夠用來處理任何類型的項目協作的工具，應用於運行和維護涉及到你的業務和企業的最困難任務，即使是對最初級的用戶都能有所幫助，可滿足不同團隊規模的需求。

1.存儲在雲端，或者可以自己架設，基於 B/S 架構；
CORNERSTONE有網頁版，並支持mac、windows、ios、Android多端同步，並支持私有部署功能。

5. 什麼是最好的項目管理工具

我覺得進度計劃網路圖是最好的項目管理工具，看了項目計劃網路圖就可以對項目一目瞭然。

6. 項目管理工具的特性

要實現企業管理的項目化，需要一套符合項目化管理思想的管理工具，領導企業執行與溝通平台 核心機制就是實現企業管理的項目化，既可以管理有生命周期項目、也可以管理常規事務、還可以將產品或客戶建立為項目、甚至可對具體的員工進行項目化管理。
項目化管理軟體需要符合以下特性：
簡化項目管理流程，輕量級的項目管理
減少對項目經理的依賴，項目成員參與項目管理。項目管理按「項目→任務→事件」的方式，「自上而下」地進行工作的部署，人員調動和資源分配。項目執行中所有涉及的信息將按照「事件→任務→項目」的方式，「自下而上」地進行匯總，數據化和圖表展示。
單一項目管理的全面性
在做項目管理的時候，需要考慮到項目管理的方方面面如：項目資源的配置，階段的劃分，項目里程碑設定等。需要有完善的項目任務管理、團隊管理、財務管理、合同管理、文檔管理、時間管理、績效管理。
具備項目溝通平台
只有溝通好了，才能談得上項目管理。在領度軟體的溝通平台中，採用活動流方式記錄項目實施過程，驅動項目執行力。通過類微博化的活動流方式將項目執行的溝通過程記錄，並且把信息同步關聯到項目，關聯到任務，關聯到客戶，關聯到同事。這樣溝通記錄便存在於項目活動流、任務活動流、客戶活動流、個人活動流中，便於事後追溯，一方便將知識精華記錄下來形成企業的知識庫，利於傳承，另一方面消除信息孤島，減少扯皮現象，責任分明，避免各部門間互相推諉。
多項目管理
在滿足單一項目管理的全面性外，還需要勝任多項目管理，將各個項目數據提煉成動態的圖形，提供給管理層有力的決策依據。比如在多項目管理中有如下數據圖形：
1.項目泳道圖——展現全部項目的投入與收益情況；
2.項目動態圖——展現全部項目推進情況；
3.項目時間評估——展現全部項目所投入人力成本；
4.項目季度復審——展現全部項目的收款、付款及合同資金情況的工具；
5.項目甘特圖——提供計劃甘特圖和追蹤甘特圖，可掌握任務的計劃和任務的執行，了解工作的進度。

7. 團隊項目管理工具的重要性

合理安排項目的進度，有效使用項目資源，確保項目能夠按期完成，並降低項目成本。通過項目管理中解結構ＷＢＳ、網路圖和關鍵路徑ＰＤＭ、資源平衡、資源優化等一系列項目管理方法和技術的使用，可以盡早地制定出項目的任務組成，並合理安排各項任務的先後順序，有效安排資源的使用，特別是項目中的關鍵資源和重點資源，從而保證項目的順利實施，並有效降低項目成本。如果不採用項目管理的方法，我們通常會盲目地啟動一個項目，將所有資源均安排在項目中，可能會有很多的人員、任務的瓶頸，同時也會造成很多的資源閑置，這樣勢必會造成資源和時間的浪費。加強項目的團隊合作，提高項目團隊的戰鬥力。項目管理的方法提供了一系列的人力資源管理、溝通管理的方法，如人力資源的管理理論、激勵理論、團隊合作方法等。通過這些方法的使用，可以增強團隊合作精神，提高項目組成員的工作士氣和效率。日事清是我們經常用的項目管理工具，是一款專業的管理工具，能提高團隊的效率，做到事半功倍。

8. 團隊項目管理工具的特點

做項目管理的目的就是就是為了提高項目的進度和效率，更好的保障項目的進行。在這個過程中對於項目的計劃安排、流程和記錄總結都必不可少。
1、共同的目標

為使項目團隊工作成效，就必須明確目的和目標，並且對於要實現的項目目標，每個團隊成員必須對此及其帶來的收益有共同的思考。因為成員在項目里扮多種角色、做多種工作、還要完成多項任務。而任務的確定要以明確目標和了解相互關系為基礎。
項目團隊必須有一個明確的共同目標，這一目標是共同憧憬在客觀環境中的具體化，並隨著環境的變化而有著相應的調整，但每個隊員也都了解它，認同它，都認為共同目標包容了個人目標，充分體現了個人的意志與利益，並且具有足夠的吸引力，能夠引發團隊成員的激情。

2、合理分工與協作

與第一條相對應的就是在共同目標的前提下，每個成員都應該明確自己的角色、權力、任務和職責，就像樂隊中拉小提琴的必須明確自己的角色定位和演奏環節。在目標明確之後，還必須明確各個成員之間的相互關系。如果每個人彼此隔絕，大家都埋頭做自己的事情，就不會形成一個真正的團隊。項目團隊在建立初期，在團隊成員的全體參與下花一定的時間明確項
3、高度的凝聚力

凝聚力指成員在項目內的團結與吸引力、向心力；也是維持項目團隊正常運轉的所有成員之間的相互吸引力。團隊對成員的吸引力越強，隊員堅守規范的可能性越大。一個有成效的項目團隊，必定是一個有高度凝聚力的團隊，它能使團隊成員積極熱情地為項目成功付出必要的時間和努力。
團隊成員的共同利益、共同目標；團隊的大小、團隊內部相互交往、相互合作，如果團隊規模越小，那麼彼此交往與作用的機會就越多，就越容易產生凝聚力；經常性的溝通可以提高團隊的凝聚力；項目目標的壓力越大，越可以增強團隊的凝聚力；團隊凝聚力的大小是隨著團隊成員需求滿足的增加而加強，因此，在形成一個項目團隊時，項目經理需要為最大限度地滿足個別需要提供保障。

4、團隊成員之間相互信任

高效團隊重要的另一個特徵就是成員之間信任，一個團隊的能力大小受到團隊內部成員相互信任程度的影響。在一個高效能的團隊里，成員會相互關心，承認彼此存在的差異，信任其他人所做和所要做的事情。在任何團隊工作，都有不同意見，要鼓勵團隊成員將其自由地表達出來，不怕打擊報復地大膽提出一些可能產生爭議或沖突的問題。 項目經理應該認識到這一點，並努力實現這一點，因此在團隊之初就應當樹立信任。通過委任、公開交流、自由交換意見來推進彼此之間的信任。

5、有效的溝通

高效的項目團隊還需具有高效溝通的能力，項目團隊必須裝備有先進的信息技術系統與通訊網路，以滿足團隊的高效溝通。團隊擁有全方位的、各種各樣的、正式的和非正式的信息溝通渠道，能保證溝通直接高效，層次少，無官僚習氣，基本無滯延。團隊擅長於運用會議、座談這種直接的溝通形式。團隊內要充滿同情心和融洽的情感。項目團隊具有開放、坦誠的溝通氣氛，隊員在團隊會議中能充分溝通意見，傾聽、接納其他隊員的意見，並經常能得到有效的反饋 。