專案管理中的問題以及改進方法

》概要設計文件不明確，導致開發人員很多時候無從下手

在這次對外包人員的管理中，這個問題尤為突出。因為設計文件不夠明確，一些模組的技術流程沒有確定下來，導致開發人員無從下手，影響了整體的開發進度。

以前之所以問題沒有凸顯，是因為開發人員的技術高，並且主動性強，對於存在的問題能夠自主找到合適的解決方法。但是對於技術水平一般的成員，沒有明確的技術流程，對他們會很大的影響。

【改進方法】

開發之前，有核心人員寫好概要設計說明書（如果要嚴格保證專案的質量，則需要有詳細設計說明書），對於重要的模組，需要明確具體的業務流程和技術實現流程。

如果因為時間問題沒有明確的文件，那一定要開發人員（尤其對於技術一般的開發人員）在開發前畫出關鍵模組的流程圖，然後進行評審，通過後才開始開發。否則會出現設計不合理導致後續變動大或者質量達不到要求。對於核心人員的開發，最好也要畫出關鍵模組的流程圖。

》缺少技術積累和自主平台，導致不同的專案重用性很低

目前這個問題很明顯，而且在小公司中也很普遍（大公司好很多）。對於技術的積累，涉及到知識庫的建立，包含軟體模型的封裝、自主平台的搭建，特定問題的處理方法，技術的積累。

由於沒有知識庫的積累，所以在不同專案中，重用的模組特別少，沒有充分利用已有的資源。同時，一旦專案組人員有變動，對專案的影響特別大。

【知識庫的建立方法】

對於知識庫的建立，因為工作量大，如果單靠專案經理來做，肯定是低效的，而且不能持久。知識庫內容的產生，必須由全體成員分享。

需要由專案經理推動，前期做重點模組、技術的積累，並形成文件，分享給團隊成員。並要求團隊成員每週寫技術週報（目前部門已推動了，只是時間長了大家不認真對待，因為沒有很好的反饋和激勵），技術週報可以由成員自主選擇技術點，也可以由專案經理指定，並且明確格式和內容。

可以嘗試將整理的知識點發布至部落格，並且在每週例會中進行點評。

推動的另乙個方法是，加大內部的培訓力度，培養團隊內部的分享氛圍。但是這個在專案時間緊張的時候，推動不起來，主講人沒有時間準備。可以嘗試每週限定加班的時間給主講人進行準備。

》缺少專案管理經驗的積累和改進

目前對於專案的管理，還比較混亂，缺少一套正規的合適的方法，還屬於小作坊式的管理。對於開發和測試，完全憑專案經理的個人意願進行，對於小團隊可能問題不會凸顯，但是對於較大的團隊，就會有很多問題，導致專案進度、質量等不可控。

雖然現在開展了很多專案，但是對於新來的專案，又是按照之前的方式，得不到有效的改善。

【改進方法】

專案經理需要抓住專案中的重點事情，然後擠出時間進行專案管理方面的總結，形成文件。並且要善於發現、製造場景挖掘團隊中的問題，讓問題盡量都暴露出來，然後解決並整理總結，然後在後續同樣的問題上進行改進。

每週必須要總結至少一次，如果能做到每天總結整理，那最好不過。並且在後續的管理中，基於已有的經驗進行改善。

》缺少行業知識的積累以及行業資源

這一點在做產品的時候尤為明顯。因為涉及到競爭對手、市場的考慮。如果產品做不到好的口碑，那麼只能靠公司銷售的關係，也只能維持短期的利益，得不到真正的推廣。產品讓使用者產生不了依賴，實用性不高，使用者掏錢購買的意願也就沒有了。

【改進方法】

多接觸行業內的合作夥伴、朋友，從他們那裡獲得行業的資訊。當然，自己也需要事先花時間收集，與他們分享。

網際網路是一種很好的資源。

》缺少會議紀要的整理以及軟體變更的記錄和控制

很多重要的會議，缺乏會議紀要的整理，導致很多會議上確定的東西以及待做的事情，在會後得不到有效的實施。對於軟體的變更，沒有統一的記錄，這樣在後續的開發和測試中，一旦團隊成員忘記了之前的變更，要追溯就顯得非常困難。

【改進方法】

確定會議紀要文件模板，每一次會議認真做好會議紀要。對於會議上確定的事情以及後續待做的事情，專案經理必須要監督，使會議確定的事項得到實施。

對於每一次的會議紀要，除了電子版提交到svn中，還需要列印出來進行傳閱、備份。