從零打造「美食預定」電商平台,三人團隊的AC畢業專案心得

( 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 的階段:

User Stories 清單

確認專案規格與使用技術

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

使用前後分離的原因

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

繪製 Wireframe

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

Nextmeal 平台的 Wireframe

繪製 ERD

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

Nextmeal 平台的 ERD 設計

規劃開發流程

時程安排

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

這次的產品開發我們依照 Scrum 架構,以一週作為一個開發週期(sprint),共安排了四個階段的 sprint 衝刺開發產品:

團隊協作

團隊分工

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

專案管理

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

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

管理 GitHub Repository

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

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

相關活動

本次開發規劃了四個階段的 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 的分享文章中就有建議網站的配色以亮色系為佳,它們能讓使用者有更愉悅的心情 — 尤其像「紅色」則有研究指出能刺激食慾 — 因此最終以偏「紅色」與對比色「綠色」為主要色系。
  • 參考相似類型的網站設計、排版與呈現方式:前台體驗過許多美食外送平台,如:UberEatsfoodpandadeliveroo 等;後台也瀏覽和參考過 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分鐘小測驗,找到你適合從哪開始學習全端開發