營運敏捷 Part 3 - 營運地圖

 【營運敏捷 Part 3 - 營運地圖】

回頭想一下，為何大多數在講敏捷時，最一頭熱的是開發、執行人員而不是老闆呢?
如果是這種現象，背後又代表著什麼跟我們的想像與期待有著落差?
老闆腦中的敏捷樣貌又是怎樣的架構和內容?

其實不難理解老闆，從老闆的角度出發，理所當然的就是營收，也就是所謂的價值。如果要做的事沒辦法跟價值連結起來，通常無法打動老闆獲得強力的支持。而價值面向最好是跟商業或產品能產生的價值，做為推廣敏捷的切入點，而非強調技術性價值，這樣會比較好獲得資源。

看看2020前SCRUM框架中，大多數比例也都是在談開發框架和迭代持續改善，老闆角度的價值被隱含在其中，沒特別強調會無感。

剛好，在Scrum Guides 2020的更新中，凸顯了價值方面的訊息和方法，特別強調了"價值"。其中提到，PO要關注Product Goal產生的Value，要能清楚定義誰是User或Customer，更要在Planning meeting時，問Why is this Sprint Valuable?

說了這麼多次的價值，到底要怎樣衡量呢?

價值的外顯表現就是"數據"，這些數據整理成有意義的解讀，就是"指標"。

我們該如何在敏捷中加入數據來做討論與發展成任務呢?

在這之前，先來看看之前的做法。由PO對市場的敏感度和認識，整理成影響地圖，再用全貌展開成使用者故事地圖，然後依照優先序排成待辦清單，轉譯成情境可討論的使用者故事和驗收標準，最後再請開發單位轉成具體的任務單。

很標準的做法，讓團隊都能有機會理解與參與，但大多數情況下，我們不太需要這麼龐大的資訊和討論。尤其是在現有營運產品中、小專案、快閃型活動、營運活動等，影響地圖和使用者故事地圖就顯得用不太到。

有沒有更有效的方式呢?

也許可以考慮下我由營運團隊經驗+黃金圈，發展出來的"營運地圖"來做任務的討論與執行，剛好符合Scrum Guides 2020中強調的價值。結構跟影響地圖一樣，只是變了裡面的定義。回到之前提到，價值的外顯就是數據，所以要用數據思維來做需求確定，這其實就是數據驅動。

我們會利用營運地圖思考框架，做視覺化的團隊討論，由數據驅動與假設做需求的正確性評估，發展出要做的任務。利用這框架的討論過程中，不難發現成員自然換位思考，因為WHO就在上面，隨時提醒在討論中以該角色討論HOW。

WHY、WHO、HOW的搭配有沒有很熟悉的感覺，是的，它同時是使用者故事的描述架構。我們在討論HOW怎麼做時，也都會用這角度融入思考，不需花腦力特別轉譯。

最後的WHAT就是預期的數據指標，當做完前面的任務且產品上線後，你自己心裡面有沒有個期望會有怎樣的效益表現。因為每一個任務的執行都是一個成本的付出，如果沒有預期效益，等於是做白工的概念-浪費。

有趣的事來了，當你開始有預期數據表現時，如果沒達到目標值，就會引發你的好奇心去探究，因為有了數據當依據，相對能在範圍內找出原因，然後進入下個迭代嘗試改善。反之，當你沒有預期的數據指標，大概就是產品上線後等著看反應，然後就"原來結果是這樣...."沒了，下次再猜看看要改哪裡。

※結論

100分的流程、工具，也改變不了0分的意願和思維。

用個思考框架來輔助團隊一起思考、討論需求，有助於整體討論效率的提升，容易聚焦在對的地方不失焦。這算是一個對話的開啟點，但能不能有效、有沒有辦法運用，還是要先檢視一下成員的意願，否則，就算是完美的工具也會得到失敗的結果。工具永遠只是輔助，重點還是人，過程中出現的問題只是現象反應，現象的背後不要忘了去發掘然後持續改善。