打造客戶喜愛的產品

定義雖短但是要走好久才能到達

Product Owner 是負責管理產品代辦清單及確保團隊執行有價值的工作之唯一人選。此人維護產品待辦清單,並確保每一個人都能清楚看見它。

這一短短的一句話,說明了幾個 Prodcut Owner 要做的事情。

  • 負責管理產品待辦清單。
  • 確保團隊執行有價值的工作。
  • 確保每一個人都能清楚看見它。

管理產品待辦清單

這邊的管理,並不是單純的有人生產出待辦清單,然後只要接著管理就好。Product Owner 作為那「唯一人選」,在前期需要瞭解市場、客戶、利害關係人,進而規劃產品願景、產品方向、才有辦法「試著」列出一些可以做的待辦清單。

即便知道有哪些待辦清單,但是由於各種時間、內外部的限制,還需要將這些清單「排序」並決定哪些事情做或不做,Product Owner 需要一直「不斷地」做決定,這也是最痛苦最煎熬的過程。

確保團隊執行有價值的工作

判斷「價值」也是非常難的事情。何況在產品初期,在還能很難將「價值」量化的時候,確保團隊能夠把時間和精力花在刀口上是 Product Owner 責無旁貸的工作。為了要確認每個工作的價值,Product Owner 需要更謹慎地了解市場、透過快速的迭代確保產出符合市場價值。

確保每一個人都能清楚看見它

剛開始我以為這邊的每一個人指的是團隊成員,但後來更加了解後才知道這邊的「每一個人」除了團隊成員,也可以包括利害關係人、客戶、甚至市場。像有些公司就會把自己的產品 Roadmap 以及待辦事項放在 Github 或 Trello 上,方便團隊和使用者、市場做更直接的溝通以及迭代。也能透過這樣的方式來管理「每一個人」對於產品的預期。

結語

本書後面很多操作性的介紹,幫助進入狀態後的 Product Owner 能夠管理相關工作項目。但最難的部分還是回歸到 Product Owner 的本質「讓產品產生價值」。最近也在公司以 Product Owner 的角色開展新的題目,也深刻體悟到這短短幾句話實行起來有多不容易。

估或不估都是問題

相信摸過 Scrum 的朋友對 Story Point 都不陌生,簡單來說就是讓團隊決定 每個 Task 的難度,將難度依照費式數列來排序。透過每個 Sprint Stroy Point 的加總可以知道團隊的戰鬥力以及預估時程。

消除誤解

這一章真的推翻很多對精益的認識,一開始就列了常見的誤解:

  • 精益的支柱并不是工具和减少浪费
  • 管理工具并不是精益的支柱

作者也列出了真實的狀況:

公司管理層承诺持續培養人才和提倡持續改善的文化。

他的起點是豐田模式中尊中他人和持續改善的哲學態度。他的原則是發展高士氣的員工、從而不斷地改進過程。職責不在黑帶的專家,而在運作公司的領導體系、他們是導師和教練。

這一段明確的帶出了整個精益思維的兩大支柱。

精益思維兩大支柱

  • 持續改善
  • 尊重他人

這兩大支柱相互支撐,持續改善擁抱變化的環境只有在尊重他人的環境下才會出現。

持續改善

在持續改善的這邊提到四個原則

  • 實地查看
  • 改善
  • 完美挑戰
  • 工作流動性

標準化工作

裡面在提到標準化工作的章節也是打破我的想法:

在精益思想中,标准化工作并不意味着顺应中央集权的标准 — — 对精益思想的一个严重误解是认为“标准化工作”意味着顺应中央集权标准的想法。从精益的角度来看,这是个重大的错误,但是却非常容易被误解,所以值得特别强调。标准化工作的想法是让团队掌握工作基准,由此可以对照改进试验的效果。这个基准(标准)是由团队(不是中央集权团体)创建的,並不斷演化。

最近在工作上也遇到需要訂立標準化的問題,但的確因為每個團隊組合、任務都不一樣,很難有一體適用的標準化方法。看到這個章節突然有所啟發。在豐田裡面透過小團隊、小迭代的方式進行持續改善,再將結果橫向傳播的方法真的非常值得學習。

對於看板的理解偏差

以前對於看板的認識僅在於視覺化工作流程、有 WIP 避免工作與價值堆積而已。這本書讓我看到很多原本沒注意到的精神。像是:

自指导工作 — — 这是在高效团队研究中发现的主题。注意:可视化管理支持自指导工作,因为人们可以非常容易看到实际情况、进行协调。同时,看板卡也有自说明作用,如“一张馅饼”或“改变网页的样式”。可视化管理知识型工作中的排队现象。

將原本無形的工作項目具體化之後,讓同事更明確目前的工作狀態對於目標的影響,的確有助於大家對於目前狀態以及目標的認知,也更容易促進自我管理。

Kanban 與 Scrum 的區別

Scrum 和 Kanban 在精神上是有很多類似的地方,例如小迭代、小增量、持續改善等等。不過在著重的地方還是有不太一樣的地方。

Kanban 提供了一個視覺化的工作流程,來幫助工作者瞭解工作的狀態。Scrum 提供一個輕量的流程(由三個角色和五個事件構成),讓團隊根據這個流程來運作。

因此在使用時, Scrum 更強調週期性的計畫、改善、迭代;Kanban 更強調將工作項目到產出價值之間的流程視覺化。

Agile=Adopt

Spotify Way

這是被網友罵爆的 Spotify Engineering Culter,被罵爆的原因不外乎 Spotify 內容裡面根本不是這樣子做的、很多東西只是換個名字而已,換湯不換藥之類的

Spotify Engineering Culture — Part 1
Spotify Engineering Culture — Part 2

無論事實如何(畢竟我沒在裡面待過),這個分享以及這些批評都點出一個問題:理論和事實永遠會有落差 XD

Scrum Guide 裡面建議的團隊人數大概是十人左右,一家上百人的公司就有十個 Scrum 團隊,這十個團隊要如何協作才能有效發揮是所有管理者的難題。Spotify 這支影片至少提供了一個解決這個問題的方向。

LESS is more

LESS 是另外一套大型敏捷框架,抱持著少即是多的精神,LESS 框架看起來好懂也不難操作,將每個延伸的角色和行動都介紹的非常清楚。目前我是有常識引入 LESS 框架中的幾個重要觀念到我們團隊。

不管走 Spotify 還是 LESS 也好,敏捷的重點在於溝通和適應,沒有一個框架能源源本本、完完整整的直接套用在任何團隊上,一定是需要持續和團隊和管理階層溝通、調整,才有辦法再實務中取得平衡、持續成長。

小抄也隨著迭代越來越厚

先附上這幾年在介紹敏捷時會用的投影片,隨著看的東西增加,這份投影片也越來越厚 XD

萌芽期

最早在團隊介紹敏捷的時候大概是 2017 年剛回台灣的時候,那時候台灣應該還對敏捷相對陌生,也沒有用什麼特別的方式來管理進度和工作事項,相信很多人都會覺得「目前做得好好的,幹嘛沒事弄個東西來管」。所以第一次介紹時候真的是完全基於分享新知的心態,告訴大家之前的團隊怎麼用敏捷來做事,以及如何運用到個人的工作中。

落地期

到了 2021 年在加入炬識之前,當時公司已經有很成熟的專案管理方式,但是對於新的開發專案就一直有點碰壁。於是跟老闆建議說,要不我們來試試看 Scrum 吧,反正情況不會更糟了(誤。

於是乎跟團隊介紹了一次敏捷開發,由於這次的敏捷式開發是會直接套用在工作中的,所以也引起滿多討論,像是「這真的有用嗎?」、「怎麼可能跟客戶合作?」、「那專案經理要幹嘛?」等等聲音,就會需要針對這些實務面的問題來回答大家的疑慮,以及提出更接地氣的做法。好在這個客戶非常好溝通,讓這次的導入有個好的開始,也能讓大家慢慢習慣以及接受這樣的做法(吧。

融合期

最近一次分享就是在新人訓練的時候了。由於這幾年敏捷在台灣也是當紅顯學,很多新人其實聽過或是在之前工作跑過 Scrum。但是敏捷這種東西也是會看各別公司的狀況而有不同。就算是現在的公司,經歷過這幾個月的迭代也跟初始狀態不太一樣了。

所以在新人訓練的時候除了基本的敏捷精神外,還會特別著重在我們進化到現在的工作流程、一些重要的沿革、以及和 PO、工程師之間相互配合的方式,幫助新人融入我們目前的敏捷團隊中。

改變對任何人來說都不是容易的事情,任何東西的導入絕對需要考慮到當下的情境,何況敏捷又特別強調迭代、適應和成長,在導入敏捷時一定要特別留意團隊和自己的狀態,不管是技能的成熟度、人際關係、以及對於敏捷的理解,才能稍微順利的讓團隊接受以及使用。

答案都在你的心理

GROW 是個非常簡單好用的對話模型,只有四種句型

  • Goal(確認目標):想要達成的目標是什麼?
  • Reality(檢核現況):現在的狀況為何?與目標的差距為何?
  • Options(選擇方案):有哪些方案可移除障礙,達成目標?除了當下這種選擇之外,還有沒有其他方法?
  • Will(意願行動):可以採取什麼行動?你想做什麼事來達成目標?

由於簡單,除了跟別人對話之外,也很適合做為跟自己對話的工具。

這次的實驗對象是我的 Mentee,他目前是個專案經理兼 BD,以下會摘要比較重要的問題和轉折,為了不要讓當事人曝光,所以部分資訊會隱藏或模糊帶過。

Mentee:我在煩惱要不要學 AWS
我:為什麼想學 AWS 啊?(G)
Mentee:因為最近接觸到很多跟 AWS 相關的專案,覺得會有幫助
我:你覺得會有什麼幫助?(R)
Mentee:可能在談案子上會更容易吧我:你目前談案子狀況如何呢?
Mentee:好像有漸入佳境的感覺,比較知道怎麼跟老闆聊天
我:你跟老闆都在聊 AWS 嗎?(R)
Mentee:也不是,不太知道為什麽最近比較聊得來

我:你目前接觸的客戶有哪些類型啊?(R)
Mentee:有 A 產業和 B 產業,A 產業的金額比較大,但是我不太熟悉;B 產業的金額沒那麼大。
我:那你自己的興趣呢?(G)
Mentee:因為背景的關係,對 B 是比較有興趣。
我:那目前 B 類型的客戶狀況如何呢?(R)
Mentee:因為熟悉產業是聊得滿來的,也知道客戶的問題。
我:那 B 類型的客戶要做多少個才能超過 A 產業呢?(R)
Mentee:(回答某個數字)

我:那你覺得有辦法在接下來的時間 Cooking 出這樣的數量或規模嗎?(O)
Mentee:不是很容易,可能要一些條件。
我:那你有相對應的人脈可以讓你搜集情報嗎?(O)
Mentee:或許可以怎樣怎樣來拿到名單。
我:那你可以給自己多少時間來嘗試看看這樣的做法?(O)
Mentee:可能有幾個月的時間。
我:那具體來說,下個月可以達到怎樣的目標呢?(W)
(===對話差不多到此結束===)

從上述的對話看來,初期大致上都在反覆確認目標(G)和現狀(R),等到現狀釐清到一定程度後才會走到(O),最後才會到(W)。

我認為使用教練對話最大的重點就是在於幫助當事人釐清自己當下的狀況、目標以及所在的位置。

比起有真的「教」了什麼東西的教練,在教練對話中的教練更像是一個超然的好奇寶寶,從一個外在的角度透過有結構性的問題來協助當事人梳理狀況;但同時也是一個目的性很強的對話,需要在適當的時機讓問題收斂、聚焦。

所謂當局者迷,陷在複雜的環境中的當事人看不清楚或是忽略掉某些解決方案的可能性,教練可以透過 GROW 這樣的問句幫助當事人來思考各種解決方法,引導出可行動的解決方案。

How to treat data as products

關於資料產品(Data Product)的定義眾說紛紜,我個人很喜歡 Simon O’Regan 在這篇文章的定義:

A product whose primary objective is to use data to facilitate an end goal.

原因有幾個:

  • 比起複雜的定義我更喜歡文字簡單的定義
  • 比起過度強調 AI、視覺化的定義、我更喜歡這種針對資料本質用途的定義。

根據這個定義,Simon 將資料產品依據內在的複雜程度分為幾個類別,類別越下面會進行越多加工、也更容易讓一般使用者(非技術人員)使用:

  • 原始資料(Raw Data)

就像農作物一樣,原始資料指的是最 Low Level 、未經加工處理的資料,可能來自於跟後端 API 溝通的資料庫、也有可能是程式執行時留下的 Log、埋在前端搜集使用者行為的事件等等。

原始資料是資料產品的最要的起點,資料分析有句名言,「Garbage in、garbage out」,如果一開始的資料品質就沒有顧好,或是沒有考量到後續的資料應用而亂設計,都會對後續資料產品品質有嚴重影響。

以使用者事件來說,光是事件的命名、資料結構、有沒有 Session ID、使用者 ID 的設計方式,都會影響後續的使用。

  • 加工資料(Derived Data)

加工資料顧名思義就是將原始資料拿來加工做近一步處理後的資料。例如後端的資料庫通常會為了效能以及去除冗余資料將資料正規化,但是在分析階段需要重新加這些正規化的表格相互 Join 反正規化,這樣的資料就是加工資料。資料加工的手法很多,除了反正規化之外,也包括了資料清洗、聚合等等,需要看需求而定、沒有一定的做法。

例如在我拿到使用者事件後,可以計算每天使用者人數、使用者最近看的影片、使用者最常點擊的按鈕等等。

  • 模型(Model)(原文是 Algorithms,但我覺得 Model 更適用)

單純的演算法其實不太能算是資料產品,而是需要將演算法融合資料後才會會形成一個用來解釋這些資料的模型(或是 AI)。模型可以用來解釋資料、或是用來猜測新資料的屬性或分佈。

當我想要預測使用者的點擊行為時,就可以根據使用者 ID 以及使用者的特徵組成要拿來產生出模型的訓練/測試資料。接著可以套用不同的演算法,像是多元回歸、羅吉斯回歸、隨機森林等等方式來預測使用者行為。

Andrew 最近也更為強調資料在 Model 中的重要性(Data Cetric AI)。

  • 輔助決策(Decision Support)

使用資料的一個重要目的就在於幫助我們做決策,不管是氣象報告也好、還是公司的財務分析報告也好,都是根據資料產生出一個可能是模型、也有可能是分析報表的資料產品提供給使用者作為決策參考之用。

  • 自動決策(Automated Decision Making)

輔助決策和自動決策的差異就是在決策中間人為涉入的程度多寡。例如導航系統會分析不同路徑到達終點的時間,但是實際上要走哪條路還是由駕駛控制,算是輔助決策;如果車子能自動根據路況來自動選擇要走哪條路,或是推薦系統根據過去資料以及模型就直接投放特定內容給使用者,就會是自動決策。

資料產品的層次並無法獨立作業,而是層層疊加。如果要做加工資料,就一定需要原始資料;如果要做模型,就一定需要加工資料;當我要開發自動決策系統時, 就一定需要原始資料、加工資料以及模型的配合。

下次再來聊聊資料產品的生命週期跟一般產品有什麼不同。

不小心就舉辦了一場史詩級的 DAKI 回顧會議

DAKI 是個非常簡單的方式,只有四個問題

D(Drop) — 什麼東西是可以/需要拋棄的

A(Add) — 可以加入什麼東西讓團隊變得更好

K(Keep) — 什麼東西是團隊喜歡、需要保留的

I(Improve) — 哪些東西可以/如何改進

議程設計

一開始是想是讓大家依序對 D、A、K、I 四個面向來討論,但是在第一次進行時,發現討論完目前有哪些東西是可以/需要拋棄(Drop)後,最好馬上討論後續可以有哪些實際的 Action Item,會讓討論更聚焦且不落於空談,因此流程上改成:

  1. 先讓大家發想有哪些東西可以 Drop
  2. 將想法整理歸納,或解釋得更清楚
  3. 討論這些想 Drop 的東西中的重要順序
  4. 討論針對前三個重要項目可以有哪些實際作為來改善並加入追蹤事項
  5. 接著回到第一點,依序討論 Add、Keep、Improve

引導

引導固然有技巧,但是要讓大家說出真實聲音是需要時間練習和培養信任感的。我們團隊跑 Scrum 大概半年,從一開始大家只想私下提出建議變成已經可以在回顧會議上提出來,並且一起理性討論問題與解決方法。

成效與回饋

在 Drop 的階段大家提出很多目前應該要捨棄的制度或工作模式,大部分都集中在客戶溝通以及內部人力安排這兩點。因為這是困擾所有人的議題,所以我們就停下來針對這些問題跟在場夥伴搜集意見以及想到的解決方案。

這個釐清問題以及解決方案的過程我認為是很有價值的。可以將大家的情緒和不滿聚焦到實際的問題上,並且將這個問題從一個被動無奈接受的狀抗,轉化成大家可以出心力主動提出方法以及改變的狀態。

之前有人討論到回顧會議最後都很像集體治療,那其實也只是治標不治本。最後這些回饋建議如果是要跨部門溝通的,就會由我跟幾個主要的提案者(受害者)將意見回饋給管理階層,將公司帶入正向的循環。

Keep

心裡有敏捷,做起來就會敏捷

Agile 是一個廣泛的概念,根據這個概念,有非常多的方法論都可以跟敏捷沾得上邊。從上面這張圖可以看到在敏捷這把大傘下,各個方法論可以根據規則多寡一字排開,越下面的就越彈性、規則越少;越上面的規則越多。

交作業第一發

「價值」是引領人行動的第一性原則,需要時時檢視才不會走偏了。關於敏捷價值我很喜歡 william 大大這篇文章其中的一句話:

敏捷,不僅著眼於百米衝刺的短期成效,更著眼於馬拉松的長期績效。

例如 Modern Agile 裡面的四個原則

  • Make People Awesome
  • Make Safety a Prerequisite
  • Experiment & Learn Rapidly
  • Deliver Value Continuously

一般來說在 Scrum 裡面比較注重的是後兩個,快速試錯學習、以及持續交付價值這兩點。但是在一般團隊管理上也都會提到,如果要成為一個好的團隊,團隊的心理安全感以及成就成員這兩件事情也是非常重要,甚至可以說是後兩者的前提。

Scrum 在流程上,最可以做到這兩點的就是在「回顧會議」的時候。

在回顧會議上塑造了一個安全可以對團隊、流程提出改善建議的環境;而這些建議基本上也是為了讓團隊變得更好才提出來的。

所謂安全感?

工作上的安全感除了基本的溫飽之外,我覺得是不怕犯錯的環境。

軟體開發面臨著高度不確定性,技術一直更新、環境一直在改變、每個人隨時都有可能犯錯。要減少錯誤方式就是累積足夠多的經驗,而在軟體業裡面也就意味著,你要踩過足夠多的才有辦法。如果不敢犯錯就很難在這個行業持續走下去。

所以我認為團隊的重點不是不犯錯,而是犯錯之後怎麼處理、以及從中學到了什麼?需要讓團隊知道這是一個允許犯錯的環境,我們大家都會在犯錯中繼續成長。

如何塑造有安全感的環境?

這件事說起來簡單,但做起來很難。同時需要讓團隊成員覺得自己不會因為提出建議而受罰;也需要讓「需要改善的人」知道這件事情是對事不對人;更需要讓公司了解這些改善不是單方面的偏袒團隊成員。

需要在三個方面打造這樣的共識:

  • 讓個人了解:提出建議的目的在於讓團隊變得更好,而不見得只是讓個人更好過
  • 讓團隊了解:讓團隊變得更好的過程,不見得大家會更好過,唯一讓大家還願意這樣做的動機就是 make people awesome
  • 讓公司了解:Awesome People will make business awesome

初始期 — 察言觀色

當團隊剛組好,或是剛採用回顧會議的手法時,因為大家都還在觀望,或是不太確定什麼叫做合適的建議,我通常都會採用匿名的方式來做回顧會議。除了保有匿名性之外,也可以讓每個人有均等發言的機會,不會被少數意見強勢的人帶風向,順便觀察團隊成員的性格以及著重的層面。

改善期 — 以身作則

當團隊開始提出改善建議時,我通常會先跳出來作為這個改善事項的 Owner:一來讓大家瞭解說回顧會議對事不對人,只需要針對需要改善的事項做思考;另外一點就是帶著大家一起走 PDCA,一起來思考解決方式,不只是單單提出想法或抱怨而已。

之後就是會在每次回顧會議上定期追蹤這些事情的改善狀況,抱持資訊的暢通和透明。

轉移期 — 培養 Ownership

由於需要改善的事情很多,一個人絕對忙不過來,這時候就可以看看有沒有人自願跳出來做為改善方案的 Owner。

有些人不敢提建議就是因為怕要負責後續的處理。但所謂自己的團隊自己救,如果對工作環境不滿,每個人都有責任讓自己的工作環境變得更好,而且每個人也同時有這樣的能力和權限可以處理團隊遇到的困難。

Scrum 不是萬靈丹

非常多團隊導入 Scrum 而失敗開始抨擊敏捷,但就我的經驗來看,團隊不是因為導入 Scrum 而變好。而是因為我們注重這些敏捷價值,才選擇有機會發揮這些價值的 Scrum 模式來運作來讓團隊變好。

Bryan Yang

資料經理人,協助資料融入企業,致力於讓資料發揮更多價值。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store