從事IT行業(yè)的工作已經(jīng)6年多了，從當初的測試人員和碼奴，到開發(fā)小組管理者，再到現(xiàn)在的項目經(jīng)理（筆者成長比較慢⊙﹏⊙b汗），期間經(jīng)歷了N多項目也發(fā)生了N多的事。下面便說說筆者帶過一個項目的總結，希望對各位能有些啟發(fā)。
那是在2009年2月到2009年7月本人作為一個500強的日企做協(xié)力員工時的一個項目，做番號管理業(yè)務系統(tǒng)，項目的主要工作就把以前N個工廠書面化的番號管理改造成WEB管理系統(tǒng)，項目成員有6個人。
本著培養(yǎng)本社員工的思想，項目團隊有如下成員組成：
項目成員A：一個剛從日本回來的經(jīng)驗者，業(yè)務和系統(tǒng)框架完全不熟悉。
項目成員B：一個工作2年的本社員，做個幾個項目但是人浮躁，有超多不良記錄。
項目成員C：一個工作1年的本社員，做了1年的配置管理和移送管理，沒有開發(fā)經(jīng)驗。
項目成員D：剛畢業(yè)的本科生。
在項目前期要件分析時雖然是大家一起開會理解要件，但是由于時間緊要件分析理解文擋是由我和A一起做的。別人則去學習我們做成要件分析理解文擋。之后便開始做設計書，在review設計書時，我發(fā)現(xiàn)組員竟然還不理解自己負責那塊到底要做什么，為什么要這么做，
我只好一個一個的說明，為了趕上進度，大家連續(xù)1周多加班到12點。
總結1：為了避免再出現(xiàn)這種情況，在前期要件時一定要確認，所有人對自己的那一塊是不是已經(jīng)掌握了，并且用開會的形式讓每個人講自己負責的那一部分。
因為全球經(jīng)濟危機爆發(fā)，公司提倡快速開發(fā)，即只做一本設計書，基本設計和詳細設計的結合體，由于組員大部分是新人，設計書偏重于代碼級的詳細設計。在我們把設計書交給日方確認時，回信說負者后期維護系統(tǒng)的人員看不懂。因為后期維護系統(tǒng)人員都是業(yè)務出身，并沒有過編碼經(jīng)歷，為了使里程碑不延期，決定在項目結束后抽出2周時間（無償，都是眼淚呀），根據(jù)現(xiàn)有的式樣書再做一份偏重業(yè)務的式樣書。
總結2：設計書作成前，定下設計書格式和寫法，不只同日方項目開發(fā)負責確認，還要同后期維護人員確認設計書的寫法。
項目組大部分是新人，所以我承擔了核心業(yè)務的設計和編碼，同時還要負責管理，再做代碼check時只把C和D代碼做了檢查，對于A和B只是抽出部分檢查，在測試時B的Bug遠遠多于其他人，因為B以前有過不良記錄，所以只給他安排以前做個相似的機能，并把之前的設計書，代碼給B參考，但B還是出了最多的問題。
總結3：盡力檢查所有人的成果物（對于有不良記錄人的成果物，必須全部檢查）。但是，如果是大型項目沒有時間來檢查所有的成果物，只能層層檢查，重點檢查有不良記錄的人。
以上是我的項目總結（之類的）
和大家分享這個項目管理中的小故事，希望能對大家有所幫助。