10 天之間，發生了什麼事？——《俄烏戰爭日誌》Live Blog 敘事實驗背後的產品選擇
在這場二戰之後的重要戰役——俄侵烏戰爭，《報導者》不僅派出致昕、映妤、子磊三位記者飛往歐洲進行採訪，更嘗試了過往我們未曾採用過的敘事方式。2022/03/14（一），《報導者》首次推出的Live Blog，正式上線了！《報導者》為什麼選擇Live Blog的新形式？從記者決定出發到Live Blog上線，只有短短10天，產品經理在想什麼？這段過程中扮演了什麼角色？又做了哪些判斷和決定？
一切的開始
每個週五早上，是《報導者》各個部門主管的會議時間。輪到編輯部時，總編輯雪莉的一句話，讓在場的眾人對於接下來即將發生的一切既感到熱血，卻又無比焦慮：「我們決定下星期派致昕到烏波邊境採訪了。」
3/4（五）的會議之前，俄侵烏戰事已經開始將近兩週，在新加入的社群部同事彥成的努力下，我們使用了 IG 限動影片與讀者溝通烏克蘭相關的資訊，並獲得了很好的成效，觸及到許多原本並未追蹤《報導者》IG 的使用者；但整體而言，處理俄侵烏戰爭即時新聞的大方向，仍然與過去相同：評估事件的進展狀況，決定當天是否進一步統整成完整的即時新聞，而即時新聞的內容則會在 FB、Twitter 等社群媒體刊出，後續再收錄進《報導者》網站當中。
《報導者》的內容性質和其他媒體有著顯著的差異，「搶快」向來不是我們的風格，也並非內部有限的人力所能負擔，因此僅有極為重大的事件發生時，我們才會跟進製作即時新聞內容。舉例來說，在俄侵烏戰爭之前，近 3 年來，曾經以即時新聞模式處理的事件包括香港反送中、COVID-19疫情、國內外大選、太魯閣出軌事故等重大新聞。由於即時新聞不是《報導者》的核心內容，產品需求相對模糊，同時也已經有 2020 年完成開發的大事記圖表產生器能夠部分回應即時新聞的使用情境，因此在產品 roadmap 當中，即時新聞的新版型和上稿工具便被放置到優先程度較低的順位。
然而這次的俄侵烏戰爭，外加即將派出記者們前往波烏邊境，又再次暴露出編輯台在處理即時新聞時的痛點：
- 大事記圖表產生器的上稿方式，對於編輯台多數同事而言仍然不夠親民與自動化，連帶影響到內部的人力作業成本。
- 大事記圖表產生器的應用場景，更適合單一軸線事件結束後的整體脈絡回顧；當事件有多種視角、或仍處於事件快速進展期間，就不那麼適合以大事記的形式呈現。
- 隨著網路科技演進，許多內容來自外部平台——例如烏克蘭總統澤倫斯基時常在 Twitter 上傳影片、烏克蘭副總理在社群上請求馬斯克（Elon Musk）提供星鏈系統援助、聯合國會議在 YouTube 頻道開啟線上直播等等，快速、方便地運用外部內容作為素材，進一步打造新的敘事，是編輯台不僅在此次俄侵烏戰爭，也是日後處理即時新聞的硬需求。但我們現有的工具，距離編輯台的期待還有相當程度的落差。
「重大即時新聞是內容產製的痛點，我們有沒有可能在這次的烏克蘭專題找到解決方式？」
關於這顆「隕石」，產品經理在想什麼？
軟體圈內有個不論產品經理、設計師或工程師，在工作中都避之唯恐不及的詞彙，叫做「隕石」。簡單來說，「隕石」指的是意料之外的突發需求與狀況，導致團隊的資源可能因此而必須重新調整及分配。
釐清需求、定義目標與範圍、產出能夠回應目標與使用者需求的產品設計、以穩定的節奏排程開發，都是產品健康發展的前提要件，沒有做好這件事情，最終很容易什麼問題也沒有解決，甚至創造更多問題，淪為「為開發而開發」的 feature factory。而隕石之所以被軟體圈的工作者所詬病，就是因為它的出現總是來得又快又突然，除了團隊手中的工作項目被迫中斷之外，也沒有時間讓產品經理與設計師好好設計，就倉促進了開發，通常還伴隨著急迫的上線時間壓力，很容易就將產品開發的節奏擊碎。
但是，所有「隕石」都是萬惡的淵藪嗎？
1. 這顆隕石，該不該接？
並不是所有隕石都是沒有意義的。編輯部即將派出記者們前往波烏邊境，並期待能夠解決即時新聞產製的痛點，這件事對於產品團隊而言固然是一顆隕石，卻是一顆我認為必須正面扛下的隕石。
在重大事件發生時，不只有編輯台在作業上感到困擾，讀者的需求在《報導者》既有的內容呈現方式之下也很難被完全滿足——分散式的閱讀每一篇收錄在網站的即時文章，其實沒有辦法回應「迅速掌握快速發展中的事件」的讀者期待。實際上，從讀者與編輯台兩種角度來拆解，我們會發現看似單一情境的即時新聞，不同使用者的需求也有著很大的差異：
即時新聞的產品需求確實存在，也具有處理的價值。同時，從《報導者》的願景層面來說，俄侵烏戰爭是二戰之後對於國際局勢影響最為深遠的一場戰役，極為值得台灣借鏡，這次基金會投注極高的成本深入歐洲，如何幫助其他部門的同事減少內容上架、編輯的時間成本，更進一步透過產品的力量讓更多讀者接觸到記者親臨現場的珍貴視角，無庸置疑是產品團隊的責任。
所以——接，當然要接。
2. 這顆隕石，要怎麼接？
不過，確定接下這顆隕石之後，接下來才是最大的問題：要怎麼接？產品團隊要做什麼？我們有可能做到嗎？
數位產品設計流程中有一個相當有名的「雙鑽石模型（Double Diamond Model）」這個模型將設計拆解成兩大階段：「問題」與「解決方案」。前面雖然確定了需求，但仍然還處於「問題層次」，尚未進入解決方案的思考。而我在解決方案層次所訂下的命題是：
怎麼在 10天內、在工程團隊的資源運用價值最大化的情況下，找到未來有可能沿用，而且能夠讓讀者眼睛一亮的解決方案？
從問題到解決方案：Live Blog
初步了解編輯台同事們的想法之後，我快速研究了幾間指標性的國外媒體網站如何處理重大即時新聞，並發現《紐約時報》（The New York Times）、《衛報》（The Guardian）、《南德意志報》（Süddeutsche Zeitung）等媒體，不約而同的都是採行 Live Blog 形式。相較之下，很少在台灣媒體看到 Live Blog 的應用。
Live Blog 指的是在單一文章裡面持續碎片化的更新事件，敘事通常具備幾種特色：(1) 具有時間戳記、(2)多人協作，能夠以不同作者的身分發文（對於在多個國家均有設立分部的國際媒體來說，便可以用來記錄不同地點發生的事件），以及 (3) 原生內容和來自社群媒體的外部素材能夠以非常自然的方式結合，達成類似策展的效果。這種敘事屬性讓 Live Blog 特別適合用來呈現選舉、頒獎典禮、社會抗爭、災害等事件。
在面向讀者的 Live Blog 產品功能，最常出現的則是置頂、索引和篩選，不僅凸顯最重要的資訊，也讓讀者在碎片化的資訊當中更容易找到自己想要閱讀的內容。前面提到的《衛報》就是經典案例，讀者可以在側邊欄看到 Live Blog 頁面的近期貼文與發布時間，點擊後就能直接跳到該篇貼文；讀者也可以選擇要在 Live Blog 頁面顯示所有內容，或是僅顯示最重要、關鍵的貼文。
總之，看起來是個已經被市場驗證可行，也非常適合作爲《報導者》在此次烏克蘭專題進行新型態敘事實驗的解決方案。
除了自己開發之外，我們有其他選擇嗎？
然而記者們隔週就要飛往波烏邊境，時間實在太過匆促，即使訂下解決方案，若要進入實際開發，還有太多產品細節需要研究與打磨，考量團隊人力、正在進行中與未來將要進行的產品開發項目，完全不可能在 10 天內生出能夠兼顧讀者與編輯台需求的 Live Blog 版型。因此「自己開發」從一開始就不是我的選項。
歐洲工商管理學院（INSEAD）的教授勞倫斯．卡普倫（Laurence Capron），在其 2012 年出版的《Build, Borrow, or Buy: Solving the Growth Dilemma》探討組織獲取資源與成長的方式，並提出能夠透過多樣化的方式取得所需資源的組織，比堅持內部研發的企業高出 12 % 的論述。這本書的出版時間距今雖然已經 10 年，但對於「資源」的觀點，在「軟體即服務（Software As A Service, SaaS）」當道的現在，我認為仍然很值得作為產品經理的思考框架。
➤ Build
・必須要由我們自己做嗎？（我們需要掌握核心技術嗎？會影響到未來的組織成長嗎？）
・我們自己做得到嗎？（有可能開發嗎？來得及開發嗎？開發/維運資源投入划算嗎？）➤ Borrow
・外面有沒有我們需要的資源？
・這個資源是可被交易的嗎？還是我們可以跟對方交換？➤ Buy
・和這個資源的密接性，是不是高到我們需要把對方買下來，讓所有權變成我們的？
・我們有足夠的經費嗎？
回到這次的烏克蘭專題，「Build」已經被排除在外，以《報導者》100% 仰賴贊助的營運模式，基本上不會有充足的財力讓「Buy」發生，剩餘最可行的，自然就是「Borrow」了。那麼，我們就來試試看「Borrow」吧！
身處於職涯前期的產品經理通常不會將使用外部服務視為可能的問題解決方案，但實際上，自己捲起袖子來開發並不是唯一的選項。對於內部資源稀缺的小團隊來說，如何運用外部服務驗證產品概念、搭建產品，是一門不得不學習的藝術。
產品經理在 10 天內做了什麼？
Day 1：確認市場上存在符合需求的 SaaS 廠商，而且費用我們還負擔得起
「Borrow」的前提，自然是市場上必須存在我們能夠「Borrow」的對象。不過現在的軟體發展不僅快，而且百花齊放，我甚至認為產品經理應該抱持著一種預設：「你所想到的產品概念，市場上都已經有人在做了。」
Google 之後很快發現，Live Blog SaaS 的國外廠商果然還真不少，初步看來費用也落在我們尚能負擔的區間，未來如果擴大使用在各種重大即時新聞，對我們來說也是可行的（只是要更緊鑼密鼓的募款就是了）。
Day 2–4：比較不同廠商的背景、功能和價格方案，試用並搭建 Prototype
由於是《報導者》初次在產品功能採取「Borrow」的做法，即使時間壓力極大，評估仍然必須加倍謹慎，內部／外部的使用者需求、行銷與社群、策略、技術等面向都充滿著各種細節。尤其在 SaaS 商業模式之下，產品服務會被切割為各種功能模組，並組合出不同的定價結構，廠商眾多、價格方案複雜、加上需要考量的面向又極廣，實在是我近期做過最困難的比較表。
Live Blog 不論在內容面、產品面都是新嘗試，為了讓編輯、社群、行銷等不同部門的同事對於 Live Blog 的想像能夠更聚焦、更立體，我也使用了不同廠商的服務，並以《報導者》曾經刊出的烏克蘭即時新聞作為素材，在網站的測試站搭建 Prototype。
Day 5：跨部門會議
若說 3/14（一）的正式上線是《俄烏戰爭日誌》Live Blog 最重要的一天，這一天就絕對是第二重要的日子。這天的跨部門會議，《報導者》所有部門都有代表參與其中，並由幾名在專案開案初期的重要角色分別帶進不同的關鍵資訊：
- 產品經理：Prototype 和 SaaS 廠商的後台操作系統 demo。
- 內容專案經理：國內外媒體針對俄烏戰爭的即時新聞處理方式，以及如果未能找到新的產品解決方案，原有的大事記圖表產生器的在內容層面的可能操作方式。
- 總編輯與外派記者：在波烏邊境及德國的移動路線和時程、預期帶回的敘事觀點及軸線。
在這場會議中，我們正式拍板確定烏克蘭專案將會使用外部廠商提供的服務，並以 Live Blog 的方式出擊，同時也初步決定預計上線的時間。接下來就是各部門高速運轉，籌備上線前各種細節的時候了。
Day 6–9：細節的功能研究與內部教學、和 SaSS 廠商協商合約內容，以及與工程、設計一起進行頁面調整
這幾天有相當多雜事，包括想辦法搞定帳號、教大家使用新工具、努力和廠商進行合約協商。我們最終選擇的 Live Blog SaaS 廠商是一間德國公司，和台灣有 7 小時的時差，因此溝通上真的是分秒必爭，晚上看到手機跳出新信件的通知，就立刻打開電腦開始讀信、回信，深怕影響 Live Blog 的使用與上線。
與此同時，為了讓外部服務能夠更符合《報導者》的品牌風格，並更凸顯 Live Blog 頁面的存在，我們花了一些時間調整 CSS 樣式，並透過 Google Optimize 這個原先被廣泛應用在 A/B test 的工具來增加新的 Live Blog icon 和網站 banner。坦白說，過程比預期還要不順利很多，不時發生新增的設計項目無法正常顯示、Google Optimize 無法正常觸發⋯⋯等問題，無比感謝泰勒、敏涓兩位工程大大的支援（跪）至於如何更好的駕馭 Google Optimize，就等之後研究再分享了。
Day 10：上線
歷經種種，我們終於在 3/14（一）晚上迎來上線！
其實以 Live Blog 而言，上線才是開始 ⋯⋯接下來的兩週，參與烏克蘭專案的同事們每天早上 10:30 都會開一場例會，同步當天的新資訊，並確定要處理的事情與分工。內容層面的處理，就得敲碗內容專案 PM 寫分享文啦！
結語：不只是敘事實驗，也是團隊配置實驗
去年（2021） 5 月底加入《報導者》到現在，這是我第一次以「產品經理」的身分參與新聞專題的製作。
在之前的《數位產品幕後：從 header 改版開始的《報導者》網站開發之路 2.0》中曾經提過，過去製作專題時，是由專案經理統籌內容、工程、設計，專題頁面也都是由自家的工程師自己刻，不只專案經理肩負極大壓力，人力資源的運用也相當浪費。這次的《俄烏戰爭日誌》則是首次出現新的角色配置，分別存在「產品經理」和「內容專案經理」兩種 PM，前者負責網站功能，後者專心處理內容，彼此都更能聚焦在各自掌握度最高的領域，我認為是相當不錯的初次嘗試。
值得一提的是，此次成員除了我之外，還有好幾位去年與今年年初到職的新夥伴也並未參與過專題製作。極為緊迫的時間壓力、為數不少的新成員，搭配新的團隊角色配置，每個人手上都還有其他工作在同步進行，竟然仍在 10 天內推出了新的 Live Blog 敘事實驗，只能說《報導者》的同事們無比強大，能夠與認真、積極又厲害的團隊一起工作，非常幸運 ❤ 但也真的是辛苦大家的肝了。
如果你喜歡這次的《俄烏戰爭日誌》Live Blog 敘事實驗，請幫我們拍拍手 👏
也歡迎在下方留言交流，我們很期待聽到讀者的回饋！
📣有你，才有《報導者》
《報導者》秉持深度、開放、非營利的精神，透過讀者的贊助支持來營運，不仰賴商業廣告置入。如果您認同我們的理念，歡迎與我們一起前進，共同推動這場媒體小革命。
☛贊助我們：https://bit.ly/3ylK401
官方網站：https://bit.ly/3rTeR1V
粉絲專頁：https://bit.ly/37jjGYD
Instagram：https://bit.ly/3rWFQJV
