營運敏捷 Part 1 - 準備

【營運敏捷 Part 1 - 準備】

●建立安全信任、大膽嘗試、允許失敗的環境

●以數據迭代持續改善

是進入營運敏捷前的基石。

開始前，我們得先承認、認清一件事實，我們面對的是VUCA市場，絕對不會有完美100分的策略、需求。再說"分數"也是在過程後才打得出來，不會一開始就能判斷分數，需要上線驗證，由玩家、消費者來評斷。

既然不能期待有完美需求，至少也要程度以上，風險相對小。如上一篇描述，會希望由團隊一起釐清、探索出高品質的需求，共同面對VUCA的市場，而不再只是一位PO決策。期望利用團隊多元觀點的特性，一起探索、設計，定義出團隊都認同的需求。

PO其實可以是一位角色或者是一個代表團隊，代表團隊意思是，PO跟另外一群人一起討論、決策。當然，如果一位PO很厲害的話，會大大降低討論的時間成本，不過相對的，PO會間接承擔較多的產品成敗責任。這感覺很奇怪，既然都已經是自我組織的敏捷團隊，那由團隊整體來承擔會合情合理些。通常，PO給的需求越精確越仔細，團隊其他成員就越覺得產品不關我的事。

在營運敏捷，我們同樣也會有一位PO，但主要是定市場方向不是需求，團隊會一起不斷探索、討論、驗證、修正這條方向。團隊一起承擔需求品質，如同要求產品品質般。有些不同的是，需求的品質較難以在事前精確的衡量判定，有時需要帶點創意，才有機會創造出新價值。

所以，團隊安全信任的環境是首要、必要的。

沒有人會因為做出錯誤的決策而受到懲罰，只要能不斷精進改善。

沒有人會因為承認錯誤、提出問題或提出新想法而讓大家感到尷尬或受到懲罰。

你在裡面會很自在的發揮自己的所有能力、甚至超過。

先安全信任，才能合作創新。以它為基礎，就會有意願大膽嘗試。而嘗試後允許失敗，團隊才能從經驗中激發創新。

當環境具備後，方法就能發揮該有的效果。從滑板車演進滑步車，"迭代"演進是大家熟悉的觀念。那具體的方法、內容，到底是以什麼為演進的依據呢?不斷的修正需求?怎修?市場回饋?不好怎修?下一個方向?

不可能一直試錯迭代，畢竟資源是有限的。背後使用的方法，除了大家較熟悉的Review meeting，這個會議算是執行後的結果。另一個是事前規劃，以"數據驅動"為基礎發展出的需求。事前、事後搭配使用，才能有效試錯，讓資源運用最大化。

如果說，產品開發階段是用"測試驅動TDD"來顧產品品質的話，同樣的，"數據驅動DDDM"也是來讓需求有品質的保證。因為會先蒐集現有的數據資料為分析基礎，團隊再來思考發想、討論要有哪些需求，哪些需求的優先序需要調整。

實際上怎麼做呢?

從數據中獲取"假設"，所有的需求都應該至少有一個假設來支撐，就跟寫USER STORY一樣，格式的最後也需要寫出WHY，呈現這需求的價值。我們會先從數據中發現產品的痛點/機會，做出假設後，再來發想可對應解決的需求方案，最後再進入執行。

當有了這個數據假設後，產品上線後的回饋就會有落差、依據，當做下一次的迭代改善方向。

※結論

因為是"假設"，所以要大膽發想、嘗試；

因為是"假設"，所以有可能猜錯、失敗。

以上概念都不難，難的是對於數據的敏感度和解讀。數據呈現可能會有很多面向，利用團隊多元觀點，有機會彌補一個人沒看到的盲點。更重要的是，當團隊有機會一起往前探索、創造需求，從數據中更具體看見自己開發的產品狀態，會更加認同、理解自己做的產品與任務，也會不斷的讓自己成長，即使目前可能對於數據概念是弱的，這狀態通常也不會太久。

下一篇：營運敏捷 Part 2 - 型式