營運敏捷 Part 2 - 型式

 【營運敏捷 Part 2 - 型式】

以營運為主的敏捷，會更著重在整個團隊要找出對的事情來做，每個人都相當清楚這個需求、活動怎麼來的，做了會產生怎樣的價值假設。

要這麼強調是因為大多數的組織分工都相當專業，也因為這個專業認知的框架，會不自覺的把非自己領域外的成員框在外面，貼上講太多也不懂的標籤，畫地自限了團隊的創意可能性。然後又不自覺的各自成了各自的穀倉，總是在應付資訊的同步和溝通，而不是討論產品該有的價值表現。

慢慢地變成了各自的事.....但有趣的是，到了最後面的產品上線後表現，竟然變成三不管地帶，沒有任何人的事，都是別人的事....

以上的困擾，營運敏捷把這些都拉成同一個團隊的事，自己親手催生出來的活動需求自己做。開始有了化學變化，當營運有了開發的全力支援，能更夠迅速、精確得到上線後數據，即時做調整，成了一個正向循環。開發也因為共同參與了探索階段，所以都能夠正確的埋點，讓數據呈現更全面。

說穿了，其實就是每個人也都擔負一點點PO的職責，開發不僅僅只接收US聽故事，更是一起創造故事的角色。

運作的流程大致如下：

前面探索階段，是數據驅動
中間設計階段，是設計思考
後面執行階段，是DevOps
最後持續改善階段，是數據+系統思考

看起來很威??

其實都是在每個階段有這些觀念、概念就好，至於需要多深入，端看產品和團隊的實際狀態。畢竟每深入一點，花的時間成本就會多一些，剛剛好就好，取適合要用的元素慢慢加入。最好的判斷加入點就是，當某個現象反應後，再去加入可以解決的元素就好。

舉例來說，我們第一次衝刺其實是著重在設計階段，加入些設計思考的元素。當團隊都很滿意自己發想的活動沒有如自己想像的熱烈，或者不知道為何好或不好，不知道有沒有打中要的TA。這時候，就會開始把數據驅動加入，也就是要驗證、衡量活動的價值。

※結論
我們的教育讓我們對於解決問題很厲害，但很少教我們怎麼定義問題。可能會變成我們總是不斷的在花時間證明它的對錯，而不是花時間思考它的價值。有很多做事的經驗，而不是很多創意的想法。如果團隊有一定成熟度的話，不要框住他們的潛力，只要告訴他們魚有多好吃，團隊自己會想出方式補魚的，連釣竿都不用給。只要有安全信任、允許失敗的環境，他們會自己長出價值的翅膀。

下一篇：營運敏捷 Part 3 - 營運地圖