下班後的產品工程師

團隊溝通、產品開發、溝通協調、團隊合作、溝通表達

下班後的產品工程師

關注

Larry

產品工程師

2023/06/16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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