文章轉自知乎帳號xzh6，表示感謝。

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

在這次對外包人員的管理中，這個問題尤為突出。因為設計文件不夠明確，一些模組的技術流程沒有確定下來，導致開發人員無從下手，影響了整體的開發進度。
以前之所以問題沒有凸顯，是因為開發人員的技術水平高，並且主動性強，對於存在的問題能夠自主找到合適的解決方法。但是對於技術水平一般的成員，沒有明確的技術流程，對他們會很大的影響。
改進方法：
開發之前，由核心人員寫好概要設計說明書（如果要嚴格保證專案的質量，則需要有詳細設計說明書），對於重要的模組，需要明確具體的業務流程和技術實現流程。
如果因為時間問題沒有明確的文件，那一定要開發人員（尤其對於技術一般的開發人員）在開發前畫出關鍵模組的流程圖，然後進行評審，通過後才開始開發。否則會出現設計不合理導致後續變動大或者質量達不到要求。不過對於核心人員的開發，最好也要畫出關鍵模組的流程圖。
針對專案質量的把控，可以通過重點模型評審等方式。

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

目前這個問題很明顯，而且在小公司中也很普遍（大公司好很多）。對於技術的積累，涉及到知識庫的建立，包含軟體模型的封裝、自主平臺的搭建，特定問題的處理方法，技術的積累。
由於沒有知識庫的積累，所以在不同專案中，重用的模組特別少，沒有充分利用已有的資源。同時，一旦專案組人員有變動，對專案的影響特別大。
知識庫的建立方法：
對於知識庫的建立，因為工作量大，如果單靠專案經理來做，肯定是低效的，而且不能持久。知識庫內容的產生，必須由全體成員分享。
需要由專案經理推動，前期做重點模組、技術的積累，並形成文件，分享給團隊成員。並要求團隊成員每週寫技術週報（目前部門已推動了，只是時間長了大家不認真對待，因為沒有很好的反饋和激勵），技術週報可以由成員自主選擇技術點，也可以由專案經理指定，並且明確格式和內容。
可以嘗試將整理的知識點發布至部落格，並且在每週例會中進行點評。
推動的另一個方法是，加大內部的培訓力度，培養團隊內部的分享氛圍。但是這個在專案時間緊張的時候，推動不起來，主講人沒有時間準備。可以嘗試每週限定時間給主講人進行準備（時間緊需要加班）。

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

目前對於專案的管理，還比較混亂，缺少一套正規的、合適的方法，還屬於小作坊式的管理。對於開發和測試，完全憑專案經理的個人意願進行，對於小團隊可能問題不會凸顯，但是對於較大的團隊，就會有很多問題，導致專案進度、質量等不可控。
雖然現在開展了很多專案，但是對於新來的專案，又是按照之前的方式，得不到有效的改善。
改進方法：
專案經理需要抓住專案中的重點事情，然後擠出時間進行專案管理方面的總結，形成文件。並且要善於發現、製造場景挖掘團隊中的問題，讓問題儘量都暴露出來，然後解決並整理總結，然後在後續同樣的問題上進行改進。
每週必須要總結至少一次，如果能做到每天總結整理，那最好不過。並且在後續的管理中，基於已有的經驗進行改善。

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

這一點在做產品的時候尤為明顯。因為涉及到競爭對手、市場的考慮。如果產品做不到好的口碑，那麼只能靠公司銷售的關係，也只能維持短期的利益，得不到真正的推廣。產品讓使用者產生不了依賴，實用性不高，使用者掏錢購買的意願也就沒有了。
改進方法：
平時多從網際網路、競爭對手官網收集行業資訊，試用競爭對手產品或者優秀的第三方產品，然後結合自己的產品進行優略勢分析(SWOT分析)、產品方向分析，借鑑別人的產品路線，以及爭取獲得行業資深人員的幫助。
多接觸行業內的合作伙伴、朋友，從他們那裡獲得行業的資訊。當然，自己也需要事先花時間收集，與他們分享。
另：網際網路是一種很好的資源。

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

很多重要的會議，缺乏會議紀要的整理，導致很多會議上確定的東西以及待做的事情，在會後得不到有效的實施。對於軟體的變更，沒有統一的記錄，這樣在後續的開發和測試中，一旦團隊成員忘記了之前的變更，要追溯就顯得非常困難。
改進方法：
確定會議紀要文件模板，每一次會議認真做好會議紀要。對於會議上確定的事情以及後續待做的事情，專案經理必須要監督，使會議確定的事項得到實施。
對於每一次的會議紀要，除了電子版提交到SVN中，還需要打印出來進行傳閱、備份。