Jan. 29 10:22~11:48
▲排除阻礙可以改善開發進度
價值驅動
在Scrum框架中,Product Owner的主要責任是負責產品的投資報酬率(ROI),換句話說要釐清對使用者有價值並且能為公司帶來收入的需求,並依據需求的價值安排施工順序。
但是,「使用者價值」是很抽象的概念。幸運的話,等產品上市之後,從銷售量與使用者回饋得以驗證。不幸的話,產品釋出乏人問津,怎麼死的都不知道。
***
PO心中的痛
既然價值不好控制也不易評估,許多Product Owner便將眼光放在「進度控管」上面,畢竟產品的釋出進度也是Product Owner需要負責的部分。Teddy認識的Product Owner,10個裡面有11個或多或少都覺得開發團隊進度太慢。Product Owner經常公開或私下抱怨:
***
為什麼快不了?
「預估進度與實際進度不符」是軟體開發經常面對的問題。根據字面上的意思,「預估」原本就包含「猜測」與「誤差」的涵義,而「實際進度」總是要等做出來之後才曉得。所以「預估進度與實際進度不符」實屬正常現象,請安心服用。
但是,身為Product Owner還是要為產品的整體進度跟老闆或客戶交代,因此無法容忍實際進度跟「Product Owner腦袋中的進度」相差太大。如同Teddy常說的,Scrum只是一面照妖鏡。Scrum跑的好,可以反映出個人、團隊與組織的現況。如果Product Owner覺得團隊進度太慢,應該與團隊一起探討關於進度認知落差的原因,例如:
***
對症下藥
沒有Product Owner會嫌自己團隊開發太快,只會覺得可以再快一點嗎。但Scrum的目的原本就不是快,而是讓公司可以在快速變動的環境之下保持成功。Scrum跑的好,首先可以反應出團隊現況的生產力。不管有多慢,很抱歉你的團隊就是這樣,除非你有能力可以換一個你覺得更棒的團隊,否則請先接受這個事實。
接下來才能夠靜下心思考,如何讓你手邊這個由派大星、海綿寶寶、天線寶寶與珊迪所組成的團隊,可以在兼顧需求交付的前提下,透過迭代與增量的方式,逐次提升團隊所能交付的價值。
這並不一定代表團隊馬上就具備越開發越快的能力,也有可能是Product Owner更能判斷客戶所需要的價值,因此開發越少的功能就能夠具備足夠的產品競爭力。也有可能是改善價值鏈的瓶頸,使得工作流動更順暢,減少交期(lead time)。當然團隊成員的投入程度、溝通與解決問題能力的提升,也是提升交付速度與價值的重要因素。
***
友藏內心獨白:敏捷就是最大化未完成工作的藝術。
沒有留言:
張貼留言