2023-06-16|閱讀時間 ‧ 約 4 分鐘

工程師要怎麼和 PM 解釋技術？

這是 30 天寫作挑戰的第 29 天。今天要來分享的是：

工程師要怎麼和 PM 解釋技術？

30 天寫作挑戰：連續 30 天，每天都會從 ChatGPT 、生活中的靈感或是網友提問中，選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你／妳的問題，可以問我一個跟工程師、技術產品經理、產品經理有關的問題。

前幾天寫了一篇《如何在沒有技術背景下怎麼和 RD 討論技術可行性？》，這篇主要是想從 PM 的角度來思考，要怎麼跟工程師溝通討論，今天我們立場互換，來說說工程師要怎麼樣跟不懂技術的 PM 解釋技術。

明知是蠢問題還問的，不會是你同事。

會問蠢問題的人，絕大多數都是他／她並不知道這是個蠢問題，如果知道還問，要馬故意要馬瞧不起你／妳。但我想以工程師的聰明才智來說，一定能夠分辨是不是故意的，對吧？

不管是抱持著做善事、幫助他人的心態，還是為了讓自己可以更好把任務完成，請務必試著用對方聽得懂的語言來解釋。

也許你／妳會想：憑什麼是我花心力來解釋，而不是 PM 自己花時間理解技術。這是因為你／妳已經花了求學階段加上工作時間的投入在鑽研，PM 不可能像你／妳這麼了解技術的極限和瓶頸在哪，因此為了讓後續兩邊都好做事，由工程師釋出善意總是好事的。而且市面上這麼多難溝通的工程師，只有你／妳最能溝通，馬上就拉出不一樣的格調了。

細節不用講，但能解決什麼問題一定要說

我們能夠區分 http 跟 https 的差別、5xx 跟 4xx 的 status code 該找前端還後端、什麼是元件內的 state 什麼是同步到資料庫的 state……。但是 PM 不見得能夠理解這些實作細節，甚至並不知道怎麼將這些資訊識別出來，而強者工程師如你／妳，就是能夠知道怎麼做到這些事。

儘管細部要怎麼做到這些事情，其他工程師會很有興趣想知道，但可惜 PM 的職責並不在此，因此他們最在意的不是實作的細節，而是在意這些技術的差異是要解決什麼樣的問題：是要解決資訊安全的問題、是要分辨是網路還是伺服器出了問題、還是使用者的資料在重新整理頁面後該不該保留……。這些技術的應用解決了什麼問題，才是 PM 最為在意的。

好啦，如果真的要講細節，至少要先把結論講出來，不然 PM 也不知道細節可以有什麼幫助。

給建議的時候，至少想想兩種方案

第一種是理想情況下，可以解決問題又能夠具備可擴充性的方案；第二種是現實情況下最土炮最無腦的處理方法。但切記這兩個解法不是拿出來給 PM 選的，是來幫助自己思考「有沒有第三選項」。

我們已經很習慣用自己的系統一，不假思索就能想到前兩種方案，但系統二沒進場的話，就不見得能夠找到最適合當下的處理方式，因此要讓自己的系統二醒來開始運作，就會需要逼自己思考第三選項的可能性。

如果你／妳真的不想做……

需要先辨別一下不想做的原因是因為對產品有害、沒有挑戰性、對於技術太過陌生、不想花時間做……。

需要內部歸因一下，知道自己之所以不想做的原因為何，如果是對公司或產品有害，或是有什麼潛在的風險需要辨明（例如不熟技術），那就大方地說出來，PM 不懂技術都願意開口問了，工程師不懂全部的技術有什麼好羞恥的？

但如果是自己任性地不想做……請長大好嗎？大家都是出來工作的，不是你／妳的保姆或僕人，需要事事都順著你／妳的意思做。

希望各位工程師能夠看完今天的文章之後，不要覺得我在講幹話，而是能夠理解善待 PM 也是善待自己的一種解法。

今日寫作觀察

今天的難點在於想到題材，但想到可以「反轉視角」來看待同一件事情，尤其是以工程師的視角來解釋事情又很少見，因此寫起來就覺得特別有趣。

分享至

成為作者繼續創作的動力吧！

下班後的產品工程師

追蹤

工程師要怎麼和 PM 解釋技術？

明知是蠢問題還問的，不會是你同事。

細節不用講，但能解決什麼問題一定要說

給建議的時候，至少想想兩種方案

如果你／妳真的不想做……

今日寫作觀察

作者的相關文章

Larry Chien的沙龍的其他內容

你可能也想看

發表回應

工程師要怎麼和 PM 解釋技術？

明知是蠢問題還問的，不會是你同事。

細節不用講，但能解決什麼問題一定要說

給建議的時候，至少想想兩種方案

如果你／妳真的不想做……

今日寫作觀察

作者的相關文章

Larry Chien的沙龍 的其他內容

你可能也想看

發表回應

Larry Chien的沙龍的其他內容