為什麼 RD 需要搞懂商業邏輯？
以前端開發者的角度來看，其實前端不懂商業邏輯也不影響功能開發，因為只要：
- PM 把 Spec 開好
- Designer 把 Mockup 弄出來
實作前再過一次功能互動，其實大部分就可以實現了（剩下技術問題），那為什麼做技術研發，要搞懂商業邏輯呢？
目錄
從產品及團隊看待技術
一個產品從概念進入到開發階段，RD 知道產品主要的核心功能、帶給使用者的價值， 這時候就會去思考如何透過自己喜愛的技術去共同開發產品，而這時候就需要去思考開發產品所需要的商業邏輯。
了解商業邏輯，才能從技術的角度想到業務層面沒想到的地方，如果不了解商業邏輯，就不知道產品到底想要做什麼功能，甚至連需求的商業邏輯都搞不清楚。
在這種情況的合作模式就是需求來了，RD 接住，然後 PM 排開發時程、開發資源。
但是 …
也許這個需求的設計不合理，你不知道～
也許這個需求有更好的解決方式，你不知道～
也許這個需求可以透過現成的技術架構、第三方套件解決，你也不知道～
都不豬到 … 只能任人宰割了
－工程師邁向攻頂之路
了解 Domain knowledge 只有好處沒壞處，一般來說 RD 的職涯升職大概是：
Junior RD => Senior RD => RD Lead / Tech Lead
RD 技術好，從公司角度來看是不可或缺的資產，但回頭看自身的職涯，技術再提升一個檔次就會升上 Sr.RD ，若要邁向攻頂之路，必須要懂得需求管理、產品商業思維、DDD（Domain Driven Design）。
在團隊當中初期的 Junior 都是在主管或 Senior 釐清需求後，將需求轉換成 Docs 規格文件和團隊溝通, Junior 只要依照文件上的指示去把產品功能完成實作，並交付給上層就完工了。
今天若想在團隊有更多的影響力，不是只有寫更多的 Code 這條路而已，可以更有意識地去理解產品需求、進入開發前比 PM, 主管及早發現功能衍生的問題、將後續功能的 Roadmap 訂定出來並提交給主管或老闆，這都是一些攻頂的方法。
一但你持續這麼做也讓團隊看到績效，受到主管及公司提拔 升上 Sr.RD, 團隊更多的 Junior 也踏上你的腳步，不僅建立團隊良好的風氣，也無形複製出跟你一樣強的 RD, 放大團隊的生產力。
成就感驅動 RD 深層理解產品商業邏輯
作為 RD，把產品功能透過程式實踐出來， 這種虛實整合的成就感是一般人難以理解的，但要獲得這份成就感勢必會驅使 RD 去理解商業邏輯。
只有了解商業邏輯，才能從更全面的視角去規劃當前、未來的應用技術，因為也許這時間點適合用 A 方法， 但產品開發完成進入用戶成長階段，用戶數量一多也許當時的 A 方法就不適用了。
不了解商業邏輯，會離用戶的真實需求非常遙遠，越難發現其中的痛點和挑戰，沒辦法提出自身的思路和解決方案，進而解決用戶的難題。
作為RD，自然希望親手打造解決用戶痛點、體驗友善的產品， 如果產品能得到用戶及團隊認同並產生影響力，那自然會特別有成就感。
解析產品需求估算開發成本
對 RD 來說，開發一個產品功能最常見的成本有時間成本、開發成本（不只這樣）， 如果懂得產品的商業邏輯才能概算出具體的成本：
- 用什麼技術解決？
- 資料的結構長怎樣？
- 產品功能彼此間的影響？
RD 如果不懂這些問題，無法把真實需求轉換成技術，那就很難合理估算出開發成本，這時只能讓 PM 來壓時程了（喂）
RD 該如何搞懂商業邏輯？
RD 要搞懂商業邏輯一定會需要這兩個能力：
- 產品服務的 Domain knowledge
- Domain knowledge 實踐轉換為程式碼功能（虛實整合的能力）
不過要搞懂商業邏輯，具體可以和 Domain Expert（領域專家）、PM 尋求幫助和溝通。 上述提及的兩種能力不可能兩三天一蹴可幾，需要在日常、工作專案去培養，平常可以這麼做：
－培養抽象化的能力
培養邏輯思考必須要有抽象化能力，也就是把事物抽象化、重新賦予定義。
訓練抽象化能力有很多種做法，舉凡寫文章、自我對話、玩魔術方塊等，但我自身的經驗和體悟是透過自己的話去描述所見所聞，進一步去定義推理、歸納。
－和團隊建立共同語言
開發系統發現團隊對於代名詞、術語沒有一個共識，進而產生龐大的溝通門檻，這是一件很耗心力的事情，但其實和團隊建立共同語言它並不困難。
團隊早期建立共同語言，白話溝通、文件化，就是建立共同語言的第一步了。
而當下次在會議或小組討論，大家就能夠很清楚知道彼此論述的重點是什麼，進而降低團隊溝通的代溝。
Ref
- Pic - NetWork Unknown Owner