在連續封閉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． 開發規範
據我了解，還是有一些公司沒有乙個統一的開發規範，**質量的好壞都是由個人的開發經驗決定的，我現在的公司在我來之前就是處於這種狀態。在這個專案中，因 為進入開發階段後還在招聘人員，能力參差不齊，而且有一部分是沒有開發經驗的，這就對**質量提出了挑戰。為了能提高**開發質量，我們引入了開發規範， 制定了開發過程中的一些規則，所有成員都要求按照這個規範進行開發。雖然成員在剛開始時受制約而感覺有些麻煩，但這樣的開發規範，不管對於專案還是整個公 司，都是重要的。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...