RojerChen 2011.03.22

在過去，只要微軟有相關的研討會，只要時間上許可，我通常都會報名參加，而我覺得這一次是我歷次參加相關的研討會來說，我最喜歡的一次。



雖然活動的題目看起來好像相當嚴肅，不過在討論的過程中，完完全全的不向題目這樣嚴肅。我覺得在這次的研討會中『不談政治、不談技術、只需要嘴砲就好(誤)』。在台上的MVP各自分享各自的工作經驗，在會議中笑點不斷，絕無冷場，這一整天的分享絕對可以讓大家在未來的工作尚少走不少淵望路，如果沒來真的是相當可惜。

以下是參加研討會的一些心得：



在 IT 界，專案經理或是IT主管是非常重要的，他們除了需要強勢之外，並且要能夠承受得住壓力、留的住底下的人才並且要能夠說服老闆。如果不強勢，容易被老闆或是客戶牽著走，這樣專案永遠無法有完成的一天。在專案開始後，每一位專案的成員都非常重要，不要輕易地更換專案成員，因為換了人之後，會帶走專案的 Domain Knowledge，相關的知識要再教導和累積更是不容易。

如何能夠有效地取得使用者需求？除了『溝通』之外還是『溝通』。在溝通上，要確保客戶與團隊成員用『同樣的語言』，避免發生我要蘋果你給我西瓜的這種狀況。在做需求訪談的時候，有很大部分的使用者是無法知道自己所想要的系統要如何設計，所以要盡可能貼近使用者的日常作息，和不斷的詢問來了解客戶的需求。當然還要配合 issue Tracker 和 source control 做議題的紀錄與程式版本的控制。

在作需求的時候，到底要到甚麼時候才進行開發呢？如果『功能項目明確且獨立』，這樣些部分就可以提早開發。而那些功能項目會彼此牽連，在處理過程中會相互影響的，開發的時程就會排在後期再作開發，這樣功能與規格也會比較明確。

對於開發人員來說，寫文件是非常痛苦的一件事情，通常都是程式寫完之後，才開始補文件。寫文件是非常重要的，特別是寫那些給 RD 看的文件，能夠寫得出文件來，這樣工作項目才能夠明確化，這樣工作才能夠分配給夥伴來作執行。有時候在工作交接的時候，有文件也比較能夠了解目前系統的架構與功能項目。

對於自己所寫的程式碼，要能夠負責並且追求品質。先透過自我測試，再經過 QA 測試，和 Code Review。有時候在我們處理其他人的 Bug 的時候，先別看程式碼，『先固定 I/O』，看看 input 資料進去後，可以產生出哪些 Output 出來，看看結果正不正確，再決定是否要看中間的這段程式碼。

有時候我們覺得 Debug 永遠比寫 Code 還要困難，就會選擇重寫。絕對不要有這種想法，因為過去累積出來的知識都累積在程式碼裡面中，如果重寫就等於把過去累積的知識一併拋棄掉。可以參考以一下過去我寫的心得約耳趣談軟體-讀後心得 - Ch24.你絕對不應該做的事之一。

在 IT 界，每天都有新的技術和名詞出現。對於這些新名詞有基本的認知就好，當你需要的時候，要能夠在短時間內快速學習。選擇認識這些新名詞，要著重在這些新名詞可以增加自己知識領域的廣度與深度。

專案的進度要如何掌控？ 以這種大腦密集的產業是很難評估專案的進度。列出專案的時程、Bug項目表都只能作參考，Code Review也是其中的一種方法，在專案的運作上絕對不要輕易換人，因為換人會讓整個專案的風險上升，更容易失敗。

如果要當顧問，要具備專業、規劃與解決問題的能力。從專業的角度分析、選擇最適合的方案來執行。身為團隊的顧問，要能夠了解團隊的成員，了解有誰可以用，並且評估專案的風險與需求。口才、規劃、專業、解決、行銷與專案管理這各種面向都是身為顧問所需要獲該具備的。

最後我想到會議中百敬老師所說的：『你要問自己你對 IT有沒有興趣，有興趣才可以在這行走得更長更遠』，這次的研討會真的相當精彩，希望以後能夠有這樣精采的研討會。