【新冠肺炎特輯】從台灣的 COVID-19 防疫小組，看產品與專案管理中的危機處理！
新冠肺炎 COVID-19 大概是全台灣人目前最關心的議題了！台灣政府這次的防疫小組（中央流行疫情指揮中心）有許多值得學習的地方，這篇文章將拆解「危機處理」中的幾個重要元素與核心價值，以及可以如何運用在產品管理與專案管理中。
在不同的團隊裡面，危機處理的 PIC（Person In Charge）或專案負責人，可能是產品經理、產品營運經理、負責處理 Issue 的工程師，也有可能會是客服、行銷、公關等第一線面對用戶的負責人，無論是誰來負責統合，都有一些共同原則與方法可以遵循。
▍第一步：辨認危機
在產品管理中，危機（Crisis）、事故（Issue）指涉的是在原本預期之外發生了可能造成損失的負面事件，舉例來說：
- 產品改動/功能上線前：資源不夠導致無法如期上線、客戶臨時改需求導致無法如期上線 …
- 產品改動/功能上線後：新功能的易用性很低導致重要指標下降、上線新功能 A 卻影響到原有功能 B 壞掉、整個產品服務發生 downtime …
原則上，以上常見危機隨著產品團隊的經驗增加都是可以避免的，但是這次台灣所面對的武漢肺炎則是外部因素而造成的危機，因此在這篇文章中，我會以「產品串接的第三方服務壞掉」而間接導致的產品事故為例。
【產品事故案例】電商平台（例如：PChome、蝦皮等同時有買賣家的雙邊平台產品）所串接的第三方物流公司系統出問題，導致電商平台上的部分訂單無法順利出貨。在辨認危機的階段，該做的事情是：
- 確認事故的第一個回報來源與情境，以利追查事故原因。
- 辨認危機的嚴重性、簡單快速的預估影響範圍與預期損失，以利跟其他進行中的事項做優先級排序。
- 了解過去是否發生過類似事件，若有則能從過去的經驗中學習。
▶ 防疫小組做了什麼1.確認事故的第一個回報來源與情境
中國在十二月時出現武漢肺炎的案例，是會經由飛沫傳染、人傳人的新型冠狀病毒。
2. 辨認危機的嚴重性、簡單快速的預估影響範圍與預期損失
一月底是華人的農曆新年，預估會有大量在中國生活的台灣人回來過年（數據可考），同時也會有台灣人前往其他地區遊玩或過年，武漢病毒在這種情況下攻進台灣的機會非常大，若因為疫情造成延後開工、開學，將會造成一定的損失（經驗與數據可考），因此這次危機的嚴重性很大、優先級很高。
3. 了解過去是否發生過類似事件
有，2003 年 SARS 事件。
▶ 產品團隊如何運用1.確認事故的第一個回報來源與情境
電商平台上的賣家 A 向客服回報，今天中午一批經由OO物流的貨送到OO倉庫後因為物流編號錯誤，導致整批貨物無法進倉，直接被退回至賣家倉庫。賣家 A 表示他們賣場有承諾買家到貨時間，這樣延後出貨會造成買家抱怨，因此非常生氣。
2. 辨認危機的嚴重性、簡單快速的預估影響範圍與預期損失
客服團隊、行銷與社群團隊：
- 釐清賣家 A 的問題之外，也至整體客戶回報後台、用戶社群中檢查是否有其他賣家 BCD 回報類似問題，確認是「單一問題」還是「整體事故」，以利接下來討論解法、確認影響範圍與可能造成的損失。
- 所謂「單一問題」是指單一用戶遇到的問題，包含賣家後台設定錯誤、賣家的小幫手沒有按照正常流程使用出貨功能、賣家已達到第三方串接的訂單編號數量上限……等，這可以藉由客服馬上協助該用戶止血、未來再由產品團隊調整 UX 讓錯誤不容易再次發生；
- 而若是「整體事故」則代表很多用戶都會被影響到，但範圍也可大可小，以這個案例來說可能的狀況由小至大範圍為：[小] 其中一個取貨點/門市資料出問題連動至進倉功能錯誤回報、[中] 整個 OO 物流系統的物流編號都出問題（但其他物流沒問題）、[大] 所有串接的物流（包含 OO 物流與其他）都發生異常狀況……等。
產品團隊：
- 工程師、PM、QA 檢查與測試第三方串接的 API、功能、數據是否異常。
- 除了 OO 物流外，也需要確認產品所串接的其他物流是否有出問題。
商業團隊：
- BD、PM 等負責與 OO 物流公司聯繫的負責人向第三方服務商回報問題，確認問題來源是否來自對方。
商業團隊/產品團隊/數據分析團隊：
- 透過平台上使用 OO 物流的賣家數量、日常訂單與出貨量來評估影響的範圍，與評估隨著問題持續的時間增加所可能造成的最終損失（畢竟有些問題可能當天修不好）。
3. 了解過去是否發生過類似事件
如果有的話，就有過去的作法可以參考了！
▍第二步：危機處理
在第一步，我們已經確認這是個危機，而且優先級很高，必須盡快處理！第二步就是主動出擊，合力找出讓危機不要擴散、或從根源解決的方法，並且建立良好的溝通方式與管道。
【0. 組建跨部門專案小組】
危機處理是目前的第一要務，但是不可能將整個事故由產品部門或客服部門等單一部門來處理；而在其他專案依然在開發、維運的情況下，也不可能整個公司都人都一起專注在這次危機。
最好的方式就是建立一個跨部門的專案小組，由各部門派出單一窗口的負責人，來統整與調度資源、進行對內對外的溝通。一旦確立好該做的事與優先順序，細節就可以交派各部門的專業人才來制定與執行。
▶ 防疫小組做了什麼
從照片中可以看到，除了最中間的衛生福利部部長陳時中與疾病管制署同仁是核心人物外，整個「中央流行疫情指揮中心」還包含了教育部（學校開學與年輕族群防疫宣導）、經濟部（防疫用品生產與物流調度）、公平交易委員會、陸委會的同仁一起在第一線面對大眾。
除了這些人以外，可以想像外交部（與國際組織進行第一線溝通）、國防部（國軍人力資源調度）、內政部（移民署出入國規定）、文化部（公共展場的開放與防疫宣導）、交通部（觀光與交通相關的緊急處置）、勞動部（年後開工、防疫照護假、遠端工作的限制）……等各部會也都必須積極參與，提供自己部會的專業知識與人力資源，來共同面對危機。
▶ 產品團隊如何運用從「第一步：辨認危機」的第二點就可以看到，在第一時間，各部門就已經被分配工作了！
除了最高負責人外，產品團隊（PM、工程師、QA）、面對用戶的團隊（客服、行銷、公關、AM）、面對合作單位的團隊（BD、Operation）也都會需要有人一起參與專案小組。
功能一是讓內部溝通順暢、提升效率，所有部門都要在狀況內（on the same page）；功能二是將資源和資訊做區分，避免重工和影響到其他正在進行的重要專案。
以產品工作常用的工具來舉例：
- 開一個此危機處理專案用的 Slack Channel，所有相關事項一率在此群組討論。
- 客服團隊使用線上客服溝通工具（如：Intercom/Zendesk/Reamaze）時，將與此議題有關的 Convo(s) 統一整理至新的專案分類/tag，並由固定成員來回覆。
- 產品團隊使用專案管理工具（如：Jira/Trello/Asana）時，將與此議題有關的 Ticket(s) 統一整理至新的 Epic/Project 中，並由固定的 PM、工程師、QA 來處理。
專案小組的任務分為兩大塊：1. 討論與執行解決方案、2. 建立溝通管道。
【1. 討論與執行解決方案】
- 討論解決方案、阻止危機擴散的方法
- 排定危機處理專案中各事項的優先級，來做資源的分配與調度
▶ 防疫小組做了什麼解決方案可能是研發出能夠對抗武漢肺炎的疫苗。
阻止危機擴散的方法則有很多種。先列出針對這次危機的重要指標：感染人數、感染率（或說傳播率）死亡人數、死亡率，接著拆解這些我們想要增加、降低的指標數據，同時多方執行。
以下內容參考自《Why I’m concerned about the coronavirus: applying viral growth data metrics to a growing crisis》作者本身是做 Product Growth 的專家，由他來說明「病毒式傳播」的行銷與用戶獲取非常有趣也很有說服力。
Reproduction number (R0) 代表的是繁殖數，舉例來說若 R0 = 2，則代表一個人可以感染兩個人、這兩人可再感染四人，以此類推的指數型成長。其公式如下：
- R0 = transmission risk (傳播風險) x contact rate (接觸率) x duration (持續時間)
因此若要以降低 R0 為目標，就可以朝降低這幾個指標為方向：
- 降低傳播風險的方法：戴口罩、勤洗手。
- 降低接觸率的方法：（個人）不去人多的地方、不去疫區旅遊和出差；（政府）與中國等疫情嚴重地區禁航、延後開學與開工、取消大型活動與展會、獨立的送醫與檢疫通道、將已確診或有風險者進行隔離。
- 降低持續時間的方法：過去 SARS 在天氣轉熱後慢慢消逝，因此預期接近夏天時疫情會接近尾聲。
另一個指標 Case fatality rate (CFR) 代表的是死亡率，亦即有感染者中死亡的人數比例，降低死亡率的方法就是讓已經感染的人當中，康復的人數增加，因此將原本處理流感（或其他疾病）的醫療資源轉來投入優先級更高的武漢肺炎病人十分重要。
▶ 產品團隊如何運用假設我們確認就是 OO 物流的 API 出問題，而我們產品平台上就是有很多用戶在這這家物流，那最直覺的解決方案就是等他們修好，我們這邊才能順利使用。
而阻止危機擴散的方法則有很多，一樣先列出針對這次危機的重要指標：受到影響的賣家數量、未成功進倉的商品數量、因未如期交貨而造成賣家的金錢損失、產品與公司的品牌危機等等，一樣個別拆解。
- 降低受到影響的賣家數量：通知目前正在使用 OO 物流的賣家，暫時關閉該物流選項、並選用其他物流選項。
- 降低未成功進倉的商品數量：針對已發貨的批次，既然由 OO 物流系統自動回傳的編號有誤，確認是否能從產品端手動修改訂單編號/出貨編號來讓這批貨能在短時間內重新進倉。
- 減少因未如期交貨而造成賣家的金錢損失：估算這次造成的損失並跟 OO 物流爭取賠償；假如產品平台有抽成或收取月費，考慮不收當筆訂單、當月份的費用來作為賠償。
優先級是一個非常主觀的東西，牽涉到總體目標。各國政府在面對疫情時排定優先級和做決策上，難免都會遇到目標衝突。舉例來說，負責決定開工時間的經濟部門和負責防疫的衛生部門就有不同的目標，前者希望盡快開工、開學、大型活動如期舉辦，後者則希望人們不要群聚在一起以免爆發社區感染。因此當中國政府與工廠們決定在年後如期開工時，很明顯偏向前者的目標。這個決策從其他國家、地區來看，也許是不合理的，那為何中國政府會如此執行呢？如果中國的總目標、價值體系並不是「阻止疫情擴散」為優先，而是「讓大多數人溫飽」呢？一個工廠的停工可能會影響幾百、幾千個家庭，造成數千人可能因為沒有如期拿到薪水而活不下去、工廠也可能因未如期交貨而陸續倒閉並造成可怕的連鎖效應；若是選擇開工，假設其中 5% 的人感染武漢肺炎死亡，對工廠來說也就只是幾十個家庭的破碎。這個說法雖然不符合普世的價值觀與道德觀，但從總體目標和損失評估的角度去看，單純用人數來判斷影響力的話，卻可能是個合理的優先排序決策。也因此，做了這個決策之後，資源可能會優先放在「開工衛生宣導」、「工廠優先取得醫療資源」等地方。
【延伸閱讀】討論解決方案
《如何發想解決方案？產品團隊的創意思考流程！》
《Why-How-ladder：產品需求探索的思考練習&工具》【延伸閱讀】排定危機處理專案中各事項的優先級
《產品經理日常掙扎：如何制定產品優先級策略(Prioritization)？》
《給產品經理和分析師：如何用指標框架計算產品改動影響力（Impact Sizing）？》
【2. 建立溝通管道】
- 口徑一致且頻繁的對外溝通管道
- 個別事件/重要人物的特殊處理
▶ 防疫小組做了什麼口徑一致且頻繁的對外溝通管道
- 每天直播防疫記者會，主動告知民眾最新狀況、 並讓記者提問。
- 使用「疾管家」Line 管道隨時推播最新消息與政策宣導。
- 建立 1922 防疫專線，讓民眾可以主動通報疫情。
個別事件/重要人物的特殊處理
- 針對滯留在海外的台灣人，建立特別小組和個別溝通管道來安撫和處理。
- 針對醫護人員、計程車司機等大量接觸不確定人士者，提供特殊的醫療資源（例如：得到更多數量的口罩）。
▶ 產品團隊如何運用口徑一致且頻繁的對外溝通管道
- 使用產品內的推播或公告功能來通知用戶目前的狀況。
- 建立一個獨立的狀態頁面（例如：status.io、statuspage.io）讓用戶可以自行上去檢查目前的產品修復狀態。
建議使用外部網站、工具來處理的原因是，如果你的網站整個 downtime 掛掉，那麼原本架在網站上的狀態頁面照理來說也會連不上去。
另一個解決方法是將 Core Product 和 Official Website 分開，如果 Core Product 掛掉了，用戶也還是能從 Official Website 連上狀態頁面。
- 建立統一的聯繫與詢問管道（例如：Intercom/Zendesk/Reamaze/官方信箱），且如同前面所述將相關問題整合在一個分類/tag 內由專人回覆。
- 不建議使用電話的方式處理。一來是能夠同時處理的通話數有限（用線上服務可以複製貼上或是大量批次傳訊息），且分工不易；二來是用電話無法有可查詢的紀錄，危機處理當下很難讓其他部門的人做評估跟分析，事後檢討時也很難紀錄清楚。
個別事件/重要人物的特殊處理
- 分出一個獨立小組優先處理與追蹤 KOL（講話大聲的人）、Key Accounts（不能得罪的重要大客戶）、訂單數量大（賠不起）等特殊客戶的狀況。
若要說在發生危機後，將「口徑一致且頻繁的對外溝通管道」做到淋漓盡致的就屬 2017 年時 GitLab 服務中斷事件了。他們除了即時在 Twitter 上更新最新修復狀況，甚至還在 YouTube 上面直播工程師修復系統時的畫面，當年吸引了大批工程師上線共襄盛舉。延伸閱讀《GitLab服務災難與危機處理的啟示：開誠布公，才能贏回信任》
加分題：不能只著眼於處理危機本身。
對外溝通最重要的原則就是透過溝通速度、管道來拿出誠意，並讓面對危機的使用者對「官方組織」建立信心。
因此有時候，某些解決方案的執行並不是真的為了解決核心問題，而是為了解決信心與信任問題。
同時，某些資源的投入，並不能以「投資」的角度來看，而必須用「避險」的角度來看。
▶ 防疫小組做了什麼舉例來說，口罩是一個防疫時期重要的物資，台灣也面臨了口罩短少與搶購的危機（大危機下的子危機），因此增加資源來投入口罩生產是必要的。
但是究竟有沒有重要到政府必須徵用台灣所有口罩業者生產的口罩來統一販賣，並且透過第二預備金出資二億台幣來建立六十條口罩產線，就是個值得思考的問題。有些人認為未來會生產過剩、甚至賠錢；有人認為為了讓每個人都拿到口罩，這是必要的投資。
其實這個大刀闊斧的做法除了「在疫情爆發時生產足夠的口罩」這個實用性價值之外，利用這一步來展現政府面對疫情的決心，對於建立國人對政府抗疫的信心會有幫助。
除此之外，這個資源的投入並不是「投資」而是「避免未來風險」 — — 避免疫情擴大之後，若延後開工所造成的經濟損失、他國禁航發造成的觀光損失、染病人數增加而造成的醫療負擔……等，這筆投下去的錢、時間、人力本身就沒有要實質回收的意思。
▶ 產品團隊如何運用以上述的其中一個處理方式為例，針對已發貨的批次，從產品端手動修改訂單編號/出貨編號來讓這批貨能在短時間內重新進倉。
這部分的手動修改除了平台端的處理，可能還需要重新列印印有新編號的出貨單並貼到相對應的包裹上。針對重要賣家、第一個回報的賣家、訂單量特別多的賣家，也許可以由團隊來主動幫他們處理，例如緊急聘請工讀生來貼新的出貨單。
這一部分也是要建立用戶的信心，拿出滿滿的誠意，希望他們可以了解我們是盡了全力在處理；同時這筆花下去的工讀生時薪，希望能夠多少避免掉這些賣家決定轉換到其他產品平台、四處進行負面評價……等未知風險。
不過說老實話，賠不賠錢、需不需要多做工、第三方出問題的責任歸咎，很多東西合約上都寫得很清楚，就看公司和團隊怎麼看待和處理這次危機。
▍第三步：事後檢討＆風險管理
事後的公關、道歉、賠償不在此篇討論範圍，這邊就來說說產品團隊、營運團隊可以做的事情。
美國專案管理協會（PMI）定義專案風險為「一個不確定的事件或條件，會對專案目標有正面或負面的影響」。風險是可以管理的，讓危機與事故的發生機率降低。每經歷一次危機、踩掉一個雷，不確定的事情又少了一件。
1. 針對這次個別事件做檢討與補強
討論如何避免未來再發生類似的事故，以及若真的又發生了該如何處理。
針對上述的電商物流案例，如果整個平台只有串接 OO 物流，發生問題時就完全只能依賴他們修好，風險非常大；在這種情況下再多串接幾間不同的物流公司會是一個能夠分散未來風險的做法。
2. 訂定整體的危機標準層級與處理方式
訂定「辨認危機」的標準，包含哪些功能是絕對不能壞、哪些場景是絕對要能夠順利執行的，並針對不同層級（高、中、低）的危機建立標準工作流程（SOP）。
舉例來說，買家不能結帳（害賣家賺不到錢）、物流出貨有問題（害賣家無法如期出貨）、後台報表無法下載（害賣家無法分析營收）的嚴重程度就不一樣。
3. 全面性的產品健康檢查
趁這個機會對產品做健康檢查，在這種時候來討論部分重構（refactor）、機器的調整等等會是最有感也最有動力進行的時刻。
非得要在緊急事件發生時，才會發現產品架構的基礎不好、公司現金流體質脆弱、遇到一點小問題就免疫系統不佳兵敗如山倒，還技術債的時候到了。
做產品是在失敗中學習，但是防疫不容失敗！
所謂的事後檢討與風險管理，並不只是一次危機的收尾，而是為了面對下次危機而做準備 — — 事前預防勝過事後治療。
做產品是在失敗中學習，透過每次的危機與事故，將產品體質調整的更優良，並建立產品團隊的共同知識庫。防疫也是在失敗中學習，台灣有了 SARS 的經驗，這次才能站穩腳步一波一波的抵擋攻擊，而這些都是從上一次慘痛經驗中學習到的。希望這個危機可以早日落幕，天佑台灣！
感謝閱讀，如果希望看到其他相關的主題也歡迎留言 📔如果單純想給我一點鼓勵，請給我 1–19 個拍手；
如果覺得文章對你有點幫助，請給我 20–49 個拍手！
如果想看更多此類型文章，請長按拍手按鈕（max50）讓我們知道 👏每週末我們都會在 產品三眼怪實驗室 (◉◉◉) 定期更新產品經理相關文章，
別忘了追蹤才不會錯過！
