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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今日寫作觀察

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