在 Pinkoi：工作工具化、創造多贏局面

在解釋什麼叫做把工作工具化之前、先讓我們來說一個小故事。

眾所皆知、 Pinkoi 是個電商網站。無可避免的，我們會定期+不定期地推出許多優惠行銷活動(像是特定商店的訂單打折或是免運費之類)。但是、這些優惠行銷活動、在最早的時候，每次都是由工程師手動修改購物車程式設定的！這也延伸出許多的相關的問題：

• 就算是同樣類型的優惠行銷活動、每個工程師的理解跟實作都不一樣。換了一個工程師實作的時候、就可能出現新的問題。每次有新人加入的時候、也必需和他說明什麼樣子的活動該修改購物車的哪些地方。也因此，每次上線新活動的時候、工程師們仍然需要花費一定的精力和時間去撰寫、測試這些行銷活動相關的程式碼。
• 就算是同樣類型的優惠行銷活動、每個開活動需求的行銷部門的夥伴也不見得知道如何正確的開需求到工程部門。導致工程師需要反覆地去和行銷部門確認需求以及要求正確格式的活動設定資料。
• 更慘的是，當工程和行銷兩邊都剛好是新人的時候，可能工程不知道要去要什麼資料、行銷也不知道要給哪些資料。
• 由於上線活動需要工程師修改程式，行銷部門在考慮舉辦活動的時候，都要先和工程部門敲定工程師的檔期。當活動越來越頻繁的時候，不但造成工程部門的人力越來越吃緊、因而沒有人力去開發其它網站功能。工程師們每次都在修改這些很類似但是卻又都有一點不一樣的活動程式，對於士氣上也是一種消耗。
• 有時候活動臨時需要調整的時候，一樣要找工程部門處理。如果剛好遇上半夜時有什麼十萬火急的調整、而原來負責處理的工程師可能又剛好聯絡不上的時候，就只能期待其它工程師剛好在線上而且還可以快速找到並理解負責處理的工程師寫的活動程式碼並且進行修改。
• 就算臨時修改的程式順利的在短時間內完成了、後續還必需等待部署到正式環境的時間。並且工程師通常還需要後續保持追蹤一段時間避免有什麼沒測試到的問題突然冒出來。
• 這些短期活動類的程式碼，通常在活動結束後、也很少有工程師會記得去將它移除。導致一堆無效的程式碼充斥在購物車邏輯中。除了浪費 server 資源外、還會造成除錯時的麻煩。

終於、有位工程師、在同一個月為三個不同的優惠行銷活動、寫了三次幾乎一模一樣的活動程式碼之後，他覺得這樣子下去不是辦法。於是他花了一點時間設計了一個簡單的架構。

• 特定類型的優惠活動都會有一個標準的設定資料(configuration)結構。舉例來說，如果是特定商店免運的活動，要求的資料可能就是: 開始時間 / 結束時間 / 商店 ID 列表 / 最低購買金額 … etc.
• 購物車增加一段專門負責特定活動的程式碼。但是它的套用條件不再是為了每個活動寫死的。而是由一個列表中讀取該特定類型活動的設定資料，並且依據裡面的設定套用相關優惠與顯示訊息。
• 以後所有的工程師新增同類型的活動時，只增加「設定資料」，不再增加/修改「程式碼」。

在這樣做之後，帶來了許多的好處、包括：

• 說明如何撰寫設定資料的難度、比說明如何撰寫程式難度低太多。並且因為需要的設定資料已經標準化了， 在跟行銷部門要求資料的時候也會有固定的格式。不再是每個人都有自己的一套、還不知道有沒有漏掉。
• 由於程式的邏輯單一化了，所有的工程師在處理優惠行銷活動時、只需要熟悉這一套邏輯即可。也讓後續不管是要針對這段程式優化、除錯、修改、防呆或是自動測試，都變得更為容易、開發資源也更加集中。
• 以上這些、除了減少了部門間來回溝通的時間、也讓活動設定變成一件更有信心的工作。而工程師完成一個優惠活動設定的時間，也從 1–3 天、縮短到 1–3 個小時、甚至低於 1 個小時的。

所以這個故事到這邊就結束了嗎? 並沒有。

倒不是這樣子的做法有什麼問題、而是我們開始思考，我們能不能做的更多、讓更多人能更輕鬆的工作、解放更多人力。這時候一個想法開始萌發。

既然我們已經有標準的活動設定資料格式了、那麼為什麼我們不新增一個UI、讓工程部門的需求方 — 行銷部門 — 可以自己新增/修改/管理優惠行銷活動呢？

免運活動編輯工具

於是我們真的行動了。在經過工程部門和行銷部門的來回討論後。我們將站上常用類型的行銷優惠活動、做了一個全面的整理。並且為每一種常見的行銷活動建立了專門的編輯用 UI。至此

對於工程部門來說

• 不需要一再撰寫既重複又容易出錯的購物車優惠程式碼（工程師士氣上升）
• 不用再特別撥出人力幫行銷部門手工設定各種優惠行銷活動、省下的人力可以轉去開發更多網站上的新功能（解放人力+更有效運用）

對於行銷部門來說

• 一般常見類型的活動不需要再和工程師喬檔期。活動想開就開、就算半小時後臨時要開快閃活動都沒問題！從此舉辦活動更有效率和彈性。
• 半夜臨時的修改、甚至整個活動撤回改期也都不用擔心找不到工程師可以幫忙。

對整個公司來說

• 行銷部門能不受工程部門人力限制、更有效率和彈性的舉辦活動。對於網站的營收有所助益。
• 工程部門可以把人力集中在其它更有價值的功能開發上、對於網站的未來發展有所助益。
• 營收上升 + 未來發展可期，讓公司有更多資源投資在所有員工身上。

我們藉由將工作工具化、創造了一個多贏的局面

之後，受到這次工具化成功的例子，我們也對於這樣的模式更有信心，後續也開始將更多的日常工作流程，做成標準的工具提供給相關的人員使用。但是，也並不是所有的工作流程都應該無條件工具化。以下是一些簡單的準則：

• 需求還沒有收斂的工作流程、不需要工具化 。如果每次工作流程都相差很大、那麼代表這不是個常態的需求、或是並不是一個可以標準化的需求。這類工作流程、基本上無法工具化。不過這裡有一個但書，有時候其實並不是工作流程沒有標準化、而是經手的人不知道該如何標準化。這時候其實需要的是比較有經驗的人來整理並且確認是否有標準化的可能性。
• 省下的資源/帶來的好處不夠大的工作流程不需要（優先）工具化。舉個例子來說：某個金流的手動退款必須要人工登入該金流的後台、花費一個客服人員大約 5 分鐘的時間來核對並且完成一筆金流的手動退款。並且、該金流的退款需求頻率大概是一星期 1–2 筆訂單。這時候，這個金流的退款功能工具化，就不會是個好的優先工具化項目，因為它只能省下一個人每星期大約5–10分鐘的時間。反之，如果這個金流的退款頻率是每星期100筆以上、那麼，為它進行工具化帶來的好處，就明顯的上升了。