為毛我又成為了 2024 Node.js 企業專題班教練？！

前言

去年其實我已經擔任過專題教練，但我也是滿意外今年我又有「榮幸」再次參與一次這次的開班整個過程，所以為了覆盤這次的過程，我決定寫一篇文章來記錄一下這次的過程以及心得，希望讓未來參加這個班的任何一位同學可以認識這個班是在做什麼，同時這一篇也是寫給我的學生們。

開班小劇場故事

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

2023 年的 11~12 月左右的某一天，有一位叫做小杰的同仁跟我說：

小杰：「ㄟㄟ，Ray 我今年到明年需要比較多一點時間規劃課程以及外部合作，所以會比較忙，有件事情只能拜託你幫忙一下，你最近會很忙嗎？」
我：「最近…還好，需要的話，我可以幫忙。」
小杰：「那 2024 的 Node.js 企業專題班就麻煩你規劃以及營運囉！從今天開始你就是專題教練長了！」
我：「？？？？」

是的，你完全沒看錯，我又再一次被我同事＆老闆挖坑跳了，所以我得到一個教訓，不管怎樣先不要開口說「可以」（誤）。

好啦，老實講在去年 2023 Node.js 軟體工程師企業專題班 結訓之後，我就已經被告知今年要擔任 專題教練長 了，但只是我沒料到連規劃/營運等都給我了 ;!!!∑(ﾟДﾟノ)ノ

但也代表老闆對我有信心，所以我也只好接下這個任務惹 QQ….

所以接下來就來聊一下這次的班級與前一次的班級有哪些什麼差異吧？

關於這個班

去年我有在 「關於我成為了 2023 Node.js 軟體工程師企業專題班教練這件事」提到過，這個班級是屬於進階課程的班級，因此難度絕對比普通的直播班/專題班還要高上許多。

過程中，不外乎你還是會體驗到以下：

• 半年完成一個專案（實際今年只有四個月左右唷！）
• 從零規劃、設計專案，跑完一個產品開發流程
• 短時間內掌握新技術
• 線上全遠端與他人協作

但每一年的直播班都會吸取去年的學生的回饋來改進，所以今年的班級也有一些不同之處：

• 里程碑設計切更細
• 提供更多參考範本
• 更多的廠商交流機會與廠商講評
• 更加強化與強調團隊合作與溝通
• 班級拆分成兩個班（入門班、企業專題班）

這些都是今年這個班級與去年不同的地方，但是考慮到這個班級是一個「企業專題班」，所以這個班級的難度絕對不是一般的專題班可以比擬的，因此你如果是一個小新手的話，是會被轉移到其他班級的（如：入門班），因為這次的班級規劃更面向實際業界開發的生態。

關於我是誰

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

嗨，大家好，我是 Ray :Dd
我是…六角學院的前端工程師/課程助教/課程助教長/專題教練/課程講師/企業講師（到底要多長？），現在又多了一個教練長的職位呢（請叫我一條龍，笑）。

這次的企業專題班是我第二次負責，在 2023 Node.js 企業專題班我是擔任專題教練，但今年我則是擔任了 專題教練長，這個職位的職責是負責規劃、營運、協調、溝通等等，總之就是一個「總指揮」的角色，而專題教練則轉由我們六角學院親自邀請並審核過的學員擔任，只是專題教練會是兩人一組，然後帶 2～3 組（一組約 5～6 人），所以我們這次找了 14 位專題教練來聽號我的司令（疑？），而我就專注於觀察學員的狀況適時介入給予一些建議與幫助，所以其實我同時要管學員與專題教練呢。

去年我跟洧杰老師、卡斯伯老師三人一同帶了 25 組學生，一人約負責 7 ～ 9 組左右（一組約 5～6 人1不等，共計 13x 學生），而今年的班我們拆分成兩個班，因此又有分「入門班」與「企業專題班」，這時候大家應該會冒出一個疑問：

「那這兩個班級有什麼差呢？以及為什麼要這樣拆呢？」

我簡單直接講結論

入門班是以「學習」為主，企業專題班則是「作品」為主的班級

因為去年開班時，我們有發現想學習的學生還是比較偏多，但企業專題班卻又以作品為主，整個面向完全是打架的，為了讓想學習的學生有一個更好的更專注的學習環境，因此我們決定拆分成兩個班級，這樣也可以讓想專注於學習的學生更專注，而非一邊做專題一邊學習導致兩頭燒的狀況發生。

什麼樣的學生適合這個班？

那麼什麼樣的學生適合參加這個班呢？

我認為至少要符合以下四點：

• 有一定工作經驗（至少半年以上）
• 有自學能力（能夠自己解決問題）
• 一週能夠拿出 20 小時以上的時間來學習新技術＋開發（每天下班 2～3 小時，假日 8 小時）
• 願意接受挑戰，並與團隊協作/溝通（課程中，你會大量與團隊成員溝通）

而這四點其實並不容易，因為你要思考一件事情，平日上班 8 小時，你下班還要撥出 2～3 小時學習新技術＋開發專案，更不用說還要與團隊成員溝通、回報進度等等，等於你一天至少要花 16 小時起跳在這個企業專題班上，這對於一個上班族來說是非常困難的，更不用說課程長達四個月左右，長期下來會是一個很大的挑戰。

因此我認為這四點缺一不可，如果你沒有想清楚就跑來的話，你絕對會 非常後悔。

這個班級的變化

談完了這些東西後，就來聊聊今年做了哪些改變吧！

但是在開始之前我要先感謝我們公司的同仁們幫忙，不然這次的文件、範例以及流程等，絕對不會那麼順利就產出來，所以感謝大家的幫忙！

里程碑設計切更細

首先，在去年我們原本的里程碑規劃算是比較粗略的，總共規劃了七大里程碑：

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

但是今年我將這些里程碑更細分了許多，變成了九大里程碑：

• 里程碑零：團隊成立
• 里程碑一：專題教練服務範圍、文件簽訂與相關注意事項
• 里程碑二：題目確認、使用者故事、網站地圖、使用技術討論
• 里程碑三：流程圖、泳道圖、線稿圖
• 里程碑四：設計稿（申請設計師服務）
• 里程碑五：API 規格
• 里程碑六：環境建立
• 里程碑七：角色端建置（實作開發）
• 里程碑八：專題簡報製作
• 里程碑九：專題發表（每組都要參加）

我們可以看到整體拆分的非常細，甚至很多事情都在前期盡可能完善，在 2023 Node.js 企業專題班的版本，光里程碑一、二、三就花了快兩個月的同學們才搞定，但是今年我們將可以往前搞定的事情盡可能往前搞定並提供大量的範例，例如…

• 使用者故事範本
• Wireframe 線稿範本
• 流程圖、泳道圖以及 Sitemap 範本
• API 規格範本
• 每個里程碑重點事項提醒
  …等等

盡可能減少學生花費的時間以及犯錯的時間，除此之外，每個里程碑都是需要被專題教練「審核通過」才能往下走的。

我這邊少提一件事情，企業專題班會有 2 日的線下實體工作坊，分別是北部場（03/16）與中部場（03/17），同學們在報名課程後，我們會提供一份問卷調查表單來去了解你的工作年資、個性、想學的東西、MBTI 以及地區等協助分組，因此 03/08 這一天我就會宣布分組名單，這時候團隊就成立並且開始進行第一個里程碑的事情，也就是全體必須閱讀「里程碑一：專題教練服務範圍、文件簽訂與相關注意事項」並且簽訂文件。

這樣有助於讓學生釐清專題教練服務的範圍，避免學生把專題教練當作私人助教或要求教練做一些不屬於教練範圍的事情。

破冰任務

接下來 03/08 距離 3/16~3/17 畢竟還有 8 天的時間，所以我們有提供所謂的「破冰任務」，破冰任務會請同學們準備以下事項

• 建立自己的小組 Discord 群
• 初步構想並討論自己想要做的主題以及撰寫初版的使用者故事
• 小組討論並使用 AI 製作出屬於自己小組的代表圖片（例如：小組 Logo）

透過上述的破冰任務，在線下工作坊時就可以更快速的推進里程碑二與確認主題，這樣就可以更快速的進入到開發階段。

而前面這次跟去年很大的不同在於我們先提供了「使用者故事範本」，因此同學們在撰寫使用者故事以及思考主題時，比較不會發散以及有太大的困難，畢竟不是每一位工程師都有機會參與到完整的開發流程：

除此之外，我們也替每一個主題跟使用者故事簡單做了一些等級分類以及預期使用技術，讓同學們可以有一個參考依據

透過這些範本以及文件，我們確實大幅度明顯改善了去年的問題：「學生花很多時間在思考使用者故事、討論主題以及技術討論上」。

Note
為什麼禁止 POS 系統呢？因為考慮到 Demo 以及參考來源等因素，因此我們才會限制不得製作 POS 系統。

兩日線下工作坊

兩日線下工作坊我們區分成了北部場與中部場，同學們會依照自己組別的地區來參加，這樣可以減少交通上的困擾，並且負責的專題教練也會到場協助。

這兩日的工作坊我們會進行以下事項：

• 說明清楚課程是以「專題」為主，但並非是真實落地系統，請以 MVP 概念去思考跟開發。
• 討論並確認主題、使用者故事以及使用技術。
• 初版 Wireframe 分工與繪畫（我們僅推薦 Miro，實驗過兩三次，使用 Figma 的學生會花很多時間在摸索 Figma 上！！！！）

基本上「里程碑二：題目確認、使用者故事、網站地圖、使用技術討論」都在這兩日的工作坊上就完成了，這樣就可以讓同學們在回家後，可以直接進入到里程碑三的「流程圖、泳道圖、線稿圖」的製作，相較於去年的版本，這次的版本可以說是大幅度的提升了 100% 以上的速度，畢竟去年光確認題目、使用者故事、網站地圖以及使用技術討論就花了兩個月的時間，這次我們僅花了兩天的時間就讓里程碑二完成了，甚至有些組別在這一天就直接開始分工繪畫「里程碑三：流程圖、泳道圖、線稿圖」的部分。

強制小組開會

去年我們得到了一個教訓，也就是小組每週必須內部開會一次，因為我們去年有一組就是打死都不開會，結果到了最後就是一團亂，接著不歡而散。

因此我們這次就強制要求每一組都必須要每週進行小組內部會議，彼此 Update 進度、討論問題、解決問題，這樣不但可以有效提升專案推進速度之外，也可以加強組員之間的情感連結，這樣才能夠讓整個專案順利進行。

你以為只有這樣嗎？那你就錯了，為了確保每一組的產出，每週學員們除了自己小組內部會議要開之外，每週也必須要跟專題教練進行線上回報進度唷！在進行線上回報之前，還必須要先撰寫每週回報表給專題教練先行觀看再報告每週進度：

這些問題是我們精心設計過的，專題教練們都可以透過學員們撰寫的內容觀察到學員狀況、專題推進狀況等等，所以非常之硬，而且我們也嚴禁流水帳寫法，否則寫每週回報有什麼意義呢？因此只要發現流水帳寫法，都會叫你重寫甚至一直提醒你不要寫流水帳。

過程中，我也會觀察學員們狀況而陸續出不少文件，例如…

如何成為開會專家：

如何與團隊協作與溝通：

還有「里程碑負責人」的職責手冊：

你以為只有這樣嗎？當然還有「如何與專題教練溝通」：

所以課程進行中，我可不是沒事做，過程我都有觀察各組學員狀況，然後依據狀況來出文件，這樣才能夠讓每組的痛點快速解決，像是一開始我還沒出這些文件之前，就有些組別開會就開了 3～4 小時起跳，後來請專題教練宣導並搭配我提供的文件後，確實將小組內部開會時間大幅降低至 1 小時內，甚至有的更多 5 分鐘就搞定了。

API 文件重新設計

今年的里程碑五算是我花最多時間去規劃的里程碑，因為我一直在思考一個問題：

「該如何讓一個沒有接觸過後端的前端開發者，也能寫出一個好的 API 文件，並且又可以讓專題教練們好審核並知道開發進度呢？」

當然，我知道業界很常用 Swagger、Postman 這類工具作為內部團隊溝通，但對於專題教練來講，並沒有辦法透過這些東西來審核，因此我在這邊規劃時，就至少花了兩個禮拜才思考出下方這個版本：

而這期間，其實有些同學可能會進入「空轉」（閒置）狀態，所以就請專題教練佈達閒置的學生可以先去做里程碑六，先把環境準備好，讓整體推進速度更快。

里程碑六跟七

剩下的里程碑六跟七就比較單純一點，里程碑六我們是設計成了環境建置，但還是有一些基本的審核規範，我們必須確保前端與後端都可以溝通上，因此必須至少要能夠登入、註冊以及修改個人資料，這樣專題教練們才知道你們前後端溝通上是無疑的，而且環境也是有準備好的。

而里程碑七就是角色端建置，這個里程碑基本上就是開發階段，但老實講里程碑五跟六左右，就已經在準備開發了，只是在做一些前置作業，例如 API 規格文件、後端該怎麼定義跟開 API 等等，這樣才能夠讓里程碑七更加順利。

當然里程碑七的時候肯定狀況會很多，也就是後端來不及開 API，然後前端已經把設計稿切完了，這時候該怎麼辦呢？如果里程碑五時，後端有好好撰寫文件，其實可以拿著文件去做 Mock API 先自己接 API，等到後端開發完畢之後再替換過去成正式的 API，這樣就可以讓前端不會因為後端開發不及時而停滯不前。

所以整體來講我們在規劃上是盡可能不要有誰等誰的狀況發生。

廠商講評與交流

廠商講評與交流是這個班最重要的核心，也是去年參加的學長姐們許願的部分，但是礙於去年時間關係，沒辦法安排廠商講評環節，所以今年我在規劃時，就將這個時段給規劃進去，當然這環節我考慮非常的久，因為廠商講評這件事情是非常殘忍的，每位廠商都是知道來參加這個班級的學生都是有工作經驗的學員，讓我一直思考著一個問題：

「廠商並不像專題教練一樣會顧及學員的心情給你摸摸頭，而是以商業角度以及市場價值來給予殘忍的建議，這樣是否對學員會太殘忍？」

但是身為教育者，不就是希望自己的學生成長嗎？所以我就直接安排每一組報告完畢後，會有短暫的 5 分鐘廠商講評時間，讓學員們可以知道自己的作品還有哪些改善與成長的空間，我認為這樣對學員才是真正有幫助的地方也是這個班級的核心理念，當然我知道廠商肯定會刻意問某些很難的問題來問倒學生，但那無疑是想看學生的「臨場反應，並非真的要考倒學生」，而是想看你的應對是如何。

所以我也希望這個廠商講評能夠讓學員們可以真正的成長，而不是只是一個「摸摸頭」的儀式跟環節，然後只會跟你說：「你們做得很棒」，結果拿著這作品去找工作去一間都上不了，這並不是我規劃的初衷以及身為教育者的初衷。

專題教練換人當

前面有提到，我這次身份從「專題教練」變成了「專題教練長」，而專題教練則是由六角學院親自邀請並審核過的學員擔任，所以每一位都是我們信任的學員，因此開課前我們也特別針對專題教練的部分給予教育訓練、專題班啟動會議等，讓他們知道自己在這個班級擔任的角色以及責任，這樣才能夠讓整個專題教練團隊更加順利。

除此之外，專題教練不單每週要跟學生進行線上會議追蹤進度，還要每週跟我進行線上會議（每個禮拜五），並將每一組狀況跟里程碑進度報告給我，這樣才能夠讓我知道每一組的狀況，並且在適當時機給予協助。

由於我自己擔任過專題教練，所以我知道專題教練的辛勞，因此我在專題教練的團隊上是採用公開、透明以及大家都是一個團隊的概念，而非主管跟下屬的概念，因為我認為專題教練本身就要花很多時間去了解學員狀況、給予適當里程碑推進建議以及分享開發心得等等就已經夠累了，更不用提還要每週跟我花 2～3 小時進行回報，如果繼續讓夥伴們保持著主管跟下屬的概念，我相信專題教練們很快就受不了了。

所以每次與專題教練開會時，我也會請他們分享一下自己生活近況如何、有沒有什麼想要分享給大家的，而我也會分享我的生活、經驗等給給大家，然後陪著大家講幹話，讓整個會議像是聊天一樣輕鬆。

對我來講，專題教練們就像一家人一樣重要，所以他們每個人的生活狀況我更加格外重視，也會特別給予回饋。

專題教練長在幹嘛？

這時候就會有人好奇了，身為專題教練長的我在幹嘛呢？

其實我無時無刻都在觀察每一組的狀況，並且在每週五的會議中，我會將每一組的狀況以及進度都記錄下來，如果有比較特殊的學員狀況就要即時回報給上面的兩位老闆，讓他們有個預期心理，這樣子當事情發生時，他們也才能夠適時的給予一些協助與建議，甚至必要時就介入（但通常這時候就很糟糕了）。

所以每次跟專題教練開完會之後，大約都落在 23:xx～00:xx 這個時間，然後我就會開始整理每週進度報告，然後再發給上面的兩位老闆，整個弄完差不多都快要 01:00～02:00 左右吧。

而我們整個企業專題班團隊架構大概是…

兩位老闆（洧杰、卡斯伯） => 專題教練長（我） => 專題教練（2 人 1 組，共 7 組） => 學員（5～6 人一組，共 16 組）

接著我依據觀察到的學員狀況＋專題教練狀況撰寫成每週週報同步給全部專題教練

好處在於，每一位專題教練的資訊都是同步的，然後這禮拜有哪些重點事項跟里程碑事項要注意 甚至會教一些暗黑技巧 。

但是認真講的話，我覺得我的角色偏向中間人吧？一方面要依據學員狀況優化課程給予相對應資源，另一方面要提供專題教練們適當的協助讓專題教練更有底氣去面對學生，因此專題教練與學員也是在學習如何向上管理，而我則是學習如何向下管理，彼此大家都是互相學習的狀態，只能說參加這個班的每一位人都是在學習的過程，然後肝到歪掉 QQ…

結語

寫的有點多了，最後就讓我來提一下這個班級的核心價值來做為結尾。

企業專題班的核心價值在於「企業接軌」、「提升自我價值」，這些是企業專題班的核心價值，所以我們花很多心思去規劃與要求學員寫很多文件、溝通、開會、準備環境、API 規格文件等等，這些都是模擬一個企業開發產品的流程與過程，同時也是普通工程師很難接觸到的範圍，因此我們希望透過這個班級讓學員們可以更加了解企業開發產品的流程與過程，這樣才能夠讓學員們更容易接軌企業，而不被淘汰，否則充其量你只是一個比較會寫程式的「碼農」而已。

我承認這幾個月真的很辛苦，但能夠熬到最後的每一位學員、專題教練們肯定都有所成長，並瞭解到開發一個產品、管理人員是多麽困難的事情，而這也是我們開這個班的目標與使命，希望每一位學員都能夠成為一位不可被取代的優秀工程師，並且能夠在企業中發光發熱哩 :D