從 1 到 50 — 我在 inline 的 640 天

2018.7.20
我加入後第 640 天, inline 的簽約餐廳數正式達到了一個里程盃。團隊也從加入時的 2 人成長到近 20 人。將近兩年的時間,每天張開眼睛就是工作,閉上眼睛睡覺,隔天繼續,週末?恩?那是什麼?可以吃嗎?我想可以稍微停下來慶祝一下這個時刻,回顧這 640 天,從 1 到 50 的神奇旅程。


產品

先簡單介紹一下 inline, inline https://inline.app 是一套專為餐廳打造的雲端 Table Management System (TMS),時至今日,我們的功能當然是更加豐富。不過,在我剛加入的時候,產品 MVP 基本上已經完成了。inline 的核心功能:候位、訂位都是上線且有 11 家餐廳每日在使用。

在前一家公司,我學到創業最艱難的第一步就是產品沒人使用,沒人使用的產品會消磨團隊的意志,最終走向結束,詳情請見兩年前「我們失敗了」一系列文章XD

有了前一個公司失敗的經驗,inline 站在一個完美的起跑點。對於一個產品來說,最重要的是「解決問題」,而 Retention Rate 是 Product Market Fit (PMF)唯一指標。

inline 一開始要解決的問題很簡單:「餐廳在候位時需要登記客人資訊、打電話請客人回來,如何讓這一切變得更有效率?」在 inline 的最前期(這段我沒有參與到,但常常聽到XD),就是找到一家願意試用的餐廳,不斷的讓其使用,收集其中的 feedback ,修改,再讓其使用,直到餐廳願意每天使用。

說起來很簡單,但實際上你得在週末花上好幾個小時站在旁邊觀察餐廳人員的使用,客人等待時的反應,結束後再詢問現場人員操作上遇到的問題,回來思考如何調整,然後再試一次。時至今日,對於每個新上線的產品,我們都還是會進行同樣的流程。就像最近我們協助一蘭改善其候位流程,連續幾個週末我們都會在現場確認整個流程是順暢好用的。唯有親眼看到,才能體會。

怎麼判斷 Product Market Fit?有一個客戶每天使用就是 Product Market Fit。


客服

在早期,我們只有 3 個人的時候,我常常跑餐廳進行教育訓練導入,結束後就會留下 LINE。到現在,我也還是會常常在週末或是平日半夜收到餐廳的 LINE 或是電話詢問系統問題。對我來說,第一線接觸客人對於產品開發是非常有幫助的。除了能直接得到產品的回饋外,更重要的是可以讓團隊能同理客戶使用上遇到問題。因此,看了幾篇有關 All Hands Support 經驗的文章後,我們也決定導入 All Hands Support。

All Hands Support 顧名思義就是所有人都要擔任客服的工作,負責處理餐廳回報的問題。我們的編制一組人由一個 RD + 一個非 RD(sales、designer、marketing、助理等)組成,在排班的期間由該組人負責回覆、處理所有客人回報的問題。

我們客服的方式以線上客服為主,主要的工具是透過 Intercom 和 Bugsee 整合了 Slack。在 App 內我們在第一層放置了幫助的按鈕,任何使用者都可以很快速的透過 Bugsee 回報問題或是透過 Intercom 發問。透過與 Slack 的串接,任何客戶反應的問題都會第一時間在 Slack 上通知團隊。有客服經驗的人應該知道,一般使用者其實非常難把問題描述的清楚,遠端的情況下更是需要許多時間來回釐清問題。而 Bugsee 的服務可以讓我們看到使用者回報前一分鐘的操作的影片錄影,對於釐清問題有非常大的幫助。確認問題後,若是技術相關是由 RD 負責進一步追查,調 log 或是 fix bug;操作或使用上的問題就直接在 Intercom 回覆餐廳。

當然我們知道 RD 是很貴的,加上客服本身是個不斷發生的中斷性工作,在值班客服時對開發上的效率必然會大打折扣(工程師最痛恨的 Context Switch XD)。即使如此,我們還是持續這樣的做法。我認為犧牲一些開發上的效率換來的好處是非常巨大的。包含:

  1. 讓整個團隊跟第一線是同步的,常常聽到有些公司 sales 與 RD 對立嚴重,Sales 不知道 RD 在幹嘛,RD 則認為 sales 提出的需求都很傻眼。透過客服,一同面對客戶,可以拉近兩邊對客戶的認知。
  2. 提高成就感。在客服的時候,因為可以第一線的接觸使用者,雖然多數是時候是在處理問題,不過也會收到一些新功能上線時客戶的肯定,看到客戶實際使用產品並且提出回饋甚至認同,我認為對開發產品人員的士氣來說是非常有幫助的。
  3. 反應更即時,主動改善產品。有時客服處理餐廳的問題時,因為是 RD 順手就把問題改掉了。餐廳也很訝異為什麼我們反應這麼快速。

在客服上,我想應該還是會維持現有的方式。


開發

在開發上,我們採用敏捷開發中的 Scrum。

在一開始 2–3 人團隊的時候,我們是以一週一個 sprint 的節奏來開發。一週一個 sprint 的好處是反應非常快速,在當時我們每週都會上一個新的 iOS app 版本。餐廳在當時對於我們開發的反應速度是非常驚訝的,因為餐廳過往使用系統的經驗,一個需求提出到完成往往需要數個月甚至一年以上的時間。而我們卻能在一週或 2–3 週內完成。能這麼快速的原因有幾個:

  1. 團隊小,沒有溝通的 overhead,大家快速討論一下就直接做了。
  2. 產品規模小,早期產品功能複雜度低,不論是新增功能或是修改現有功能都不會有太多的 side-effect。
  3. 全面導入自動化測試與持續部署(CI / CD),在人少的情況,自動化是改善速度的一大妙方。所以即使在專案只有一個人開發的時候,我們每個專案一開始的第一個 UserStory 一定是測試環境與 CI 的建置。

以 iOS 專案為例,我們的流程包含:
 a. unit test on every commit
 b. Merge 到 develop branch 會自動發布 beta 版本
 c. 開啟 release/xxx branch 會自動發布 release candidate 版本
 d. Merge 到 master branch 會自動 submit 至 AppStore 並且自動提交 review

前 3 項比較常見,但最後一項自動提交 review 的部分,一開始覺得沒什麼必要,不過是手動登入按幾個鈕而已,所以我們也沒有導入。但過了一陣子後,發現這個動作實在是太機械性、太煩躁了,所以我們也調整為 CI 會自動提交 review 。從此人生又少了一件事情要做。提交新版本只要用手機開 Github PR 按下 merge 就好了,好不快活!

以一週一個 Sprint 的步調開發維持了大約一年的時間,直到團隊成員成長到 5–6 人左右,在一次 retro 中大家提出討論希望能把 sprint 的長度延長到兩週。評估後我也認為是合理的,主要原因有三點:

  1. 會議的 overhead,每週一個 sprint 意味這週一 planning 、週五 review + retro ,當時我們 planning 一個上午、review + retro 一個上午,實際上開發的時間大概只有 4 天。隨著團隊成員的增加,會議的時間無可避免的會拉長。每週一個 sprint 的 overhead 有點過高。
  2. 產品規模的成長,經過了一年,inline 的產品從一開始最精簡的訂、候位管理系統發展到許多周邊的功能,如顧客管理、線上訂位、機器人訂位、訂位控管、時間軸訂位管理等等。加上快速 feedback 開發的代價不可避免的會累積技術債,加上多人同時開發,修改一個地方已經不是單純的事情,需要考慮的事情更多。
  3. 商業規模的成長,在此同時,我們的餐廳數也不斷在成長。當初快速迭代時即使改壞了,影響的餐廳數量有限。但隨著餐廳數的成長,我們在釋出每個版本時都會影響更多餐廳、客人,背負著更大的壓力。

改為兩週一個 Sprint 後,整個團隊的步調直到現在都還是覺得很 ok。

做為一個同時開發、營運上線的產品的團隊,無可避免的就是插件的處理。包含了:上了新的版本發現的問題,客戶使用上遇到的舊問題,重要的新客戶提出的需求等等。

對此,我的看法很簡單,既然沒辦法擺脫它,就是:

面對它、接受它、處理它、放下它

所以,常常還是會有插件的產生,需要立即的處理。有點不太好的是,每個 sprint 我們幾乎都沒有完成原本 planning 的規劃,往往都有 leftover 的 tasks。對此的因應措施,我們有幾個正在執行中:

  1. 謹慎的 release ,導入 release management。早期對於每個版本我們都抱著快速上線的心裡。經過幾次出包花了更多時間 hotfix 出包的問題後,我們認為應該對於 release 更加謹慎。同時也引入了 release manager,由專人負責紀錄每次 release 影響的範圍。
  2. 更完整的自動化測試,剛剛提到幾個插件中,唯一真正需要立即處理的就是 critical bug 的 hotfix。對此,別無他法,只有投資時間來增加更完整的自動化測試。在 API 方面,我們自動化測試的涵蓋率非常高,所以 API 的部署遇到的問題相對 iOS app 來得少。iOS 我們有自動化測試,但在早期快速開發的過程中,這部分的確是被犧牲的部分。現在我們開始要求每個 bug fix & feature 開發都要有完整的測試。
  3. 客戶的需求,相對於第一點,客戶的需求容易處理許多。早期,為了爭取客戶,加上產品本身的功能的確不完整。我們對於合理的需求都是快速的開發滿足其需要。現在,產品相對成熟後,大部分需求其實都是一個 nice to have 而不是 must have 。我們可以投資更多時間在產品的穩定度與效能上,將需求做適當安排,而不用插件處理。

問題

目前我們遇到了幾個問題:

  1. PM :由於我們沒有專職的 PM,所以整個 PM 的工作幾乎都在我身上,而我本身又同時在進行開發。在早期團隊較小時的確沒有太大的問題。不過隨著團隊與客戶的成長,越來越多事情需要更完整的計畫讓 Sales 與客戶清楚產品的方向與進度。所以我們開始尋找適合的 PM 人選。
  2. 效能:我一直以來的夢想就是系統能遇到效能問題XD 但實際上遇到了實在不是一件能輕鬆應對的事情。效能問題隨著客戶數的增加會越來越嚴重,在進行整個效能改善的同時,也必須維持現有服務的穩定。 這就是像是同時在一架飛行中的飛機上面新增功能、修補破洞,又要保持其不會墜機。加上團隊一直都沒有一個專職的 Backend Engineer ,都是大家兼著做。目前這部分我們已經完成了 90% ,也通過了一蘭拉麵線上的壓力測試。但事後檢討我認為開發時,我們應該能更注重效能一點。我們也在徵求 Backend Engineer!
  3. 需求不斷累積,隨著公司規模的成長,我們的目標也不止於此。Todo List 以現在的人力而言,大概已經累積到後年的程度。我們非常缺 Front-end Developer。

如果看完這篇文章,您也認同我們的想法,我們竭誠歡迎您加入 inline!

履歷請來信 ken@inline.app

#inline

Like what you read? Give Ken Kuan a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.