1、第一週階段總結：
目標要明確，即每一項工作達到什麼目標，要提出時間、步驟、進度、質量等方面的具體要求，能夠量化的則要量化，不能量化的也要有質的要求。如果沒有具體要求，只是籠統地提一兩句話，那就不好操作，人們不明白具體目標是什麼、該朝什麼方向努力，就不會有壓力和動力，工作質量和效率就會受到影響。有些目標要求還要落實到擔當者。
2、第二階段總結：
必須將項目任務細化、具體化，然後落實到具體的開發人員的頭上，並制定好明確的開發日程，按照開發日程嚴格監控項目開發進度，固定週期檢查先項目進度，發現項目延遲，直接定位到哪項任務、哪個開發人員發生延遲，延遲的原因，解決方案都明確出來，並要求趕上進度的期限，在該期限內重點監控延遲的任務。
要掌握項目組當中每個人的能力水平，這樣在項目開發過程當中需要調配人員開發任務的時候才得心應手，不至於新手負擔太重，老手過於清閒，平衡項目當中的人員任務量，平均的推進項目進度。
本來打算項目結束之後，召集項目組的全體成員聚一次，吃個飯，不過後來想想，項目都結束了吃飯聯絡感情好像作用不是很大，遂決定，提前到項目的開發關鍵時期之前，這樣可以承前啓後，激勵大家，同時聯絡感情在之後的工作能更好的團結協作。
3、第三階段總結：
一定要保護好項目的核心主程人員，有鋼使在刃上，不能讓這樣的成員將時間花費在文檔，和重複性的編碼工作上，讓他們主要負責解決技術難題。
4、第四階段總結：
開發之前就要確定好開發環境版本，儘可能提早真機或實際情況下的測試，儘早提供系統的原型給客戶演示，找客戶確認，不斷地找客戶確認，跟緊客戶的思路。
哎！鬱悶！項目出現問題了，驗收階段，客戶提出了一些之前沒有的需求，還說這些是我應該早就想到的，崩潰，哪有項目開發的人主動增加客戶的需求呢！真受不了這個四川老了，當初需求一點沒有提，現在驗收階段提出了一堆問題，鬧死個心了，跟開發人員一協調需要整個調整程序結構，連帶着開發需要兩週時間來完成，這個客戶卻只給我兩天還是週末，要求項目按原來流程走，啊！！！我該怎麼辦？？……………………………………問題解決了：只不過要加點班，全當吸取教訓積累經驗了。
5、第五階段總結：
但凡是設計項目需求的相關問題都要以郵件的方式進行確認，並且郵件的標題就要寫明：項目名稱-需求內容，如此做就是爲了日後方便查找，在項目需求出現衝突的時候，可以把又見拿出來作爲證據，切記這一點，凡是確認的東西都要保留文檔，形成資料。
每個不經意提到的要求，都要進行記錄並分析，能不能形成正式需求，能夠形成的，就及時確認，不能形成的也要留好記錄，寫明緣由，作爲以後該需求廢除的依據。
其實，反思自己，也有很大責任，存僥倖心理，對項目的理解不夠，歸根結底還是項目的經驗不足，把握項目的需求能力欠缺，以後要在這個方面加大投入精力，涉獵各個方面的項目。更要站在需求分析師德角度上來考慮問題，而不是站在一個項目開發者的角度，這樣就更能把握項目的需求，如果一個項目坐下來自己都認爲用着麻煩，或者沒什麼用的時候，那麼這個項目肯定很失敗，及時客戶勉強接受，那麼要想達到長期合作希望就很渺茫。
6、第六階段總結：
項目開發之初就要明確的問題：項目開發所選用的語言、開發環境的版本、系統上線之後安裝的系統環境（操作系統版本、輔助的軟件版本環境等），以上這些問題是最基本的需求要明確的問題，如果開發之初稀裏糊塗，到項目結束的階段很可能造成開發、上線、以及後期維護一系列的問題，而且造成這些問題的責任還都要項目承接開發方來背。
領導一定要有威嚴，對待下屬，辦不好做不完的事情，可以再給一次機會，如果還做不好，必須採取懲罰手段（逐出項目組或直接辭退），對待下屬切不可一再的縱容，否則天長日久就沒人聽你的了。
項目終於進入到驗收階段了，由於質量控制做的還不錯，基本沒出現什麼問題，準備週末大傢伙一起聚個餐，增進一下感情，算是宣告項目圓滿結束吧！呵呵！
7、第七階段總結：
項目結束驗收該準備的東西有很多，系統需要統計的數據也有很多，諸如：系統代碼行數、系統畫面數、系統測試bug數、系統測試bug的詳細記述列表、系統開發環境版本、最終的可執行程序、詳細設計文檔等。（注意：這些文檔都要仔細整理，驗收的時候要及時拿出來講解）
項目驗收會議注意事項：
a、首先一定要明確系統的功能範圍，固守住這個範圍，系統就實現哪幾項功能，其他的一概不知道，分清自己的職責，不是自己的活，一丁點都不要沾，一旦沾了，就很有可能會擴大化，進而不可收拾，讓人認爲這也是你項目中的一個部分了。
b、項目驗收會議上，作爲項目開發的乙方，只需要做好兩件事情：1、詳細介紹整個項目週期，每段時間內都完成了哪些工作，如果有延遲需要闡述延遲的原因，但切記不要說由於哪一方的原因，而只針對問題點來進行闡述。2、介紹系統實現了哪些功能，每個功能是怎麼樣的，系統達到一個什麼樣的性能指標等。3、都有編寫了那些文檔，每份文檔的內容都是什麼，做個簡單的闡述。4、詳細闡述都做了哪些方面的測試，測試的點數是多少？測試出的bug都有哪些？現在這些問題都是否存在（這方面設計產品的質量，是客戶所關心的）。闡述完成以上四點之後，就不再發言，配合項目的發起人員來補充說明。
c、如有人提出問題，首先判定是否在本項目範疇以內，如果不在，直接說不清楚、不知道，即便心裏很明白也說不清楚，直接說非本項目範疇，不清楚無法回答；如果在本項目範圍內，則直接闡述本項目的該項需求具體是什麼樣子的，現在項目實現的是什麼樣子的，已經達到了當初項目的需求，不要被人提出的問題帶偏了軌道。總之，記住一點，就是直說本項目以內的東西，相關的和以外的內容一概不談。
d、如有人提出一個功能點的時候，首先判斷是否是本次項目需求以內的，如果是則作答，如果不是直接反駁此功能點並非本次項目需求，如果需要可以作爲下期項目的需求來做，本次項目並沒有。
e、驗收會議上，把了解項目的人劃爲一方，不瞭解項目的人劃爲一方，做總結髮言的時候就說了解項目的人能聽懂的本項目的術語，迴避說不了解項目的人懂的相關術語及業務內容的話，要讓不懂項目的人提不出來問題，懂項目的人，都能夠滿意現在的實現已經達到了開始的需求。
f、注意發言時的技巧（任何會議的場合只要發言都要如此）：1、開場白，再簡單的回憶也要有開場白。2、語速要慢、聲音要大、講解PPT的時候，一頁一頁的講，注意聽者的表情（聽者的表情能夠直接反映出他們是否能夠理解你所說的內容，是表情木然，還是輕鬆點頭）。3、講解的時候重點突出項目最開始的設計意圖、着重點是什麼（這樣做就是爲了圈定項目的範圍，使得之後在討論的時候不至於提出偏離項目的問題）。4、明確會議的目的，對偏離會議主題的討論，及時作出定義迫使其停止（不至會議拖沓，失去中心進而縮短會議時間）。
g、會議上有發言的時候，一定要提前準備，進行策劃，從會議的流程上，發言的內容以及發言的技巧上面進行安排。
今天開了項目的驗收會議，雖然通過了，但是對自己的表現很不滿意，事出突然沒做準備是一個原因，再有就是發言的時候聲音太小，語速太快，聽者表情木訥。說了一些項目相牽連的方面，涉及到了驗收領導業務內的東西，勾起了他們表現業務能力的慾望，提了很多不相關的問題，偏離了驗收這個會議的主題，致使會議時間嚴重拖長。很失敗！前事不忘後事之師！希望通過總結下次再有機會的時候好好表現一下！呵呵！！