今天在 Facebook 上看到一則貼文，在討論「工程師是否需要參與需求制定，需不需要理解需求？」
很多人會直覺回答：「當然要懂啊！」
但現實世界的狀況，往往沒那麼簡單。
一、懂需求，是工程師的基本素養
不論你是做前端、後端、測試，還是 DevOps，只要參與的是對使用者有價值的產品開發，就必須具備基本的需求理解能力。這不代表每位工程師都要成為需求分析師，但至少要能掌握：
- 為什麼要做這個功能？
- 它解決了什麼樣的問題？
- 使用者的真實情境是什麼？
如果工程師完全不了解需求，只是照著任務單「寫功能」，很容易出現「做了沒人用」或「看起來像是對的，其實根本錯」的情況。
二、理解需求 ≠ 負責整理需求
實務上，應該有專業角色（如產品經理或商業分析師）來負責需求的蒐集、澄清與整合。
但這不代表其他人就可以不理解需求。相反的，在分工下更需要靠機制來補足知識鴻溝。
- 小型團隊或新創公司：常常一人身兼數職，PM、前後端都可能是同一人。此時需求掌握度自然必須更高。
- 中大型組織（如台積電等規模）：一個系統往往由上百人協作，分工精細，這時候每個人能理解的範圍有限，就更需要設計一套讓資訊流通的機制。
三、不是「人人全懂」，而是「人人有機會多懂一點」
這才是真正現實中可以做到的事情。
與其追求「所有人都要全懂」，我們應該問的是：
組織有沒有設計出「讓大家能夠略懂略懂」的機會與流程？
這正是像 Large Scale Scrum（LeSS）這樣的大規模協作框架所強調的重點。例如：
- Multi-team Refinement： 多個團隊共同釐清需求，避免知識落單。
- Feature Team 而非 Component Team： 讓團隊對一整塊功能負責，而非只是某個小模組。
- 共同參與 Sprint Review 與需求範例共構（Specification by Example）： 建立跨角色的共同語言與脈絡。
這些機制不是要大家變成萬能，而是為了讓團隊成員都能擁有足以判斷、協作與提早發現問題的知識基礎。
四、好團隊靠設計創造「共知」機會
組織若缺乏以下這些設計，就會導致資訊斷裂與品質失控：
- 工程師從不參與需求釐清
- 任務直接從 Jira 派發，沒人說明背景
- 產品目標變動無人告知技術團隊
反之，當你有好的對話機會與合作流程，就能逐步補足理解的落差。以下是幾個值得實施的協作做法：
- 三明治會議（Three Amigos）： 開發、測試、產品三方一起討論需求與驗收條件
- 需求範例工作坊（Specification by Example）： 以具體案例拆解模糊需求
- 跨團隊共學時段與技術分享會： 建立共享語境
這些不是為了流程完整，而是為了降低「照做但做錯」的風險，提高「提早發現問題」的能力。
結語：不是你要全懂，而是組織要讓你懂得起來
工程師要懂需求，這句話不是命令，而是一種提醒。
懂，是每位工程師的責任；
但能不能懂，是組織設計出來的條件。
你不需要每個人都成為需求專家，
但你需要讓每個人都能理解需求背後的價值與邏輯，
這樣才能避免開發變成「交差」而非「解決問題」。
從追求「全知」到設計「共知」的過程，正是一個團隊成熟與否的分水嶺。
發表迴響