產品經理一定要懂技術嗎？
? 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！
謝謝你們的閱讀
瀏覽 2,299 次
