常常有人說 Scrum 中的 Product owner, 除了管理需求外, 似乎沒有做什麼事情. 或者說他和傳統專案經理做的事情差不多.
真的是這樣嗎? 或許做的事情有些接近, 但是在所使用的工具是有所不同的, 以下是我整理出的一些差異:
1. 產品願景
這裏要強調的一點, Product owner 不該只是排定需求的優先順序, 他還需要給團隊做這系統的動機, 以及做事情的方向.
也就是說, 他要告訴團隊成員為什麼需要做這個產品(why), 我們要解的是什麼問題 (what), 為了誰要做這個系統 (for who). 唯有這三件事情溝通清楚, 團隊才會有強大的凝聚力.
2. 將想法轉成故事
傳統 waterfall 有不少需求分析的方法, 有些招式或許在 agile 中可以繼續使用. 但是在 agile 開發流程中, 他的主要精神, 是強調透過集體合作討論, 來完成大多的事情, 並不喜歡只是單兵作戰, 做完某項工作後, 才交給下一個繼續處理.
因此你可以使用 impact mapping, 和團隊成員討論動機和需求的關聯, 讓大家知道為何而戰. 接者, 利用 user story mapping 組織需求, 讓大家可以集體討論出系統的需求全貌, 並且知道我們會如何分階段把系統給做出來. 然後, 使用 spec by example , 把需求的範圍給界定下來. 這些都是在協同合作下完成的.
3. 處理需求(demand) 和處理能力匹配的問題
團隊有多少能力, 就只能處理多少事情. 當外面進來的事情超過團隊的能力時, 往往是挑戰 product owner 的應變能力.
傳統做法中, 有可能是強要團隊在某個時間內吃下來, 造成團隊無止境的加班, 士氣低落. 另一種方法, 則是藉由培養團隊能力下手, 讓團隊能力提升, 便能處理更多事情. 不過這需要較多的時間, 並且也考驗老闆的耐心.
Agile 採取的是另一種方式, 就是限制同時處理工作量數目, 讓隊員們先集中火力處理某件事情, 完了之後再處理下一件. 也就是 WIP的做法. 當然啦, 有些團隊做不到 WIP 的境界, 他們可以採用yesterday weather 的想法, 上次能完成多少故事點數, 這次也大約能完成多, 讓團隊有空間處理及慢慢進步.
當然, 還有件更重要的事情, 就是決定哪些事情不要做. 就是要有減法. 大多數的狀況下, 大家只會一直加東西進行, 但是忘記有些東西是不值得加進來做的.
4. 排出故事的優先順序
這是一般認為 Product Owner 要做的事情. 他需要根據依商業價值來列出優先順序, 這裏他需要和使用者討論才會有結論. 另外他也需要和團隊成員商量, 從技術的複雜度上來看, 那些故事的優先順序需要做調整
5. 消除風險
做產品並不是乖乖把東西做出來就可以賺錢了, 一路上會有很多不確定性, 有很多風險要一一排除, 這樣才能有機會做出市場要的東西.
因此在開始做產品時, Product Owner 要不斷的釐清以下事情:
(1) 做對的故事: 這些東西是客戶要的嗎?
(2) 找到對的人: 這些人可以做出產品嗎?
(3) 技術上可行嗎?
(4) 時間合理嗎? 可以賺合理的錢嗎?
因此, Product Owner 是在確認大家是否在做對的事情, 唯有方向正確了, 才能確保產品有成功的機會.
全站熱搜
留言列表
