黑先生

  【營運敏捷 Part 2 - 型式】 以營運為主的敏捷，會更著重在整個團隊要 找出對的事情 來做，每個人都相當清楚這個需求、活動怎麼來的，做了會產生怎樣的價值假設。 要這麼強調是因為大多數的組織分工都相當專業，也因為這個專業認知的框架，會不自覺的把非自己領域外的成員框在外面，貼上講太多也不懂的標籤，畫地自限了團隊的創意可能性。然後又不自覺的各自成了各自的穀倉，總是在應付資訊的同步和溝通，而不是討論產品該有的價值表現。 慢慢地變成了各自的事.....但有趣的是，到了最後面的產品上線後表現，竟然變成三不管地帶，沒有任何人的事，都是別人的事.... 以上的困擾，營運敏捷把這些都拉成同一個團隊的事，自己親手催生出來的活動需求自己做。開始有了化學變化，當營運有了開發的全力支援，能更夠迅速、精確得到上線後數據，即時做調整，成了一個正向循環。開發也因為共同參與了探索階段，所以都能夠正確的埋點，讓數據呈現更全面。 說穿了，其實就是每個人也都擔負一點點PO的職責，開發不僅僅只接收US聽故事，更是一起創造故事的角色。 運作的流程大致如下： 前面探索階段，是 數據驅動 中間設計階段，是 設計思考 後面執行階段，是 DevOps 最後持續改善階段，是 數據+系統思考 看起來很威?? 其實都是在每個階段有這些觀念、概念就好，至於需要多深入，端看產品和團隊的實際狀態。畢竟每深入一點，花的時間成本就會多一些，剛剛好就好，取適合要用的元素慢慢加入。最好的判斷加入點就是，當某個 現象 反應後，再去加入可以解決的元素就好。 舉例來說，我們第一次衝刺其實是著重在 設計階段 ，加入些設計思考的元素。當團隊都很滿意自己發想的活動沒有如自己想像的熱烈，或者不知道為何好或不好，不知道有沒有打中要的TA。這時候，就會開始把 數據驅動 加入，也就是要驗證、衡量活動的價值。 ※結論 我們的教育讓我們對於 解決問題 很厲害，但很少教我們怎麼 定義問題。 可能會變成我們總是不斷的在花時間證明它的對錯，而不是花時間思考它的價值。有很多做事的經驗，而不是很多創意的想法。如果團隊有一定成熟度的話，不要框住他們的潛力，只要告訴他們魚有多好吃，團隊自己會想出方式補魚的，連釣竿都不用給。只要有安全信任、允許失敗的環境，他們會自己長出價值的翅膀。 下一篇： 營運敏捷 Part 3 - 營運地圖

【營運敏捷 Part 1 - 準備】 ●建立安全信任、大膽嘗試、允許失敗的環境 ●以數據迭代持續改善 是進入營運敏捷前的基石。 開始前，我們得先承認、認清一件事實，我們面對的是VUCA市場，絕對不會有完美100分的策略、需求。再說"分數"也是在過程後才打得出來，不會一開始就能判斷分數，需要上線驗證，由玩家、消費者來評斷。 既然不能期待有完美需求，至少也要程度以上，風險相對小。如 上一篇 描述，會希望由團隊一起釐清、探索出高品質的需求，共同面對VUCA的市場，而不再只是一位PO決策。期望利用團隊多元觀點的特性，一起探索、設計，定義出團隊都認同的需求。 PO其實可以是一位角色或者是一個代表團隊，代表團隊意思是，PO跟另外一群人一起討論、決策。當然，如果一位PO很厲害的話，會大大降低討論的時間成本，不過相對的，PO會間接承擔較多的產品成敗責任。這感覺很奇怪，既然都已經是自我組織的敏捷團隊，那由團隊整體來承擔會合情合理些。 通常，PO給的需求越精確越仔細，團隊其他成員就越覺得產品不關我的事。 在營運敏捷，我們同樣也會有一位PO，但主要是定市場方向不是需求，團隊會一起不斷探索、討論、驗證、修正這條方向。團隊一起承擔需求品質，如同要求產品品質般。有些不同的是，需求的品質較難以在事前精確的衡量判定，有時需要帶點創意，才有機會創造出新價值。 所以， 團隊安全信任的環境是首要、必要的。 沒有人會因為做出錯誤的決策而受到懲罰，只要能不斷精進改善。 沒有人會因為承認錯誤、提出問題或提出新想法而讓大家感到尷尬或受到懲罰。 你在裡面會很自在的發揮自己的所有能力、甚至超過。 先安全信任，才能合作創新。以它為基礎，就會有意願大膽嘗試。而嘗試後允許失敗，團隊才能從經驗中激發創新。 當環境具備後，方法就能發揮該有的效果。從滑板車演進滑步車，"迭代"演進是大家熟悉的觀念。 那具體的方法、內容，到底是以什麼為演進的依據呢? 不斷的修正需求?怎修?市場回饋?不好怎修?下一個方向? 不可能一直試錯迭代，畢竟資源是有限的。背後使用的方法，除了大家較熟悉的Review meeting，這個會議算是執行後的結果。另一個是事前規劃，以" 數據驅動 "為基礎發展出的需求。事前、事後搭配使用，才能有效試錯，讓資源運用最大化。 如果說，產品開發階段是用"

【營運敏捷 Part 0 - 前言】 為何我們既然面對的是VUCA市場，卻相信只要一位PO的專業就能看清市場變化Do the right things? 為何我們沒有懷疑PBI的優先序與價值?PO決定好需求，就期待團隊能Do the things right? 為何我們會認為PO描述、解釋US完後，就期待團隊能理解與認同需求的價值?然後開始有想法?對產品有了連結? 為何我們大多是在關心產品的品質而非需求的品質? (如果團隊成員對於需求的理解還是僅止於這是PO的需求，這現象是不會消失的。) 敏捷團隊角色中雖然有一位PO專責在跟利害關係人和市場變化、需求，但也因為這明確職責界線，讓其他成員有時太過相信或依賴PO的決策。 好一點的Planning meeting，可能會在多講一些需求US的WHY；更好一點的會再帶入數據背景；通常大多是看到產品現象後，PO依據經驗判斷，需求這樣做有機會改善。 如果PO的能力與經驗夠專業，產品發展大多不會有太大的問題，就是快速迭代驗證、持續改善。但這樣的PO可遇不可求，有這樣的PO在團隊內，公司上面層級大多也都是信任授權，讓團隊照自己的方式去發展產品。 (敏捷團隊成立後，不同階段有不同的課題) 更多的團隊PO可能是企劃為主的專案管理，對產品也是有一定的理解，但對市場的掌握可能就沒那麼熟悉。這時，如果能加入營運的元素在敏捷中，像是一些營運常用的指標DAU、MAU、ARPPU、次流、回流、持續、新增...等，當作需求的原因或驗證，團隊也會有追求達標的依據。 如果套用US的格式來看的話，我是___我想要___因為___，其中的"因為__"可以用數據來表達。 更重要的是，團隊能更理解為什麼要做這些需求，更理解與認同產品，自然而然的在開發執行上就會更積極主動。 既然敏捷團隊的最終是自我組織，除了對於產品的品質負責之外，更需要要對需求的品質負責。 最理想的狀態是，需求發掘、定義是由團隊成員一起投入、參與，而非只有一位PO。PO放入的重心、比重會多，但其他人絕對不能是消化需求而已，進一步要理解WHY，更要利用團隊多元特性，一起挖掘、探索需求的盲點。 (團隊越成熟越有機會一起面對需求、市場，進化成商業思維) 好的需求品質才會有好的產品品質、價值。 要如何有好的需求品質呢? 設計思考、數據驅動加入在Planning meeting或需求源頭