T、RD两者在组织内和专案上扮演的角色截然不同，自然工作思维也不同，不该作为「都是弄电脑的」混为一谈。
让我们聊聊软体工程团队内的专业分工。在台湾，软体工程师最常被称为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用的作法，是很不专业的。