l

2019年1月15日 星期二

Product Owner 的存在

Jan. 15 12:48~14:33

螢幕截圖 2019-01-15 14.20.44

▲擁有就要負責,不要製造流浪產品。


作為解決方案

Product Owner(產品擁有者、產品負責人)這個角色接近傳統專案的產品經理或專案經理,雖然傳統專案沒有這個角色,但Product Owner目的與責任並不難理解。畢竟不管瀑布式專案或敏捷專案,總是要有人來管理需求與規劃產品藍圖,

依據中文版Scrum Guide對於Product Owner的說明:

螢幕截圖 2019-01-15 12.53.12

由此可看出Product Owner藉由管理Product Backlog將產品價值最大化,其他文字敘述則是進一步解釋Product Owner這個角色如何達到此目的常見做法,也就是對Product Owner這個解決方案的詳細說明。

***

解決什麼問題

如果Product Owner是一種解決方案(Solution),請問他要解決的問題是什麼?

從Scrum Guide的敘述,Product Owner要解決的問題有三種可能的表達方式:

Problem 1:如何最大化產品價值?

Problem 2:如何管理Product Backlog?

Problem 3:如何管理Product Backlog以最大化產品價值?

Solution:指派一位Product Owner來負責。

***

Product Owner Pattern對於Product Owner的描敘則是:

One person needs to be responsible for the Product Backlog. This person needs deep domain knowledge, business insight, understanding of product technology, technical dependencies, and the authority to force rank the backlog to maximize business value.

(一個人需要負責產品Backlog。 此人需要深入的領域知識、商業洞察力、對產品技術的理解、技術相依性,以及排序代辦事項以最大化商業價值的權限。)

依據Product Owner Pattern的描述,可以將Product Owner要解決的問題寫成:

Problem:如何管理Product Backlog?

Solution:指派一位Product Owner來負責。

***

Product Owner的難題

指派一個人當任Product Owner,透過排序product backlog item (產品待辦事項)來最大化產品的商業價值,即時且持續的交付高價值的產品給客戶,聽起來是多麼理想與合理的一件事。但實務上,好的Product Owner也是很難找。

Product Owner經常遇到以下難題:

  • 未被授權:既然Product Owner「擁有產品」,就應該被公司充分授權,才能夠對產品的成敗負責。但實務上,Teddy遇到不少「有名無實」的Product Owner,只是老闆的代理人,大部分團隊提出的問題都無法當場回覆而必須回頭問老闆。遺憾的是,老闆又很忙,無法及時與Product Owner討論,導致整個團隊溝通非常不順,也很容易造成大量的重工(等產品做好之後老闆看到才說這不是他要的)。
  • 沒有主見,不願承擔:也有不少Product Owner雖然獲得公司充分授權,但他卻不敢也不想承擔「做決策」的風險。這種Product Owner的口頭禪就是:「由團隊決定、都可以、這個需要再研究。」甚至把做決定的工作「外包」給其他單位,以便到時候萬一產品失敗,可以有人一起承擔「歷史共業」。

 沒有主見或不願承擔,也有可能代表Product Owner 對於產品領域知識不足,也缺乏產品的熱忱。

  • 進度壓力無處發洩:依據Scrum框架,Product Owner決定What(做什麼),開發團隊決定How(怎麼做、做多久)。換句話說,完成每一個功能所需的時間是由開發團隊所決定,Product Owner必須尊重。

在傳統的專案開發中,如果產品經理或主管對於開發團隊的進度不滿意,大體脫不了痛罵一頓與祭出激勵手段(棍子與胡蘿蔔策略),最後再要求員工 強迫 自願加班。但採行Scrum之後,Product Owner突然失去「自願加班」這個萬用工具,當他覺得進度落後時,自然會產生焦慮感,然後將此種壓力用明示或暗示的方法轉嫁到開發團隊身上。久而久之Product Owner與開發團隊彼此看不順眼,互相抱怨。

***

熱情與看法

Teddy始終相信,如果你對於產品沒有熱情,就不要擔任該產品的Product Owner。就好像如果你不喜歡貓,就不要貿然的學人家養貓。你可以養狗、養鳥、養烏龜、養兔子、養小孩,甚至什麼都不養。

有熱情,才會想方設法把產品做好。熱情可能來自先天對於產品的喜愛,例如有些人天生就熱愛玩Game。熱情也可能來自後天的訓練,例如你原本不喜歡玩Game,但為了生活從事遊戲開發若干年後,慢慢地愛上玩Game。

對事情有熱情,就會慢慢培養出「職業達人」的堅持。自己對於產品有看法,才不會人云亦云,做出有特色的產品。

***

友藏內心獨白:不要製造流浪產品。

2019年1月14日 星期一

Scrum Master 的存在

Jan. 14 10:52~12:48

螢幕截圖 2019-01-14 12.46.52

▲泰國清萊的白廟,過橋後到達天堂不可走回頭路


作為解決方案

對於初次接觸Scrum的朋友,Scrum Master這個角色是一個不容易理解的存在。依據中文版Scrum Guide對於Scrum Master的說明:

螢幕截圖 2019-01-14 10.53.19

由此可看出Scrum Master負責推廣與支持Scrum。其他部分的文字敘述都是在進一步解釋Scrum Master這個角色如何達到「推廣與支持Scrum」的細部做法,包含Scrum Guide文件後續提到Scrum Master分別對於Product Owner、開發團隊與組織所提供的各種服務都是針對Scrum Master這個解決方案的描述。

作為一種解決方案,接觸過Scrum的鄉民多多少少可以講出Scrum Master是:

  • 牧羊犬,保護開發團隊不受大野狼(外部因素)干擾
  • 流程專家
  • 敏捷教練
  • 敏捷轉型引導者
  • 僕人式領導

***

解決什麼問題

如果Scrum Master是一種解決方案(Solution),請問他要解決的問題是什麼?

從Scrum Guide的敘述,可以將Scrum Master要解決的問題寫成:

Problem:如何推廣與支持Scrum?

Solution:指派一位Scrum Master來負責。

***


ScrumMaster Pattern中針對Scrum Master的解決的問題有一個較精確地描述:
Development Teams, Product Owners, and organizations cannot get the benefits of Scrum without deep understanding and application of its principles and values.

(如果沒有深入理解和應用其原則和價值觀,開發團隊、產品擁有者和組織就無法獲得Scrum的好處。)

依據ScrumMaster Pattern的描述,可以將Scrum Master要解決的問題寫成:

Problem:如何讓開發團隊、產品擁有者和組織獲得Scrum的好處

Solution:指派一位Scrum Master來負責。

***

是否需要專職的Scrum Master

在台灣,Teddy遇到不少剛導入Scrum的團隊面臨到沒有專職Scrum Master的困境。其原因不外乎人手不夠、老闆不同意有一個專職的人每天無所事事不用寫程式,只負責「流程改善」這種虛無飄渺的工作

依據Scrum框架,每個Scrum團隊都需要一位專職的Scrum Master。理由之前已經說明過了,就是「要讓開發團隊、產品擁有者、組織獲得Scrum的好處」。

如果你的團隊不需要Scrum Master也可以「獲得Scrum的好處」,那當然可以不需要這個專職的角色,畢竟Scrum Master只是「如何讓要讓開發團隊、產品擁有者、組織獲得Scrum好處?」這個問題的一種解決方案,團隊可以自行探索其他可能的解決方案。

《金剛經》中講過:「汝等比丘,知我說法,如筏喻者,法尚應舍,何況非法。」Scrum Master只是幫助團隊到達敏捷彼岸的一種媒介,正所謂「過河拆橋」,到達彼岸之後橋就用不到了,可以把Scrum Master丟掉XD。

但是,就是因為產品擁有者、開發團隊與組織都不懂Scrum,尚未獲得Scrum的好處,才需要「導入Scrum」。既然決定要導入Scrum,安排合適的專職Scrum Master,減少敏捷轉型過程的碰撞並提高成功機會,這一點點的投資也是很合理的。

***

友藏內心獨白:不要落入「省小錢、花大錢」的陷阱。

2019年1月11日 星期五

我想用Scala

Jan. 11 8:34~9:21

螢幕截圖 2019-01-11 09.14.04


數年前Teddy帶幾個學弟開發一個系統,討論完需求後,學弟A建議採用Scala語言。

雖然Scala同時具備物件導向語言與函數導向語言的優點,但在當時Scala還是一個相當新的語言,採用的專案不多,會的人更少。Teddy擔心除了學弟A以外,Teddy自己與其他團隊成員還需要時間學習Scala,可能會模糊專案目標並且影響開發時程。另外,萬一學弟們畢業後,日後系統維護找不到懂Scala的人也是一個問題。再加上使用新語言雖然很酷,但新語言通常有很多「雷」等著不怕死的人去清除。為了 怕麻煩 降低專案風險,於是Teddy建議學弟還是保守一點,用實驗室最熟悉的Java語言來開發這個系統。

多年後函數語言已融入主流的物件導向語言之中,物件與函數的「混搭風」成為主流的開發模式。不知怎麼的幾天前突然想起多年前的這個故事,驚覺到隨著年齡增長,年輕時的冒險犯難精神不知道消失到哪裡了

年輕時剛出社會寫程式,剛好趕上第一波網際網路大爆發時代,Java、Java Applet、JavaScript、HTTP、HTML,這些當年的「新技術」在學校完全沒學過(學校教的是Pascal、C/C++、Fortran、組合語言),但工作上就是要用到,怎麼辦?沒怎麼辦,做中學就是了,專案需要用到什麼技術,就去學什麼技術。當時雖然開發軟體的經驗不足,但企圖心與衝勁十足

***

N年後,多做了一些專案、多讀了一點書,也多了一層鮪魚肚,漸漸補足了當年缺少的軟體開發與軟體生命週期管理的經驗。但隨著手中抓住的東西越多,很多時候反倒捨不得打破現況,去追求那些最新的、風險最高的新東西。

高風險通常伴隨著高失敗率與高收益。人在年輕時應該找機會多冒險、多累積失敗經驗,從失敗中學習。公司也是,特別是新創公司。

那年紀大了怎麼辦!?只能不斷提醒自己:「取捨風險與利益,不要事事都打安全牌,也不要變成自己年輕時所討厭的老屁股XD」。或者,變成支持年輕人去冒險犯難的老人,也是一種不錯的選擇。

***

友藏內心獨白:快速失敗,不斷學習。