如何在沒有技術背景下怎麼和 RD 討論技術可行性？
閱讀時間約 3 分鐘
這是 30 天寫作挑戰的第 26 天。今天要來回答臉書留言的提問：
如何在沒有技術背景下怎麼和 RD 討論技術可行性？
30 天寫作挑戰：連續 30 天，每天都會從 ChatGPT 、生活中的靈感或是網友提問中，選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你／妳的問題，可以問我一個跟工程師、技術產品經理、產品經理有關的問題。
為什麼想跟工程師討論技術可行性？
會起心動念想跟工程師討論技術可行性，不外乎是因為：
- 有個功能想要實作在產品中，但不確定要花多少時間。
- 在時間壓力下想要完成某件事情，不確定有沒有辦法做到。
- 看到可能的市場機會，想發展公司的第二曲線，但不知道要投入多少資源。
- 純粹很好奇某項技術，想跟工程師交流討論。
我覺得不管是哪一種，作為開啟討論的動機都是可以的，但千萬要記得在《怎麼和團隊中的 RD 有效溝通？》有稍微提到的：「如果只是單純要讓工程師聽你／妳的，那並不叫溝通」。
要怎麼開啟技術可行性的討論？
先說，我不能算是「沒有技術背景」的人，我能夠分享的經驗是：當我不熟悉某項技術時，是怎麼跟熟悉技術的工程師溝通的。
最好用的方式，當然就是開誠布公地說想要討論技術（或可行性），並且表明原因為何。可以參考《金字塔原理》的表達方式，讓對話可以在一開始就聚焦在想解決的問題（也就是技術可行性）上。
討論過程中，工程師如果講出專業術語，可以看情況發問，或是先記錄下來，等對話告一段落再詢問或是自己查找研究（當然看不懂的話還是要問啦）。
要記得，這段對話的目的是想要透過技術解決某項問題，因此在討論的過程中，確認每個技術它扮演的角色、解決什麼樣的問題、為什麼我們需要它、有沒有替代方案……等等的問題，都可以視討論時間判斷能不能夠釐清。
要怎麼判斷是工程師不想做，還是真的做不了？
倘若是霹哩啪拉抱怨式的回應，那顯然就是不想做。破解法就是追問原因、了解困難點在於哪裡，如果工程師避重就輕地回答，就抱著打破沙鍋問到底，想幫工程師找資源解決困難點的精神來了解，並且在能夠幫助的時候，真的提供適時的幫助。
如果是真的做不了，那也應該請工程師解釋原因，並且最好在工程師解釋完畢後，用自己的話覆述一次，確保雙方對於目前遇到的困難點的認知是一致的。
小心誤區
跟工程師討論會感覺受挫的工作者中，常有的想法是：
「是不是只要我學會技術，就可以跟工程師溝通了？」
答案是肯定也是否定。肯定的是：越了解技術，就越不容易被工程師唬弄，也會對於目前產品可行性邊界有更明確的意識，自然就不容易有受挫感；否定的是：那你／妳原本的工作職能要用什麼時間來精進？你／妳是想要轉職成工程師嗎？
對於技術的了解越深當然越好，但是要了解多深，應該是以「了解該項技術能夠解決什麼問題」作為標準，如果真的有興趣再往下鑽研，最起碼知道可以怎麼使用這項技術，那就已經足夠了。
小結
每個技術都是為了解決特定問題而存在的，可能是解決執行效率、可能是串連起兩個不同的產品、可能是加快開發速度……。如同前面所提，對技術較不熟悉的工作者，如果不是想要以工程師為職志，那了解某項技術可以怎麼使用、某項技術可以和不可以做到什麼事情，就已經可以應付大多數需要跟工程師討論的情況了。
希望各位讀者在看完這篇文章之後，能夠對於和工程師討論技術可行性，有多了一點自信和把握。
今日寫作觀察
今天的題目回答起來有點拾人牙慧，畢竟這個情境我多數是回答的角色，因此只能用我自己跟其他工程師討論時的經驗，以及我認為帶著什麼樣的意識來討論技術可行性就能說是準備充分。
一連兩天，雖然是臉友的提問，但每篇的提問回答起來都有些挑戰，除了讓自己換位思考以外，也是趁機幫腦袋中的想法梳理清楚。也就不自覺寫了超量的內容。
為什麼會看到廣告
20會員
32內容數
我是 Larry，《下班後的產品工程師》是我在下班之餘分享我對網路產業的工程師、產品經理相關職能的想法和心得，也會分享一些自己突發奇想的產品、商業問題。希望文章內容能帶給你／妳收穫。對了，如果很久沒有更新，一定不是因為我還沒下班。
留言0
查看全部
本篇參與的主題活動
從開始經營方格子到現在已經十個月了。說實話，這是從我淡出巴哈姆特四年後，再次有意識的經營作品。
雖然從事小說創作，我卻是一個只要講述自己的情感就會有些嘴笨的人，心中有太多太多感受，很難一次表達出來，只能再次說，非常謝謝大家的支持，沒有你們，我走不到現在。
今年是很特別的一年，我的沙龍
虛構故事，我們得以暫時忘記活著的殘酷。賣火柴的小女孩燃盡自己的生命，讓我們在死亡陰影中感受到溫暖。未來無非是死亡的延伸，現實並不比童話更仁慈，但在故事中，我們看見了比真實更真實的光芒。故事不是真相，卻教我們如何面對真相。或許，我們每個人都是寫著自己故事的小女孩，藉由夢境短暫取暖，直到生命的火光熄滅。
本篇文章介紹了麗薩·克龍的著作《你能寫出好故事》，她是一位知名的故事教練，透過腦科學與心理學的研究，揭示了成功故事的要素與寫作方法。文章詳述了吸引讀者的故事要素，包括情節、人物、挑戰和變化等，並強調了突出焦點及製造衝突的重要性，以及如何高效構建引人入勝的故事。它是每位寫作者不可或缺的創作指南。
回想起來，五年前剛剛使用方格子寫教學心得時，往往想到什麼點子寫什麼、遇到什麼教學狀況寫什麼……毫無組織架構可言。然而，隨著越寫越多，這些文章竟然漸漸在我眼前相連成幾條清晰的脈胳，每一條脈胳都是一個主題，每一、兩個主題似乎都有寫成一本書的價值。
同樣是表達「某件事的原因」，Because、As、Since 和 For 這四個詞看似相似，實際上各有不同的常用情境和細微差異！
許多學生常在練習英文寫作中問我：「這四個詞到底該怎麼選？」、「哪種情況適合用哪一個『因為』？」為了一次解開這個疑惑，我整理了一篇關於這些「因爲」的特性與常見用法！
從開始經營方格子到現在已經十個月了。說實話，這是從我淡出巴哈姆特四年後，再次有意識的經營作品。
雖然從事小說創作，我卻是一個只要講述自己的情感就會有些嘴笨的人，心中有太多太多感受，很難一次表達出來，只能再次說，非常謝謝大家的支持，沒有你們，我走不到現在。
今年是很特別的一年，我的沙龍
虛構故事，我們得以暫時忘記活著的殘酷。賣火柴的小女孩燃盡自己的生命，讓我們在死亡陰影中感受到溫暖。未來無非是死亡的延伸，現實並不比童話更仁慈，但在故事中，我們看見了比真實更真實的光芒。故事不是真相，卻教我們如何面對真相。或許，我們每個人都是寫著自己故事的小女孩，藉由夢境短暫取暖，直到生命的火光熄滅。
本篇文章介紹了麗薩·克龍的著作《你能寫出好故事》，她是一位知名的故事教練，透過腦科學與心理學的研究，揭示了成功故事的要素與寫作方法。文章詳述了吸引讀者的故事要素，包括情節、人物、挑戰和變化等，並強調了突出焦點及製造衝突的重要性，以及如何高效構建引人入勝的故事。它是每位寫作者不可或缺的創作指南。
回想起來，五年前剛剛使用方格子寫教學心得時，往往想到什麼點子寫什麼、遇到什麼教學狀況寫什麼……毫無組織架構可言。然而，隨著越寫越多，這些文章竟然漸漸在我眼前相連成幾條清晰的脈胳，每一條脈胳都是一個主題，每一、兩個主題似乎都有寫成一本書的價值。
同樣是表達「某件事的原因」，Because、As、Since 和 For 這四個詞看似相似，實際上各有不同的常用情境和細微差異！
許多學生常在練習英文寫作中問我：「這四個詞到底該怎麼選？」、「哪種情況適合用哪一個『因為』？」為了一次解開這個疑惑，我整理了一篇關於這些「因爲」的特性與常見用法！
你可能也想看
Google News 追蹤
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
工程師希望能釐清任務的輕重緩急，其中那些「看起來不錯，但目前重要性沒那麼高」的任務，就叫做 nice-to-have...
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
在職場中，理想狀態與實際資源常常存在一定差距，如何在技術追求與商業考量之間平衡？
透過專案管理手法中的三個變項，在滿足客戶需求和保持技術創新之間找到一個平衡點。
你知道「技術債」是什麼嗎？忽略技術債可能會影響一家公司的專案進行或技術營運，這主題想寫很久一直被我放在草稿清單，今天來談談技術債。
在《為什麼這樣工作會快、準、好》一書中，作者Charles Duhigg介紹了「工程設計流程（engineering design process）」決策法，這是一套要求人們在解決問題的過程中，需要根據以下幾個步驟：明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在選大學校系，甚至是選擇職業的時候，大家通常都會關注產業前景跟工作報酬，但卻忽略了最重要的一點，你的熱情在何處？如果沒有熱情，連持續學習該領域都顯得困難，又要怎麼做到在產業中競爭呢？不是別人做的工作看上去好就是好，自己過得好與不好只有自己知道，也無須和他人比較。
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
工程師希望能釐清任務的輕重緩急，其中那些「看起來不錯，但目前重要性沒那麼高」的任務，就叫做 nice-to-have...
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
在職場中，理想狀態與實際資源常常存在一定差距，如何在技術追求與商業考量之間平衡？
透過專案管理手法中的三個變項，在滿足客戶需求和保持技術創新之間找到一個平衡點。
你知道「技術債」是什麼嗎？忽略技術債可能會影響一家公司的專案進行或技術營運，這主題想寫很久一直被我放在草稿清單，今天來談談技術債。
在《為什麼這樣工作會快、準、好》一書中，作者Charles Duhigg介紹了「工程設計流程（engineering design process）」決策法，這是一套要求人們在解決問題的過程中，需要根據以下幾個步驟：明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在選大學校系，甚至是選擇職業的時候，大家通常都會關注產業前景跟工作報酬，但卻忽略了最重要的一點，你的熱情在何處？如果沒有熱情，連持續學習該領域都顯得困難，又要怎麼做到在產業中競爭呢？不是別人做的工作看上去好就是好，自己過得好與不好只有自己知道，也無須和他人比較。