工程師要怎麼和 PM 解釋技術？
閱讀時間約 3 分鐘
這是 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 也是善待自己的一種解法。
今日寫作觀察
今天的難點在於想到題材，但想到可以「反轉視角」來看待同一件事情，尤其是以工程師的視角來解釋事情又很少見，因此寫起來就覺得特別有趣。
為什麼會看到廣告
20會員
32內容數
我是 Larry，《下班後的產品工程師》是我在下班之餘分享我對網路產業的工程師、產品經理相關職能的想法和心得，也會分享一些自己突發奇想的產品、商業問題。希望文章內容能帶給你／妳收穫。對了，如果很久沒有更新，一定不是因為我還沒下班。
留言0
查看全部
本篇參與的主題活動
從開始經營方格子到現在已經十個月了。說實話，這是從我淡出巴哈姆特四年後，再次有意識的經營作品。
雖然從事小說創作，我卻是一個只要講述自己的情感就會有些嘴笨的人，心中有太多太多感受，很難一次表達出來，只能再次說，非常謝謝大家的支持，沒有你們，我走不到現在。
今年是很特別的一年，我的沙龍
虛構故事，我們得以暫時忘記活著的殘酷。賣火柴的小女孩燃盡自己的生命，讓我們在死亡陰影中感受到溫暖。未來無非是死亡的延伸，現實並不比童話更仁慈，但在故事中，我們看見了比真實更真實的光芒。故事不是真相，卻教我們如何面對真相。或許，我們每個人都是寫著自己故事的小女孩，藉由夢境短暫取暖，直到生命的火光熄滅。
本篇文章介紹了麗薩·克龍的著作《你能寫出好故事》，她是一位知名的故事教練，透過腦科學與心理學的研究，揭示了成功故事的要素與寫作方法。文章詳述了吸引讀者的故事要素，包括情節、人物、挑戰和變化等，並強調了突出焦點及製造衝突的重要性，以及如何高效構建引人入勝的故事。它是每位寫作者不可或缺的創作指南。
回想起來，五年前剛剛使用方格子寫教學心得時，往往想到什麼點子寫什麼、遇到什麼教學狀況寫什麼……毫無組織架構可言。然而，隨著越寫越多，這些文章竟然漸漸在我眼前相連成幾條清晰的脈胳，每一條脈胳都是一個主題，每一、兩個主題似乎都有寫成一本書的價值。
同樣是表達「某件事的原因」，Because、As、Since 和 For 這四個詞看似相似，實際上各有不同的常用情境和細微差異！
許多學生常在練習英文寫作中問我：「這四個詞到底該怎麼選？」、「哪種情況適合用哪一個『因為』？」為了一次解開這個疑惑，我整理了一篇關於這些「因爲」的特性與常見用法！
從開始經營方格子到現在已經十個月了。說實話，這是從我淡出巴哈姆特四年後，再次有意識的經營作品。
雖然從事小說創作，我卻是一個只要講述自己的情感就會有些嘴笨的人，心中有太多太多感受，很難一次表達出來，只能再次說，非常謝謝大家的支持，沒有你們，我走不到現在。
今年是很特別的一年，我的沙龍
虛構故事，我們得以暫時忘記活著的殘酷。賣火柴的小女孩燃盡自己的生命，讓我們在死亡陰影中感受到溫暖。未來無非是死亡的延伸，現實並不比童話更仁慈，但在故事中，我們看見了比真實更真實的光芒。故事不是真相，卻教我們如何面對真相。或許，我們每個人都是寫著自己故事的小女孩，藉由夢境短暫取暖，直到生命的火光熄滅。
本篇文章介紹了麗薩·克龍的著作《你能寫出好故事》，她是一位知名的故事教練，透過腦科學與心理學的研究，揭示了成功故事的要素與寫作方法。文章詳述了吸引讀者的故事要素，包括情節、人物、挑戰和變化等，並強調了突出焦點及製造衝突的重要性，以及如何高效構建引人入勝的故事。它是每位寫作者不可或缺的創作指南。
回想起來，五年前剛剛使用方格子寫教學心得時，往往想到什麼點子寫什麼、遇到什麼教學狀況寫什麼……毫無組織架構可言。然而，隨著越寫越多，這些文章竟然漸漸在我眼前相連成幾條清晰的脈胳，每一條脈胳都是一個主題，每一、兩個主題似乎都有寫成一本書的價值。
同樣是表達「某件事的原因」，Because、As、Since 和 For 這四個詞看似相似，實際上各有不同的常用情境和細微差異！
許多學生常在練習英文寫作中問我：「這四個詞到底該怎麼選？」、「哪種情況適合用哪一個『因為』？」為了一次解開這個疑惑，我整理了一篇關於這些「因爲」的特性與常見用法！
你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
工程師希望能釐清任務的輕重緩急，其中那些「看起來不錯，但目前重要性沒那麼高」的任務，就叫做 nice-to-have...
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
深入探討土木工程師的一天，包括現場視察、設計討論、技術研究和自我提升，我葉瀚林希望可以讓讀者更了解這個職業的工作內容和挑戰。希望能夠激勵更多有志於投身這個行業的年輕人。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
在職場中，理想狀態與實際資源常常存在一定差距，如何在技術追求與商業考量之間平衡？
透過專案管理手法中的三個變項，在滿足客戶需求和保持技術創新之間找到一個平衡點。
從母語使用者到專利工程師，這篇文章分享了作者從事新工作的體驗和感受。包括工作內容、困難和情緒波動。作者深入探討了作為專利工程師可能遇到的挑戰，並呈現對工作的認真與努力。
你知道「技術債」是什麼嗎？忽略技術債可能會影響一家公司的專案進行或技術營運，這主題想寫很久一直被我放在草稿清單，今天來談談技術債。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
工程師希望能釐清任務的輕重緩急，其中那些「看起來不錯，但目前重要性沒那麼高」的任務，就叫做 nice-to-have...
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
深入探討土木工程師的一天，包括現場視察、設計討論、技術研究和自我提升，我葉瀚林希望可以讓讀者更了解這個職業的工作內容和挑戰。希望能夠激勵更多有志於投身這個行業的年輕人。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
在職場中，理想狀態與實際資源常常存在一定差距，如何在技術追求與商業考量之間平衡？
透過專案管理手法中的三個變項，在滿足客戶需求和保持技術創新之間找到一個平衡點。
從母語使用者到專利工程師，這篇文章分享了作者從事新工作的體驗和感受。包括工作內容、困難和情緒波動。作者深入探討了作為專利工程師可能遇到的挑戰，並呈現對工作的認真與努力。
你知道「技術債」是什麼嗎？忽略技術債可能會影響一家公司的專案進行或技術營運，這主題想寫很久一直被我放在草稿清單，今天來談談技術債。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。