IT專案經理手冊（轉）

專案跟蹤
　　
　　專案跟蹤要跟蹤什麼呢？主要針對計劃、任務和專案成員三個方面，是為了瞭解專案的實際進展情況而進行。如瞭解成員工作完成情況，瞭解整個專案計劃完成情況等內容。

　　專案跟蹤是必要的，因為它可以證明計劃是否可執行，同時可以說明計劃是否可以被完成。因為可以對計劃進行檢驗，所以如果把計劃和跟蹤作為一個工作迴圈，那麼計劃將得到適時的改進，因為跟蹤過程中會發現大量的計劃的不當之處。現在我們的專案中，有很多計劃做的不夠，這可以促使我們去改進和完善。專案跟蹤實施人應該是專案經理，因為專案經理制定專案計劃，並且專案經理有權進行工作的協調和調動。也就是說，跟蹤的主要目的是給專案經理一個工作的參考。跟蹤的結果和資料是“最好的教材”。

　　跟蹤的好處有：
　　1、瞭解成員的工作情況。一個任務分配下來後，專案經理應該知道工作的進展情況，那麼他就必須去跟專案成員進行交流，瞭解這個成員的情況。所以他要得到的資訊是“能不能按時並保值保量的完成？如果不能按時完成，需要什麼樣的幫助呢？”這是專案經理最關心的。而且需要隨時的收集。如果這個資訊沒有被收集上來，那麼專案經理就失去了對專案的瞭解，也就失去可適時調整的時機，如此，後果就可想而知了，專案拖延、混亂……

　　2、調整工作安排，合理利用資源。如果專案組中有幾個或者幾十個人的時候，就可能出現完成任務早晚的不同，完成早的不能閒著，完成晚的要拖後腿。這時就需要專案經理進行工作的調整。那麼這個跟蹤結果和資料就可以幫助專案經理完成這個工作。

　　3、促進完善計劃內容。專案人員多了，又去跟蹤，這就必然要求專案經理做出詳細的計劃，這個計劃必須要明確任務，明確任務的負責人，明確任務的開始和結束時間。這就要求專案經理把整個專案分成若干部分。詳細的考慮分工。專案經理的跟蹤必然促使專案組成員更加詳細、合理的制定自己工作計劃，最終形成一種可喜的情況，那就是計劃展現出的層次結構（專案計劃、階段計劃和個人計劃）。

　　 4、促進專案經理對人員的認識。工作分解後，應該按照個人的特長分配工作，因為特長就是效率。所以專案經理必須瞭解專案成員的情況。即使在開始時不瞭解這種情況，這種資訊在跟蹤中也會很快的被體現出來。也就是說跟蹤促使專案經理對成員進行一個評估，並且這個評估是可以找到根據的（專案跟蹤的結果）。

　　5、促進對專案工作量的估計。在一個好的跟蹤工具中應該有對工作量的估計。工作量的估計總是很不準確，這個問題在跟蹤中表現為完不成任務/計劃，或者工作超前。在這種情況發生後，也必然促使專案經理去考慮工作量的評估問題（包括整個專案的工作量，各個任務的工作量，有可能導致整個專案計劃的修改啊）。

　　6、統計並瞭解專案總體進度。經常會遇到這種情況，專案組在同一時間進行不同階段的工作。這時對於工作進度的把握，尤其是總體進度的把握就比較困難。如果專案經理把階段劃分的很清楚，並且階段工作量也很明確，而且專案成員也對自己的工作量進行評估的話（完成了任務的百分數），那麼專案的總體進度可以由工具自動生成（完成的百分比）。這當然不是很準確，但卻可以作為一個參考。而且是一個比較好的參考。

　　7、有利於人員考核。專案成員的工作能力（是否按時完成任務，完成工作量的大小…… 很多資訊都可以體現出來）。

　　從跟蹤方面來說，是專案經理主動去了解專案的情況。但專案成員應該主動向專案經理彙報工作，尤其是工作中的問題。正所謂“沒有問題就是問題”。現在我們需要一個好的工具，來建立並完善我們的跟蹤工作。
　　
　　交流的心態
　　
　　交流需要好的心態，尤其是PM，必須懂得傾聽，在聽意見的時候，不要過於自信！應該創造一個良好的交流環境，一個好的交流環境可以激發人的思維，一個差的交流環境會抑止交流的慾望。而在這個環境中，PM的心態是比較重要的。

　　我發現每個軟體公司幾乎都有例會制度，但是每次例會的效果越來越差，幾乎就變成了一個人說話了。例會制度本來是為了保證交流，增加交流。但是，由於這種例會形式過於正式，所以使人感覺氣氛壓抑，所以就抑止了交流慾望，結果反是減少了交流！氛圍決定交流的效果，比如PM請專案組人員去喝酒，這時的話肯定比例會時的多！

　　以前看到美國人、印度人每天下午都有一個喝咖啡的時間，曾經很納悶！現在感覺到了，原來是調節交流氛圍的！
　　
　　任務監控
　　
　　在專案組中經常出現一種情況，就是PM對各個組員的工作檢查太多，導致很多工作不能及時執行。在專案組中也有很多這樣的情況，就是PM不知道如何去做一份可行的計劃，不清楚如何去分工。當然以上工作主要看PM的能力，但是也要看方法。就拿第一種情況來說。交流會起多大的作用？這首先要分析一下，PM為什麼增加檢查力度，細緻且繁瑣。PM擔心組員不能把任務保質保量的完成，所以就不斷的檢查。這種擔心是有必要的，但也在很大的程度上說明組員沒有理解你的意思，沒有理解你分配的任務，不清楚你到底要什麼？而這個問題主要是PM的問題。

　　在分配工作的時候，經常出現不知如何下手的情況。任務分解不了，時間也不能確定......，這些只是PM自己的想法，為什麼不問問你的組員呢？你去問會讓你的感到似乎是技不如人，感覺有些彆扭。那就開會好了，大家來討論如何解決（這針對與大的分工）。可以確信一點，到大家討論的時候，肯定考慮的比PM一個人考慮的全面，而且可能更科學。

　　我們現在的PM一般在分工的時候，都會說一句話，就是“你先做著看吧”，為什麼是這樣的？當這句話說出口的時候，組員可能有多種理解：
　　1、PM是不是認為這個部分不重要？
　　2、是不是完成不完成都沒有什麼區別？
　　3、既然沒有要求，那做好做壞都一個樣了？

　　如果有了這些想法，那你這個任務分配是失敗的。在PM分配了一個“模糊”的任務後，一般不會得到好的效果，總是存在這樣或那樣的問題。而且自己在檢查工作的時候也不知道該檢查什麼，也不清晰什麼狀況下才是完成了。

　　在這種情況下，PM不加大力度去監控，不花更多的時間是檢查，那肯定不行！

　　當PM不能將任務分配的時候，最好先不要將任務分配下去！磨刀不誤砍柴工嗎，最好先把工作理順了，可以討論，然後再將PM的要求清晰的傳達給組員，當組員瞭解自己要做什麼，知道要達到的要求後，PM也就知道了，至少在檢查的時候，就可以有的放矢了！

　　交流的順暢與否，其實可以明確一點，就是大家的相互關係的好壞！要是你的組員總是感覺被你訓斥，你想讓他來跟你交流？那不是“找罵”嗎！交流應該隨時隨地的進行。我們的一些交流其實都很不到位。有很多兩人交流中，談著談著聲音就變大了，感覺像是在吵架。這種情況尤其容易出現在一個給另一個講解的時候。交流如果充分的話，可以讓你發現許多問題，在工作檢查的時候，當兩個人在激烈辯論後，其他人都會發現，原來還有這麼我沒有思考到的地方。
　　
　　軟體文件的必備要素
　　
　　和大多數同行一樣，我明白軟體文件的重要性。不幸的是，在任務開始前我很少閱讀文件。相反，我常常像視線不清的父母一樣，在裝配好他們孩子的腳踏車之後，還落下一兩個零部件沒裝上。 如果我們明白文件的重要性，那為什麼我們不更經常用它呢？然而，許多軟體文件存在以下問題：
　　· 錯誤的語法和/或拼錯的詞語
　　· 不完整
　　· 過時或不準確
　　· 過於冗長
　　· 未經解釋的縮略語或專用術語
　　· 查詢資訊困難

　　存在這些問題的主要原因是軟體文件常常被退居次位。工程預算迫使我們優先考慮開發過程中的主要活動，也就是那些可以看得到利潤的地方。編寫文件需要成本，因而它常常成為一項主觀上的活動，而且通常被認為沒有重要作用，應該儘量避免。許多專案經理認為客戶不需要文件，它只是用來裝點門面的。 軟體文件質量差的另外一個原因在於文件撰寫者。許多應用程式開發經理認為軟體文件的編寫是軟體開發過程的一個標準組成部分，因此要求開發人員在編碼的過程中產出文件。

　　儘管這種做法在理論上行得通，但它沒有考慮開發人員編寫文件的能力。簡單來說，技術人員是用來開發軟體而不是編寫文件的。為了解決這個問題，許多應用程式開發經理僱傭專業技術文件編寫者或業務分析師，以期改進軟體文件的質量。但這又遇到了另一個難題：專業編寫者及業務分析師的技術水平有限。

　　解決這個問題要考慮需要編寫的文件以及文件的預期讀者。一般的規則是，寫文件需要團隊協作，這樣就允許開發人員和文件編寫者利用彼此的長處，取長補短。例如，如果預期讀者是系統設計師，開發人員需要提供技術細節，然後文件編寫者按照正確語法組織和編輯內容。不考慮預期讀者或專門編寫者，軟體文件的質量取決於其可用性，可從以下6個方面去評價其可用性：
　　· 應用性：文件是否提供相關資訊？
　　· 及時性：資訊是否及時？
　　· 準確性：資訊是否正確？
　　· 完整性：文件是否足夠詳細而又不會太過拘泥細節？
　　· 可得性：文件是否隨時可得？
　　· 可用性：你能否很快憑直覺就找到所需資訊？

　　軟體文件的最主要目標是傳達一個系統的技術要素和使用方法。第二個目標是提供軟體開發過程中的需求，決策，行為，角色和責任的書面記錄。只有實現了這兩個目標，軟體文件才真正提供了有意義的資訊。
　　針對被開除人員的應急計劃
　　在職員離開企業時限制風險的出現是你的責任。在職員因不和睦而離職時這個責任就更加緊迫。找出和分析你的組織由於前任職員不滿而面臨的風險，是你的系統每天所面對的整體風險的一個延伸。不幸的是，對於很多組織來說，全面的風險和漏洞分析通常會超出預算限制。然而，還是有一些常用的措施可以使用的。

　　首先要在全面地審計資訊系統資產的基礎上確定風險暴露和漏洞。然後，基於資訊系統安全性的三個主要組成部分來分析這些資產弱點。資訊系統安全性的三個主要組成部分是：
　　· 機密性：保證組織的資訊資產不會被不恰當地洩露。
　　· 完整性：保證資訊系統資產的準確性和可靠性。
　　· 可用性：保證資訊系統資產以一種及時、可靠和可預測的方式可用。

　　接著，考慮每個部分在出現裂口的成本和影響，以確定你的風險優先順序。在確定風險優先順序時，請向你自己提出以下問題：
　　· 資產的價值是什麼？
　　· 危及資產價值的安全有多複雜？
　　· 威脅發生的機率是多少？
　　· 如果資產被危及安全，其成本是多少？
　　· 恢復資產的難度有多大？

　　最後，採取以下步驟減輕這些風險。這些步驟涉及的範圍很廣，從鎖定應用程式安全到刪除對系統資產的物理訪問都有。

　　保護組織不受被開除職員不適當動作的危害之關鍵是速度和準備。人員位置通常不允許你有很多時間去準備；因此，這就是你的計劃的用武之地。例如，你應該在一個職員被開除的前幾個鐘頭內採取以下動作：
　　· 刪除對 IT 資產的物理訪問。
　　· 刪除網路、Web 和應用程式授權/身份驗證。
　　· 隔離系統。（這可能包括刪除 VPN、調變解調器或其它接入。）
　　· 要求歸還所有公司資產。
　　· 與該職員的主管和同事進行針對該職員的風險評估。
　　· 實現一個離職訪談，期間你還可以評估風險。
　　· 保證這個職員儘快地離開其工作崗位。
　　· 將一個責任資源分配給一直與這個職員一起工作的人。
　　· 審計該職員的工作站和工作區域以確定風險等級。
　　· 通知他的所有同事該職員已經離職。
　　· 保持適當警惕地完成一個保險評估，以保證你的同事是安全的。
　　· 再次檢視事件響應計劃，並將它們都準備就緒。

　　雖然很多步驟看上去可能很無情，但不適當的動作造成的影響也很無情。做好準備就可以以不變應萬變。[@more@]