如何有效地幫助新人融入專案中

2021-06-06 08:15:31 字數 1360 閱讀 5923

今天看了《布道之道》,裡面有些提到的很多經驗的確很實用。不僅又想起了,在剛剛參加工作時,在第一家公司裡就進行了如何提高溝通效率的培訓。當時很多都以自身的經歷,說明了溝通的重要性,也分享了一些溝通技巧。前幾天,有新同事加入到專案中,來參與其中乙個日誌分析軟體模組的開發。這次,我並沒有親自給他講解,而是讓之前參與到這個專案的另外乙個同事給他講解。我只是在一旁靜靜地聽他們之間的交談,同時我也在思考如何可以讓新同事快速地融入到專案中。

新同事的學習和領悟能力自然是非常重要,然而乙個好的「師傅」能夠帶他進門,也會極大降低學習的門檻。在這裡,分享一點自己的心得,我一般按照下面幾步進行介紹,而我自己在進入到乙個新專案中一般也是按照這幾步進行學習的。

在這個環節,我會介紹為什麼會有這個專案,專案的目標是什麼,當前的狀態以及專案組的組織結構等。這裡,一定不要忘記把當前的產品展示新同事,使其有乙個直觀的印象。

雖然我們都是搞技術的,但是對於乙個新同事,一上來就直接深入細節而拋開專案背景,顯然是不合適的。因為,乙個人是否可以把事情做好,除了取決於他的技術能力;還和他是否對專案或者業務方向有認可度,是否願意投入精力去用心讓專案成果。如果乙個人對專案本身的目標都不認可,怎麼可能會做好呢。

介紹了專案的相關情況以後,對於有經驗的開發者來講,一般都會在腦海基於原來的經驗有乙個大致的實現思路。那麼這個時候,就可以介紹專案開發用到的技術有哪些,這些技術大概都用在什麼地方。

以上兩個方面都是從巨集觀的角度進行總覽,下面就要深入到細節中了。

在這裡,我可能會開啟工程目錄,介紹工程的組織結構,每個資料夾以及某些重要檔案的作用。對於有過類似專案經驗的同事來說,相對比較容易理解,而對於經驗相對缺乏的同事來講,可能只是有乙個簡單的印象,還需要在以後的工作中不斷的加強印象。

雖然很多專案大致相同,但是還是有很多細微差別之處。這個時候,我就會拿乙個具體的功能,從頁面到控制層,再到服務層,在到資料層,最後到資料庫,完完整整地講解一遍,把相關的**檔案都串起來。在這裡,尤其要告訴新同事,如果新增乙個新功能時應該新增、修改哪些檔案,這些檔案之間的對應以及呼叫關係是什麼樣的。

經過這一步,即使經驗不是很豐富的新同事,也可以照貓畫虎,做出乙個簡單的功能。

功能完成以後,自然是要上線測試的。一般情況下,在專案中都會生產、演練和測試等幾套環境同時執行,本地編寫和測試完成的**,還需要發布到測試和演練環境中進行測試,確保更改有效。於是就需要,告訴他打包、發布和測試的步驟。

在上面的五步中,肯定會有一些問題積累下來,這個時候就可以對這些問題進行深入討論,加深對某些部分的深入理解。如果有些問題,我無法解答,就會帶他找到這個方面比較有經驗的同事,進行請教。

作為當代的程式設計師,我們不但要會寫**,更要能夠把我們的經驗傳播出去,那麼溝通能力的提高就是很緊迫的了。

另外,作為過來人,我想對這些過來人說一句,多給新同事機會。在幫助新同事的同時,也是提高我們自己能力的時候。

如何有效地幫助新人融入專案中

今天看了 布道之道 裡面有些提到的很多經驗的確很實用。不僅又想起了,在剛剛參加工作時,在第一家公司裡就進行了如何提高溝通效率的培訓。當時很多都以自身的經歷,說明了溝通的重要性,也分享了一些溝通技巧。前幾天,有新同事加入到專案中,來參與其中乙個日誌分析軟體模組的開發。這次,我並沒有親自給他講解,而是讓...

如何有效地報告Bug?

simon首先列舉了一系列拙劣bug報告的例子,包括 接著,他點出了報告bug的目的 在bug報告裡,要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話,您可以省去推測,但是千萬別省略事實。然後,simon針對bug報告的不同問題分別提出了自己...

如何有效地報告Bug?

作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法,他列舉了一系列拙劣bug報告的例子,並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子,包括 接著,他點出了報告bug的目的 在bug報告裡,要設法搞清什麼是事實 ...