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

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

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

大綱

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：如果公司有導入 CI/CD來做部署，或是由專人負責部署作業，就能大幅降低錯誤操作的可能性（通常 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. 新工程師報到，我該準備哪些東西來加快交接進度呢？(筆者部落格)

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

管理人員
➤ 依照公司團隊建立根目錄的專案
➤ 在用戶清單中加入團隊成員
➤ 依照團隊默契建立問題樣板(或是直接使用全域問題樣板)
➤ 依據團隊建立大群組，依據職權建立小群組
➤ 建立子專案
➤ 建立新議題
開發人員
➤ 開發人員收到議題
➤ 新增子議題、相關議題
➤ 在看板調整工作進度
➤ 編輯議題
測試人員
➤ 驗證議題功能正確性
➤ 建立發現錯誤的議題並分派給相關群組

管理人員

通常都是由 team leader 擔任這個角色，如果公司允許讓管理人員擁有『管理者』的權限會更理想；因為管理團隊用戶/群組這些事情 team leader 會比較清楚，不需要一直麻煩 MIS 人員做處理。

依照公司團隊建立根目錄的專案

每個案子都需要新增一個專案，但如果全都放在專案清單會造成視覺上的錯亂，所以這裡會建議用團隊來區分案子。

STEP 1：網站管理 > 專案清單 > 建立新專案

STEP 2 ：填寫專案基礎資訊 > 建立

• 名稱：請填寫大家都看得懂的，如果專案有英文縮寫請放在代碼
• 代碼：這個欄位儲存後無法修改，請謹慎填寫
• 公開：除非是全公司都能看到的專案，不然請勿打勾
• 模組：建議全選

在用戶清單中加入團隊成員

需要用『管理者』的身份才能建立新用戶

STEP 1：網站管理 > 用戶清單 > 建立新用戶

STEP 2：填寫用戶基礎資訊 > 建立

• 管理者：跟『管理人員』的角色意義是不同的，有管理者權限的才能使用『網站管理』
• 產生密碼 & 必須在下次登入時變更密碼：建議都打勾避嫌
• 寄送帳戶資訊電子郵件給用戶：不寄信給對方他也不知道你幫他建好帳號了
• 電子郵件提醒選項：依照範例的選擇會收到最完整的 Email

依照團隊默契建立問題樣板

為了保證議題的格式有相同的 Style ，所以建議團隊要建立問題的樣板，以確保每個議題的內容都有精準描述減少來回溝通的成本。

STEP 1：在專案清單選擇專案 > 問題樣板 > 新增樣板

• 問題樣板：專門為這個專案設計的問題樣板
• 全域問題樣板：所有專案都能夠使用的問題樣板

STEP 2：填寫問題樣板內容 > 建立

• 追蹤標籤：這個樣板是給哪個追蹤標籤使用的
• 預設值：建議打勾，最後真正的預設值還是看排序，另外子專案設計的問題樣板會蓋過全域問題樣板
• 啟用：打勾後才能讓使用者選用
• 在專案樹狀結構中分享：建議打勾，因為模板通常都會共享

依據團隊建立大群組，依據職權建立小群組

每個專案都有獨立的成員列表，並賦予成員不同的角色；建議群組由大到小會分成三個層次：

• 全公司：有些專案或是資訊是要給全公司的人都知道的
• 部門團隊：比如網頁負責的是一個 Team，android app、windows app 是另外一個 Team
• 功能團隊：網頁團隊下會有不同的小組，有些負責 UI/UX 設計、有些負責後端 api 撰寫；這的層次是依造職權的分類

STEP 1：網站管理 > 群組清單 > 建立新群組

STEP 2：填寫群組名稱 > 建立

STEP 3：選擇剛剛建立的群組 > 用戶清單 > 建立新用戶 > 選擇要加入的用戶 > 新增

STEP 4：專案清單 > 加入專案 > 選擇欲加入的專案 & 加入的角色 > 新增

建立子專案

子專案才是真正的放專案資訊的地方

• 代碼：因為是子專案，建議代碼也要有關聯性方便識別
• 父專案：記得選擇
• 繼承父專案成員：建議打勾，通常成員的角色都是固定的，不太可能今天是『開發人員』明天就轉職成『測試人員』

STEP 1：網站管理 > 專案清單 > 建立新專案 > 填寫專案基礎資訊 > 建立

🌟專案重要設定說明🌟

• 成員：除了繼承父專案成員外，你還可以在這裡做角色權限調整，一個用戶可以有多重角色

• 版本：專案一定會有版本的更迭，每項議題如果都有對應的版本在管理及追蹤上可以容易釐清責任

• 議題分類清單：新人剛加入團隊時可能對成員的職權並不是很了解，如果在這裡建立分類的防可以快速幫助不熟悉團隊的人了解每個人的職權分配

• issue columns：設定議題的子議題要呈現哪些欄位

建立新議題

專案基礎配置完成後開始分配每個成員的任務，這裡先從 UI/UX 的設計圖開始

STEP 1：議題清單 > 建立新議題

STEP 2：填寫議題內容 > 建立

• 追蹤標籤＆問題樣板：問題樣板會跟著追蹤標籤顯示；用戶依照樣板填寫的資料填入必須資訊即可
• 概述：圖片可以用複製貼上，但上面只會顯示『!xxx.png!』，需要去『預覽』才能看到實際的結果

• 提及(memtion)：在撰寫議題概述的時候很長會提到其他同事(ex:這項決議是哪位長官決定、這塊功能會由誰負責…)，可以用 @ 來操作喔

• 被分派者＆分類：調整分類就會自動填入被分派者，能幫助不熟悉用戶職權的人輕鬆的做議題分配

• Checklist：作為議題的輔助，讓你紀錄要完成的細項

• 監看者(watcher)：與任務相關的同事，通常會將直屬長官設為監看者

開發人員

開發人員的涵蓋範圍很廣，包含前端、後端、硬體工程師…UI/UX 設計師等，通常會在收到管理人員分配的議題後開始作業

開發人員收到議題

原則上只要用戶被分配議題、mention提及、設定為監看者，就會收到類似的 email 通知如下：

新增子議題、相關議題

在信箱點擊連結會直接前往該議題，但收到的信件一多還是要依照以下步驟找出自己要負責的項目

STEP 1：專案清單 > 選擇專案 > 議題追蹤

STEP 2：在篩選條件中使用追蹤標籤找到由自己負責的議題

STEP 3：新增子任務

閱讀完議題的需求後再依據自己實際的工作項目去細分子議題，操作方式非常直覺就不再多做介紹

在看板調整工作進度

請注意這裡只能調整議題的『狀態』、『進度』，並不會紀錄工作時間

一個一個議題點進去更新真的很慢，所以我們可以在『看板』用拖拉議題的方式改變他的『狀態』，且能於此『更新進度』的百分比

編輯議題

被分配到議題時要記得編輯啊！不然主管以為你沒做事😞

• 狀態：可調整為『實作中』、『已解決』
• 預估工時＆完成百分比：會有報表產出，所以請認真填寫
• 紀錄時間：為了好看的工作報表就好好填寫吧
• 筆記：因為『概述』完成後就不能修改，我們要用『筆記』做後續議題的討論和紀錄

測試人員

測試人員是系統的守護者，通常會接收到由『開發人員』、『管理人員』分配的測試任務，如果在測試過程中遇到了其他的錯誤可以自行在新增議題做分配

驗證議題功能正確性

STEP 1：先找出清單中自己被指派的任務

STEP 2：依照議題概述去完成相關測試

STEP 3：依據測試結果給予議題回應

• 測試成功：狀態改為『已結束』
• 測試失敗：狀態改為『測試不符合預期』，並增加『筆記』做說明

建立發現錯誤的議題並分派給相關群組

如果是在測試項目外發現錯誤，就是自己建立新議題，並指派議題給負責的群組，如果不清楚該功能由誰負責請使用『分類』來做自動分派。

以下是我整理 Redmine 的相關資源，想更進一步了解的朋友可以參考看看：
👍 Redmine 超詳細安裝教學：Redmine 4.1.1 on Ubuntu 16.04
👍 如何用 Redmine 做專案管理＆體驗心得
👍 Redmine Plugins & Themes 介紹：那些我成功擴充的外掛
👍 用 Redmine 做專案管理 — 管理者不可不知的設定
👍 用 Redmine 做專案管理 — 一般用戶不可不知的基礎功能

🙂 讀完這篇文章後