前言說明

身為前端工程師，這篇文章想分享在職場是如何與非工程部門（例如 產品部門、設計部門 等）進行有效溝通。

隨著工作經驗的累積，職場上的不順心往往不是工作內容不會做，而是來自與人協作上的磨合。例如 在合作的過程中，可能會遇到想法落差或時程評估不合理的情況，進而造成後續進度混亂 （隕石的由來🌚）。

因此想分享一些我在實際場合使用過，覺得蠻好用的方法，當然效果因人而異😅，希望能讓大家在跨部門合作溝通時能更加順利。

實務上用過的好方法 ①：搶先一步制定需求

在參與討論需求時，PM 可能會拋出一個方向，但細節還沒完全定下來。
這個時候如果工程師能結合現有系統架構，主動提出一個「相對好擴展、維護成本低」的解決方案，PM 或 SA 很可能就會沿著這個建議去調整需求。畢竟站在公司的角度，大家都希望能用最高效率的方式完成項目。

以下舉例來說：
客戶提到：「想做一個滿額贈功能，結帳時自動贈送小禮物，希望吸引客戶消費。」
若直接開發全新的「滿額贈功能」，就需要重新設計前端介面、後端邏輯與 API，開發週期會拖長，也會增加一個全新功能的測試範圍。
但如果工程師就現有功能先提出：「其實可以沿用現有的「優惠券／折扣邏輯」，只要把小禮物設定成其中一種類別的優惠券兌換，並在達成條件時自動加入購物車。」以這樣的做法來說，是新增判斷在現有功能上，開發與測試的範圍可以縮小許多。

❗ 當然，實際上還是要依需求情境判斷。若強行塞進現有功能反而影響既有邏輯 ⚠，或需求本身與現有架構差異過大，那就應該依「開發新的功能」的方向去做思考。

實務上用過的好方法 ②：關於時程太趕

假設客戶臨時要求：「你們可以幫我從倉儲管理系統（WMS）撈產品資訊也記錄到網站上嗎？他們說有辦法可以讓你們撈資料到網站。 」
對沒有技術背景的 PM 來說，可能會覺得：「就現有功能加幾個產品欄位嘛，不就是打一支 API 嗎？」因此很自然地給出一個非常短的開發時程。

但實際上，工程師可能會遇到這些情況：

• 串接第三方 API 時，有時需要整合多筆資訊，若只請求一支 API，有可能缺少資料庫中禁止空值的欄位（例如 product_stock_quantity）。
• 又或者，有些欄位並非單支 API 就能取得，而是需要透過呼叫其他支 API，才能湊齊所有需要的資訊。
• 就算資料拿到了，API回傳回來的資料格式（例如 SOAP、XML），與現有系統不同或資料庫欄位型別不符，需要額外處理。

你很難直接告訴沒有技術背景的PM說：
「主要產品那隻 API 回傳的 payload 缺少現有資料庫的 NOT NULL 欄位 product_stock_quantity，導致無法直接 insert 資料；
而且 product_stock_quantity 欄位不是單純透過打一支 request 就能拿到，必須先透過多個 endpoint 呼叫進行資料聚合，才能湊齊完整資訊；最後，即便 response 成功回傳，response body 的結構或資料型別（data type）也與現有資料庫不相容，還需要額外做資料轉換（Type Conversion）與資料驗證（Data Validation）才能正確寫入。」

有時候，當我們直接把這些技術層面的細節告訴PM，對方可能只會覺得這是工程師要處理的事情吧？ 😯 所以回答「好哦！聽起來很複雜，加油～」──完全沒意識到開發時程過短才是真正的問題（只覺得聽了一段外星語👽💫）。

這時候，可以用貼近現實的情境舉例來說明，根據上面那段話舉三個情境來說：

• 情境 1： 假設要兌換限定版海報，需要先集齊「太」、「棒」、「了」這一組貼紙。
  ✅ 貼紙的比喻是缺少的資料庫禁止空值 product_stock_quantity 欄位。

• 情境 2： 一種飲料只能拿到其中一個字的貼紙，要集滿三張就得分別去不同店家購買不同店家限定款飲料。
  ✅ 到處跑收集貼紙的比喻是需要透過多個 endpoint 呼叫進行資料聚合。

• 情境 3： 貼紙集齊後，還得按照正確順序貼在集點卡上，才能成功兌換海報。
  ✅ 貼集點卡的順序的比喻就是 response body 或 data type 必須與資料庫欄位相容（格式轉換 + 驗證）。

所以，看似只是「兌換一張海報」一件事，但背後的前置作業、東奔西跑的流程，才是真正花時間的地方。依現實舉例等同於這樣麻煩，當我們用這樣的方式解釋時，PM 較能理解為什麼時程不能壓得太緊，也更能同理工程師的難處。畢竟我們主要目的不是要告訴 PM 程式該怎麼寫，而是要讓他們明白：我們需要合理的時間，才能把事情做好。

如果我們能常用這種貼近日常的比喻來說明，讓 PM 聽得懂就會覺得我們是 「會說人話的工程師」，溝通起來更順暢。這樣合作下來往後可能會有機會，讓他們主動來找我們討論，形成更好的合作循環，達成雙贏的局面 🙌。

實務上用過的好方法 ③：提早釐清異常狀態

在前面文章有提到，設計稿有時不包含正常狀態以外的情境，如果有興趣了解更多關於設計與開發差在哪，歡迎閱讀第十篇。設計稿通常只給「正常流程」的畫面，但實際開發會遇到很多「非預期情境」。
如果在開發前能主動提醒設計師：「這邊如果資料為空或權限不足要顯示什麼呢？」就能避免後期補設計或臨時改需求，又或者是我們自行排版但設計師覺得不夠美觀 😂。

例如 在做「會員列表」功能時，設計稿只提供「會員列表有資料」的畫面。
這時候工程師可以提問：「那如果訪問列表沒有權限呢？是否要顯示「無權限查看」提示字就好，還是需要給按鈕引導回哪一頁？」
這樣設計師會更清楚目前功能 API 會回傳什麼，遇到什麼額外狀況有意識去補齊這些設計，避免工程師卡住或顯示結果不符合預期。

實務上用過的好方法 ④：用「流程圖或情境化描述」幫助對齊需求

有時候在前期文字討論需求，PM 腦中想的畫面與流程和工程師實際理解的邏輯不一樣時，會導致最後雙方落差很大。
這時候我們能主動用一張 使用者流程圖 (Flowchart) 把需求可視化，能大幅減少誤解。

舉個網頁功能：
PM 說：「購物車要新增折扣代碼功能。」

這時候我們可以先畫一個功能流程：

再補一句：「這邊的折扣代碼是只能用一次？還是可以和其他優惠券併用呢？」

這樣不只讓 PM 馬上有畫面，也能把容易遺漏的邊界條件提早釐清，避免到開發後期才發現落差雙方少來回，合作體驗更順暢。

結語

跨部門合作最大的挑戰，不在於誰懂不懂技術，而在於彼此能不能「聽懂對方在說什麼」。用比喻解釋時程、釐清異常情境，還是透過流程圖幫助溝通，這些方法的核心都是把對對方而言抽象的事物，轉化成對方能理解的語言。

當設計師、PM 和工程師都能在同一個頻率上交流，溝通就不再是雞同鴨講，而是能真正彼此協作，畢竟我們的共同目標從來就不是「誰對誰錯」，而是讓產品以最高效率開發完成，並讓客戶覺得好用。

參考資料與延伸閱讀

⑴ 功能流程使用工具來源：FigJam