試用期的自我總結範文
專案開展大概三個月了。從軟體開發規範的流程的學習開始，到熟悉專案周邊產品，到Demo製作，到系統規格設計，專案所需只是的培訓，到系統需求分析，滲透著我們共同努力的汗水。
專案開展初期，初聞領導對該專案的重視，也感受到了大家摩拳擦掌的戰鬥氣氛，很是感覺良好。猶有繃緊神經，提高鬥志，端槍上戰場的鼓動。轉眼兩個月過去了，鬥志依然昂揚，時刻準備著下一輪的衝鋒
初入專案組，心情忐忑不安，跑起來也沒有方向，抓住一點就使勁的做好，有時候雖然這樣看起來沒有什麼必要，但實事證明這樣確實為以後的工作省了不少氣力。最開始接觸的是軟體程式設計規範的學習，有些同事並沒有太重視程式設計規範，對我而言，我花了很大力氣去學習。雖然我覺得學的行庫，但是收穫也很多，心裡甚慰，同時也覺得路走的踏實。
我們的專案是一個綜合性的專案，集成了公司總多的資料業務產品，最終版本所涉及的產品現在能確定下來的就有28種之多。就說RBT，從最初的瞭解到內部交流到確定整合方案，花去了不少時間與精力；當然這是必須的，對周邊產品沒有良好的理解是無法做出整合該產品的精品出來的。我是我們專案足RBT介面人，初期首先瀏覽了眾多RBT公開資料，並找RBT專案組的介面人申請了其它的RBT資料，在基本比較熟悉這些資料的基礎上，整理了RBT與我們專案密切相關的部分，並在專案組內部開展了一次RBT基礎培訓，以便讓所有的組員都能較好的理解RBT，更好的做好本專案組內與RBT相關的工作。RBT是這樣，其它相關產品也是這樣。
讓我感覺專案開始的第一步是寫作文件“統一Portal配置方法”。主要包括PortalONE組網方案說明，軟硬體配置說明，效能估算分析；組網方案美譽哦費多大勁，主要是teamleader言傳身教，我只是代筆。據的費勁的就是組網圖。就一個用word畫的圖，光畫這個圖就耗去了一個下午的時光，有時候真是不敢想象，僅僅在一份文件中就凝聚著多少人辛勤工作的結晶。效能估算分析也花了不少氣力，參考資料有限，只能憑藉著合理的邏輯推理去定製各種估算模型，再依照估算模型去套用假設前提來進行估算，不知道是對是錯，是否合理，當時也無法考證，心裡有些忐忑不安，生怕因此對專案有什麼負面影響。不過到了後來，才知道估算的還算準確，與別的大致類似的系統性能估算的結果也大致等同，心中多了些許安慰。
經過一段時間的醞釀與準備，專案進入了系統規格設計階段（SDS），我參與了PortalONE系統重要功能原理的'事先的設計工作，由於是初期接觸SDS，再則是專案需求還沒有非常明確的定位，在寫SDS文件的時候犯了錯，將重要功能實現原理寫的比較理想化，偏向與學術論文性質。透過頻繁的與相關介面人有效果的溝通與交流後，逐步的調整了文件寫作的方向和力度，較好如期的完成了自己所負責的系統功能設計。
由於在系統規格設計階段定位的系統是一場龐大與複雜，且專案涉及到眾多的周邊產品，為了儘量降低風險，細緻認真嚴格的評審環節和與周邊產品的有效交流溝通是專案良性進展的保障：自我評審，修改完善，他人評審，修改完善，大家一起評審，修改完善。每天至少十小時的滿負荷運轉，讓大腦甚十疲憊。事情是一點一點的發展的。初期開始總是模糊、彷徨，摸著石頭過河，等走到河中的時候，事情也大致一步一步的清晰起來。系統的核心模組模版管理是我負責的。模版管理是非常重要的一塊，貫穿於整個系統的核心。其他模組與模版管理模組聯絡緊密，模版管理的滯後牽涉著整個專案的進度。我以往沒有相關經驗，一切都是從新開始，時間又是相當的緊迫，沉著穩重的應對中卻收效甚微。在以teamleader為核心的領導下，透過不斷與相應的模組責任人的溝通交流，teamleader提出了一套模版管理思路，並設計除了相應的模版資料庫表。這對一籌莫展的我是極大的鼓舞。在積極領會teamleader的模版思想，與其他專案人員有效溝通與交流後，完成了初步的模版管理的SDS，並給予了其他模組責任人關於模版管理的有效支援，促進了專案良好的執行。
專案如期進展，按照原定計劃，專案進入需求文件階段（SRS）。由於時間的原因，專案下一設計階段只有兩天的時間，只有將設計階段的許多工作提前到需求階段完成。即要在短時間內完成需求階段的事情，又增加了設計階段涉及的許多細節，同時又要保障文件的高質量，這是一個艱鉅嚴峻的挑戰。雖然幾乎抽出每個週末大部分時間，可仍然感覺時間、精力很不夠用。
專案良好的進展有賴於我們共同的努力。按照原定計劃，專案進入了HLD階段，而且很快就進入編碼階段。對於編碼階段的許多技術對我而言是陌生的，struts,velocity,hibernate,iSap等等，這對我的工作進度造成一定的影響。如何充分利用現有資源，在很短時間內將這些技術掌握並有效運用到專案中去，是我後期工作的重點。
願我們的專案一路走好!