ft. 產品三眼怪 podcast
前情提要
這集節目是由兩個 pm 和 一位工程師在討論的議題，我覺得非常實用而且很生活日常！
雖然這類似的文章已經很多了，但還是想要分享紀錄一下自己學到的內容，非常開心產品三眼怪分享了這麼棒的內容！這集真的來來回回聽了兩次，原來可以在職涯上和工作中幫助自己更快速地進入狀況！
這週剛 onboard 兩週，然後有別於之前的工作性質是需要繪製產品 roadmap和一些 wireframe 的頁面功能，這份工作最主要是要了解工程師 coding 的語言，因此在也在這兩天沈澱了一下，可以在這裡學習到什麼，原來這些需求可能是指哪些東西。
在這個工作性質的銜接之下，以終為始的心態就非常重要，剛開始會焦慮也有點迷惘，我可以在這裡提供什麼價值？可以在這邊了解到什麼應用端？這些角色的應用是什麼？大家團隊之間的合作模式等等！
感覺這個又可以另外寫一篇文章分享！期待XDDD （自己說
好的！總之目前的工作會遇到好多工程師，所以也會想要了解他們在處理什麼，也是成為一位產品經理的必經道路八！
🟡 有技術背景的 PM vs. 沒有技術背景的 PM
我們常常會糾結這個原因，就是因為 PM 會時常跟工程師溝通，如果了解一些技術語言的話，溝通會不會比較順暢！？
答案非常明顯！是會順暢很多的！
但是如果沒有技術背景出生的 PM，其實也有著力的點，像是專案管理的能力非常強、或是對於使用者行為和 UIUX 非常有研究，都是從事產品經理的切入點！最重要的是找到自己的專長在哪！
但有些工程師很不喜歡遇到也有技術背景的 pm，因為工程師會覺得那個 PM有充足的知識去跟他抗衡或是吵架，開發會覺得很容易不被尊重！工程師有時候甚至希望 PM 沒有工作背景 XD
但我覺得了解技術是為了讓彼此的溝通更順暢，是為了減少溝通成本，而不是反而讓成本增加。
尊重彼此的專業
也是一門學問
像有些像是 TPM（技術產品經理），公司就會希望有比較多技術背景的人來擔任這個角色，有時候像是工程師丟一個工程相關的問題出來，那他們就會比較快的理解他們在說什麼，那個複雜度的龐大性，沒有工程背景相關的 PM 就會需要花更多時間去理解這個 issue。
但是如果你是 TPM ，就算你有很強的背景，如果沒有真的實際跑過那開發流程的話，最好都詢問工程師，把所有意見跟選擇提供給工程師，由他們來跟你說這邊的複雜度是什麼！
那技術產品經理也會常常代表技術團隊去對外部進行溝通和協調的角色，將本身團隊的資源做內部整合後，將我們的需求跟外部團隊做交流，也是團隊中非常重要的角色！
🟡 To C 的產品經理就不用太了解技術嗎？
主持人提到，之前在新加坡的經驗有 buyer experience 的功能，然後做一個電商 market place 的時候，就會遇到「 搜尋、推薦 」的功能，這些比較注重技術面向的問題，那時候同事就是之前在 Google 做 search 的 pm，他就會較快速的了解 search 的 ranking ，並且做一些問題分析，可以快速的了解可能會遇到的問題有哪些！
但還是真的常看產品面向，To c 的話其實不太常會用到這麼深的技術知識，就算工程師沒有 ml 的技術背景，也不會很快的了解，所以只要大概懂那個框架就好！所以可能也是跟 domain knowledge 有關！
另一個主持人也有提到，之前在 Spotify 做 ML 相關的 project，那裡的工程師就會做相關的 workshop 讓大家更了解 ML 的東西，實驗要怎麼設計等等。
我覺得工程師耐心的解釋，還有透過各種讀書會或是 workshop，讓我們更加理解他們的世界～～～～～
🟡 菜鳥 PM 可以先切入的技術知識
👀 From 產品經理的角度
📍system design
主持人提到，像是 Google 在 PM interview 中，常會有 system design
環節。
為什麼需要了解這個？
因為在那個時候，分工會越來越細，pm想要挑戰那種大型公司大型團隊，這個功能會有什麼樣的團隊，可能會有多少人幫你處理？
在這個過程中去多瞭解，也會比較能夠快速進入狀況，這個 service 的database 會在哪裡？如果我這個 database 做這些變動的話，那我會影響到什麼部門？
在這邊非常推薦大家學！我也要開始來研究這方面的 domain knowhow了！
📍API document
知道 API 是怎麼設計的，非常重要！client 會討論怎麼跟後端研究，把 user的data儲存起來，如何把帳號跟密碼用什麼方式？
在這邊的 client 我們是指用戶端，sever 是指伺服器，接下來會常常提到這些名詞。
我們需要了解這個過程中，是透過什麼位置傳給後端，那要怎麼驗證？那後端有了這個相對應的位置就會知道怎麼驗證，那這個共識就是 API ！
那常常 client 跟後端提到我們這邊這個需求需要這個 API，那意思就是說，後端需要想辦法提供一個管道，讓 client 可以把正確的資料傳給後端，然後後端可以在他的 sever 裡面做相對應的data處理，最後還給前端一個回答，最後就會得到相對應的反應！
之前在有看過 API Spec 的經驗，但還不曉得看得懂這份是非常重要的事情XD 原來看得懂這份文件能夠應用的層面非常廣！
👀 From 工程師的角度
📍了解工程師團隊中的成員有哪些？
當你聽到這個工程師的位置時，就會馬上了解他們的職責！至少要有 sense！
像是以一個新創的團隊：常見團隊 size 有五到八個人，有一個 web、android、ios 等等，可能會分別有一個工程師，或是再加一個後端，執行data storage 、data processing 這樣的一個服務，可能再大一些，就會有data enginer、data analysis 等等比較更多一些個人化的功能開發！
📍PM 要清楚的知道這個問題是誰的需求！！可以找誰！
當你聽到這個工程師的位置時，就會馬上了解他們的職責！至少要有 sense！
因為工程師會自己發現，當一個 PM pass 一個 issue 給他的時候，當解 bug 解個半天，卻在解完之後發現這個是要 pass 給其他人的需求，像是如果是client 的 bug 的話，如果拿給後端，就是錯亂了！！！
很難分辨的需求怎麼辦？
基本上還是有一些資訊可以判斷：
- 像是如果這個問題在 ios 的頁面有關，那我們可以去打開 android 或是 web 上面有沒有問題，但如果這個問題在各大平台都有出現的話，那可能是 return 一個 error，就比較像是後端的問題！
- 如果是按扭歪掉，或是介面上的東西就有比較像是前端的問題！
- 多平台如果都是有出現問題的話，那可能就是後端的問題了！因為都回錯誤的資料！
🔥 當工程師的時候，什麼時候會最不爽？
就是當你拿一個 bug 來的時候，
但是上面的資訊內容非常的不清楚！！！！！
真的會牙起來＾＾
工程師會希望可以把一些需求寫的清楚一些，會蠻大幅度的幫助工程師解決問題的時間唷！
🟡 產品經理最常用到的語言
📍 什麼東西是一個 commit？
工程師寫了一些程式碼，他覺得這些程式碼已經到了初步完成的階段並且可以打包起來了！
📍 什麼是一個 pr？
就是代表一個相對完整的 feature，一個新的功能要上線啦～
新的功能其實是需要多個 commit，所以一個 pr就代表多了commit，可以被完整發布上的功能！
📍 什麼是 repository？
軟體工程師都會寫很多的程式碼，會存放在安全的地方，那一個 repository 就像是一個資料夾的概念，代表你這個 project 裡面的程式碼，一個repository 就會有多個 pr。
📍 什麼是 deploy？
常常會聽到工程師說做了一個 deploy，把程式碼不僅做好了，還已經發佈到end user 的 app 端或是 server 端，就代表使用者可以使用了！
📍 什麼是 refactor？rewrite？
我們在不改變這個功能的目的的前提下，把這個裡面的細節全部換掉！
👀 從 pm 的角度聽到：
「 有人發 pr！」
「 有人 commit 新 code上去！ 」
「 我 deploy 東西上去囉！」
就是代表工程師有進度
就是恩！很好！有在推進～～～～～
但是如果聽到：
「我想要 refactor、rewrite ！」
就會覺得：「阿哭啊～哇嗚～這邊可能會花很多時間！」可能就是會想要了解到底目前的 code 是亂到什麼程度？所以可能需要詢問工程師：
為什麼我們需要 refactor？
如果我們不馬上 refactor 的話，會影響到未來的哪一些開發？
因為工程師永遠都會覺得 code 可以寫得更好，所以當 refactor 的時候，不會改變原本的功能，所以對 user 來說，其實感受不太到差異。
所以當如果需要有這個狀況的時候，可以跟工程師說，目前的產品 roadmap是什麼？找出這個時間點是不是正確的時機去做這件事情！好好討論並且站在對方立場傾聽理解～
結論
主持人說，其實這些資訊技術都是慢慢在工作中、產業中累積出來的，不需要想太多，或是一定要陷入此時此刻都要懂～
怎麼樣跟工程師透明的溝通，圓滑的跟工程師與團隊部門間溝通，不要壓死線，收集了所有資訊之後，做出恰當的選擇，然後提供給工程師，他們比較需要這個！！！
在工作中也需要學會圓融並且尊重專業，不懂就問，或是自己去查資料也行，也覺得逐漸能理解透過這些知識可以如何用到職涯中，還蠻不錯的！現在有一種豁然開朗的感覺！ya！🥳
ok！之後會在產更多關於產品經理的文章的！大家一起 gogo！
謝謝你們的閱讀
【大家大家 ~~~ 快去註冊Medium吧 !】
若想讓我的三分鐘熱度持續下去
可以「拍手」給我支持：
1. 喜歡我的文章：請給我 1~10 個拍手；
2. 有所收穫：請給我 11~20 個拍手；
3. 給我撐下去! 想繼續看接下來的文章!!：21~50 拍隨便你拍！
