告別兩個月的成長
我很慶幸我們那麼努力,一直堅持走到最後。
一直盼望著我能在最後的這個時候感慨地寫下我這篇個人總結,以總結我們這兩個月的工作和付出的努力,我一直在這篇“個人”總結大談“我們”,因為我實在沒有辦法將我這兩個月的工作和我的團隊區分開來。兩個月以來,我們都是以一個強大的團體而堅持走到最後的,這個團隊是由“喜羊羊與灰太狼”Team Dev的七個人和禮平老師、張浩宇老師構建而成的。
請由我自作主張地將兩位老師劃為我們的團隊。
如果沒有兩位老師的協助和鼓勵,我想我們這樣一個“非牛”團隊並不能順利地完成任務。兩個月以來,張浩宇老師一直如我們的一個開發成員一樣陪我們攻破一個個的技術難關,從最開始的小作業、部署VSS開始,每每遇到問題、陷入困境,QQ上閃爍的“棒棒糖”老師,總會及時地給我們帶來有效地解決方案,老師的耐心、指導、和我們一起討論出現的問題、並不時地鼓勵我們,常常讓我錯覺我們的團隊增加了一個這樣的友善的成員,以致每次解決了問題都會忍不住和老師分享。真是抱歉一直打擾老師那麼久,也謝謝老師每一次的協助和每一句激勵,讓我覺得充滿著力量。
真誠的禮平老師,帶給我們的不僅是他豐富的項目經驗,還有他對項目敏銳的洞察力,他的每一次檢查都能及時地給我們反饋資訊,並告訴我們要如何使得我們的項目進行地更有效率。沒有忘記老師在課堂上教會我們的要簡化問題,無論是我們的項目還是我們做人。我們就是照著簡化項目的思想,將問題逐步分解,最終制定詳細的計劃而確定我們的開發。而讓這一次開發不僅僅成為一個課程的原因就是老師一直強調的創新,讓我們在開發的同時,不斷積累和學習別組的優秀,並不斷找尋我們的亮點,我們一直在努力用我們有限地技術力量使得我們的項目與眾不同。而在這個過程中,老師一直強調每一組都可以成功,並給我們提出了很多可行的建議,給予我們堅持下去的信心。
作為專案經理的我,從一開始就那麼真誠地希望能通過自己的努力讓我們組裡這樣一群內斂的開發人員發散他們的光彩,事實證明,我們的開發人員確實有如此多的閃光點,哪怕我的努力那麼微小,這樣亮點最後在我們的項目得到了有效地體現。
雖然只是兩個月不到的時間,我卻從我的老師和團隊成員那收穫了太多。
(一)計劃
首先,不得不讓我談及的就是計劃的重要性。在第六周禮平老師做初步驗收的時候我們已經能夠拿出一個基本的系統,而在後期很多組忙著趕代碼的時候,我們的過程只是在不斷地最佳化和創新。這很大一部分原因都源於我們詳細的計劃。在制定我們最初的開發計劃的時候,我們的架構師就給我們畫出了詳細的WBS圖,使得我們的任務分解可細化到每個人每個頁面。在每個裡程碑之後我們都能依據實際的開發情況,制定更為詳細的計劃。詳細至每天,每個功能點,每個文檔的細節處,我們的計劃不僅是口頭上的協定,而是通過落實在我們的計劃文檔上,讓每個人的工作能夠落到實處,督促著大家按照計劃有序進行工作。
這些計劃讓我們的每個模組都能落實到負責人,使得我們的變更和反饋能夠更加及時。若沒有詳細的時間計劃和任務計劃,我們的團隊再強大,都不能如此有序地完成這個項目。計劃在我們這次的開發過程中起到的支柱作用,讓我對軟體工程過程有了更為具體的瞭解。
(二)需求分析
若說我們系統遇到的最大的問題,追其根源,莫過於我們對需求的不夠重視。不得不承認,我們到後期開發確實遇到了很多的問題,等系統完成後我們竟發現還有商務程序沒有很明確的地方,比如書城的網店關閉後那麼該店的書籍如何處理,店長添加書籍是否能夠添加重複的書籍,店長刪除書籍時哪些書籍是能刪除的,哪些事不能的,刪除後訂單、借閱請求、收藏夾、購物車中的資訊如何處理。
有幸的是,我們及時地發現問題,通過努力和加班,問題也得到瞭解決。通過總結,我們發現原因竟然出在我們項目開始的時候,大家做需求分析和進行需求瞭解時僅僅考慮準系統塊,而至於塊與塊之間的聯絡,具體的書店處理流程我們卻沒有深究,而導致我們到後期花費了大量的時間用於修複之前沒有考慮周全而帶來的問題。
正如禮平老師所說,我們現在不怕遇到問題,甚至遇到的問題越多越好,因為現在允許我們犯錯,而以後真正在工作中卻沒有這樣的機會了。
而我感謝這些錯誤,讓我重視起需求來,儘管從軟體工程的課程學習開始,到我們上需求分析建模課程,老師不斷強調需求的重要性,但我卻至始至終沒有引起注意,以致於我錯誤地帶領團隊極其迅速地跳過了需求這個環節。當真正在項目開發中遇到問題時才發現理論不僅僅是理論,它往往是有實踐在支援著它,我想需求的重要性,是眾多的項目開發都能夠得出的一致結論。在我們的這個小項目中同樣如此。
(三)責任與態度
能遇上這樣的團隊是我的幸運,我想很難再遇上這樣一群如此有責任心的人,一直記住幫我們解決問題的老師,哪怕是深夜,我們提問,老師都會一一解答;關注我們項目進行並提出有效建議的禮平老師;一直要幫著我們攻破技術難關的美工;為每一次版本勞苦費心的部署經理;專業的測試經理;細緻認真不知疲倦的產品經理;嚴謹敏銳的架構經理;虛心學習的開發經理。
讓我驚奇的是很少有老師說的只有部分人工作的情況,每個人都十分重視這個項目,都原意為自己的模組coding到半夜,當別的組還沒有進入狀態,沒有開始開發的時候,我們經按照進度計劃完成了我們前期的任務,進入到了我們開發中期。最難的是開發的那兩個星期,每三天一次的整合,我們從未間斷,每次我都不忍心催促大家交代碼,然而總是能夠順利地整合成功,沒有人會說我的模組非常難,我不能完成,我要延期的。我們都沒有開發經驗,然而憑藉著大家對於項目的熱忱與責任心,最後我們都7個人學會了.net開發的基本知識,我最後發現在修複bug的時候,我們美工竟然能夠很快地解決一個我想了很久都沒弄懂的問題。
團隊這樣的這樣的責任感讓我到後期都不願意將工作分配下去,因為我知道大家都會花費很多時間和精神,甚至犧牲自己所有的休息時間。
別人可以嘗試這在我們的系統進行大量的資料輸入,可以嘗試一些破壞性的操作,你會發現我們小到使用者輸入的電話號碼,我們都進行了嚴格的控制,要幾位長度,是不是可以包含區號,手機號是否以13或者15開頭,我們的開發人員都經過了嚴格的處理。而在最初是我不能理解的,我覺得應該以大的功能點為主,而這樣的細節我們大可不必考慮,直到第六周老師檢查的時候,問到之前示範的組是不是進行了資料控制,你的文字框是如何處理的,你的輸入資料可以是多長,你購買書籍可以購買多少的時候,我竟然發現我們組竟然都有考慮到。團隊成員的這樣認真的態度讓我深深地折服,這是我一直都缺少的,也是我在這個項目開發過程中從我們的團隊成員學到的重要的一點。
(四)專案管理
我是一個那麼一個粗心的人,當我小心翼翼地當上這個小小的專案經理,我一點信心都沒有,我只有不斷地督促自己不斷地制定自己的小組的計劃,在項目初期的,每晚睡覺之前總會把項目前幾天的進展在腦子裡過一遍,把自己的計劃回憶一遍,反覆計劃第二天的工作,導致剛開始的一周多,常常處於失眠狀態。
然後當知道了我們採用的是MSF開發模型的時候,我彷彿鬆了一口氣。因為MSF提倡小組內明確分工,角色平等,我以為這樣就沒有了做專案經理的壓力。然而在第一周的工作總結我發現了問題,並發現自己的理解出現了偏差。
MSF固然有它的優勢,然而我們的團隊必定要做適合我們自己的改動,小組成員提出我們需要一個人帶領,需要有人組織,我開始給自己正確地定位,瞭解自己的重點是加強開發人員之間的溝通,監督進度的施行,監控項目中隨時可能出現的問題。謝謝這次項目開發,讓我對與項目更具洞察力,現在要讓我接受一個項目我想起碼不會再如之前那樣迷茫,也能提前感知一些項目中即將出現的問題。在給自己定位的過程中,組員給予了我很大的支援,他們也開始給自己定位,明確自己的職責,瞭解並確定小組中自己的主人地位。
事實證明,適合自己團隊的方式才是最好的項目開發方式。
(五)溝通
小組給我這樣好的機會讓我能過成為團隊中的專案經理,讓我能夠在小組中起到溝通團隊的作用。
我也曾暗暗和自己生氣,因為常常在同一時間有人提出發現的問題,有人要改系統,有人對文檔提出疑問,有人對計劃提出質疑,有人遇到問題需要溝通,我會慌慌張張然後遺漏到一部分問題,也會因為手忙腳亂態度不好。事情結束之後自己又會很自責,小組的成員卻用行動告訴我他們對此理解,讓我在後期能夠自信地做計劃,能夠解決任何溝通的問題,讓我有動力地堅持解決問題。所以,在此,團隊成員告訴我最好的溝通基礎是理解並用行動來告知對方你的想法。
雖然我們只是7個人的小團隊,可是我們也會出現溝通障礙的時候,比如說我們在邏輯上有關人員進行了處理了,而美工方面卻不得知,兩邊不能一致。所以每周的例會、每次的臨時會議、我們的gmail工作平台、實訓平台、QQ群,飛信群,讓我們的溝通更加便利。我們用我們周圍可利用的眾多工具來加強我們之間的聯絡。我想在這點上我們算是物盡其用了吧。
溝通的重要性是不言而喻的,在處理團隊溝通的過程中我更願意用面對面的方式與某個人進行溝通,願意以文檔的方式與整個團隊溝通。因為開發過程中的事實告訴我往往面對面的交流更能讓對方瞭解你的想法,若有疑問也能當面解決。而對團隊的時候文檔的方式更具有效率且不易造成理解上的不一致。
這篇個人總結實有寫感謝函的嫌疑,因為這些這些收穫是我之前沒有預想到的,在這個開發過程中我也確實有太多感謝的人。兩個月以來,我得到的收穫到的其實遠不止我在這篇總結中所提到的,所有的這些經驗教訓都會成為我以後工作生活的重要依據,而在這個過程中建立起來的與老師、團隊成員的友誼也是我倍感珍惜的。