iT邦幫忙

2021 iThome 鐵人賽

DAY 28
1
Software Development

全端工程師生存筆記系列 第 28

[職場]新工程師報到,如何協助他成為有效戰力

我一定要把你帶好,如果我不把你拉上來,那誰把我推上去。

每間公司在新人教育訓練上,願意投資的資源落差很大;有些有完整的制度與流程,讓新人一步步走上軌道;而有些則是放牛吃草,讓他自行摸索。

筆者這幾年觀察下來,除非新人天賦異稟、經驗豐富,不然讓他自行摸索其實是跟自生自滅一樣的。作為公司的前輩,也許我們可以換位思考:「如果今天到了一個新的工作環境,我希望可以得到哪些幫助?」

大綱

  1. 新人報到前的準備工作

    • 1.1 申請 VPN 連線
    • 1.2 註冊公司內部協作平台
    • 1.3 設定內部 Server 登入權限
    • 1.4 整理技術相關文件
    • 1.5 整理工作相關文件
  2. 新人入職後的協助

    • 2.1 讓新人對公司有好感
    • 2.2 了解新人的能力,用合適的方式做教育訓練
    • 2.3 最終目標是讓新人有獨立作業的能力

1. 新人報到前的準備工作

隨著公司的擴張,會有越來越多人加入團隊來分擔你的工作,此時你需要準備交接文件,以保證他們會成為團隊中的神隊友;而不是增加你工作份量的豬隊友,這篇文章我會列出自己在交接時準備的東西。

1.1 申請 VPN 連線

因為疫情關係,越來越多公司的 IT 部門採取遠端工作,但許多工作上的資料以及開發環境都在公司內網

所以在新人報到前,你要先幫忙申請 VPN 帳號,常見的 VPN 連線方式有 PPTP、L2TP。

這邊筆者要特別提醒一下,因為安全性問題,Mac 從 Catalina 這個版本開始就不支援 PPTP 的連線;建議還在使用 PPTP 來做 VPN 連線的公司,可以考慮換一個更安全的連線方式。


1.2 註冊公司內部協作平台

如果公司內部有專案管理系統(ex:Jira、Zentao、Redmine)或是軟體開發平台(ex:GitLab),請先幫新人註冊好帳號,並列成清單讓他們知道不同協作平台的功能。


1.3 設定內部 Server 登入權限

通常會根據專案的測試進度部署到不同環境:

  • DEV 開發環境
    工程師內部開發與測試使用,功能穩定性不高,但版本都是最新。
  • QA 測試環境
    工程師開發完成,並通過自己 Unit Test 的驗證後,會交給公司的測試團隊在這個環境做各式各樣的測試。
  • PROD 正式環境
    測試部門確認功能穩定且通過壓力測試後,就能部署到正式環境。

這三個情境會對應到不同的 Server,筆者建議一開始只給新人登入 DEV Server 的權限,等到熟悉環境後再慢慢把 QA、PROD 的操作權限給他;避免新人在不熟悉環境的狀態下操作,導致不可挽回的後果

備註 1:建議設定 alias name 來登入 Server,用 ip 登入只要一時眼花手滑就可能導致悲劇。

備註 2:如果公司有導入 K8s,由專人負責部署作業,就能大幅降低錯誤操作的可能性(通常 QA、PROD 除了環境變數外,其他設定都是一樣的,以此保證部署的穩定性)。


1.4 整理技術相關文件

  • Coding Style(程式碼風格)
    一樣米養百樣人,工程師來自五湖四海自然風格迥異,公司可以使用 ESLint 這類工具來約束風格,但程式碼的效能、長度、分類…很多事情還是需要有前輩跟新人說明。
  • Deploy 的方式
    如果團隊有導入 CI/CD,你就要跟對方解釋清楚哪些 branch 在 merge 時會自動 Deploy 到對應的 Server

    警告:如果有設計這種依照 branch 更新做自動部署的功能,建議將新人的權限設定為 Developer;避免他推送更新到受保護的 branch。

  • 專案文件
    大概可以分成:專案架構文件、API 功能說明文件、過去開發的需求規格這 3 種;基本上這些文件是為了讓對方快速了解專案的結構,而不是讓他了解每一行程式碼的意義。
  • 會用到的相關技能
    假設公司今天來了一個後端工程師,他過去的工作經驗是用 PHP 開發,但現在公司的專案是用 Node.js 開發;儘管都是後端工程師,但兩者的技能樹存在一定的差距
    如果知道新人有這種狀況,除了「相關技能」外,我還會準備「基礎知識」的學習連結,讓他可以快速上手,舉例來說:
    • 基礎知識
      • Node.js 的 iT 邦幫忙鐵人賽系列文。

        由有經驗的人來挑選學習素材,較能分辨誰寫的文章更適合新手入門。

    • 相關技能
      • 如何用 POSTMAN 測試 API、切換執行環境、建立 Mock Server,連結
      • API 文件的撰寫格式,以及產生的方式。
      • 團隊 Git Flow 規則。
  • Debug 的基礎知識
    筆者發現有些新人缺乏 Debug 的基礎能力,講解了好幾次他還是跑來問你類似的問題;我相信這個問題不只發生在筆者身上,所以建議大家可以寫了一份文件說明 Debug 的基礎知識,內容包含:
    • 如何印出錯誤訊息。
    • 設計程式斷點,縮小錯誤範圍。
    • 理解錯誤訊息。
    • 判斷是因為程式邏輯造成的錯誤,還是運行環境導致的問題。
    • 解決問題的方向,可以參考的資源。

1.5 整理工作相關文件

  • 列出例行公事清單
    列出團隊、部門、公司的例會時間點,並簡述參與人員、討論內容;讓新人日後參與會議時能搞清楚狀況。
    如果有要繳交週報、月報,會說明繳交的時間點並提供撰寫格式。
  • 列出待辦事項
    新人會協助或接替你的工作,因此你可以先將手中待完成的任務做一個難易度排序,先將簡單的任務交給新人,觀察他的完成度及適應性
  • 提點行政庶務
    新人剛入職時誰都不認識,印表機不知道怎麼操作、專案管理系統不會用、電腦不會設定開發環境;你可以撰寫「秘笈」讓他了解遇到問題時可以向哪個窗口提問
  • 了解團隊中每個人的職權
    以一個雲端開發團隊來說,你需要讓新人知道遇到前端、後端、資料庫、伺服器...的問題時要找誰,讓他了解團隊每個人的職權,才能讓新人更快的融入團隊。
  • 保密協議
    如果公司開發的專案有其機密性,記得提醒新進人員不可洩露專案內容。

2. 新人入職後的協助

如果沒辦法讓新人成為戰力,那當初根本沒有招募的必要。

很多人會以手上工作太多為藉口,不幫忙帶新人以及做教育訓練,但新人來公司就是為了分擔你過多的工作,如果不教他怎麼做事,你不是活該自己做到死?

2.1 讓新人對公司有好感

  • 不要讓新人一入職,就感受到沈重的壓力
    有些公司會準備好一系列的新人教育課程,期待他可以快速上工;但如果這些課程排得太過密集、要記住的事項太多,坐在台下的新人可能聽到一半就魂遊太虛了,不要期待新人可以在短短的一天、一週就學會所有事情。
  • 與新人建立連結,帶他熟悉周圍還境
    最輕鬆簡單的方式就是中午帶新人一起吃飯,在前往餐廳的路上,可以向新人介紹周圍的環境,像是餐廳、停車場、大眾交通工具等。
    到了餐廳坐下來後,大家可以在較為輕鬆的環境下再次自我介紹,可以多聊聊興趣、休閒活動,如果有共同興趣愛好可以更快建立連結。

    備註:有些人會自己帶便當,或是有午休的習慣;千萬不要把帶新人吃午餐當成 SOP,請先詢問對方的意願,搞不好新人更想自己一個人靜靜的午休,一起吃飯反而給他帶來更大的壓力。

  • 安排資深員工協助新人
    無論有在完善的教育訓練、交接文件;新人總是會遇到一些「基礎、非專業」的問題,比如:「看不懂群組的特殊用詞、不知道適合向主管匯報的時間、不清楚辦公室的特殊禮節...」與其讓新人與公司的文化碰撞,不如安排一個資深員工在初期帶領他

2.2 了解新人的能力,用合適的方式做教育訓練

請依據每個新人的狀況去調整教育訓練的內容,就像應屆畢業生跟有 5 年經驗的工程師;就算同為新人,但你肯定對這兩個人的能力期待有所不同,下面是筆者公司過去安排教育訓練的步驟:

  • 應屆畢業生
    • SETP 1:熟悉工作會用到的技術
      應屆畢業生的技術通常跟工作會用到的技術有一定的差距,因此在入職後的 1~2 個禮拜,我會先讓他熟悉工作會用到的技術。
    • SETP 2:能使用工作的技術做出簡單的 Side Project
      在掌握基礎技術後,我會請他們花 2 週的時間寫一個 Side Project,主題不限。
      主要是藉由這個機會了解他們程式的撰寫風格,對技術理解的深度,這樣比較方便評估日後要安排的工作。
    • SETP 3:實作 Senior 工程師分配的小 Feature
      大約入職一個月後,才會請 Senior 工程師分配小 Feature 給新人,讓他們真正參與開發。
  • 5 年工作經驗的工程師
    • SETP 1:有專人一對一帶他了解專案架構
      我們期待有經驗的工程師可以快速上手成為團隊即戰力,所以會帶他了解整個專案的架構;並期許他可以在 2 週的時間內對專案有基礎的認知,到達可以開發的地步。(熟悉的時間會依照專案大小而有所不同)
    • SETP 2:指派一些簡單的 Feature 觀察實作能力
      在對專案有基礎的掌握後,就會開始指派一些不影響系統主功能的簡單 Feature (ex:開發新功能、維護舊程式)。
      以此觀察新人對開發時程的掌控度、程式碼的自我要求、團隊的溝通能力,確認他的能力是否符合職位要求。

2.3 最終目標是讓新人有獨立作業的能力

  • 用 Code Review 讓新人的程式能力提升
    在新人完成 Feature 發出 merge request 後,由團隊的資深工程師做 Code Review,告訴新人哪裡可以再做改善;這個步驟的好處有:
    • 新人日後寫程式時會特別注意這些問題。
    • 維護專案程式碼的水平。
  • 透過 Scrum 機制讓新人融入團隊
    儘管新人主要是做被指派的任務,但透過 Scrum 的機制他可以:
    • 更清楚專案全貌,知道自己負責的 Feature 能幫上什麼忙。
    • 了解同事各自負責的領域、實作進度。
    • 透過報告工作進度,讓其他同事對自己的能力有更清晰的認知。
  • 讓新人能自己解決問題,不要養成依賴的習慣
    在前期,有人協助新人可以讓他更快的適應環境;但這個幫助是有限度的,過度的幫助只會讓人養成依賴的壞習慣
    如果遇到問題找前輩就能解決,那長期下來他就會放棄思考;因此在新人結束適應期後(大約 2~3 個月),筆者會有意識的讓新人知道:
    • 每個人的工作都很忙,遇到問題要先想辦法靠自己解決。
    • 在我有空的時候,你還是可以問我問題;但我只會給你解題的方向,不會直接告訴你答案。

後記

有些人喜歡在新人面前留一手,在教育訓練時故意漏講一些技術重點,害怕新人成長太快超越自己。

如果在 20 年前,這樣做或許能保留身為前輩的尊嚴;但現在時代不同了,即便你不教,網路上也有一堆免費資源供他學習;所以筆者建議不如做個順水人情,在教育訓練時盡心盡力,我相信新人也會對你更加尊敬。

幫企業培養人才,幫自己培養人脈;筆者認為這才是職場的正向循環。

感謝大家的閱讀,如果喜歡我的文章可以訂閱接收通知;如果有幫助到你,按Like可以讓我更有寫文的動力,我們明天見~

參考資源

  1. 新工程師報到,我該準備哪些東西來加快交接進度呢?(筆者部落格)

上一篇
[職場]不放過每個細節,完成一場 0 失誤的專案 Demo!
下一篇
[職場]舒服的工作環境是需要經營的
系列文
全端工程師生存筆記30

尚未有邦友留言

立即登入留言