前言
我是丹叔 Danny，當前是跨國團隊的 PM，這一個月來我花費了很多時間把入門及精通 Scrum 文章寫了 40 餘篇，可以看這裡入門學習 Scrum 及 進階精通 Scrum ，接著我會開始寫一些例項分享，同時入門及進階系列文章也會持續更新，希望能夠寫得更加全面以及完整，讓所有的 PM 或是 scrum 使用者都可以輕鬆閱讀以及解惑，也歡迎來信跟我交流。 在這篇文章中我想要和大家分享一個例項 Scrum，談談外部合作廠商的風險評估例項，透過這個例項我們可以看到 Scrum 在應對不確保性和風險時的優勢，同時我也在反省檢討有些思慮不周的部分
背景
我們的團隊是一家餐飲解決方案的業者，同時我們也開發了支付系統，接入了幾家三方支付廠商，可以自由切換不同的 payment 和 gateway。去年 10 月我們收到了 PO 通知要多界接其他三方支付業者，需要在 12 月底前完成對 Apple Pay 及其他 payment 的支援。於是我們開始在後續 sprint 中進行規劃，並針對支付系統開啟相關的討論會議進行規劃以及排程，以此確保能夠在時間內完成對 Apple Pay 的支援。
相關的會議可以參考：
進階 Scrum Part 3：如何透過 Planning Meeting 有效地規劃和安排任務
進階 Scrum Part 4：如何透過 Daily Stand-up meeting 改善溝通和團隊協作
進階 Scrum Part 5：如何透過 Daily Stand-up meeting 提高團隊決策效率
進階 Scrum Part 6：如何透過 Review Meeting 評估 Sprint 的成果和效能
進階 Scrum Part 7：如何透過 Retrospective Meeting 持續改善團隊流程
進階 Scrum Part 16：教你透過 Backlog grooming Meeting 規劃產品策略、產品規劃和產品
風險評估
在開始開發前，我們進行了外部合作廠商的風險評估，針對合作廠商的可靠性、技術實力、交付能力進行了評估，評估的過程我們先入為主的做了信任，認為大公司開放的界接 API 不會有太大的問題，按照先前的經驗界接也沒有太大的問題，跟這家公司也不是第一次界接 API 支付，因此我就先入為主的認為多支援一個 Apple Pay 也不會是太大的問題，只是多接一個 gateway 的選項，過去在臺灣界接綠界和藍新之類的三方，經驗上也都是幾天內就完事，因此就沒做過多的分析，這便是我犯下的第一個錯誤，太過自信且先入為主。
進階 Scrum Part 21：在 scrum 中管理進行風險評估及風險處理 - PM LIFE DAY 產品經理的日常
進階 Scrum Part 24：如何正確的評估外部合作廠商工作時程及風險 - PM LIFE DAY 產品經理的日常
問題浮現
當我們都規劃完成後，宣布並且讓工程師開始開發後，我們很快就遇到了問題。當我們接入 Apple Pay 的支付 API 時，出現了錯誤以及缺少一些 API 回應，我們詢問了支付業者，但是支付業者表示他們尚未遇到過這種情況，需要進行調查和修改，在這過程中我們也只能等待對方修改，並且等待的時間其實也延誤了原本的版本 release 時程，同時我們也在 PM Meeting 的時候檢討為什麼會需要等待支付業者修改? 這不是應該很成熟的東西了嗎，我們也不是第一家吧 ? 別人沒遇到問題嗎?
我們也不是第一家吧?
我脫口而出這句話之後，大家也想，應該.... 不是?
我就說去問問 PO 吧
過了一陣子 PO 來了 Meeting，結果 PO 說：恩，沒錯，我們是第一家接他的 Apple Pay 😎
謎底揭曉，這個問題我們就是沒有評估到，我們是第一家，也就是很多問題他們根本也沒遇過，所以才會造成這個原因，但誰又能想到 Apple Pay 推出這麼多年後我們會是這家支付業者的第一個使用 Apple Pay 客戶呢 😂
接著已經超過 deadline，但這已經不是單純我方的問題，我們只能夠先將版本從 branch 中抽離往後延繼續等待，將其他後面安排的規劃拉回來恢復正軌，接著就是農曆新年一路就來到 2 月，還沒有訊息，一直到 2 月中才出了一版修正版給我們。
一直來來回回修改也到了 3 月中，我們後面也有幾個版本再安排，隨意插入其實也會造成我們其他不可抗的風險，他們出了修正版後就有點希望我們馬上處理好，但我們也有既定好的排程呀，當我們遇到這個問題時，我們立即召開了一個緊急會議，並決定了以下應對方法：
加固溝通：我們增加了與三方支付業者的溝通頻率，並確保了問題的嚴重性和影響範圍。這有助於確保我們在解決問題時能夠保持一致的目標。
確保可靠的測試流程：因為關係到錢，我們還是特別加固各種情境的測試專案並確保支付系統支援 Apple Pay 的過程中，所有的測試都被充分執行以確保軟體質量及穩定性，因此我們也調整了 sprint ，請所有團隊成員如果 QA Team 在 Apple Pay 測試途中出現任何問題請放下手邊任何工作優先支援修復。
- 復盤檢討：雖然問題解決但我們仍然重複復盤並且檢討一些問題點，以應對未來可能發生的類似問題。這包括在與新的合作夥伴進行合作時，進行更全面的風險評估，並確保如何處理可能的問題。
最後我們在 4 月中左右已經順利上線，當前也使用中沒有太大的問題，這是可喜可賀的一部分呀😎
結語
在這個案例中我們看到 Scrum 框架如何幫助我們應對風險和不確保性，Scrum 框架強調團隊合作和透明度，這讓我們能夠快速回應問題，並進行協調和解決。這種方法的成功在於我們能夠及時發現問題並採取措施，而這也使我們的產品和服務更加可靠和有保障，同時我們也要思考更多可能的情境造成的風險與問題，隨時保持 scrum 的彈性可以應對。
當然經過這件事情後我也深刻檢討，不能因為先前成功的經驗就忽略了之後的案例，每個案例都可能是獨立事件並且有不同的風險存在，必須考慮進去並且保留 sprint 的彈性可以應對。
