（ Mike 是 ALPHA Camp 全端Web App開發 學期四的學員，本文轉載自他的部落格）

專案起源

經過數日的線上討論

專案發想初期有如創業般，我們先給予團隊的彼此一些時間做發想，接著在會議上，大家都拋出許多自己的點子進行討論 — 不單純是為了要確認這個題目是團隊成員們都有興趣的產品，更重要的是確認市場需求是否存在、了解是否已經有相似性的產品及產品本身是否能解決使用者痛點 — 最終經過不斷的收斂與修正，我們決定要打造一個「餐點預定」的電商平台 — Nextmeal — 讓合作餐廳能推出美味的料理吸引附近食客；使用者也能透過經濟實惠的價格，提前預訂隔日餐點，並在預定的時間直接到餐廳取餐。

實戰第一 從無到有打造業界規格的 Web App

何謂餐點預定平台

Nextmeal 與餐廳合作，由餐廳每日在平台上提供一道經典菜色供消費者一天前預訂。平台採每月訂閱制，使用者可選擇月付 1000 元，獲得訂購十餐的點數或月付 2000 元，獲得訂購二十餐的點數。

為什麼做餐點預訂平台？

解決消費者痛點

在台大城市中 — 外食族的人口甚多，有些人願意負擔「額外的費用」透過外送平台解決一餐，也有些人願意「花費時間」在外遊走決定要吃什麼和排隊等待餐點。餐點預訂平台 Nextmeal 則介在兩者之中：

1. 使用者能透過平台，看到和嘗試附近優質的餐廳，省去「不知道該吃什麼」的煩惱
2. 使用者透過提前一日預定餐點，能直接在指定時間到店取餐，省去「用餐時間大排長龍」的麻煩
3. 使用者透過訂閱制，每餐能用較經濟實惠的價格享用到美食，省去「在大城市中餐食費用高昂」的煩惱

解決餐廳痛點

許多餐廳在用餐尖峰時間供餐不及，也未必有多餘心力或能力做行銷，吸引客群，透過餐點預訂平台 Nextmeal：

1. 餐廳能及早備餐，並在尖峰時間服務到更多消費客群
2. 餐廳無需和領餐客人進行結帳流程，省去人力成本
3. 餐廳每日只需準備一種餐點，備料上較輕鬆、成本也有機會降低
4. 餐廳能觸及更多附近的客群 — 相對外送平台的高昂抽成費用，成本較低
5. 餐廳能收集平台消費者反饋，為餐點與服務進行改善

專案規劃

撰寫使用者故事

發想使用者故事

在確認專案的目標、客群與解決的痛點後，我們站在使用者的角度開始討論「使用者的需求是什麼？」並發散式的逐一列下使用者需求。

收斂使用者故事

在發想使用者故事的時候，為了鼓勵大家將好的想法拋出來，所以採用發散式的方式進行，因此最終列下八九十條的使用者故事。然而我們開發的時間有限，另一方面，依照敏捷開發的方式，我們應該以能盡快端出 MVP 「最小可用產品」為目標，並向市場測試接收度，再回頭調整產品最為合適。

因此，我們開始思考著「哪些才是最核心的功能」並依照重要性將其排序，另外，也將「Better to have」的功能，暫時排除在欲開發的使用者故事清單中 — 最終收斂到約 50 條使用者故事，且依照重要性歸類成 1–6 的階段：

確認專案規格與使用技術

這次的開發我們採用前後分離：

• 後端： 使用 Node.js 搭配 Express.js 開發，建立 RESTful API
• 前端：使用 Vue.js、Vuex、Sass、Bootstrap 開發，串接後端 RESTful API
• 部署：Heroku
• 資料庫：本地使用 MySQL、部署使用 Heroku Postgres
• 單元測試：mocha、chai 、sinon 、supertest
• API 串接：Google Maps JavaScript API、Google Maps Geocoding API

使用前後分離的原因

依照我們的專案主題與功能來看，的確也可以在後端依照 MVC 架構開發，並採用 Server-side render 的方式，最終對於使用者體驗不會相差甚遠。然而透過 Vue.js 開發 SPA（Single Page Application）的好處在於：許多元件在開發時，可以重複被利用，因此，對於長遠開發來說，我們覺得更有效率。當然比較次要的小細節，我個人覺得在頁面與元件間提供好的轉場效果，相較使用 Server-side render 在等待頁面跳轉與讀取時的白屏來說，使用者體驗會更好。

繪製 Wireframe

使用者故事與專案規格確定後，由我開始規劃 UI 和 UX，並繪製 Wireframe：包含繪製訪客瀏覽頁面、會員訂餐、登入、訂單管理與個人資料頁面、餐廳管理後台、管理員後台，並設計頁面與元件轉換的流程。

繪製 ERD

資料庫實體關聯圖則由我的夥伴 Danny 和 Tao 完成，並經過我們多次的討論與修正後，完成以下最終的版本：

規劃開發流程

時程安排

專案初步規劃完成後，我們安排了一週的準備時間做專案的基本建置、GitHub repo 建置、Wireframe 與 EDR 的確立與新技術探索。

這次的產品開發我們依照 Scrum 架構，以一週作為一個開發週期（sprint），共安排了四個階段的 sprint 衝刺開發產品：

團隊協作

團隊分工

這次的開發採前後分離，我們將團隊拆分成「一名前端開發工程師」與「兩名後端開發工程師」協作開發，最終彼此互相測試功能，並給予評論 。

專案管理

開發 Nextmeal 專案時，我們導入 Kanban 管理工具 — Trello ，協助我們在專案管理與開發上更有效率 ，有關我們 Kanban 設計上的重點：

• Backlog 產品待辦清單：將所有需要被完成的使用者故事都各自開成一張卡片，並依照使用者故事清單中的「開發階段」，為每張卡片貼上顏色標籤，清楚識別開發的優先順序
• 拉式系統：開發期間卡片都只能由左側被拉往右側，且卡片上會被標示這張卡片的開發者。若在開發期間遇到問題，則大家需要先停下腳步，一同協助解決問題。
• 串接 GitHub：透過 Trello 上提供的 POWER-UPS 功能，串接 Github 上的 專案 Repository。開發者在 PR 發出後，於卡片中標示隸屬的 PR，就能清楚在卡片上和卡片中看到目前 PR 處理的狀態。

管理 GitHub Repository

本次開發由我在初期建置基礎的專案架構，並在 GitHub 上建立好專案 Repository 與完成相關設定，規劃與設定上的幾個重點：

• master 主幹：規劃為長期穩定版本
• dev 分支：規劃為開發階段的主幹
• 審核機制：每次的 PR 在 Merge 到 dev 分支以前，皆須經由團隊中另一位開發者測試功能，並撰寫評語
• PR 樣板：依照 GitHub 說明，我們導入 PR 樣板 — 每次 Pull Request 時，皆會自動生成我們團隊預設的內容，一放面讓所有的 PR 內容更統一，另一放面也能幫助 Code review 的成員，更快了解本次開發或解決問題的重點與須知：

相關活動

本次開發規劃了四個階段的 Sprint 週期，開發期間我們有以下的活動：

• 衝刺規劃會議（Sprint Planning Meeting）：每週一會透過 Zoom 線上會議，根據 Trello 確認上週開發進度，在與預期目標比對後，規劃本週 Sprint 開發目標、開發優先順序與分工。本會議上通常包含了「衝刺自省會議」 （Sprint Retrospective Meeting）內容 — 檢視開發流程，並檢討改善。
• 每日衝刺會議 （Daily Scrum）：每隔兩天會進行一次 stand-up meeting — 團隊成員會分享目前開發進度與目前遇到的問題。由於我們在開發上遇到問題時，皆會透過 Slack 和 Zoom 快速溝通，因此，若沒有需要被提出討論的議題，則會透過 Slack 文字，彼此更新進度。

我在專案中負責的項目

1. 專案基礎建置

本次產品開發採行前後分離，由於我們希望將前後端專案放在同一個 Repository 當中，因此由我模索如何依照此架構，建立專案的基礎：建立後端 Node.js + Express.js 專案與 MVC 架構、建立前端 Vue.js + Vue router + Vuex 專案。

採用將「前後端專案放置於同一個 Repo」的原因
團隊成員都只需要 clone 同一個專案下來，就能快速將前後端跑起來進行測試
測試時若發現異常，大家都能直接在專案資料夾中，快速檢視前後端的程式碼，並即時給予回饋（畢竟我們是學習全端，大概對於前端與後端都有一些概念！）

2. GitHub 專案建立與主要分支管理

在本地間裡好專案基礎架構後，由我在 GitHub 上開立專案 Repository，並完成相關設定：（1）master 和 dev 分支保護 — 新增功能或解決問題的每一個 PR 都必須經過至少一人的 Code review 後才可以 merge （2）建立 PR Template — 讓團隊協作者在開 PR 時能有統一格式，確保能提供充足資訊，讓 code review 的隊友清楚了解更新內容。

最終由我監控分支狀況，並在開發階段，將 PR merge 到 dev 分支；在完成 MVP（最小可用產品） 後，將 dev 分支 merge 到 master 主幹 — 長期穩地定版本。

3. Wireframe 設計與繪製

在專案的使用者、目標與使用者故事都確認後，由我開始規劃 Wireframe 的設計。我知道我不是專業的網頁設計師或使用者經驗設計師，因此在開始動筆以前，我依照我們的產品與客群先行做了一些研究，期許能將網頁的介面、體驗和流程設計的更好，更順暢：

• 了解其他網頁設計師對於打造食物類型的網站可以如何設計：例如由 Carrie Cousins 的分享文章中就有建議網站的配色以亮色系為佳，它們能讓使用者有更愉悅的心情 — 尤其像「紅色」則有研究指出能刺激食慾 — 因此最終以偏「紅色」與對比色「綠色」為主要色系。
• 參考相似類型的網站設計、排版與呈現方式：前台體驗過許多美食外送平台，如：UberEats、foodpanda、deliveroo 等；後台也瀏覽和參考過 UberEats 與許多後台管理介面樣板。

在做完研究後，就能開始設計和繪製 Wireframe。本文上半部有展示過使用繪圖軟體 draw.io 繪製的完整 Wireframe，但實際上在事前都可能經過如下圖的草稿，並與同伴討論與優化後，再用線上繪圖軟體，更清楚描繪內容、架構與流程。

4. 前端網頁開發

開發頁面與元件功能

在 Wireframe 完成，並與後端夥伴一同討論與設計路由、RESTful API、資料回傳格式與內容後，就由我負責所有前端的開發，本次採用 Vue.js 框架為基礎，依照 Mobile First「行動優先」為考量，打造以 RWD 原則的網頁佈局，頁面大致分類為：

• 訪客造訪的前台頁面
• 會員登入驗證、訂閱方案、訂餐、管理訂單與個人資料頁面
• 餐廳業主後台管理頁面
• 管理員後台管理頁面

導入新技術

除了頁面開發外，我也學習和引入新技術和套件等，來提升前端開發效率和優化功能與使用者體驗，本次「額外」學習或使用的新技術與套件有：

• 串接 Google Maps JavaScript API：製作客製化地圖與地標，呈現餐廳與使用者位置
• 串接 Google Maps Geocoding API：實現地址轉換經緯度供後端儲存使用
• 導入 Sass 開發：提升 CSS 程式碼的簡潔性與可維護性，並降低重複性
• 使用 Vuelidate：進行客製化表單驗證 — 除了一般資料格式驗證，亦包含使用非同步驗證，即時向後端 API 確認用戶輸入的電子信箱是否已被使用
• 使用 vue-carousel：製作符合 RWD 設計的客製化圖卡輪播功能
• 使用 vue2-datepicker：客製化精美的日期選單

5. 與後端團隊協作

除了前端的開發，也和後端團隊一同討論 ERD 的設計、第三方金流串接等。平時也協助後端夥伴完成 Code review。

專案協作成功之處

透明與快速的溝通

團體協作上最忌諱的就是「不溝通」，造成彼此之間的誤會與代溝，的確我們在開發過程中，有時也會遇到這個難題，但我們打從剛開始就在 Slack 上建立了開放的管道，並鼓勵大家隨時提出任何的新想法、遇到的問題或覺得可以優化之處。此外，雖然是遠距協作，但只要遇到比較大的議題需要討論時，也會透過 Zoom 視訊會議，大幅降低溝通成本，也因此我們在整個協作上算是很順利的。

開發前充足的規劃與準備

在開發前，我們其實花費了非常多的時間進行發想、討論、激辯，連 Wireframe 和 ERD 也做了許多次的優化，然而，這也幫助了我們在事後開發時，目標非常明確，方向也沒有大幅度的調整過，讓開發上更有效率。

另一方面，在產品方向與功能確立後，我們也沒有急著開發，而是給予彼此一週的時間，去探索與學習新技能：例如 Tao 摸索了第三方金流的實作方式、Danny 研究了資料庫排程與測試、我則學習 Sass 與 Google Maps API 串接。這讓我們在開發前，有充足的時間能彼此討論導入的方式、好與不好之處；在開發過程中，則團員們間都有基本的概念，協作上更有效率。

開發心得與感觸

多花點時間溝通反而更省時

有別於以往的團隊協作分工是「自己同時打造前端與後端」，這次我們採取的是前端工程團隊搭配後端工程團隊一同協作開發，因此事前對於功能的確認、商討傳輸資料的格式與內容都顯得非常重要 — 如果沒有做足完善的討論，則雙方會在不同的水平上開發，並在開發到一個階段後，才發現衝突，最終反而需要花更多時間回頭修改，因此事前的討論、過程中的確認、事後的檢視都是團隊協作中非常重要的一環。

遇到難題和挫折是正常的

在打造新產品或專案的過程中，有時會遇到對於新技術或功能可能不了解該如何實作 ，但又想要或必須完成的挑戰 — 例如在這次的專案過程中，需要串接 Google Maps Api，或著想在前端頁面還在取得後端資料時，製作如下圖的 Skeleton Loading Animation 來提升使用者體驗，又或者需要使用 Vuelidate 實作表單驗證 — 這些都是我在打造產品前沒有實作過的經驗。雖然剛開始可能會有點緊張，不確定自己是否可以達成，但只要抱持著開放、冷靜與興奮的態度面對，並懂得翻閱文件、查找相關資料或請教他人，一定有機會能完成的 — 「畢竟技術每天都在進步，很難有學習完的一天，我們只能用開放與願意嘗試的心情來擁抱它，或許最終反而能學習到更多！」

多聽取使用者反饋來優化產品與功能

在實作功能和頁面出來後，一定有可能收到「使用者反饋體驗不佳或可以優化的地方 」— 例如在這次的協作過程中，助教就有提到在管理後台的資料呈現上，採用頁碼呈現，讓使用者讀取更多資料，會比透過「More」按鈕來的友善。對我來說，的確在剛聽到反饋時會有點失望，畢竟這是我認真打造的功能 ，然而，產品還是需要以使用者為中心，因此，換個角度思考：「這些反饋反而讓我的產品更好，也更貼近使用者需求！」

查看作品

Nextmeal 預定餐點網站

您可用以下測試帳號登入

‍ 一般會員
email: [email protected]
password: Nextmeal!

餐廳管理者
email: [email protected]
password: Nextmeal!

管理員
email: root@example.com
password: Nextmeal!

GitHub 程式碼與詳細介紹

結語

很開心這次能與 Danny 和 Tao 一起從產品發想到完整打造，走完有如創業般的過程。這次的專案規模相較以往大很多，在功能實作上也相對複雜 — 雖然一路上有非常多的困難與挑戰，但我們都願意相信我們所設定的目標，共同努力很扶持，一同完成了作品。雖然我們可能自己會覺得還有很多可以改善或優化的地方，但就像創業一樣，有時無法預測使用者的口味，很多的功能都需要快點經過市場的測試、收集反饋，再回頭不斷的調整、新增或優化。但這次更重要的，是能與你們一同走過產品打造的這條路！

3分鐘小測驗，找到你適合從哪開始學習全端開發