讓我們聊聊軟體工程團隊內的專業分工。在台灣，軟體工程師最常被稱為RD（Research & Development）或是IT（Information Technology）。工程師的團隊，在公司內常被稱為「技術部」或「工程部」，由公司其他團隊拋出需求給工程師處理。另外，跟大家討論需求，然後幫工程師排工作、追進度的，統稱「PM」（專案經理）。
很多的上市公司、中小企業和新創公司，組織編制都差不多，故此，在台灣的職場拋出「RD」或「PM」的職缺，各會有同質性相當高的人選們來應徵。
進一步而言，這種軟體工程編制算是相當陽春且專業度低，長久下來多會對組織造成負面影響，問題出在這種編制下「組織角色」很模糊。
職務都叫「工程師」，角色卻差很多
如果今天公司內的工程團隊都是RD與PM的編制，那今天客戶碰到問題，PM整理問題和要做的事情給RD做；公司內部要開發新的功能（feature），也是PM整理給RD去做。如此一來，大家要不是沒有想清楚，就是認為「RD不就是寫Code嗎？其他的事情都是PM的事」。
推薦閱讀：工程師與專案經理的摩擦
這當然就是問題所在，大家職務可能都是工程師，但是在專案中的角色不可能只有一種。正常來說，一個人的「角色」，是相對於情境和面對的對象。同一職務的人，在任何專案中，都很有可能扮演多個不同的角色。
聽「RD」的中文就是「研發」，排除純學術性的研究工作後，大部分公司內的RD工程師，負責的業務很多都與產品管理相關。當產品程式碼紊亂，需要整理或是改寫（清理技術債，repaying tech debt），或是產品運作速度太慢需要調校（最佳化，optimization），在這種情況下，專案的需求方就是PM或是其工程管理者。
RD工程團隊主要是以軟體開發為主，一般來說更講究工程流程管理、技能培訓、品質控管以及發布管理。這些工程管理的面向，在台灣科技公司中很少落實，但這已經超出這次的討論篇幅。
說到IT部門，在很多公司內也稱MIS（管理資訊系統）部門。不管是在做IT還是做MIS，這部門的工程師目標不是軟體開發，而是在做採購評估和系統整合。
打個比方，幫公司採購辦公軟體、設置帳戶、串接ERP（企業資源規畫系統）、設定VPN（虛擬私人網路）等，都是落在IT部門內。
IT部門正常而言，需求方是公司的其他部門，意思是IT部門作為公司其他部門資訊服務的提供者。通常IT部門沒有什麼PM，因為流程上比較線性，可以直接用很簡單的Issue Tracker（事務追蹤系統）來向公司其他部門「接案」，組織管理簡單許多。
由此可見，RD跟IT在同一家公司內的作用是完全不同的。很多RD這輩子根本沒碰過ERP，不會幫你設定網路；同時，很多IT寫的Code重點在於快速整合而非新功能，不應該被抓來當自家產品開發工程師。
況且，IT部門使用的工具如FileMaker、MS Access去做的整合工作，根本都是一般RD工程師不會去接觸的工具。
IT、RD大不同，混為一談有失專業
很多RD工程師的開發工作都是以自身系統的特性和限制為考量，打個比方，RD工程師可能會開發自然語言套件，但通常是解決方案工程師才會去了解Slack、臉書、LINE的Chatbot API如何去整合串接。當然，有些人會認為叫RD工程師去了解這些外部需求無傷大雅，但是這其實就在慢慢侵蝕一位工程師在組織角色的專業度。
這些不同部門的工程師，不單對應的需求方不同，團隊編制也大相逕庭： RD部門通常都會由工程管理體系來領導，解決方案通常是由業務體系來領導，而IT部門則是由公司的營運體系來領導，不可以混為一談。
在新創團隊中，由於人手少、組織扁平，「一人身兼多職」沒什麼好奇怪的。
但是，已經籌了募資A輪的新創，或是更成熟的中小企業和上市公司，如果還是用RD vs. PM這種陽春的管理方式在管理工程師，那組織的營運效率，就差其他組織規畫更成熟的公司一大截了。
很多台灣老闆看待工程師的方式，就好像在看待「免洗筷」一樣：他們多半認為反正都是工程師，研發工程師會突然被老闆挖去見客戶、幫客戶解決問題，或是莫名其妙地被要求去開發一套內部的CRM（顧客關係管理系統）。
所謂「工欲善其事、必先利其器」。當一個組織的規模發展到一定程度，應在適當情況下用合宜的人才解決問題。
為什麼拿「免洗筷」做為台灣工程文化的比喻？因為免洗筷可以夾、可以戳、可以剪，在老闆眼裡「什麼都能加減做」，事實上什麼也沒做得特別好。重點是免洗筷成本極低，且一雙筷子兩支長得差不多，不用計較那麼多，反正免洗筷隨時可以換。
這種文化可謂掩耳盜鈴。因為出了國際，若隨便把RD當作解決方案工程師用、或是RD當IT用的作法，是很不專業的。
責任編輯：陳建鈞
