從 1 到 50 — 我在 inline 的 640 天

2019.7.3 更新

時間過的很快，距離上次發文不知不覺 11 個月過去了。這 11 個月伴隨著 inline 成長，也隨之帶來許多問題，在處理問題的過程中，也讓我持續的成長。不過天下無不散的宴席，我已於 6/21 離開 inline。這兩年十個月的時間，我見識了從 1 到 100 的過程，也飽嘗了創業的酸甜苦辣，很慶幸能跟一群充滿熱情的夥伴一同奮鬥、努力。

目前對於下一步還沒有一個確定的方向，還在看看外面的世界中。如果有什麼合作機會，都非常歡迎談談！

個人的 email: [email protected]

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。