# 工具的盲點，讓產品團隊自然而然的發力 - 林佑霖(Eason Lin)

{%hackmd @HWDC/BJOE4qInR %}

>#### 》[議程介紹](https://hwdc.ithome.com.tw/2024/session-page/3190)
>#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/NDUmN9ubwxGAiqcU9)

講者有產品開發、ScrumMaster、PO的工作經驗

聆聽也是一門重要的學問，所以把聆聽把在技能上

提到這次的分享都是講者的觀點，觀點是對客觀事實的主觀看法，所以要大家仔細思考自己的情境後，謹慎服用。

# 工具與框架

定義工具與框架，如：組織架構、工作流程、分工的作法…
這些東西都「可能」是某個成功經驗下的產物，為什麼說可能？也有可能是聰明的人們認為這樣做可行而想出來的作法，不一定帶有成功經驗的。
像Spotify Model，到近年被幾個參與者說到，Spotify其實不是完全照著跑，而跑的過程也有失敗的情況。

### Structure isn't the most important. Culture will eat any structure.
文化會吃掉他們認為不適合的結構

### 工具與框架是身在戰場中的人，在產品發展中一步步解決問題而發展出來的作法

所謂的盲點，「照著別人的方式做，就會像別人一樣成功」

# 工業產品 vs 軟體產品

以iphone為例
iphone，一年一代的改版，每年的生產都會新的model，
而軟體就是隨著需求慢慢長出來的一堆code，改版還是這堆code，
在維修上，iphone要維修他就是換零件給你，不然就是換整新機給你，而軟體呢？還是這堆code。
回應需求上，像手機這類產品的回應需求也只能是設計生產一隻全新的，而軟體呢？還是這堆code…
所以本質上軟體跟硬體在開發上，人員的學習跟需求傳遞上就有些不同。

而我們在軟體開發上有學習工業產品的作法嗎？
Waterfall, 專業分工
在專業分工的情況下，容易發生各別最佳化的情況，在工業產品的領域是可行的，但在軟體產品的情況下，每個分工負責的部份，容易思考太多在自身完美而花了太多的成本，對產品可能沒有直接的幫助。

# 新創從開始到成功後的轉變


從一開始的四肢都代表一個人，之後四肢跟軀幹開始長人出來，到最後長了滿滿的人，新創公司，一開始，每個人都了解產品了解市場，隨著公司業績上升，人員的增加，隨之而來的溝通、分工的作法就開始產生改變。

怎麼讓公司在團隊持續成長的情況下，還能保持新創時的樣貌？

目標：怎麼讓產品團隊能像新創團隊般，自然而然的發力
大家喜歡這個目標嗎？

# 我的一些想法

## 第一步，切分產品，減少Dependency
切分的方式是讓每個團隊都能面對到自己產品的end user，而不是像前端後端的切分


這決定了產品團隊會負責的部份，而且直接可以對end user、對產品做事，不過depend on別的團隊。

然後要區分出產品團隊與服務團隊，服務團隊要思考怎麼讓產品團隊能更快的交付產品，
例如：Infra團隊在CDN快取上，可以提供API，讓產品團隊能快速的自己清，不需要多餘的資訊傳遞與人力。
這樣回應需求的速度就會變快。

## 第二步，公司/產品的全貌被看見

是挑戰也是關鍵的一步

讓PO多說些產品故事（市場、數據）
讓PO定期說產品的狀況，而不是只是Story的目的跟需求，讓團隊能了解自己做的產品發生了什麼事，而不只是你叫我做我就做的情況。

講者提到一個APP前端團隊遇到後端的功能沒有團隊有空做，所以產品可能要半年後才能上線，講者嘗試把問題拋給團隊，並且剛好講者懂一些後端，問團隊有沒有興趣嘗試自己做，也能讓產品在一個月內上線，結果團隊接受，現在團隊是APP全端團隊。

講者提到另一個全端團隊調校DB效能，這團隊產品上線後開始遇到效能問題，有團隊成員就提到「我們沒有DBA」，講者就跟他們說我剛好有一些DB效能調校的東西，你們要不要嘗試看看，然後團隊就學會了一部份的DB效能調校的能力。

### 當人們知道了問題，通常就會想解決

講者提到在PO看團隊拿Story時，有拿多拿少的問題，中間的差距有點大，所以就問團隊怎麼會差這麼大，講者建議讓PO說出產品的壓力，而不是在乎團隊拿多拿少，當團隊知道產品的現況與壓力，團隊就會思考怎麼取捨，變動的該是Scope，而不是要拿哪一張Story。

### 不是做這個還是做那個，而是面對產品現況，我們可以怎麼做？

講者提到把Story做到「好」有很多方式，提到微服務拆得很漂亮，但產品沒人用沒賺錢…，這是好嗎？

### 技術會因為產品的問題而長出來

揭露雲成本的細節，當人們看到產品的價值與成本，就會知道問題在哪，自然而然技術就會長了出來。

當團隊為了解決公司/產品的問題，而有了學習，那才會是更有價值的學習。

## 第三步，清晰明確的產品目標

這是最重要的指標來看產品團隊的價值，大家才不會有單點最佳化。
而產品有價值、團隊跟Developer才有價值。

## 第四步，新創思維、團隊賦能、自主管理

當全貌與目標都清晰，團隊自然就知道為何而戰，好奇心與成就感就會長出來
Ownership

要平平凡凡聽命行事，還是要幹點大事？

管理的責任就會慢慢從主管轉移到團隊的身上

講者提到自主升遷的情況，好的情況該是主管是組織情況與文化的維護者，而團隊本身在自主升遷上彼此就對彼此有一些要求與想法，團隊認為能升的才會進去。
而這個情況應發生在日常，而不是半年或一年說一次，那都太慢了。

講者提到One on one retrospective，One on One會聊的，大家一起討論反而不容易出來。所以可以嘗試。

## 第五步，陪伴者，技術/非技術、務實、系統思維

應挑選技術較硬、務實、能把東西做出來讓團隊感受到好，而驅動學習接受的人，當做團隊的陪伴者。

### 技術不夠硬，敏捷不起來

團隊走偏走歪要發聲、要有系統思考的思維，找到系統的機會點。

看到問題中的機會。

## Culture will create the structure
只要文化對了，自然會長出適合的結構

請大家謹慎服務，所有事都是有Pros & Cons

講者提到若自己在一個組織兩到三年，思維會固化，所以希望大家能多多交流，讓彼此都能不斷的有新的思維成長，歡迎加好友。

臉書專頁
https://www.facebook.com/JellyTsAgileNote/

Linkedin
https://www.linkedin.com/in/eason-lin-131433b1/

# Q&A from Slido

## APP前端願意學習後端技能，是不是因為相信SM您的引導與您有後端能力，才願意嘗試？若沒有人引導下前端要如何願意點亮後端技能？

回答：我的步驟會是了解公司內有沒有這方面的資源，例如有後端的專業，或是有資源可以讓同仁去上課之類的。若有，那我就會把目前的問題拿去問團隊，有沒有意願為了產品上線或是其他的產品問題，讓我們加快交付回應市場，我們也有相應的資源來分配，看看團隊有沒有意願。不過相應的，在這之前，應該要把產品目標弄清晰，讓大家有拚的方向，這樣問題拋出來，團隊解決是一種很自然的情況。

## 如何讓團隊成員願意誇職能解決”產品的問題”，想請您講的更多

回答：我的想法是確立產品目標，讓這個產品團隊（PO+Team）負責這個產品，之後開始讓這個產品團隊了解產品的全貌（價值、成本、產品現況…），產品團隊知道問題在哪，他就必須（應該）要想辦法解決，而不是職能的問題，當然公司也要提供必要的資源，例如要有人員能夠陪伴、帶領他們朝著為了解決問題而學習或想辦法，或是提供資源在他們覺得他們需要學習什麼技能而苦手時，提供學習的資源之類的。

## 本身經驗提供，新創公司若沒有賺錢（燒錢） （正向講法：投資加速階段）就算自主升遷提報也不太會有改變，只能自求多福找出路⋯

回答：感謝經驗提供，我在想如果產品團隊一直為提升產品的收入想方設法的時候，或許就會有戰功（成功讓產品有所突破），那這種情況，升遷應不會是難事。而我認為產品開發者的價值正是在此（能夠為產品找到突破點）。當然如果產品一直沒有突破，那就真的難辦一點。XD

## 你講的好像專注在管理團隊，那服務團隊呢？

回答：我講的比較偏產品團隊（我想題目應該是打錯，我就這麼回答，如果有錯可以連絡再交流！），而服務團隊，我在分享時提到幾個，像Infra、DBA又或是HR，這些都算是服務型的團隊，他們旨在服務公司產品相關的人員或提供必要的服務，這時我的想法第一步會是訂定每一個服務團隊的目標，例如我在分享時提到的，Infra如何讓產品團隊在回應市場的速度能越快越好，需要人工幫忙的服務怎麼建立自動化的作法，Infra相關的成本與服務狀態，怎麼讓產品團隊能越容易清楚掌握。這該是服務型團隊的使命，而為了做好這個使命，相應的學習肯定也會很多，但對服務團隊中的每個成員，跟公司的未來，肯定是相對比較好的發展。

### 以上是回應在Slido上的問題，如果有更多的問題，歡迎可以加臉書或Linkedin交流！感謝！