年尾的時候，我跟公司一位 junior 工程師做了年度檢核。

我們是一間純遠端公司，開發更新週期長，時間非常自由，但同時也代表每個人都要有很高的獨立決策能力。這位同事是我們找進來的第二位 junior，但一年下來，結果還是很明顯：只要他需要獨立作業，交付內容就常常不對。

我一開始也直覺地把問題放在個人能力上，但回頭看，我認為這更像是「制度設計 + 人才匹配」的複合問題。

問題不只是 junior，而是學習閉環沒有形成#

我們公司常見的場景是：

  • 一出狀況，資深工程師很快就自己解掉
  • junior 沒有參與解題過程，也就吸收不到決策脈絡
  • 任務結束後，團隊也不一定留下可重用的學習素材

這會導致一個結果：同樣的坑，下一次 junior 仍然可能再踩一次。

我們當然有做 PR review，但如果 review 只剩「這行改一下、那行補一下」，對 junior 來說比較像是修正格式，不是建立工程判斷力。

遠端模式對 junior 的真實門檻，比想像更高#

遠端不等於只要會寫 code 就能存活。

在我們這種模式下，需要的是：

  • 能自己定義問題
  • 能主動同步風險
  • 能在資訊不完整時做出合理決策

而這些能力，對 junior 來說本來就需要訓練期。如果團隊沒有刻意設計學習路徑，結果就會是表面上時間很自由，實際上成長很慢。

另一個常被忽略的因素是語言能力與學習方式。當 junior 閱讀英文原文能力弱，碰到新技術時就更容易被二手摘要綁住，理解深度和遷移能力都會受限。

為什麼 CRUD 做得出來，取捨題卻做不出來#

我看到的典型落差是：

  • CRUD 類任務可以完成
  • 一遇到架構取捨（例如 2PC 這類問題）就無法辨識問題
  • 即使專案裡已有相似功能，也不一定知道怎麼套用

這不是「不努力」，而是缺少把經驗抽象化的能力。沒有被訓練去回答「為什麼這樣設計」，就很難在下一題舉一反三。

AI 進場後，培養邏輯必須重做#

公司已經導入 AI solutions，很多時候程式碼本身可以很快產生。

這直接改變了 junior 的評估重點：

  • 過去：你能不能把功能寫出來
  • 現在：你能不能定義問題、判斷風險、驗證結果

如果團隊還用舊標準培養新人，就會出現一種假進步：code 看起來有產出，但能力其實沒有被建立。

我們還有另一個現實難題：當 code 由 AI 快速生成後，審查焦點常被推到 UI 審美。但 UI 在我們公司又缺少可訓練、可評估的共識，最後常常只剩「看行銷怎麼說」。這會讓工程端很難建立穩定的成長標準。

我現在的兩個拉扯#

我確實考慮過每月固定幾次大家聚在一起分享，建立共同話題。

但我同時也認為，遠端團隊的基礎不該依賴碰面，而是能去中心化運作：

  • 不碰面，仍能清楚定義任務
  • 不同步，仍能保留決策脈絡
  • 不靠特定資深，仍能持續交付

所以我的第一優先仍然是找對的人，再讓制度去放大這個人的成長。問題是，對的人往往不是現有薪資帶可以輕鬆滿足，這是最尷尬也最現實的限制。

PIP 不是懲罰，而是誠實機制#

就這個個案來看，進入 PIP 可能是必要選項。

但我更在意的是：即使進入 PIP，也不能把它當成單純的淘汰流程，而是用來驗證一件事：

  • 在明確支持與明確標準下，這位同事是否能達標

如果答案仍然是否定的，那就是角色匹配問題；如果答案是肯定的，代表公司原本的培養流程真的有缺口。

所以，junior 的優勢只剩年輕的肝嗎？#

我現在的答案是：不是。

junior 真正的優勢應該是：

  • 可塑性
  • 學習速度
  • 對新工具（包含 AI）的適應彈性

但這些優勢有個前提：公司要有可運作的成長閉環。

如果沒有，junior 最後確實只會被當成工時資源，而不是可被培養的人才。

這次年尾總結讓我更確定一件事：

在遠端與 AI 並行的時代，最該被設計的不是「如何讓 junior 更快產出」，而是「如何讓學習、溝通與決策能力被持續複利」。