記錄一次小型專案管理的經驗

專案背景：從ie6公升級到ie11，時間長度大概為2個月，人數為3個人，內容不多，但是需要寫一些文件（詳細設計與測試結果報告書）。我帶兩個新入職的員工來完成這次的公升級專案。

總結的教訓：　

1.任務的劃分不夠細，沒有明確的劃分出每個人應該負責的部分，也沒有劃分到每個人每天應該完成的工作

2.即使是很簡單的工作，在開始做完第一本之後，就應該相互檢查，如果不進行檢查，最後錯誤的地方就會越來越多，即使是簡單的工作，也不要相信他人不會做錯，要及時檢查

3.不應該在一些技術難點上面去糾結，耗費太多的時間，先完成容易的部分

4.不能每個任務都只完成了一半，最後要花費太多的時間去更改

5.注意第3點和第4點的平衡，問題總要解決，出現問題可以先放著，完成容易完成的部分，但是不能把問題留到最後來解決，最好能在任務完成十分之一左右就解決前面的所有問題，徹底完成那十分之一

6.在任務開始之前要完全的檢視設計書，從頭到尾不要漏掉。其中關於功能實現的部分，不能光相信做詳細設計的人給出的方案，要有自己的判斷，判斷該方案是否會引出新的問題

7.從專案最開始的時候就要弄清楚最後專案要交付的資料。對於內部的指摘，測試遇到的bug要求每個人都要記錄好。大概乙個星期要進行兩次的內部指摘對應，bug登記

8.注意任務管理的過程中，不要出現任務等待的現象，合理分配任務量。不能乙個人忙死，另外乙個人等他忙完

9.作為專案的分配者，盡量留少一點的任務給自己，讓自己有足夠的時間處理專案中遇到的技術難點。如果分配的任務跟組員的一樣，那樣如果組員遇到了問題來詢問自己，或者在哪個地方卡住了，那樣的話，將會沒有時間來完成分配給自己的任務。

10.作為專案的管理者，不要什麼都抓住，什麼都親力親為，那樣到最後你的組員在任務中遇到了稍微難點的地方，就會都扔給你自己，讓你頭大，沒時間處理。任務可以分給組員去做，但是自己必須檢查好，來確保完成的質量。

11.事情都分輕重緩急，分清楚哪些任務是緊急的，那些任務是放到最後去做的。

12.一天的上午或者下午專注於完成一項任務，不要做一會兒這個，又做一會兒那個，那樣效率太低。

13.每天對專案的進度進行整理，防止專案延期。