CSPO課程心得

為什麼上CSPO
去年上了SCM課程，上完課發現「挺好的」(呂毅語氣)
學到滿多東西的，特別是Scrum每個meeting的Goal及Why
例如，講師詢問Daily meeting的Goal
自以為的回答「觀察每日進度及即時調整！」，又被追問那Why？為什麼要做這件事
才發現回答的都是What，回答不出來為什麼
Daily meeting的Goal是觀察及調整沒錯，但要知道目標才知道如何調整
目標到底是什麼 - 滿足這個sprint backlog item呀

被糾正觀念後，就覺得這課程真的滿不錯的
因此決定再來上PO的課程

學到什麼呢？以下做個筆記
Origin of scrum
The new new product development game
只給日期，時間到了要有Shippable product
其他讓Team自己決定(Cross-functional/Self-originated)
雖然之前SCM就有聽過了，但再聽一次，總是refresh一下Scrum最核心的精神

Empirical process (野雁)
開發Product如同野雁南飛一樣
做一段，檢查一下(Inspect & Adapt)
離目標多遠，需要調整以更接近目標
Scrum很多Practice就是要這事兒發生, ex. daily scrum, burn down chart, ...

Sprint中，PO需要參與嗎

• Product Backlog Item(What)
• PO的職責
• Sprint Backlog Item(How + What)
• Dev的職責

也就是Sprint中，Dev有需要再問PO，PO不用插手Dev

PO關心What，不是How

Demo meeting改叫Review meeting

回到剛的Daily meeting的Goal是要完成sprint backlog item
而Demo meeting的Goal呢？
除了demo外... 應該要Inspect與Goal的差異
因此應該叫Review meeting比較合適

Scrum framework 欠缺Why
Why是離Goal的差距，因此Review meeting是PO Inspect & Adapt的時機

再看各個meeting的重點 - 以終為始
說很簡單，但實做才發現自己都漫無目標的在做
雖然有inspect，但都沒在與goal比較，只是求局部最佳

Goal不是只有指如期完成，而是如期交付最適合市場的Product，也就是說最後交付的Product有可能已經不是當初定的Goal了

換位思考
這次上CSPO最大的感受... 就是每個問題的答案都跟我的想法有出入
甚至有時聽不太懂講師在說什麼，上SCM還沒差這麼大
後來才意識到我還在用developer的角度思考
我只想著要把MVP做出來，而PO想著是有Business value的feature
而且... 做出來要能feedback到之後的sprint

為什麼！？調整產品的走向呀~~
我還是只能想到自省會議的改善項目(Deliver的部份)
PO要想著Discover的部份

PM的價值在於Project成功，PO的價值在於Product成功
課程中有討論Product Owner與Project Manager的不同
點出兩者職責的不同，因此重視的東西便不同

「PM的價值在於Project成功」
這句話真是有fu
感受到過去被PM壓榨的fu
感覺上PM只在乎有沒有如期交付，但不會深入討論有價值的feature
只會逼著developer交付，把develop team當可以置換的人力
成功都是他的，失敗都是別人

但什麼才是對的，Project成功了，但Product失敗了,這能叫成功嗎？

PO應重視Business Value

課程中有玩Business Value Game,這跟之前玩的Kanban Game滿像的
遊戲裡有些可以改善開發效率的feature,很直覺的就應該先擺在前面先做

但遊戲結束後，才發現分數並不高
因為遊戲故意設計重點在Business Value(有做完才算!!!)
所以要評估如何讓Business value最大化
這裡的陷阱在回合有限，做完改善後，遊戲(專案)已經結束了
改善的項目是沒有business value的!!!

因此PO常不理develop team的改善需求
雖然現實也是這樣，但對PO還是有很多抱怨

事後討論，這類型的改善，應該在每個sprint一點一滴的做掉是最好的

這遊戲真厲害，一次讓兩個角色搞明白(呂毅語氣)

Product Version
影片 - IDEO Shopping Cart
影片提到如何在幾天內重新設計Shopping Cart(重點當然是在如何進行重新設計)

• 收集客戶問題，想辦法解決
• 不要自己想，太花時間了
• 看客戶怎麼用，自己也下去玩

Excise: Spec Writing Game
分成兩組人，一組寫文件，一組實作

• 題目
• 左邊是題目，右邊是我們的成果 XD
• 規則
• Timebox : 10分鐘
• 兩組人只能透過文字(件)溝通
• 不可畫圖(當然!!!)
• 可以修改文件
• Writer可以觀察實作者的情況，再修改文件
• 實作者不可提問

結果
太晚給Spec，有疑惑來不及修改文件
忘了把文件拍下來... 不然大家可以來畫畫看...
記得文件寫左上角的六角型直徑1.5公分
但Writer看我們畫完，才發現.... 他們是要寫半徑1.5公司... 所以大小差很多

上方的星星跟下方的甜甜圈則是連文件都來不及寫...

心得

• Writer會想把文件一次寫清楚，但花太多時間且有認知落差，發現實作誤解再調整文件
• 越早開始，越早修正認知落差
• 能當面溝通或畫圖描述都是很直接的幫助 => 用文字(件)不一定是最好的方法

又是一個一次讓兩個角色搞明白的遊戲(太強了)

Story是Delta，不是Baseline
透過Acceptance Test留下活文件