怎樣找出和預防內容營運的痛點

內容設計師很少會專注在單一項目。我們經常同時兜住幾個，而請求從四面八方來。這些請求通常都是一個更大流程的一部分，由產品構思到市場推出，而寫作就坐在正中間。

即是話，內容經常在所有東西的中心。下游任務例如 QA、產品上線和本地化，全部依賴文案準時簽核；而上游任務例如 UX/UI 或者市場推出，全部依賴內容準備好。

但實際上，工作流很少會是最優化的。工作效率上的缺口、未解決的歷史遺留問題和新出現的障礙，全部都好常見。如果有一項卡住，成條工作流可以硬生生停低。一旦這樣，死線就會走漏、上線延遲、一片混亂——就好像一班延誤了的轉機航班。

不過，當內容營運出現問題的時候，內容設計師的位置好適合採取主動。這份指南介紹 Agile 的 Value Stream Mapping（VSM）方法——一個實用工具，幫你清楚識別低效和樽頸、精簡流程、減少延誤，並加強跨團隊協作，令工作流有效這樣改善得到。

內容營運的 Value Stream Mapping

Value Stream Mapping（VSM）出自 Agile 專案管理。這個精益方法用流程圖顯示每一個流程步驟，突出浪費和低效，藉此縮短週期時間、提升客戶價值。它將工作流的現狀 map 出來，看價值怎樣累積、潛在樽頸可能在哪。

例如，如果你訂機票去你最鍾意的度假地點，你的 value stream mapping 大概會是這樣：

登入航空公司網站 > 輸入目的地 > 輸入偏好日期和艙等 > 頁面載入 > 頁面顯示可選日期和航班時間 > 用戶揀航班時間 > 頁面載入 > 輸入個人資料 > 選擇附加服務 > 揀座位 > 覆核行程細節 > 付款 > 頁面和銀行核對付款資料 > 認證完成 > 收到登機證和確認電郵。

在這個情況下，假如客戶撞到任何阻礙，要識別他們在哪裏發生、以及怎樣累積起來，就容易很多。訂票過程整體延誤，可能源自搜尋之後那次頁面載入；而附加服務那一步再卡多一次，就令個可憐的旅客更慘。

除了識別痛點之外，VSM 亦令你可以簡化成條 value stream，甚至將不同階段合併。試想像你要訂機票——如果你可以在同一版揀座位和附加服務，又或者同時揀航班時間和日期，是否好些、又節省時間？

所以，如果客戶撞到路障，VSM 幫你精確指出延誤可能發生在哪，以及項目管理者可以在哪裏着手，透過解決樽頸和簡化工作流去減輕整體影響。

登入航空公司網站
輸入目的地
輸入偏好日期和艙等
頁面載入
頁面顯示可選日期和航班時間
用戶揀航班時間
頁面載入
輸入個人資料
選擇附加服務
揀座位
覆核行程細節
付款
頁面和銀行核對付款資料
認證完成
收到登機證和確認電郵

識別我們內容營運的樽頸

返返我自己做內容團隊領導的經驗。我隊人每日收到雪崩式的任務，由廣告文案、內容設計，去到翻譯和本地化。這些任務來自好廣泛的 product owner 和各地市場經理。所以，令工作流盡可能順暢、盡可能少延誤，就很關鍵。我們的內容營運裏面任何一環塞住，成條流都受影響。

個流程大致是這樣：

Product owner 制定任務 > product owner 填 ticket > 文案介入，做 UX writing 或者 campaign 文案 > 文案獲批 > 翻譯和本地化開始 > 創意團隊按廣告文案製作 banner > 項目上線。

在這裏，我將好用的 VSM 派上用場。我想理解工作由哪裏來、有沒有用最有效的方式交付、以及樽頸在哪。

將所有東西列完出來之後，我立刻識別到的一個樽頸，就是文案 ticket 的請求表格實在太累贅。裏面有很多沒有必要的欄位，對使用者來講非常複雜。所以我第一步就是精簡個請求，令它更簡單、更易用（作為 UX writer，精簡產品是本能）。

完成之後，我對成條工作流和些樽頸就有了一幅相當清晰的圖。跟住我留意到步驟之間有很長的等待，期間幾乎沒有溝通，一切靠假設。

我修改了工作流：一旦出現任何延誤，上游必須通知下游。這件事未必消除到延誤，但它肯定帶來清晰很多的能見度。

Product owner 制定任務
Product owner 填 ticket
文案介入，做 UX writing 或者 campaign 文案
文案獲批
翻譯和本地化開始
創意團隊按廣告文案製作 banner
項目上線

逐個解決內容營運問題

以我的經驗，抱住一種主動心態，可以令一個內容設計師做到的東西遠多過寫文案。當時還餘低三個關鍵痛點。

第一，我們的工作流軟件在 ticket 批核之後沒有通知機制，即是話有很大一截 lead time 用了在等一個「可以繼續」的訊號。
第二，因為沒有訊號，文案和 product owner 要在一份 Google Sheet 表格裏面，在特定格仔打「approved」去人手批核每一件工作。這件事製造了額外門檻，亦是溝通斷層的來源，因為雙方在批核發生當時都收不到通知。
第三，內容設計師收到的任務全部沒有情境，導致很多本來避得開的返工，因為動機不清楚。

VSM 令我行得到動。首先，我向 IT 提出請求，在 CMS 或者 kanban board 有批核的時候，經即時通訊系統發通知。這樣，一旦 ticket 獲批，雙方都不會含糊。同時，靠自動系統就不再需要在 Google Sheet 格仔人手批核，等於移走了一個關鍵步驟和障礙。這件事做得到，是因為通知已經達成了原本想要的效果。

另外，我們落實了一條新規則：value stream 任何一部分一出現延誤，整條 value stream 的死線都必須順延。這個做法帶來更好的溝通，以及對工作流階段和卡位的能見度。

我做過更深層的一步，是*寫了一份新 SOP*，涵蓋 UX、產品和內容設計師，核心目標是培養情境和溝通。這樣，我們逐步打破了筒倉，合作得更緊密，溝通斷層減少，想法亦分享得更好，確保到文案的貼題度和質素。

不過我們要記住，VSM 不是所有內容營運障礙的解藥。例如，一個經常導致延誤的主要障礙，就是不清楚或者不斷變動的產品範圍。這個可能源自產品團隊的內部溝通問題，又或者業務需求本身在演變。改良過的溝通同工具可以紓緩一部分問題，但解法可能在另一隊人手上，我們只可以減輕影響。

VSM 是一條沒有終點的路。業務情況演變，工作量和隨之而來的問題亦會演變。Agile 原則本身就是設計來透過回饋和迭代循環促成持續改善。或者正因如此，我們那次 VSM 練習，為之後全公司層面的 AI 工作流改造打好了基礎。

三個關鍵痛點

第一

我們的工作流軟件在 ticket 批核之後沒有通知機制，即是話有很大一截 lead time 用了在等一個「可以繼續」的訊號。

第二

因為沒有訊號，文案和 product owner 要在一份 Google Sheet 表格裏面，在特定格仔打「approved」去人手批核每一件工作。這件事製造了額外門檻，亦是溝通斷層的來源，因為雙方在批核發生當時都收不到通知。

第三

內容設計師收到的任務全部沒有情境，導致很多本來避得開的返工，因為動機不清楚。