關於我成為了 2023 Node.js 軟體工程師企業專題班教練這件事

前言

最近公司為期半年的 Node.js 軟體工程師企業專題班終於告一個段落了，所以就寫一篇文章來記錄一下這半年的過程以及心得，希望讓未來參加這個班的任何一位同學可以認識這個班在做什麼，同時這一篇也是寫給我的學生們。

關於這個班

Warning：
在你往下看之前，我希望你先知道一件事情，這一篇文章並不代表「六角學院」立場，而是我個人的立場及分享。

這個班是六角學院第一次開的進階班，難度相對比以往的班級來講，真的高上許多 QQ

但是過程中你將會體會到以下：

• 半年內完成一個專案
• 從零開始規劃、設計專案
• 短時間內掌握新技術
• 與陌生人遠端協作

這些都是這個班你一定會體會到的事情，最終你們還要上台發表簡報你的專題，你以為就只是單純的報告給我們六角的人員聽嗎？

不，你錯了！你的簡報是要報告給我們邀請來的外部廠商聽，因此這個班不是單純的教學班，而是真正的企業專題班，所以你也是真的在體驗一個專案從零到有的過程。

所以這個班其實比較適合有一定工作經驗或有一定基礎的人來參加，如果你是剛入門的人，我個人是非常不推薦你來的，因為這個過程你會感到非常痛苦。

關於我是誰

繼續往下說明之前，我也先簡單自我介紹一下我是誰，避免大家不認識我 QQ…

我是 Ray
我是六角學院的前端工程師兼任助教及講師，
現在還兼任 Node.js 軟體工程師企業專題班的教練（又斜槓一個職位了 Orz）

而這個企業專題班首次三位教練（洧杰、卡斯伯及我）一起合作帶領學生們完成專案，所以以成本考量來講其實是非常高的。

我們這一個班的總人數約 13x 人左右，共計 25 組（每組約 5～6 人），而我們三位教練分別帶領 7～9 組不等。

以我自己來講我就帶了 9 組，而每一組的主題都不同，什麼意思呢？

簡單來講，學生是可以自行挑選以下主題來實作的：

• 生產力工具（Trello、Jira）
• 資訊情報網（面試趣、比薪水）
• 數位簽名系統（凱鈿行動科技）
• 人力銀行網站
• 線上學習平台
• 活動訂票服務
• POS 系統
• 募資網站
• 部落格平台
• 短網址服務

而我帶領的組別及主題分別是以下：

• 北一組，主題：資訊情報網
• 北三組，主題：接案系統（類似資訊情報網）
• 北七組，主題：線上學習平台
• 北九組，主題：生產力工具
• 北十一組，主題：POS 系統
• 北十三組，主題：生產力工具
• 北十五組，主題：生產力工具
• 北十七組，主題：募資網站
• 南一組，主題：POS 系統

這時候大家應該滿好奇教練在這個班是幹嘛的對吧？這個我後面再來詳談吧～

關於這個班的過程

那麼這個班的過程是怎麼樣的呢？接下來就讓我來說說吧！

首先我們在規劃這個班的時候總共有規劃了七大里程碑，分別是：

• 里程碑一：題目確認
• 里程碑二：專題定稿
• 里程碑三：進修技術
• 里程碑四：API 規格
• 里程碑五：環境建立
• 里程碑六：角色端建置
• 里程碑七：簡報階段

你們必須通過教練的審核才能夠往下挑戰，透過里程碑審核我們可以確定學生的進度是否有達到我們預期的目標，如果沒有達到，我們也會給予同學一些建議，讓同學可以盡可能地推進里程碑進度。

而每一個里程碑都會有一個負責人，我們是希望每個里程碑都是不同的負責人，為什麼呢？因為我們希望每一位成員都可以有機會去體驗到管理專案的過程，這樣才能夠讓大家有更多的成長，而這過程也非常訓練溝通能力。

接下來，我也會簡單描述一下每個里程碑的內容，讓大家可以有個大概的概念了解每個里程碑都在幹嘛。

里程碑一：題目確認

首先這個里程碑開始之前，因為我們會協助分組的關係，所以會先給每一位同學填寫問卷，這個問卷請你千萬千萬不要亂寫，因為這是會大大影響你被分配到的組別與組員，所以問卷請不要有工作經驗卻填寫沒工作經驗 🫴🫴🫴

接著，當學生被分配好組別之後，我們六角這邊就會舉辦第一次的線下討論會，我們希望可以透過線下討論會讓原本陌生的大家可以有機會面對面的認識進而破冰，並且也可以與組員討論對於哪一個專題主題比較感興趣。（而這也是我第一次與我的學生們見面）

在這個里程碑除了「確認題目」之外，同時也要撰寫使用者故事，雖然看起來使用者故事很簡單，而且大家都是有工作經驗的狀況下，你應該會認為寫個使用者故事應該很簡單吧？你應該是這樣想的對吧？！

但是事實上，這個里程碑有些組別還是卡了很久，為什麼呢？

儘管大家都是有工作經驗的工程師，但也不代表大家有從頭到尾規劃一個專案的經驗，因此滿多組別卡在這邊一段時間的。

而最常見的狀況有以下：

• 不知道要怎麼寫使用者故事
• 需求寫得太大或寫不明確
• 沒有拆出角色

因此前期有幾次線上進度會議都是在釐清需求，並重新撰寫使用者故事，滿多時候會請同學參考現有的系統去撰寫使用者故事，接著再從這些使用者故事中砍掉一些需求，避免專案太大，因此這也是我們會協助的部分（砍需求/釐清需求的部分）。

當然，我的立場是盡可能的保留學生想做的功能，因此如果同學本身有想做的功能，那麼我就會轉換成請同學安排成許願，採用核心功能先上線的方式，這樣子才能夠確保專案的產出（也就是所謂的 「MVP 最小可行性產品」）。

那麼這邊有一件題外話可以分享，其實在線下討論會結束時，我這邊有一半的組別都是挑選 POS 系統，但是後來進行第一次線上進度追蹤會議時，大家幾乎都改了自己主題 XD

（第一次的線上進度追蹤會議剛剛好是我的生日 XD）

里程碑二：專題定稿

接下來專題定稿這個里程碑其實就是要讓每一組繪畫自己的專題線稿圖（Wireframe），一開始我們是請同學們使用 whimsical 來繪畫線稿圖，但後來發現 whimsical 不適合用來繪畫線稿圖，因為 whimsical 有免費額度的限制關係，導致同學們畫到一半就會被限制住 QQ

因此後來我們就改用 Miro 來畫線稿圖，而且相較 whimsical 之下我自己認為 Miro 好用很多。

那麼由於參加這個班的人絕大部分都是工程師（少部分有設計背景），因此大家對於繪畫線稿圖這件事情都是非常陌生的，所以遇到卡關的狀況時，我都會請同學們可以參考現有的服務，畢竟現有的服務就是一個非常好的參考範本，並搭配前面所寫的使用者故事一起來繪畫，這樣子就可以避免卡關的狀況。

你以為這個里程碑這樣就結束了嗎？不，你錯了！

因為這個里程碑除了要繪畫線稿圖之外，同時也會有一個角色介入，也就是六角這邊安排的外部設計師，每一組都會安排一個設計師，而越早完成線稿圖的同學就可以越早拿到設計師的設計稿，因此這邊也是一個很重要的里程碑。

但是！這個里程碑的線稿圖並不是沒有限制的，基本上你只能提供五頁的設計稿給設計師設計，因此並不是你畫多少就設計多少（設計費很貴 der），所以學生必須要能夠分析出哪五頁是最重要的核心五個頁面，並與教練共同討論後提交給設計師，而教練也會針對這五頁的線稿圖提供一些意見，除此之外，設計師也會給予一些線稿圖上的建議，讓整體設計稿可以更完善。

oh！差點忘了，這個里程碑也要繪畫流程圖與泳道圖，確保程式碼的運作邏輯與流程是正確的。

里程碑三：進修技術

這個里程碑看起來格外的輕鬆，因為這個里程碑主要目標是讓同學們挑選本次想要在這個專題使用的技術，而我們也會針對同學們的技術選擇提供一些意見。

這時候你可能會想說…

「遇到什麼都想學的學生怎麼辦？」

其實不用擔心，為了避免同學們發生「什麼都想學」的心態而瘋狂列出來技術，所以我們用了點數的概念去讓同學自我分析，因此我們設定了一條規範是 1 點為 4 個小時，每個人的點數總和不得超過 15 點，也就是 4 * 15 = 60 小時（15天），而同一個技術一個人最大不可超過 10 點，這樣子就可以避免同學列太多技術，而導致專案無法完成。

這邊也提一下為什麼是 1 點代表 4 小時呢？因為我們的預設立場是每一位同學都是在職的工程師，因此通常下班之後能夠活用的時間大約只有 4 個小時，因此我們就以 4 個小時為 1 點的標準。

那麼如果評估的單一技術點數超過 10 點該怎麼辦呢？這邊讓我提供一張範例圖給予參考：

請忽略 NextJS 打成了 NestJS（笑

首先你可以看到 Ray 的欄位對於「Vue3 or React or Angular 環境」預估要花 10 點，其實這樣就等於已經到達頂天了，那麼這時候身為教練的我是會打槍的，但是如果組員內有其他人一起共同研究（也就是洧杰與卡斯伯和我一起研究的話），那麼其實點數其實是等於 10/3 = 3.333…，等於你的點數其實是沒有超過的，雖然這不是一個很好的解決方法，但是至少可以讓同學們知道這個技術點數是可以共同研究，也可以避免同學過度發散。

這時候的里程碑不得不說是很難拿捏的，因為每一個人的時空背景及學習能力皆不同，因此很難知道當你同意了他使用這個技術時，最終他能不能活用於這個專題上，而這也是一個大風險，所以身為教練的我就必須要請同學們好好思考，並且提供一些意見，當然以我的立場來講我是盡可能地去尊重每一位學生想學的技術，但是如果技術列出太多或是與本次專題無關，那麼我也是會直接打槍掉。

當然這個里程碑也會請組員們討論一下自己想要負責前端開發還是後端開發

這個里程碑感覺滿輕鬆的吧？其實這樣子規劃是有原因的，因為在里程碑一與二是非常燒腦的，因此才在這邊特別規劃了里程碑三讓大家可以休息一下，因為接下來的里程碑就是痛苦的開始。

里程碑四：API 規格

接下來就準備要進入開發了，但是在開發之前我們會請每一組先規劃 API 文件，基本上就是請同學依照自已畫的線搞圖並依據 RESTful API 的規範去寫出 API 文件。

(上圖只是截圖部分而已，滿多同學都開到 50～80 隻 API)

同時間這個里程碑比較早提交並通過里程碑二的同學，都會陸續在這個里程碑四開始收到設計師的設計稿通知，而設計稿完稿會到里程碑五才會真正的完成，因此這階段除了要規劃 API 之外，也會需要一直與設計師溝通設計稿的調整。

而我在這邊會盡可能協助並釐清同學們有沒有少開 API 或者多開 API，但是 API 的內容我就不會看了，為什麼呢？

因為開發過程中，同學們其實會一直做一些調整，如果我介入的話，有時候同學會為了符合我一開始講的規格，反而會不敢調整，因此我會盡可能地不去介入 API 的內容，基本上我是希望同學們盡可能互相討論出彼此都滿意的 API 規格，而這也是在讓同學們磨練溝通的能力。

里程碑五：環境建立

環境建立這個里程碑就真的滿單純的，你只要把環境部署上去，把路由開出來並實作註冊與登入 API 基本上就通過了。

這個里程碑的目的是要讓同學開始有準備進入開發的感覺，可以說是一個儀式感，因為前面其實滿多時間都是在討論與規劃期，所以很多同學到這邊如果還不進去開發的話，基本上倦怠期就會開始了，這也是為什麼我們會規劃這個里程碑，讓同學們可以開始進入開發的感覺。

截至目前為止，其實到這個階段的里程碑就跑了將近快兩個月左右的時間。

里程碑六：角色端建立

接下來這階段就是每一位工程師最期待的！也就是開發階段！！！！！

進入開發階段後，理論上應該要很順利才對，畢竟大家都是工程師，因此對於開發上一定都很順利都沒問題的…吧？

如果你是這樣想的話，那就大錯特錯了！

因為進入這里程碑後大家才發現其實沒有想像中那麼簡單 XD

因此在這邊我們教練對於學生的基本通關條件是先以一個角色為目標就好，例如：募資網站的提案者這個角色，完成之後再去做第二個角色，盡可能避免同時實作多個角色。

那麼有時候為了加速開發，我們會跟同學說可以塞假資料（意旨不開 API 純靜態）盡可能加速開發並豐富整體的畫面，但是如果可以的話，我自己是不希望這麼做，因為這樣會讓同學在後面想要調整格式時相對會比較麻煩一點，除非是時間非常緊迫的狀況下才會這麼做。

里程碑七：簡報階段

這個階段基本上就是…做簡報，沒錯就是做簡報。

以我教練的立場來講，我會去看同學們的簡報寫的如何、講的如何，內容夠不夠吸引人等，所以其實這個里程碑也是很重要的，畢竟是要講給外部廠商的，而作品也會請同學開始填寫一些模擬資料，進而增加整體的真實感。

基本上只要通過這個階段也代表著你完成了成果發表會，也就是我們這個班級的最終里程碑 👏👏👏👏

關於教練

前面講了滿多里程碑的事情，而身為教練的我到底在這個班幹了什麼呢？讓我來娓娓道來。

首先每週一的晚上 21:00 ~ 00:00 我都會與同學們線上核對進度，每組總共線上回報 20 分鐘，雖然我會盡可能去控制時間，但還是偶爾會發生超時狀況到半夜 1 點，因此如果真的超時的話，我也會先跟比較後面的組別溝通讓他們改隔天晚上回報，這樣比較不會影響到還要上班的同學們。

線上核對進度時，除了回報當前里程碑進度之外，我偶爾也會協助釐清一些開發、需求上的問題，但由於每一組只有 20 分鐘的關係，所以如果要佔用太多時間，我都會請同學活用 Discord 來跟我非同步討論，這樣比較不會影響到其他組別的回報時間。

從 3/13 第一次線上核對進度開始，到 6/19 最後一次線上核對進度，我總共與同學們線上討論了 13 次（扣除連假），每次約 3 小時，總共 39 小時，雖然看起來很少，但實際上這只是粗估時間而已，因為很多時候都是超過 3 小時或提早結束的，而且這還不包含花時間在做非同步溝通的部分。

那麼我帶了幾組呢？前面有提到我一個人總共帶了九組，每組約 5 ~ 6 人（6 * 9 = 粗估 54 人左右），其實認真來講量有點大，所以未來每一位教練只會 3~4 組左右，否則真的心理負擔豪大 RRRR Orz

身為教練除了追蹤各里程碑進度之外，我也會需要了解每一位學生的狀況，因為每一位同學們都是在職的關係，因此有時候會發生公司突然有事情需要加班的狀況，因此我就必須要掌握每一位同學的狀況以確保沒有同學跳車 XD

（當然也不是完全沒有同學跳車，也有同學一開始就跳車，或者是中途跳車的。）

如果同學想跳車該怎麼辦呢？其實我會提醒同學如果你想跳車之前，請先跟我聊聊發生什麼事情，至少讓我掌握你的狀況，有時候你想跳車的原因可能只是一時不小心進入了負面漩渦，但只要有個人提供一點建議給你，你就可以離開這個漩渦並持續推進，如果真的想跳車的話，我也會請你跟組員釐清你手上有哪些工作該如何分配下去，這樣才不會影響到組員的進度。

以我的立場來講，非必要狀況下，我是盡可能不要去砍同學們的需求，畢竟里程碑二的時候就已經砍過/調整過需求，後續如果因為組員的跳車，而導致開發人數不足被迫砍需求的話，對於組員來講士氣是會大大降低的，甚至有可能發生大家都不想做了的情況，因此非必要狀況下我是盡可能不要再去做需求調整這件事。

當然，也不是每一組一開始進度就很順利，就像我講的，大家都是在職的工程師，因此倦怠一定有，所以有些組別在後期開發階段其實進度是落後的，那麼我的任務就是負責想盡辦法把同學們的進度往前推。

ok，看到現在我也來條列一下身為教練的我這次做了哪些事情吧？

• 追蹤各里程碑進度
• 協助釐清開發、需求上的問題
• 與同學們線上討論/非同步溝通
• 了解組員之間的協調狀況
• 提供技術上的建議
• 未來職涯及自我經驗的分享

最後一點就是和同學們「一起爆肝」 XD

因此我一週七天大約有四~五天都在處理關於教練的事情，雖然有些人覺得很爆肝沒錯，但我自己覺得滿見仁見智的，因為我最終看到你們作出東西後，其實我認為這些爆肝都滿值得的。

當然我所做的事情不只這些，因為課程不一定什麼都會教到，所以這段時間我也有額外花時間寫其他文章分享給同學，例如：

• Token 放 localStorage？sessionStorage？還是 Cookie？
• Demo 的時候機子睡著好尷尬怎麼辦？用 UptimeRobot 或 cron-job.org 來幫你吧！
• 或許你該懂一下 CI/CD？用 CD 部署到 Render.com
• 沒辦法用 TypeScript？別擔心，你還可以寫 JSDoc 標注類型
• 用 Express 建立一個簡易 WebSocket 聊天室
• 別再用 1+1=2 學測試了！這次就讓我們從 Vitest 開始學單元測試吧！
• 讓我們從頭學習如何畫一個流程圖(Flow Chart)吧！
• 前端工程師的光與影：仔細思考後再踏進這個領域
• 博弈公司的工程師生活：揭開神秘面紗，機會與挑戰並存

這些文章都是我在這段時間產出來的，主要是因為同學們會問、課程可能沒教到，那麼為了讓大家可以加速挑戰通過里程碑，我就會花時間寫這些文章。

最後給學生的話

前面講了很多關於這次企業專題班的事情，最後我還是想跟我帶的這九組同學們講一些話。

首先，我很感謝你們成為我的學生，雖然我自認為不是一個很好的教練，但我也從你們身上學到了很多東西，不得不說這個過程真的滿痛苦的，每個禮拜要跟我線上核對進度之外，還會在每個禮拜四或五被我追著用文字再次回報當週進度，雖然感覺上有點像是在逼著你們一樣，但是我也是希望你們不要放棄這個班，也希望你們可以有任何狀況就跟我說，而我會盡可能的去幫你們解決。

雖然很可惜這個課程進行中，有些人因為公司的關係而被迫要加班或者是上班要學新技術，下班也要學新技術整個人壓力爆表 🫠

但是最終的結果來講，你們都成功做出了作品，或許最後的作品成果可能不如一開始你心中的預期，畢竟計劃趕不上變化，許多時候為了能夠在死線內完成的關係，而導致某些功能不得不放棄，但是我相信你們已經在這個班級得到你們想要的東西，而且我也相信你們未來遇到任何問題時，都能夠迎刃而解，畢竟你們都已經熬過這個企業專題班了，那麼未來不論發生什麼事情我相信絕對打不倒你們的 💪

那麼我也相信滿多同學也深刻有感一件事情，真正困難的點不會是技術，而是團隊協作、團隊溝通，經歷過這次的團隊協作之後，我相信每一位同學都能夠更懂的如何與自己公司的團隊、夥伴溝通，並且能夠更有效率的找出優先度較高的任務。

最後的最後，我想跟你們說一聲：

「你們辛苦了，雖然這個企業專題班的里程碑告一個段落了，但一個里程碑的結束，也代表著另一個新的里程碑的開始，如同我們的專題規劃一樣，偶爾會很辛苦、很燒腦，偶爾會很順利、很開心，但是只要你願意堅持下去，願意繼續努力，那麼最後的結果一定會是你想要的，加油！」

那麼這一篇文章也差不多告一個段落了，我也終於可以下台一鞠躬退下教練這個身份，回歸一位普通的前端工程師/助教，但是請記得一件事情…

只要你需要我協助，我永遠會在線上等你來私訊我 😊