一、R&D概念的分拆
搞研发的掏出名片来一般会印上这么个部门：R&D。所谓R&D就是Research & Develop，研究与开发，所以简称研发。我曾经碰到个高人，强调把这两词拆开来单独理解。“研究”就是把一个团队知识之外的知识点弄懂，引入项目中使用；“开发”就是把已经明白的东西做出来。
二、为什么多数程序员更喜欢搞研究
一般来说，研究人员比较嚣张，不喜欢按规矩行事，理想状态是中国文化里那种特立独行的大侠，一人单挑各种技术难题、熬夜数周最后搞定，写个DEMO CODE解决了关键问题，最多再搞篇技术总结文档，就可以长嘘一口气，等待众同事膜拜；而开发人员相对比较孙子，胆敢做点不合规矩的事，那就是藐视流程藐视公司制度，要镇压的。所以在研发领域，绝大多数人比较向往研究岗位，待遇好地位高、可以单干、能够证明自己的智商，最重要的是能够不断做新的东西不用重复劳动；而开发人员是苦力，整天做些“体力活”，比较没有技术含量，也难有比较大的长进，工作本质和手机生产线上按图纸插元器件的小妹差不了多少。
我也遇到过某些比较特别的、喜欢做重复性劳动的、喜欢在已知领做工程开发的程序员，实际上这些程序员没有很好的职业素养，而且基本都缺乏上进心，朽木不可雕也。
三、重研究轻开发的中小型团队多数下场悲哀
但对于中小型团队，尤其是创业阶段的团队，如果只做开发而不做研究，运气好还能苟延残喘一阵子，养活团队估计还没问题；而侧重研究而没有开发，绝对是死路一条，结果就是工程师做完研究，砍完大BOSS获得经验值和等级的快速提升（我称为“镀金”）完毕后，已经把投资人的钱烧光了，留个废品给投资人，然后各自高飞。
比如一个创业阶段的小团队想做个很炫的UI框架能和iPhone媲美；或者想自己做个3D游戏引擎；或者想做一个矢量地图引擎。不仅多数程序员喜欢砍这种高经验值的大BOSS，投资人也很难挡住这种诱惑力。但如果不是在该领域已有很深厚的积累，而是在只掌握了一二成核心技术的情况下去做这种研究，试图把这种高风险项目做出来以获得高回报的话，那基本上等于找死。高度研究型项目对于中小型团队来说，就是投资人的高风险，程序员的高回报。
我就有过这方面的教训。本人天赋不咋地，04年底从零开始奉命研究播放器核心，死磕TCPMP代码，到07年自己写出一个播放器核心的时候，我这组人已经是换第三拨了，前两拨十几个兄弟都耐不住寂寞离职了。另一组人则有企业博士后带队，对MP3、REAL、H264的解码效率进行优化，研究也持续了两年多，换了两拨人马。最后这个播放器和优化了效率的解码器也没在手机电视市场爆发的时候为公司带来多少价值。还好是个大公司养着这两个“研究团队”，要是换小公司的话，两三年投入不出产品，早就死了。
四、研究和开发的资源布局
既然是R&D并提，说明两者基本上密不可分。做软件不可避免地、或多或少都会有研究的成分，而不纯粹是工程开发。所以出现下面两种资源布局：
（1）有的公司是把研究和开发任务混在一起，平均分给每个工程师；
（2）有的公司则把两者割裂开，有专门的精英团队做研究，有专门的工程团队做开发。
有些软件团队会有这样的追求：少数几个大牛搞定一个开发框架，然后用月薪两三千块钱大量招“代码工人”进来，快速开发出客户需求。这是一种“软件流水线化生产”的思路。当我们把这种软件公司的模式比作“中国制造”的时候，就发现这很有趣。这种模式在国内做企业开发（ERP、CRM、OA等）和网络游戏开发的公司中被广泛采用，实际上就是上面所说的第二种方式，建立两个团队分别做研究和开发。
补充: 网友评论中提到, 现在第二种方法是业界趋势，甚至工程团队中根本不用自己的人，向人力资源外包公司"租借"工程师来完成. 这使我想起华为、微软上海也是这么干的，而福州某家效益很好的软件公司能够用200名左右的项目经理和系统分析师, 管理2000多人的外包派遣工程师来做项目.
这两种方式都有利有弊，前者会把核心人员浪费在体力活上，但有利于团队的“和谐稳定”以及从外围人员培养出新的核心成员；后者的组织效率会更高一些，但是由于阶级化明显，做工程开发的外围团队人员流失率会比较高，也不利于培养核心成员出来。
所以我认为，对于一个想获得成功的研发团队而言
（1）要想清楚研就和开发的投入比例。用虽然笨拙的已知方法替代对未知的、高效的、很酷的未知方法，在很多时候是必要的。项目风险必须处于可控范围内。我见过个数据，软件项目中的未知核心技术如果能占所需核心技术的20%以下，那么这个项目的成功率会大大提高。当然，这个也和行业领域的特点也有关系。
（2）要想清楚如何分配研究和开发任务。如上面所说，是分拆成两个团队单独做，还是把任务混合后平均地分配所有工程师。