在連續封閉N個月以及再后來的N個月的加班后，項目終于以延期N個月的結果結束了。不管曾經發生過什么，不管項目是否延期，重要的是項目結束了，所有的項目成員都可以松一口氣了。曾經和同事開玩笑說：在我經過過的失敗項目中多了一個項目，以后就能避免同樣類型的失敗了。同事們聽了，都笑了。在那段時間里，很久沒有聽到過同事們暢快的笑了。

　　現在，我以我目前的知識水平，總結一下項目中存在的問題，這些問題的出現也不是一兩個因素造成的。當然，專業水平太低，也總結不出什么高深的內容。不管怎么樣，也算是對項目的總結吧。這里先總結一下我認為的問題，項目值得學習的方面將在下次總結。?

　　1．?項目計劃的制定

　　我不是很清楚是否在一開始了解過這個項目的規模，估算過項目的成本和工期以及資源和技術的可行性。當我進入這個項目的時候，就被告知項目在3個月內完成，當時我們正在客戶方做業務需求了解。（說明一下，3個月的時間是在項目開始之前公司決定的，而并沒有經過項目組成員根據功能估算以及項目經理的綜合制定） 也不知道了解的情況是不是這樣，但不管怎么樣，在還沒有了解項目的功能就做好了項目的開發時間，這樣項目的風險性是否較高呢？這樣導致的結果是開發人員按照規定的時間制定開發計劃，最后發現項目規模較大，很多功能也都沒有按期完成，也很難按期完成。不但無法按期完成，為了趕進度，代碼的質量也就得不到保證，某些項目組成員有推倒重寫的沖動。（代碼質量也不止是計劃導致的，還包括個人的開發經驗） 如果不是項目經理超強的管理控制能力，我想項目也不會有結束的日子。?

　　2．?開發團隊的穩定

在業務了解階段，項目組所需要的人員還在招聘中沒有全部到位。進入界面原型開發階段，項目組新近N人。在封閉開發期間，又加入N人，同時，也有N人離開。項目在開發的中前期團隊就沒有得到穩定，導致工作進度和計劃的不一致。而且，每次來增加人員后，都得進行相關的培訓和業務了解。同時，人員變更導致不同的人都接手過同一模塊，造成代碼維護的難度加大。?

　　3．?需求了解

?????? 為了趕項目進度，二是對業務的不了解，三是業務人員業務掌握的差異，在沒有全部了解并消化的情況，項目組進行封閉開發。同時，相關人員也在繼續了解其他的業務。這所有的情況，導致開發期間發生過N次的設計變更，程序無數次的改動。而且，在開發的后期都發生過業務不斷的改變的情況。?

　　4．?總體設計把握

??????? 項目缺乏總體設計的把握，每個人都是只了解自己那塊的東西，其他的模塊也不了解，在做設計的時候，也考慮不到其他模塊的影響和需求。當兩個模塊之間有交互時，更多的是兩個模塊負責人之間的溝通和交流。而且模塊之間的交互設計是放在各模塊開發差不多的情況下進行的，后面涉及到的改動也就不可避免。現在模塊之間的交互，也許是各模塊負責人最頭疼的問題了。（當然，這個問題也不的存在也是無奈，時間緊迫，而且業務不熟，設計也就自然存在缺陷。）?

　　5．?引入第三方技術

?????? 引入第三方技術，是受到項目進度、業務功能和公司所能提供資源的影響，也是不得已而為之 。在經過簡單的測試后，就投入項目中使用。值得慶幸的是，第三方技術的引入，還沒有對項目造成太大的影響。但是，我們也應該意識到引入不熟悉的第三方組件給項目造成的風險。?

　　6．?沒有嚴格的單元測試

?????? 因為每個成員經驗的不同，代碼的質量不一樣，單元測試是很有必要的。也不能說沒有進行單元測試，每實現一個函數都會進行調用，如果得到想要的結果，那就算成功了。但這還不夠，我們很少進行邊界測試、不合理數據輸入測試等，最后在系統測試階段，出現了很多不應該出現的錯誤，比如什么對象為空的調用、錯誤數據等，造成剛開始的測試進度非常緩慢。（沒辦法，項目工期太緊）

　　下面主要總結一下項目成功的可能因素，比較膚淺。
　　雖然項目受很多不利的因素的困擾，但最終還是交付給用戶使用，不管怎么樣，這中間還是有很多值得思考的方面。

　　1．? 項目經理

　　這個項目經歷過很多的困難，從一開始的人員沒有到位，到被限定的項目時間，再到需求的不完善等。如果不是項目經理超強的全局把握能力和領導魅力，不論是在封 閉期間，還是在那段加班的日子，依然保持團隊的團結和斗志。因為這個項目經理，團隊核心人員都沒有離去，心甘情愿的跟著他把項目完成。有一個好的項目經 理，對項目來說太重要了。當然，項目的每個成員都很重要。

　　2．? 團隊的團結

　　我們這個團隊，是一個年輕的團隊，因為這個項目而組建的，還有一部分成員是沒有任何開發經驗的。面對很多不利因素，所以能夠完成這個項目，很重要的一個原因是團隊的團結。封閉的N個月以及加班的N個日夜，雖然很艱苦，但是卻是我們團隊最懷念的日子。大家在一起，同甘共苦，一起培訓，一起交流，一起熬夜，一起吃方便面，一起玩CS，痛并快樂著。即使中間因為討論而出現過爭吵，但從來沒有影響過成員間的感情。

　　3．? 寬松的管理

　　我的意思并不是說管理松散，而是項目組的柔性管理。在項目開發期間，我們因為某些事情而無法及時到崗時，都會獲批處理事情，只要在以后的工作中將這次落下的 工作及時完成，不影響項目計劃。我感覺這樣的管理方式，至少在我們這個團隊執行的很成功。我們不會偷懶，相反我們會更加勤奮地工作，回報領導的信任和關 心。因為解決了后顧之憂，我們還有什么理由不全身心投入到工作中呢？

　　4．? 二次開發平臺

　　在這個項目中，我們引入了二次開發平臺。雖然二次開發平臺因為時間的原因，并不是很成熟，中間也出現過一些問題，但二次開發平臺在我們項目開發中還是起到了 很大的作用。通過使用二次開發平臺，規范了部分的代碼開發，減少重復勞動，強化代碼復用，讓開發人員更多的關注，模塊功能，從而提高了開發效率。如果沒有 二次開發平臺，也許我們現在還陷入在開發的泥沼中。

　　5．? RUP開發過程

　　按照以往的軟件開發經驗，項目一般都會采用瀑布模型，未必是嚴格按照瀑布模型的規定的一個階段的結束是另一個階段的開始，但大體都是按照這個過程安排項目計劃的。在這次軟件開發中，我們引入了RUP軟件開發過程，采用迭代模型和快速界面原型等開發模型，制定項目里程碑和迭代計劃。雖然并不是嚴格按照RUP規定的迭代進行，因為資源的有限和團隊的年輕而有些變味，但還是有效地解決了一部分項目風險。

　　6．? 開發規范

　　據我了解，還是有一些公司沒有一個統一的開發規范，代碼質量的好壞都是由個人的開發經驗決定的，我現在的公司在我來之前就是處于這種狀態。在這個項目中，因 為進入開發階段后還在招聘人員，能力參差不齊，而且有一部分是沒有開發經驗的，這就對代碼質量提出了挑戰。為了能提高代碼開發質量，我們引入了開發規范， 制定了開發過程中的一些規則，所有成員都要求按照這個規范進行開發。雖然成員在剛開始時受制約而感覺有些麻煩，但這樣的開發規范，不管對于項目還是整個公 司，都是重要的。

總結

以上是生活随笔為你收集整理的艾伟也谈项目管理，项目做完了，总结一下的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。