🌼體貼別人的心情是什麼意思
最近有個新朋友和我聊到他以前遭遇的悲慘經驗。
聊完之後，回家途中遇到工程師同事，便稍稍帶到方才聽到的八點檔般誇張經驗。
工程師聽了我的簡單描述，便對我說：你怎麼知道他說的是真的？也許…
很多時候，追求真實這件事情很重要。但是在傾聽別人的遭遇時，卻是一點也不重要。
老實說，無論對方曾經發生過什麼事，都和我們無關；是真是假，我們不需要、也沒辦法去確認。
如果真的想要確認這件事情，那也必須要搜集其他來源的證據，而不會從單一的來源做判斷。
重要的是我們眼前這個人，他的心情與感受是什麼，或是他是否帶有特殊目的。
目的識別可以透過當事人能否得利來評估，也就是這麼做對他有什麼好處。
如果沒什麼特別的好處，或是他的目的對我們來說並非壞事（例如取得我們的信任），那麼也不必計較太多了。
所以…除非對方帶有目的，否則真實性如何根本不重要。
沒有一個人的經驗與回憶是100%真實的－－人類大腦的記憶原本就是如此。
但是了解對方的感受與情緒，就能明白為什麼對方的行動與判斷是如此；對方也會因為你的體貼與同理，更願意對你敞開心房。
從「理解對方」的角度來看，真實性不重要，對方看到什麼才重要。
我們自以為真實的風景，不是對方看到的模樣；既然看到的風景不同，又怎麼能期待透過它來理解對方呢？
#pm日記 #批判性思考
工程師pm意思 在 [討論] 產品經理(PM)需要懂技術嗎？ - 看板Soft_Job 的美食出口停車場
月經文來著。
我兩年前曾經在板上問過這個問題，
偶爾也會有人站內信找我討論，
所以就寫了一篇文章分享自己的想法、跟大家交流交流～～～
Medium 有圖有參考連結好讀版：
https://pse.is/3hk2n9
懂技術當然比不懂技術好，上知天文下知地理當然比什麼都不懂好。而會有人不斷討論這個問題的原因大概分為兩個層面：
1. 想要轉職，不知道技術知識到什麼程度才能找到產品經理的工作機會
2. 已在職中，身為 PM 不確定自己技術知識夠不夠，還能朝哪些方面加強
將問題拆解後，我們背後真正想問的是：
- 若要成為一個及格的產品經理，對技術的了解要有多少？
- 產品經理有那麼多種技能要點，技術在這所有技能中有多重要？
- 為了轉職/為了職涯發展/為了讓工作與溝通更順暢，我應該優先補足技術知識、還是精進其他技能？
【文章目錄】
- 產品經理什麼時候會用到技術知識？
- 所謂的「懂技術」是什麼意思？溝通技術的不同層次
- 怎樣才算是夠懂技術了？
- 如何跟工程師合作？
- 結語：產品經理技能樹
這邊先長話短說、下個小結，一般來說：
PM 對技術的理解，要足夠跟工程師溝通、安排資源、解決問題。
也跟工程師們喊話下：
你的 PM 亂答應需求、亂訂時程不一定是因為他不懂技術，
有可能只是因為他不懂得溝通與拒絕的藝術。
▍產品經理什麼時候會用到技術知識？
目標：加速產品開發、確保團隊在往對的方向前進
有技術知識的 PM 能夠：
- 了解產品的核心技術競爭力，對於在做的產品有正確的認識
- 分辨市場上其他競品強不強，是強在技術還是其他地方
- 在做產品決策、優先級排序、規劃與協調資源時更順利
- 跟工程師與技術單位溝通時更順暢
擁有技術知識，讓 PM 在以下工作階段更順利
- 研究問題、討論解法、優先級排序（需求方、使用者、客戶）
- 資源安排＆實作（設計師、工程師）
- 處理緊急 issues（整個團隊）
寫程式不是 PM 的工作！
有些人會有個迷思，好像 PM 必須要會寫程式才能做好自己的工作。
問了一些工程師朋友和同事，PM 的技術能力要到什麼程度？他們的答案是「可以跟工程師溝通就 OK」「了解技術限制、複雜度、成本之類的就很棒了」「不會寫程式沒什麼關係啊」「寫程式是我們的工作吧！」
如果你覺得學會寫程式就能成為一個好的產品經理，那我會說你只是在偷懶而已。
擁有技術知識、懂產品背後的邏輯，並不代表你自己需要會寫程式。會寫程式當然很好，能更懂行話、也對跟工程師溝通有幫助，但與其自己實際練習寫程式，我會寧願花時間在其他地方。
▍懂技術是什麼意思？懂技術的不同層次
PM 不用知道如何寫程式，但要知道產品背後的邏輯與技術限制。
技術知識要能輸出成為「理解能力」與「溝通能力」兩個方面才有用：聽得懂是第一步，能夠參與討論是第二步，有能力做出合理的判斷是終極目標。
我將技術知識含量多寡以及能達到的成果分成以下幾種類別。
【高】技術知識作為決策的一環
- 跟需求方討論時，可以判斷做不做得到、難易度如何、可能遇到的問題
- 排序產品與問題優先級時，能精準的將技術複雜度作為一個維度來參考
- 能夠將核心技術轉化成產品的核心競爭力之一
- 能夠從頭參與新產品、新服務的討論，包含選擇什麼技術來實作、資料庫架構的欄位與內容、是否要找第三方的服務來串接
- 了解技術團隊使用的外部服務（AWS、Sentry、CircleCI）的成本
- 了解什麼是正確的時機 refactor、解決技術債（Tech Debt）、Legacy Code 的問題
【中】良好的溝通媒介
- 接收需求時，能清楚釐清問題內容，以利後續跟技術團隊討論實作可行性跟時程
- 接收需求時，能判斷是否跟目前邏輯相違背、有沒有 dependencies 等
- 接收需求時，能描繪出改動的範圍大小，並向需求方建立正確的期待
- 討論產品解法時，能顧慮到技術限制、技術可行性
- 與技術團隊討論時，知道該問哪些問題、聽得懂對方的解釋、參與討論
- 遇到 issues 時，知道怎麼回報、怎麼重現 bug 並提出可能的原因
- 若需要跟第三方服務或客戶串接，要看得懂技術文件，或至少知道哪一部分需要跟技術團隊確認
- 在寫產品文件時，能將部分技術規格也納入其中，並搭配工程師的 Techical Spec
【初】基礎中的基礎
- 了解最基本的網路產品如何運作
- Daily Standup 時聽得懂工程師說明他在做的事、遇到的困難
- 遇到問題時不會問錯人！前端、後端、Data Team 的工作範圍都不同；就算都是後端，他們負責跟維護的部分可能也不同，要能判斷這塊需求或問題要問誰才對
- 能夠和工程師一起處理 issues & bugs
【零分】能力不足
- 聽不懂工程師說的技術名詞卻也不會問
- 不懂得釐清需求方的問題，要來來回回問工程師很多次
- 工程師回覆之後也無法好好解釋給需求方，讓需求方了解技術限制或 bug 發生的原因
- 規劃產品時沒考慮到技術問題，也沒諮詢過技術團隊
【哎呀扣分】懂技術不是讓你用來不尊重專業意見的
最忌諱的就是 PM 覺得自己懂點技術，所以就不尊重工程師的專業意見，因此自己壓時程、亂答應、質疑工程師的判斷。
有時候一個乍看很簡單的東西，可能會因為自家產品背後混亂的 codebase 而變得難以實作，或是需要先進行 refactoring 才有辦法開始開發。
每一間公司、每一個產品都會有不一樣的狀況，因此不要輕視彼此的專業、不要幫對方做決定，大家在能力上應該是互補的關係，而懂對方的語言的目的只是為了讓內部溝通更順暢。
另一種狀況是 PM 太過關注技術複雜性。我曾經因為覺得某個東西技術上應該很難實作，所以就自作主張推掉需求，但後來才發現其實工程師能夠想到其他很好的技術解法，這就是自以為懂技術的糟糕心態。
應該說，每個人各司其職、為自己的位置與角色發聲才是最好的平衡。我不應該過度幫工程師擔心技術的事情，而是應該帶著我身為 PM 的想法與立場去溝通與搜集專業意見，同時設定好雙方的期待。
PM 很常需要在中間當協調人或決策者，勢必要能夠聽懂別人說的話、了解別人在意的事情，但不是取代其他專業同事應該要做的事。
【翻譯蒟蒻】除了跟行內的人溝通，還要能夠解釋給外行人聽
當老闆、業務、客服問 PM 為什麼這個做不到、為什麼會發生這些 issues，你能不能用很簡單的邏輯與案例解釋給他聽？
當一個產品需求會被拒絕，有時候是需求本身不合理、有時候是設計上的難題、有時候是技術上的限制，PM 在接收需求的時候心中就要做簡單的分析，知道這些問題該問誰、問完之後有哪些因素影響團隊做決定（做或不做、優先級如何），跟產品團隊討論完後再回去找需求方溝通。
遇到 issues 的時候也一樣，PM 就像一台翻譯機，客服回報問題，PM 整理好問題影響範圍、重現方式並翻譯成技術語言給工程師聽；工程師找到問題後告訴 PM 背後的根本原因和可能的解決方案、PM 再翻譯回去給客服聽，討論該如何跟客戶或使用者溝通。
最後是關於一些常見的技術問題，團隊應該要建立起共同的知識資料庫，避免一樣的問答不斷重複發生。PM 總是幫忙工程師回答問題也不是辦法，文件化並分享知識給同事才是最有效率的作法。
▍怎樣才算是夠懂技術了？
標準答案：看公司！看團隊！
1. 最基本的技術知識
延續上面提到的技術與溝通等級，對新手 PM 來說，有【初】基礎中的基礎就不錯了，其中的了解網路產品如何運作包含理解以下名詞：
Backend、Frontend
Server、Client、Cloud、DNS
Database、SQL
FTP、API
Cache、Cookies、Session
Container、Docker、GitHub、CI/CD、Deployment
會使用 Browser DevTools 並大概知道每個區塊的作用
2. 技能對應到工作需求
有些公司裡面會有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色，在這些團隊內他們會吃下很多技術相關的工作，一般 PM 對於技術知識的理解與溝通可以透過他們來協助。
但另外一些公司則可能會希望 PM 擁有一定的技術知識與背景，所以真正的問題是，我需要多少的技術知識，才能支撐我做好在這間公司、這個產品的產品工作。在面試前可以先：
- 了解這間公司的技術架構，在使用的服務等等
- 找該公司的工程師或其他職位的 JD 來看，是否懂裡面所有的專有名詞
- 搜尋該公司的 PM 面試題目，看看是否有技術相關題目
Ref: IGotAnOffer — Product manager interview questions (the ultimate list)
如果面試的時候有跟工程師對到，在問問題階段也可以反問他們對於 PM 的技術能力的要求與期待是什麼。如果你想進去的產業跟公司的產品技術含量高，技術背景就會是標準配備。
而每間公司、每個產品的程式架構都不一樣，使用的服務、背後的邏輯也不盡相同，到了新的團隊或換新產品的時候都需要重新學習跟理解。
在《產品經理就職手冊：抓住四大學習重點，讓你快速進入狀況》中有提到，剛入職時可以請工程師帶著 PM 了解目前產品的技術架構和 Tech Roadmap。
若產品經理了解技術架構與限制，也會多少對判斷 Dependency 與了解可能的技術坑有幫助。針對這點可以請工程師跟你說明目前是使用什麼 Tech stack、前後端如何互相呼叫、有哪些主要的 API / Service / Database，以及我們是否跟其他團隊在技術層面會有高度合作關係等等。
3. 基本的撈資料、分析能力
一樣根據工作所需，有些基本的撈資料、分析是 PM 會自己做的：
- 用 SQL 撈資料（知道資料庫裡有哪些欄位、怎麼存資料、關聯性為何）
- 用 Crawler 爬資料
- 埋點、分析 Events、A/B Testing
▍如何跟工程師合作？
有的時候技術問題很複雜、或是程式過去是很多人共同在維護，技術知識學海無涯，工程師本人也不一定隨時都知道技術問題的答案，可能會需要先花時間去看一下、研究一下才能跟你討論。因此問問題與合作時先做功課、虛心請教、給對方足夠的時間研究也是很重要的。
執行細節歡迎參考我們過去的文章：
【PM夥伴攻略】如何跟工程師合作？
【PM夥伴攻略】番外篇：工程師雷區幹話大全
【PM夥伴攻略】如何與工程主管 Engineer Manager 合作？
▍結語：產品經理技能樹
在 《從入門到卓越，產品經理技能檢核表與職涯發展路徑》中提到的「Technical Sense — 對技術理解的能力」主要集中在 Senior PM 的職涯階段。不過在這個產業工作，多瞭解點技術相關知識總還是非常有幫助的。
做產品就是在商業價值、使用者體驗、技術之間取得平衡，三種技能一定都會點到，但每個 PM 的興趣和專長都不同，長遠的職涯發展朝向不同方向，相對應所需的知識和技能就會有所不同。
最重要的是，PM 跟商業團隊、技術團隊、設計團隊其實合起來是一個全方位的產品團隊，大家做好份內的專業外，自己的能力能夠跟團隊成員互補、並持續進行知識交流是很重要的，大家要一起成長，才會變成更棒的產品團隊！
以上，歡迎 PM、工程師們一起來交流，
擁有什麼樣的技術知識才足夠成為及格的產品經理。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.162.152.200 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1625481555.A.131.html
※ 編輯: annedoo (1.162.152.200 臺灣), 07/05/2021 18:40:36
※ 編輯: annedoo (1.162.152.200 臺灣), 07/05/2021 18:42:00
... <看更多>