背景
公司決定將兩個事業體各自成功的遊戲，移植到彼此的平台上。這是首次大規模的跨事業體合作，時程設定四個月，同時背負 Q2 營收重點產品、事業體技術能力比拼、部門成效的多重壓力。
挑戰
- 與兩位工程師首次合作：一位是能擔任團隊 Lead 的資深工程師，另一位是經驗不多的資淺工程師
- 若照慣例把複雜困難的工作交給資深工程師，他的產出量會被壓縮；資淺工程師速度較慢，又可能拖累整體完整度
我怎麼解
先看清這次移植的本質：困難在「整體完整度」，要解決的是數量的問題，不是困難技術的單點突破。所以採取反直覺的分配策略：
- 「數量多但簡單」交給強的工程師——發揮速度優勢，確保產出量
- 「數量少但複雜」交給較資淺的工程師——專注品質，慢慢磨
成果
- 超過 50% 的功能由資深工程師完成，前期就確保了移植數量，專案穩定度大幅提高
- 資深工程師處理效率高，行有餘力還能支援資淺工程師，避免對方卡住
- 資淺工程師的問題集中在特定功能上，不會擴散到整個系統，專案後期問題明顯較少
回頭看
過去我常看見「能者多勞」的困境。這次我採取不同策略——真正要控制的風險，是能者多勞之下，當那個最強的人卡住，整個團隊就跟著卡住。
把複雜難題交由資淺成員嘗試、讓資深成員保有餘裕，團隊的風險就由所有人分擔，每個人的風險都在可控範圍內。
✔️ Problem Solving ✔️ Resource Management ✔️ Risk Management ✔️ Cross-functional Communication