營運敏捷 Part 0

【營運敏捷 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或需求源頭，會讓需求更有價值依據與判斷。

設計思考，讓團隊一起探索、設計需求；

數據驅動，佐證需求為何要做的原因。

通常我們會花多點時間在需求探索討論，更著重找出對的事情做Do the rights things，然後盡快迭代驗證。以Scrum框架來看的話，就是在Planning meeting中再細分階段，一起思考、設計，再利用數據來驅動需求產出，進入衝刺。

如果這麼做的話，首先遇到的第一個難關是，團隊從習慣接收需求轉變成群體討論需求，以及時間的運用。接下來就分幾篇介紹囉~

黑先生