謝謝六角學院的課程，讓我有幸能在這 120 天的專題課程中，與組員們和專題教練 Ray，經歷了一段極為濃縮的 MVP（最小可行性產品，Minimum Viable Product）建立過程。
這是什麼？
這是由六角學院主辦的課程，【16 週帶你做產品】Node.js 軟體工程師企業專題班，課程的最主要目的是：完成一個產品。
要怎麼跟不認識的人一起開始？
首先會是分組：
在報名完成後，會有一份相當完整且詳細的表單，表單中會需要填寫自己的技術能力、預計精進方向、年資等等，甚至會要求你去做十六人格測驗（隔一段時間測都會不太一樣…這個班剛開始時測出來是 ESFJ）。
在填寫這表單的時候就能深刻體會到六角的用心，其實除了作為分組依據之外，在回答表單問題的時候也釐清了許多自己對於這課程的期許，對抱持著「總之先衝一發再說」的心態按下報名按鈕的自己來說，確實是在這份表單中獲得了更加明確的想像，想像課程結束後的自己應該會經歷過什麼、成長了什麼。
之後組員會在 Discord 上建立各組的伺服器中開始熟悉彼此。熟悉彼此的部分六角學院這邊也有提供四個小階段讓組員們破冰～從自我介紹、透過 AI 繪圖來產生小組形象圖、討論專題題目等等開始慢慢認識組員。
再來是線下見面會：
這是在專案完成之前唯一一次與組員們實際見面的機會，見面三分情對於素未蒙面的彼此來說是真的很重要。
而這次線下見面會同時也開始了我們的第一個里程碑：決定題目。
PS.里程碑：此課程主要分為七個里程碑進行，從決定題目到開發環境的建置、完成 MVP 為止，也可以說是建立一個產品的不同階段。
里程碑
1. 決定題目（里程碑一：題目確認）
六角學院會提供十種題目的類型，分別有生產力工具（Trello、Jira）、資訊情報網（面試趣、比薪水）、人力銀行網站、線上學習平台…等等。
一開始小組原本是討論想做電影院的訂票平台，可以讓各家電影院的負責人註冊並上映自己電影院會播放的電影、播放的廳院、座位、時刻表等等，但聽聞現場有多數組別也是選擇了相同的主題；心想這樣會看不出差異性，後來著眼的主題則是，燒烤店的 POS 系統。
POS 系統有著相似的操作流程，除此之外，這是個除非到餐廳打工，不然不太會有機會接觸到的系統，也希望能藉著這次的機會來了解一個異於平常所接觸領域。（雖然在這之後馬上就得知也有不少組別改成了 POS 系統…我想我們是不能在競標場跟人標價的類型…），儘管有些許波折，我們還是決定繼續做這個題目了。
2. 了解題目（里程碑一、二：題目確認、專題定稿）
這個階段會開始繪製我們專題的線稿、使用者故事、使用者流程以及泳道圖，並交由與此課程合作的設計師進行設計稿的繪製。但是 POS 系統其實是個有點難做功課的主題，一般來說除了從業人員之外，不太會碰到這些東西，而這也不會是個能直接在網站中操作的系統，當初碰到的第一個難點就是這塊了：POS 系統到底做了什麼？
而了解這個，同時也是我們這個里程碑最主要的目的，透過一些有做 POS 系統廠商的網站簡介、詢問實際在餐廳打工過的友人、外食時留心觀察餐廳人員的工作等等，才慢慢地可以開始進行下列的里程碑項目：
- 線稿：有了最初步的畫面後，就可以開始思考實際操作時會需要哪些流程、按鈕、資訊等等。
- 使用者故事：操作的流程會先透過使用者故事做一個初步的發想，這邊簡單列出一些：
- 我是後台管理者，我可以登入登出管理平台
- 我是內場人員，我可以查看目前點餐狀況，了解目前該做哪些餐點
- 我是櫃檯人員，我可以結帳，結算單筆帳單
- 我是外場人員，我可以點餐，幫客人點餐，並將點餐結果轉至內場
- 使用者流程：流程的部分就要搭配線稿的畫面進行，我們會將每一個操作的流程都畫出流程圖
透過流程圖，我們可以重新審視線稿是否有缺漏，或是操作上不合理的地方再加以修正，這個階段有確實審視的話，對後續的開發有著極大的幫助。 - 泳道圖：呈現涉及多個角色端之間相互溝通的流程
走到這邊時，會對於未來要開發的東西有更清晰的想像，而更重要的是確認這個認知是全組的共識，盡可能地彌平認知上的差距。
3. 為開發做準備（里程碑三、四：進修技術、API 規格）
進修技術：
這邊會根據我們的專案，來對可能會用到的技術進行評估，熟悉的、不熟悉但是想要玩玩看的、想要玩但是有技術難度與時程壓力的…等等，列出來之後會把每個項目分配給負責的組員，並估算預計花費的研究時間，會由教練來評估是否有必要或是進行調整。記得那時候有位負責後端的組員想推薦大家使用 Nest.js，花了兩天晚上整整六小時的時間來對大家做簡報、Live coding，為的就是導入這個後端的框架（推坑不遺餘力），後來也真的因為這個框架的使用，讓後端的開發體驗更加地良好。API 規格：
這個里程碑中負責後端的三位組員投入了大量的時間去開 API 的表單，前前後後大約開了六十支 API 出來…
4. 終於能寫 code！（里程碑五、六：環境建立、角色端建置）
環境建立：
前後端會開啟 repo 並部署完成，除此之外還要完成登入的功能。在這邊大家才真正的開始進入了開發的協作流程，趁時程還不趕的時候，在這個階段制定團隊共通的 coding style、git flow、git commit 規範等等。角色端建置：
這段時間是整個課程中最需要奉獻肝指數的部分，做的事情就跟工作上的開發流程一樣，開牌卡、發 PR、code review、debug、確認欄位資料是否有誤、調整 api 回傳格式、UX 操作流程改善、UI 調整等等。
5. 用十五分鐘來展現我們的成果（里程碑七：簡報）
我們的專案是燒烤店的 POS 系統，相較其他組別來說的劣勢是較無精美的前端畫面，以及使用者角色有三個；如果單純用介紹：「這邊是點餐，按下去之後可以從點餐紀錄看到剛剛送出的訂單」、「這邊是註記，可以告知廚房這杯可樂要多冰」等等，單純敘述功能的介紹方式的話，會十分地單調；且因使用者角色較多，容易在來回介紹不同使用者畫面時造成聽者的混亂。
這時我們後來的主講者與 Ray 教練都不約而同地提出了一種簡報的方式：透過情境的模擬，來介紹我們的系統。
而我們負責主講的組員在當日也是不負眾望地發揮了比私下練習時好上一百倍的表現，看來真的是個戲精。透過主講組員模擬的情境，依序帶入了這個專案各層面的說明：
- 從我們五位組員到了一間只用紙筆紀錄的燒烤店用餐後，發現了許多明顯的問題：點餐、結帳、候位、出餐失誤等等，來帶入我們系統的幾個主要功能
- 再來是模擬一家四口從來電訂位、帶到指定的桌位等步驟，來呈現櫃檯人員的操作流程
- 而外場服務人員的情境則是，開始桌邊點餐、顧客點餐時的需求（餐點少飯、飲料多冰）、送出點餐
- 送出點餐項目後，場景就來到了廚房端，透過即時呈現外場服務員送來的餐點項目可以得知目前需要製作的項目
- 製作完成後，會由廚房這邊按下「出菜」按鈕，這時在外場服務員看到的餐點狀態中，就會出現可以上菜的提示按鈕了
- 當顧客用餐結束後會前往櫃檯結帳，用餐金額的計算則會在此時加上服務費、搭配的優惠活動等等
- 最後，在服務人員將桌位清理完成後，可以點擊「清理完成」的按鈕，如此一來桌位的狀態就會恢復到「閒置」狀態以接待下一組顧客
回顧
謝天謝地謝組員謝 Ray 謝六角謝彼此
真的是除了感謝還是感謝了…
首先是感謝每週一晚上與 Ray 教練的進度同步，透過每週一的檢視，讓我們去收斂過於發散的需求、繪製清楚的流程圖、選擇符合專案需求的技術、改善系統的操作流程、設定開發的優先順序、尋找在時間壓力下的替代做法、將簡報的重點聚焦與透過模擬情境來介紹……等等有太多太多的事情，都是多虧了 Ray 的親力親為來不斷地協助我們調整、改善，謝謝 Ray！
再來則是與組員之間，大家都是在上班的同時一同推進這個專案的進度，忍著耍廢的衝動（好吧，也許有那麼個幾天我沒忍住…）努力打起精神在 DC 上開會討論，討論時難免會有方向模糊、意見不合的時候，在已經上了一整天班最想休息時還要跟人對話真的是辛苦了…但也真的很慶幸遇到的是這些隊友們，討論時總是能客觀地提出意見、交流，接受建言的一方也能調整自身的做法，來更貼近團隊的走向（開發習慣、想做的項目、技術選擇、code review 等等）。
在初期彼此不熟悉的時候，組員們大多都會對於表達自己的意見感到有所顧慮，也因為討論的方式尚未有磨合出一個合適的流程。這讓初期負責里程碑一的組員負擔了過多的作業量，在里程碑一告一個段落後，自己有發起一個會議來檢討目前的討論方式。真的是很幸運的，是跟這些組員們一同努力，提出的當下其實一直擔心自己是否管太多、自以為是地下指導棋，所幸組員們也對這些議題提出了不少的建議與積極地討論往後的合作、會議模式、交換意見；彼此的隔閡仿佛在此刻開始慢慢地散去。
討論會議的會議
在參加此次專題前不久，因參加了去年六角學院主辦的前端精神時光屋，而剛好有了另一個線上的小組協作的經驗。
在前期討論時發現了一些在彼此溝通上可以做些調整的事情：
- 里程碑負責人幾乎將該里程碑的所有事情都一手包辦把它完成了
- 優點：一條龍作業，可以確實掌握各個項目的進行情形，也因為決策與執行人都是同一個，所以幾乎是沒有資訊的落差
- 缺點：會累垮，工作都壓在一個人身上，隊友也很難了解狀況從旁協助，同時也會覺得是否不被信任，所以才沒將工作分配出來
- 在線下的實體見面會時，就有安排了各自要負責的事項，等到會議時再一起討論
- 但這時幾乎全部人都一起做了原先預定要分工的項目，這樣做的話會變成無法聚焦，而負責人也要顧及每一位提案人的想法
- 除此之外，也會讓原先可以不用做的人產生心理壓力，覺得自己不跟著做不行
- 會議討論
- 在會議前，組員對會議要討論的項目並不清楚，不確定應該要做哪些準備
- 會議主持人在會議後自己整理了一份要與專題教練同步時的報告，但有些項目與自己在討論時認知有差距
將這些可能造成溝通上產生誤會的部分列出來，並將可能的改善方式提出來與組員們討論後，決定用下列的方式來調整我們的溝通模式：
- 建立 scrum 流程，明確地在牌卡上描述負責的項目後，也能得知對應的任務該向誰詢問
- 在會前要先準備初步的議程文件，內容包含：會議主題、討論項目、結論、臨時動議等等，藉由會議記錄來確保彼此的認知是一致的，同時也方便日後查找當時的決議項目
果然還是謝謝
整個課程來說並不輕鬆，前期與後期各有其令人費神的部分。在前期，精力會花在建立對產品的共識、決定功能走向、建立會議流程、彼此磨合熟悉；而後期進入開發後則是開發流程、工作項目分配、code review、前後端協調。
彼此大可選擇自掃門前雪的方式，相信這在被開發進度追著跑的時候，也絕對會是個更為輕鬆的做法；但是組員們隨著開發進入後期較為高壓的時候，除了更加地提高了投注的時間與心力之外，也更為頻繁地進行討論、同步。一同開發前端的組員在 code review 時也總是會細心地提出建議，在專案中維持一定的開發架構、程式碼風格並不是一件容易的事情，需要耐心與一致的標準來審核每一次的 PR，以達到維護良好、一致的專案架構的目的。
而負責後端的組員們更是在達到預定進度後，主動提出來協助前端的開發…隔著螢幕都能感受到組員背後散發的聖光…
除此之外，不止一次，當情況有些模糊不清的時候，組員也會主動地將目前的情況整理出來討論，擬定方案並執行，很大程度地避免了搞錯優先順序與過於鑽牛角尖的情形，在進度與品質間取得了平衡。
完全是可以感到驕傲的！
當表達的意見或是反映的情形會受到確實的回饋時，能帶動整個團隊相互主動溝通的氣氛，以及降低主動發言的心理門檻。也因為如此，彼此能更誠實的反應遇到的問題，加班、卡關、想休息、PR 的回饋等等，因為大家面對各種情況所做出的選擇，最後是營造出這樣鼓勵討論、交流的團隊文化，我想這是我們在這個專題班中所做到的最了不起、可以驕傲的事情。
五位組員們與六角學院的 Ray 教練能一同在這 120 天中，完成一個 POS 系統的 MVP。我們真的是…很努力欸…辛苦彼此了，謝謝你們。
