「電商專案實戰」- 原來產品開發是這麼一回事!

Pierce Shih
皮爾斯的自學旅程
19 min readOct 7, 2019

職涯如同打造一個產品,每走一步都是經驗的累積,也迭代出更好的自己。

前言

筆者在將近一年的程式自學旅程中,主要以 JavaScript 實作全端(Full-Stack)網站開發,力行自我產品迭代,也累積技術筆記和作品集,落實個人品牌的經營。

下一步目標,以軟體工程師的角色,加入一間具有長期企業使命的新創公司,鎖定雲端軟體(SaaS)產業、教育科技產業、電商產業,更期許自己未來透過「商業」、「產品」、「技術」的跨領域整合,解決更多的問題。

因此,我希望陸續透過下列五篇文章跟大家分享我是誰,包含我的轉職初衷、過往 SaaS 軟體職涯經驗、如何運用 MVP 思維迭代更好的自己、我的產品開發經驗、做事方式和團隊角色定位,以及未來的職涯目標和想法。

4. 「 新創 SaaS 實戰 」- 紙上談兵,不如血淋淋的作戰經驗!(10 月中旬)

3.「 電商專案實戰 」- 原來產品開發是這麼一回事!(本篇)

2.「 MVP思維實戰 」- 策略化實踐職涯的產品迭代!

1.「願景驅動改變」- 當能力撐不起野心,歸零學習創造一條新的路

核心用意是幫助大家從中了解我的經驗和故事,也希望有機會為你所處的團隊帶來更多價值,如果有興趣交流聊聊,歡迎隨時與我聯繫 :D

Photo Credit by Scott Webb from unsplash

產品開發實戰

過去一年所開發的專案較為零散單一,但本次電商專案的規模和實作範疇更為全面,因此,專案開始前,不僅令人相當期待,也讓我感受到許多的不確定性,甚至略微緊張。

不過現在回頭看,卻是我收穫最多的一個實戰經驗。

本文章將分成下列幾點跟大家分享我的心路歷程,分別是:

・專案簡介與緣起

・專案領導與負責事項

・團隊分工模式

・團隊成功協作的三大關鍵

・從專案中體驗未來工作的日常

・結語

專案簡介

首先,讓我們更進一步來介紹這個前後端分離的電商專案吧

GPW 電商網站,是一個前後端分離的電商網站,前端使用 Vue.js 建置,後端則使用 Node.js + Express + MySQL/PostgreSQL 建立資料庫與 RESTFul API,部署於 Heroku,平台使用者分別為一般消費者(Visitor)、商家管理員(Admin)。

專案網站:GPW 電商網 Demo Link想進一步了解,可見 Github 前端 / Github 後端

專案緣起

而專案是由 Alpha Camp 畢業專題發想,選定「電商平台」為主題,打造一個前後端分離的作品,期望透過技術解決傳統店家要拓展線上通路進入門檻過高的問題,包含網站開發、金流串接…等等。

因此,我們目標建立一個讓店家輕鬆開店、提供消費者各種優惠,也管理商品庫存的電商網站,如前台購物功能、後台上架管理功能…等等,期望為一般消費者(Visitor)、商家管理員(Admin)帶來不同的核心價值。

・為一般消費者(Visitor)提供一個產品資訊清楚,購物/付費流程簡單,體驗良好的網路購物平台。・為商家管理員(Admin)提供一個電商解決方案,大幅減低網路開店的成本,輕鬆轉型電商,省去自行開發的時間,讓商家專注在本業商品的研發與生產。
Photo Credit by MI PHAM from unsplash

本專案共有三位開發者參與,包含我、振壹 Wanaka敬杰 Ginger,兩位也一同參與 Alpha Camp 全端網站開發課程的夥伴,同時,也有一位業界的工程師前輩 Sam 擔任專案 Mentor,提供產品開發上的建議與回饋。

專案領導與負責事項

專案中,我除了擔任團隊領導的角色,也身兼 PM 職務統籌產品開發事務。

在開發端,我主要負責電商「購物流程」的功能開發,包含購物車、訂單創建、瀏覽訂單、優惠券功能…等。

工作內容如下:

・Leader / PM 工作內容:> 負責團隊資源協調與相關事宜安排
> 建立團隊合作機制,力行資訊透明,提升團隊協作效率
> 建立專案會議機制,有效管理會議目標與決策產出
> 導入專案開發工具,實踐各階段的產品開發目標
> 協同團隊確立專案規格(User Story, Wireframe, ERD Model…etc)
・Developer 工作內容:> 負責前後端購物車、訂單創建、瀏覽訂單、優惠券功能開發
> 負責專案核心分支管理,協助團隊 PR 審核
> 協同團隊建立資料庫架構、種子資料與 Heroku 部署
> 協同團隊串接第三方藍新金流
詳情可見 git commit(前端 / 後端)
Photo Credit by Quino Al from unsplash

團隊分工模式

這是我第一次在產品開發上擔任領導的角色,因此,對我來說也是個探索與嘗試的機會。

而有別於大家熟知的前後端分工機制,在本次專案中,團隊則是採行以使用者故事(UserStories)劃分職責的方式分工開發任務。

相信你一定很好奇,為什麼我們採行以 UserStories 劃分職責的分工模式?

專案價值極大化

考量每個人都是第一次開發前後端分離的專案,即使大家未來都有明確的求職目標,但站在團隊領導的角色,我的核心想法是,讓團隊每個人不僅累積前後端的開發經驗,更學習到全面的產品開發思維與架構。

因此,每個人會全權負責所拿到的使用者故事(UserStories)。

以我負責的購物車頁面,其使用者故事如下:

PS:是不是寫的蠻清楚的呀(我們可是討論好幾次的呢XD)

在一條龍的開發任務中,我不僅參與後端資料庫的設計,也撰寫測試碼實作單元測試(Unit Test),更自行開立 RESTFul API 串接至前端使用。

同時,也和團隊一同處理 CORS 跨網域、第三方金流串接、自動化測試/部署(CI / CD)..等議題。

此外,大家都是第一次使用 Vue.js 進行開發,對我們來說也是一個很棒的實戰機會,對我而言,更累積許多實務上的使用經驗,包含使用 Vue-Axios 串接 RESTFul API 的資料傳遞、Vue Router 路由管理、Vue props / emit 實踐組件資料傳遞,還有 ES7(async/await)資料庫非同步操作…等等。

最印象深刻的是,在串接第三方金流功能時,有個頁面需要運用生命週期的觀念,透過 created hook / updated hook 的執行先後順序,才能順利完成,這也讓我更加理解原來生命週期是這麼一回事。

延伸閱讀:「Vue.js 學習筆記 Day14」- 生命週期

回歸「專案價值極大化」的初衷,在這樣的團隊分工下,不僅讓每個人體驗到全面的產品開發經驗,當隊友遇到問題時,由於我們都擁有相近的前後端知識和實作經驗,更能加速團隊解決問題的效率。

同學同學~~專案過程中,你們有遇到意見不同或程式碼衝突的情況嗎?如何解決的?

江湖走跳,衝突是常態

雖然產品開發是透過電腦幫忙做事,但回歸團隊合作的根本,關鍵的是人與人之間的溝通,因此,我們透過頻繁的事前準備和溝通,大幅降低這類衝突事件的發生頻率。

舉例來說:在目前的分工模式下,每一個功能實作都會有和後端資料庫互動的需求,我們預想這是衝突最容易發生的地方,所以,團隊投資了不少心力。專案至今花了六週的時間,在最初的兩週,我們將心力著重在事前討論,透過 Google SpreadSheet / Draw.io 文件化管理團隊共識與專案開發規格,例如使用者故事(UserStories)和資料庫架構(ERD Model)。此外,開發初期,我們也透過實體會議,一同搞定專案基本架構設計與開發需求,若有任何問題,當下也可以馬上釐清與修正。

因此,在上述協作機制下,縱使過程中有衝突或需求異動,大家都能掌握每一個修正所影響的功能,更能提醒彼此哪邊需要修改,以便降低衝突發生的頻率和影響範圍。

Photo Credit by NESA by Makers from unsplash
感謝你完成 1/3 的內容閱讀囉~如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻歡迎繼續往下查看內容呦~

前面分享了團隊合作的模式,這邊想跟大家聊聊,我認為專案成功協作的三大關鍵,提供大家進行參考。

團隊成功協作的三大關鍵

經過六週的團隊協作之後,相信我們還有許多可以優化進步的地方,但最令我開心的事情是,大家都能在目前的協作機制下逐步完成專案目標和任務。

雖然過往沒有帶領開發團隊協作的經驗,但過程中就是不斷的學習與整合,更擁抱我一直深信的核心觀念,並持續執行。

大膽假設,小步快跑,大量試錯,反覆迭代

而回歸個人職涯的最終目標,就是擁有跨領域整合解決問題的核心能力,致力成為一位具有產品思維的軟體工程師,進而帶動公司業績成長。

從結果來看,這次專案也幫助我探索自己的職涯角色與定位,應該是有走在正確的路途上,不僅證明自己能獨立完成被賦予的開發任務,也擁有引導團隊共同往前的領導職能,最重要的是,我真的很享受這次專案實作的過程!

因此,初步回顧開發過程後,也跟大家分享專案成功協作的三大關鍵。

1. 產品開發思維(MVP)

首先,軟體開發有別於過往硬體開發的思維,它本身就是一個不斷迭代的過程,所以有更多的彈性來面對市場需求和開發需求的變動。

專案初期總共有 76 個使用者故事(UserStories),我們依照重要性將開發任務進行優先排序,分成了 phase 1, phase 2, phase 3 的三個開發階段。

如此一來,大家不僅能清楚掌握每階段必須實踐的專案目標,同時,更能專注每個階段該做哪些事情,提升團隊整體的開發效率。

因此,我們分別為這兩個平台使用者,設定不同的專案任務,而兩者之間也具有高度相依性,支撐每一階段團隊需要完成的核心目標,專注於完成屬於我們專案的 MVP 產品。

以消費者來說

・phase 1:消費者可以完成一筆訂單的商品購買行為

・phase 2:消費者可以完成其訂單的付款行為

・phase 3:消費者可以使用優待券,完成折價行為

以管理員來說

・phase 1:管理員可以在後台完成商品上架和查看訂單行為

・phase 2:管理員可以整合第三方金流,實踐平台付款功能

・phase 3:管理員可以開放優待券功能,提升平台消費誘因

因此,我們目前已經開發完成 phase 1~phase 3 的內容,實作出屬於我們專案的 MVP 產品,後續也有一些產品優化的計畫正進行中,敬請期待。

Photo Credit by Lindsay Henwood from unsplash

不過,由於大家都是遠端參與專案,如何讓團隊保持高度凝聚力,創造正向循環的協作模式,便是我第一個要面臨的課題。

2. 參與式的團隊協作

結合過往的團隊領導經驗,我認為團隊凝聚力的行程來自於大家的積極參與,因此,我不僅要讓團隊認同彼此是一起打造產品的好夥伴,更要引導大家對於產品有其歸屬感,如此一來才能發揮 1+1+1 > 3 的團隊綜效。

Step1:個人發想

所以我透過問題引導團隊表達想法,將每個人的創意彙整成可以落地的執行方案,尤其團隊處於邊研究邊實作的歷程,所以也沒有太多的開發經驗。

因此,比起短時間達成專案成果,我更在意大家的共同參與和經驗累積。

舉例來說:在專案初期,我們花了將近兩週的時間,才敲定使用者故事(UserStories)和資料庫架構(ERD Model),過程中最重要的是給予彼此充分的思考時間,讓大家都能好好參與專案的發想過程。同時,為了幫助團隊慢慢理解如何打造一個電商產品,我們研究市面上既有的產品,如 Shopline仙境傳說 RO 電商pokestore 寶可電商,同時,提供大家發想的範本模板,引導每個人在框架中發揮自身的創意與想法。

Step 2:團隊討論

當大家都已經有自己的初步想法後,才開始下一步的團隊討論。

首先,透過團隊先前所訂立 phase 1, phase 2, phase 3 的開發階段目標,引導團隊在一致的認知標準下,專注討論 Google SpreadSheet 每一個想法,釐清每個需求背後的動機。

而充分溝通後,我們才彙整成團隊最終的執行方案,縱使過程中大家想法可能會不同,但鼓勵團隊積極參與,也慢慢創建一個正向的團隊文化。

舉例來說:在一開始討論管理員帳號功能的開發階段時,團隊曾經有意見上的分歧,我認為它可以在 phase 1 階段完成,但振壹認為可以在 phase 2 階段,甚至是在 phase 3 階段再來開發,最終,團隊採行振壹的想法,將其遞延至 phase 2 階段才開發。團隊決策的原則如下:正因為管理員帳號功能,不影響管理員完成他在 phase 1 階段的核心目標任務,因此,團隊憑藉這個決策標準,共同做出決定,過程中也幫助大家了解每個決策背後的思維,創造一個良好的溝通模式。

綜合上述所提,我認為專案成功協作的第二個關鍵在於擁有「參與式的團隊協作」文化,而這件事情必須從每一次的日常討論當中塑造與累積,我真的很享受這次和 振壹 Wanaka敬杰 Ginger 共同協作專案的過程。

Photo Credit by Priscilla Du Preez from unsplash

接下來還有第二個問題需要解決,那就是如何讓專案資訊透明化,降低溝通成本,提高團隊開發效率。

3. 透明化的溝通模式

之前曾在書上看到,一位軟體工程師,工作時程大致會被切分成三等分,分別是技術債時間、開發/研究時間,還有溝通時間。

經過本次專案後,深刻體會到溝通這件事,在軟體開發上有多麽的重要!

因此,團隊協作時,我們善用不同網路軟體,確保所有專案資訊透明化。

舉例來說:除了先前使用 Google SpreadSheet 統一彙整使用者故事(UserStories)和資料庫架構(ERD Model)之外,我們也把每一個使用者故事(UserStories)轉換為 Trello 上的每一個 ticket。不僅幫助大家管理各自的開發事項,也讓每個人掌握現在專案開發的全貌,甚至是未來有可能排入開發進度的產品需求,有效降低團隊溝通成本。

此外,我們非常重視每一次會議的目標和效率,所以每一次會議前,我們都會在 Slack / Google Canlendar 註明會議流程,也告知需要事前準備的內容,鼓勵大家事前一天把自身想法先分享給團隊,確保大家都是在準備好的狀態下,進而才參加當日的專案會議。

核心目標就是讓團隊在會議結束後能有具體決策產出,持續驅動專案往前。

專案運作至今(7/16 ~ Now ),團隊有 27 場會議(22 場線上 和 5 場實體),合計每個人皆投入 70 個小時的會議時間。

不過回頭看團隊投資大量的溝通時間,不僅有助於創造一個「透明化的溝通模式」,也讓大家清楚掌握專案的全貌,增加團隊整體的協作效率。

因此,我認為上述三點,產品開發思維、參與式的團隊協作、透明化的溝通方式,正是這個專案能成功協作的關鍵因素。

Photo Credit by Randy Fath from unsplash
感謝你完成 2/3 的內容閱讀囉~如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻歡迎繼續往下查看內容呦~

接下來,我要分享在專案中的收穫和未來工作日常的體會。

從專案中體驗未來工作的日常

我會用三句話,帶出不同的三個小故事來分享我的所得所獲。

1. 從實作中,探索自我職涯的可能性

首先,我在電商專案實作過程中,持續驗證著最適合自己的團隊角色和工作內容。

老實說,我很享受身兼 PM 和 Developer 的角色,特別是我知道我的人格特質和細節導向的做事方式有助於我在 PM 職務上發揮得更好。

雖然初期的職涯目標,還是會希望以軟體工程師為主,從中累積更多技術開發能力和實務經驗,不過我主動找尋一些除了程式開發外,也能碰觸到產品開發全貌的職涯機會。

如此一來,不僅有助於專研自身技術能力,也發揮跨領域經驗來幫助公司和團隊解決問題,持續累積相關的實戰經驗。

2. 從未知中,創造自我突破的機會

對於新創公司來說,往往都在解決一些沒有標準答案的問題,縱使網路上有許多參考資料,但如何落地到自身的專業領域,這又是一門很大的學問,如果沒有親自走過,真的很難體會。

而如何在未知中突破成長,則是我的第二個故事。

不論是過往擔任 BD 負責雲端 SaaS 產品的市場推廣或是實作本次電商專案的過程,也都是在這樣的過程中,持續地進行自我的產品迭代。

其實在專案初期,我們還不知道如何實作出一個前後端分離的產品,甚至是完全不知道從何開始,但我們始終保持一個健康的心態,相信自己辦得到!

舉例來說:在本次專案中,不論是初期產品開發的規格規劃,還是如何架構 RESTFul API,甚至是第一次使用 Vue.js 進行專案開發,對我們都是一個很大的自我嘗試與突破。而真實的樣貌,其實大家都是在邊摸索邊實戰中,一步一腳印,不斷突破未知的過程,最後才完成現在的 MVP 產品樣貌。

上述這件事情不禁讓我聯想到,這不就是未來我們工作的日常嗎?

我也始終相信,當你不知道答案時,其實就是一個最棒的成長機會。

回歸我的核心觀念:大膽假設,小步快跑,大量試錯,反覆迭代

如此一來,不僅有助於引導我們更快速找到解決方案,也有助於你達成個人 10 倍速的自我成長,而這些能力也都是你一輩子帶著走的優勢與經驗。

3. 從錯誤中,獲取更多新知識

在電腦世界當中,一旦你的邏輯不對或是有錯誤出現時,它的反饋非常即時,不過錯誤對於軟體工程師來說,其實是一個很棒的消息,因為你又有 bug 要處理了(揍飛XD)

與其這樣說,不如聊聊我自己,在這次專案中遇到錯誤的學習。

舉例來說:那是一個訂單創建功能的異常,裡面包含許多不同的函式,也牽動到不同資料庫的互動行為,處理上其實有點複雜。當它第一次發生問題時,我將訂單創建的功能拆解成不同的步驟,逐一來檢查問題發生的地方,後來發現原來是前端頁面表單要上傳至後端資料庫時,遇到資料格式不相同的問題。

在上網研究後,我學會一個新知識,原來表單資料上傳與資料庫溝通的方式有下列兩種,分別是:

(ㄧ)資料上傳格式為 x-www-form-urlencoded前端頁面若是透過 v-model 方法逐一取值,接著存入陣列之中,再透過 API 上傳至伺服器,此時的資料格式預設的是 x-www-form-urlencoded 的文字格式。而後端 express 框架,預設的格式也為 x-www-form-urlencoded,因此,前後端可以正常溝通。(二)資料上傳格式為 multipart/form-data前端頁面若是透過 formData 的方法一次打包,此時,打包後的資料格式會是 multipart/form-data,若此時後端使用 express 框架,檔案格式為 x-www-form-urlencoded 的文字格式,所以兩個會有不相符的情況產品,因此跳錯。為解決這個問題,我們需要在後端引入 multer 套件,並於 route 時使用,以便前後端才可以順利進行溝通。參考資料:multer套件

而當時我使用的資料打包方式為 formData 格式,因此,我必須要引用 multer 套件,才能解決讓前後端的資料順利進行溝通交互。

透過上述的第三個小故事,也讓我體會到產品開發,其實也是一個不斷反覆試錯的過程,你踩的雷越多,你更有機會比其他人學會更多東西,長期來說,過程中的每一個小錯誤,都是我們持續成長的充沛養分。

Photo Credit by Robert Collins from unsplash

結語

再次感謝我的兩位夥伴 振壹Wanaka敬杰 Ginger,有你們的參與共創這個電商產品,也激盪出不同火花,互相鼓勵與學習,成就更好的彼此。

而在撰寫文章的過程中,我不斷回顧專案的每一個小細節,卻也慢慢發現原來是過程中的點點滴滴,才累積成現在的專案成果。

其實打造一個產品,就像是自身職涯的發展一樣,約莫一年之前,我是一個完全不太懂技術的 BD,碰到問題時,往往也只能提供業務解,但碰到更深入的技術問題時,我卻無能為力,只能將命運交付在他人手上,而這也是我當初為什麼決定要開始程式自學的旅程。

延伸閱讀:「願景驅動改變」- 當能力撐不起野心,歸零學習創造一條新的路

一年後的現在,相信我還有許多要研究學習的地方,但至少我具備了一些基礎的知識,也知道如何從中找尋問題的答案,更享受這樣的過程。

最後,真的很開心,即使目前的產品不甚完美,但它卻為我們帶來最貼近業界的開發體驗和協作方式,更讓我理解原來動手做產品是這麼一回事!

謝謝你的閱讀!如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻
最後,若希望持續追蹤我的最新文章,別忘了追蹤 皮爾斯的自學旅程 唷,乾溫 :D

--

--

皮爾斯的自學旅程
皮爾斯的自學旅程

Published in 皮爾斯的自學旅程

Software Engineer with product mindset to lead business growth

Pierce Shih
Pierce Shih

Written by Pierce Shih

Leading business growth with product mindset and technical perspective