本文是《IT研发中心管理思路、策略和制度》专题的一部分。
本文针对于中小公司设计，研发人数在1千人以上的大公司或者小于50人的小微公司也可参考。
打破传统架构那样的一个个封闭的部门和团队，让他们以多元的形式更好地配合，避免冗余和不一致给中后期带来的不利影响。特别是基础能力和技术，非常有必要形成统一的力量。当然，其他的，比如说业务，当业务越来越多的时候，也趋向于凝聚、沉淀成基础的共享能力。
举几个例子：一个叫做Supercell的游戏公司，共200余人，划分为中台和前台两部分，中台凝聚力量，前台快速冲刺、试错。这种架构非常成功，后来被腾讯以84亿美元收购，每位员工贡献值超过3.5亿人民币。阿里考察了Supercell，同时结合自己遇到的问题，在2009年成立了技术保障事业部、共享平台事业务。就连原本以产品为主的腾讯，在2018年，历时6年的架构大调整中，也成立几大事业部围绕技术委员会这样一个架构，同时还有一个技术工程事业部，专门负责基础技术和架构。然后是百度，也在2018年做出了架构调整，汇聚原来分散的基础能力（基础架构、共享平台、各分散的运维等），成立了基础技术体系事业群（TG）。同年，京东集团也发布了组织架构调整，成立前台、中台、后台，短短的说明中，重点提到了专业化、系统化、组件化。
以上例子是后期加上的，只是想印证关于我下面的设计之合理性，实际上，下面这些设计是我多年的实践、不断反思和改进的结果，有些思想和上述公司不谋而合，但是也有一些差别，因为我是针对于“中小公司”设计的，这是前提。
1、一定不要让研发、运维、测试等多权分立，办事流程低下，架构得不到统一，各团队一点都不团结，互相推诿甚至陷害，那画面真的不能太美。
2、一定要重视架构和规范（前期欠下架构的债，迟早是要还的，而且代价非常大——“IT是重要且巨大的资产，而资产的根基由架构决定”）。且架构和规范的落地，一定是从顶层向下，由行政保障。IT人员是很有性格的，而且是有些犯贱的性格，你要让他们乖乖做事，理由充分还不够，还得让事情本身是“名正言顺”、“理所当然”，所以组织架构实际上是很大一门学问。
研发中心，为抽象的概念，以产品和研发为主的中小公司，一般不设实体研发中心。对于特大的集团公司，可以设研发子公司。下述的“研发中心”，都是抽象的概念，泛指和产品、技术相关的组织集合。
研发中心（或者说研发相关的组织，人数大于50人）的管理岗位可以设：总经理/研发总监 一名，副总监1~2名（一个偏技术，一个偏产品），资深技术总助1名，其他具备管理资格的各分支和团队leader若干。（ 各分支和团队leader，一般是从下面所说的 产品项目团队 和 虚拟组织 中选出来，但名额不多，不是每个组都有leader）
上图只画了研发相关的虚拟组织，实际上，公司还有其他的虚拟组织，虚拟组织和产品研发团队，不是上下级关系。不能以传统的思维来认识这种架构。
这个图还可以再增加其他非研发岗位的人员，纳入到研发的管理体系，研发相关的组织是没有边界的。由于没有独立的大研发部门，就没有各部门的隔阂，公司所有人员和研发人员都是一体的，只是有些离研发近一点，有些离研发远一点而已。
另外，产品研发团队的各个项目组之间不是完全独立的，因为项目组有大有小，多个小项目组也可能形成一个产品线、产品平台，通常我们会把某个业务团队的管理单元调整到一个合适的规模，比如6~9人，大的会拆分、小的会合并。
1、以产品研发团队为中心，设计了人力资源池，绝大部分研发人员都在人力资源池里面。只有少部分高端技术人才或特殊人才，跳出了人力资源池，站在更高的服务者角度，推动产品研发团队的发展。
2、在产品研发团队之外，明确了许多虚拟组织，这些组织成员，大多不是全职参与，但提供专业服务，能使研发中心工程效率、管理及规范化、先进性等方面得到明显改善。
1、传统的一级、二部门较多，部门与部门之间存在隔阂。而这套架构，首先，将产品和技术绑在一起管理，上面有研发总监、研发组织部、研发管理部、安全管理部统一管理。其次，将运维和测试，定位为产品研发团队的服务组织，并与基础设施研发团队一起，受“基创团队”的负责人管理，而基创团队的负责人（总监助理级别），通常又是技术管理组的负责人，间接管理所有研发项目，但是他又受技术与架构部的负责人（副总监级别）管理。副总监不过问具体项目，但是监管所有项目并管理所有架构。所以，我们看到，组织与组织之间，都是配合关系，不能有矛盾。举个例子，根据需求及内部讨论，后端架构组提出使用分布式文件存储，架构部负责人（副总监）同意说做，那么应该由中间件组负责去调研，找到一款开源的产品后，但是要做少量二次开发，于是要成立一个开发组，在基创团队负责人（总监助理）的协助下，成立这个组，安排架构和开发人员开始做，完后，再让技术管理组负责人（总监助理）要求各项目组开发经理配合接入。这个事情就这么顺利，居然都没经过研发总监和研发组织部！话说总监和研发组织部，才是最后的杀手锏，再难的事情到那儿都可以搞定。
2、所有团队都不是单军作战，比如说，某个项目组，需要性能测试支援，开发经理直接跟自己的上级说就是，因为开发经理的上级和测试部门的上上级是同一个人（技术管理组组长-总监助理级别），分分钟就能协调好资源。安全技术组做事，就更简单，它可以以安全管理组（顶层组织）的名义，直接向整个公司发文。运维做事也简单，中间件运维搞不定，直接由中间件技术组接手，运维想推行一个规范，直接给上级领导说，上级领导同意，分分钟直接要求下属开发经理去落实。大数据技术组、安全技术组等，都是基创团队的上级部门，有需要基创的地方，直接提要求就是了。基创虽然是服务部门，但它与架构部相辅相成啊（架构部的大佬基本都是基创团队的leader级成员），而且又和产品研发团队同属于开发性质，可共享人力资源池。
但是经验丰富的人可能会说：组织安排清晰、妥当了，并不代表组织一定能按预期效果运转。是的，还需要与这种组织方式配套的工作流程，绩效管理，人才管理，组织文化等方面共同作用。重点是 与该组织架构配套的 工作流程，每个人做事的方式，和传统的也不一样，但是这篇文章不讨论，本文重点讨论的是组织和岗位设计，其他方面参见其他文章，如。
另外，如果研发人数少于50人，则不能照搬，需要精简，但很多思路是相通的，可以参考。
虚拟组织（半虚拟的组织，大多数人是兼职）
1、大多数成员为兼职，仍然要参与产品研发部的日常工作；
除了少数身兼数职或特殊岗位的人员外，绝大多数人都会参与到产品研发团队中。
2、工作安排灵活，可由成员自由发起某项工作，通过评审和领导审批即可去做；
3、虚拟组织内部，设置1个或多个负责人，例如部长、副部长、组长、副组长，主要负责统筹规划和评审等各项工作。
虚拟组织负责人，对其成员的管理，侧重于专业技艺，个人发展和激励等方面，氛围很OPEN。
顶级虚拟组织：研发组织部（0级）、研发管理部（一级）、安全管理部（一级），由研发总监（P10）亲自领导。(后文有详细说明)
一级虚拟组织：产品与设计部，由 资深产品架构师 / 副总监兼产品总监（P9） 领导。
一级虚拟组织：技术与架构部，由 资深技术架构师 / 副总监（P9） 领导。
一级虚拟组织：基础服务与创新团队（简称“基创”团队），通常由技术管理组组长（P8）领导
（注：安全测试和性能测试 由 技术架构部的安全技术组和测试架构组支撑）
类似于“阿里组织部”，主要由各组织的leader组成，每个成员都是一个组织的代表，组织部会定期召开会议。
负责研发管理策略的研究，以及各种研发流程和制度建设，并检查其执行。
积极推动研发能力提升、研发成熟度提升（规范化、可复用、可优化、最佳实践），使各个项目都遵循产品和架构组相关的规范和最佳实践，达到较高的研发水平和标准；推动架构/产品/技术的优化和整改，推动统一技术平台的实施和落地等。
促进和提高队伍的研发能力，强化研发队伍，做好人员招聘，新员工入职引导和培训，积极推动和组织各种技术交流/培训活动。
组成人员：由研发总监直接领导，组成人员包括 副总监/总监助理，各一级虚拟部门的leader，加上少量核心资深的产品经理和架构师，以及一些非技术类“研发管理岗”(下面有介绍) 负责人组成。
一个行政事务和综合事务机构，服务于整个研发中心，其事务主要由研发中心负责人和研发组织部下发，比如研发中心的员工招聘、入职引导和培训，活动组织等人力和行政工作，以及跟踪研发流程、制度的执行，考核数据收集整理等综合管理工作。
组成人员： 综合管理，非技术类的“研发管理岗（行政+综合管理，下面有介绍）”，研发总监任部长，可以由副总监主持工作，也可以总监亲自主持工作。
研发管理岗（组织及管理事务）：（招聘人数1~2人）
研发管理岗（人事及HRBP）：（招聘人数1~2人）
-
熟悉IT领域业务知识和人力招聘知识，为业务部门招聘专业人才；
-
负责研发中心的新员工入职引导，协助办理离职、入职等手续；
-
对接公司的人力资源及财务部门， 负责薪酬福利方面的工作；
-
协调员工关系，组织团队建设和培训，关注人才成长并负责绩效辅导。
研发管理岗（行政和综合事务）：（招聘人数1~2人）
行政/综合管理岗位也分为初、中、高级，高级行政/综合管理要能站在领导的宏观高度，进行规划、规范、组织、协调和督促。
-
优秀的人际沟通协调能力、亲和力，有较强的文字表达能力；
-
诚信正直，品行端正，公正客观；
-
工作细致认真，做事有条理，责任心强，执行能力强；
-
大学本科及以上学历，行政管理、汉语言文学、计算机等相关专业优先；
-
有行政、人力相关工作经验优先；
-
熟悉研发工作和技术，有过产品、开发、测试、运维等岗位工作经验优先。
由安全管理专家担任副部长（主持工作，通常由安全技术组的组长兼任），加上弱技术类的“安全管理岗”1~2位人员组成。
安全管理岗：（偏管理、弱技术岗位，要求具备一点点系统运维知识）
负责各产品线组的日常技术类管理。协调开发人员工作，参与工作量评估、技术方案评审、代码走查等工作，领导解决各产品线组的技术难题，线上故障，并做好防范方案。对研发质量负责，协调测试、安全人员工作。
负责各个系统的架构。使其满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新，并且识别非功能型需求，做好技术选型、技术架构风险识别和评估。
参与各种技术规范和最佳实践的研究和制定，并负责在各个项目组内落地实施，让各项目达到一致的研发水平和标准。
组成人员：应用架构师（需要 有丰富的应用设计经验和资深的技术水平），建议1个架构师服务3~5个产品线，任该产品线组的技术经理。(技术经理，虽然侧重于技术管理，但仍然具有一定的管理性质，需要具备基本的管理能力和责任心）
工作方式：架构师必须得熟悉自己负责的项目使用的技术及重要的功能，对于特别重要的设计，需要多个架构师参与讨论和评审。
技术管理组的应用架构师，相对于传统的一个项目一个技术经理的配置，更能优化和节省高级技术人员，而且他们都隶属于技术管理组，方便交流和沟通。
负责各产品线组的日常管理，类似于项目经理，不但要统筹产品研发工作，还要负责管理好团队人员。偏业务和管理，建议从资深/高级产品经理中选拔，业务能力占40%，项目和管理经验占30%，管理能力、责任心等占30%。
负责各个产品设计，并推动产品的研发和落地使用或商业使用。协调产品经理/助理、UI/UE设计师、运营等工作。
组成人员：高级/资深产品经理，建议一个人负责1个产品线组，任该产品线组的项目经理。
工作方式：全权对产品和项目负责，有权组建新产品项目组，在技术经理的辅导下完成对项目组所有团队人员的管理。
建立健全测试体系，将测试意识，测试工具，测试流程，渗透到研发的各个阶段。让测试工作能在研发团队高效的开展。
另外，负责一些复杂的测试，比如白盒测试、性能测试和中间件测试，涉及Linux、网络、各种程序等，需要具备较全面的知识，能参与到系统架构中去，辅助架构设计，参与中间件选型的测试。可以由技术架构师兼职。（注意：安全强相关的测试，放到安全技术组去）。
举个例子：生产环境，有些测试验证很难做，因为生产环境必须要真实数据，比如真实的商户，真实的“新”客户，真实的大额资金转账等。这时，就要论“测试设计，测试数据”的重要性了。比如上面的场景，可以设置一些模拟的接口，模拟真实场景，但是却能区分测试数据，在某些不方便测试的地方，做Mock。或者设计一个反向操作，设计一种方式可以清除测试数据。（只针对核心业务场景，专门设计，其他非核心的暂不考虑）。另一种方案，放入极小部分真实的流量做测试，这时不能在UI上操作，只能在后台看日志，所以关键流程的日志一定要有，而且最好是能聚合在一起方便查看，注意这个方案有一定风险，毕竟是真实客户，出了问题要有处理方案，最好是能控制到放入流量的用户数量。
测试平台，测试模拟器等，也都需要由测试架构组牵头设计和研发。
强技术岗位，由信息安全专家组成。需要具备较全面深厚的知识，以及很强的动手能力。
负责研发中心一切信息安全技术相关的事务，比如应用安全、系统安全、中间件安全、网络安全等。（行政相关的工作，则可以通过安全管理部去下发和跟踪落实）
安全专家：熟悉漏洞、病毒原理，会渗透测试，有一定开发能力。
负责网络技术研究，对研发中心各个组织（开发）提供网络技术支撑，并主导网络相关的事项。
网络技术专家：熟悉或精通各种网络技术、网络设备，包括公有云网络和网络虚拟化，深入理解网络原理，具备一定编程能力。
牵头运维自动化、智能化的整体设计和技术研究。包括运维基础设施的自动化管理（参考cmdb、ansible、阿里star-agent等），容器云平台架构，底层存储（参考CephFS、GlusterFS、NAS等），CI/CD及DevOps一体化运维平台，全维监控体系，智能告警、日志采集，运维大数据平台（与大数据技术组共建），使用ChatOps、AIOps技术构建智能运维平台。
9、其他领域的技术组（前端技术组、大数据技术组等）
由该领域的专家领导，该领域的所有专业技术人员均为成员，但几乎都为兼职，日常以自己的项目工作为主。
专业技术组，负责专业领域的技术研究，并将研究结果应用于开发、测试、运维等团队。另外，会定期组织技术分享、培训，也有可能会集思广益，做一些架构研讨。
运维的整体设计思路，借鉴与目前越来越主流的DevOps、微服务运维、容器云运维、AIOps方法，使用各种工具，及自研运维工具，将运维工作减少60%，剩下的20%由研发团队借助自动化、智能化运维工具自己做，最后运维团队只剩20%的工作，这20%主要侧重于管理。运维团队的其他时间，可以用来研究运维相关的底层技术。
除了中间件运维，其他运维工作（包括简单的网络操作），都由“系统运维组”负责。
注意，这里没有网络组，简单的网络运维操作，比如开策略、简单的路由防火墙配置等，都交给安全管理组、系统运维组做了。为了让网络技术更专业，将成立网络技术组，放在技术架构部下，专门负责网络技术研究，做网络架构及解决网络疑难问题。
“2016年的时候，阿里巴巴技术团队经历了一次非常大的调整：把日常的运维工作交给研发做。
原来的 PE（Production Engineer）要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应的只能黯然离开。
这是阿里运维从工具化到自动化的过程里，最重要的一步。以前运维团队需要支撑集团非常多的BU，干的都是脏活、杂活、累活。”
Netflix 从一开始就强调开发人员进行自助化运维，他们的理念是：谁构建，谁运维。其运维工作全部由开发人员完成，只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是电商业务还是 AWS 公有云业务，都由开发负责。
我设计的这个运维部，是一个高度自动化运维之后的一个偏产品、研究和管理的组织，他们是真正的运维专家，我期望他们干脏活儿、累活儿、杂活儿的时间，不超过20%，如果超过这个时间，就得考虑改进，短期内将一些技术含量低的工作，交给外包或者实习生。
1、系统运维（普通技术岗位，偏应用方向）：
熟悉或者精通linux系统及常用工具，熟悉网络技术，熟悉虚拟化和容器技术，熟悉shell编程，熟悉监控和问题排查，熟悉各种运维工具，熟悉各种常见应用和中间件的部署和配置（nginx、mysql、redis、tomcat等）。
2、系统运维（普通技术岗位，偏主机和网络维护）
说明：如果主机和网络维护的工作量不多（小型的数据中心），可以由应用运维和网络专家兼职！（如果使用云服务器，也可以不招聘这个岗位的人）
-
1.负责公司主机、存储和SAN交换等软硬件设备运维、优化及故障处理，负责数据机房的巡检、维护；
-
2.负责各业务系统所需服务器的资源管理、环境搭建及部署；
-
3.负责各种服务器、存储的配置规划、性能调优和资源可用性监控；
-
4.负责公司网络设备配置及调试，如路由器、交换机、防火墙设置等，及网络流量分析和监控；
-
5.负责公司主机服务器、网络等相关系统安全策略的配置和管理。
PS：可能有人注意到，没有“应用运维组”，是的，应用都由研发自己运维，但系统运维组会提供必要的协助和管理。
上面已经介绍了，中间件包括MQ、Redis、数据库、分布式存储等，还包括一些大数据的东西。传统的运维人员根本搞不定这么多，得由研发专家兼职，且优先考虑自动化、智能化运维。某些方面也可以或需要和系统运维结合。
负责实用类技术创新工作，研究和引进新兴技术和工具（包括但不限于前端、后端、大数据、开发、运维等），研发具有自主知识产权的技术类产品，并负责研发和落地实施。
促进运维、测试、开发（后端、前端、移动端、大数据）等相关效率的提升。负责搭建公共技术平台&创新平台，主持研发基础组件、中间件等，包括但不限于 统一配置中心，自动化运维平台，基础大数据平台，基础开发框架，基础UI框架，自动化测试框架等。
组成人员：由系统架构师和各类技术专家组成，副总监/总监助理/高级别架构师担任部长（建议与技术管理组组长为同一人），根据需要，成立临时或长期的项目组，选拔负责人，并分配中高级开发人员。比如：
另外，可以单独设置平行兄弟机构：创新研究院，专门负责前沿高新技术产品的研究。
无论是基础设施研发部还是创新研究院，都可以承接产品类的研究和开发任务、有产品经理参与。
包括各产品业务线 或 独立项目团队，负责完整的产品研发（产品设计、开发、测试、运维等）。例如：
项目组主要受“产品与体验部-产品管理组”和“技术与架构部-技术管理组”共同管理。产品研发团队成员的日常工作管理和考核，主要由产品项目经理（PO）和技术经理来负责，但他们都不是固定岗位。每个组内，产品、开发、测试等各司其职，由高级的人员带低级的人员，项目计划由产品和开发根据产品部和架构部的指导自己协调。
问题一：产品研发团队与公司的其他部门（销售，运营，管理......），是如何组织的？
答案：以人为单位来看-->
1）人员的组织安排，是以其岗位和职责来确定的，换句话说，他的工作重心在哪里，他就应该在哪里。
举个例子：市场部，张某某，参与辅助产品A的市场推广和运营，属于产品和市场客户之间的一个桥梁，但是他花在产品研究和测试上的时间达到了40%，而且他的工作对研发团队有着巨大的影响。但是张某某的职责还是属于市场推广和运营，他不是产品，也不是测试，而且他也不具备产品或测试的专业能力。市场部觉得他工作做得不好，可以换掉他；产品项目团队觉得他很重要，可以将他借调或者划归过去，甚至可以转岗。
2）跨部门之间的任务协调，如果两个人熟悉，可以直接点对点直接分派任务。如果双方不熟悉，通过双方的共同上级组织和领导，也可以快速分配和执行任务。
举个例子：客服中心，邓某某，时常需要研发团队的支持，或反馈一些问题，研发团队也有跟踪解决，但是邓某某是为客服中心服务的，她和研发团队双方之间的任务推动，可能要经过各自的上级组织和领导进行沟通。（前提是双方的上级，一定是可以顺畅沟通、达成一致的，在这个例子中，邓某某如果对研发组成员熟悉，目标清晰，她也可以直接跟该成员沟通并发起任务，最坏情况下，邓某某对研发组成员不熟，她想要给研发组发起任务，就要通过两个组织的上级关系的连线进行：邓先提交任务给自己的直属领导A，A与研发团队无直接关系，则A自动往上抛，抛到上级运营总监B处，而运营总监B和研发部的几个负责人熟悉，所以他可以直达研发部的许多个负责人，目标明确后，他可以直接把任务转到某个研发部负责人或联络人处，然后再由那个人决定将这个任务分配给具体团队的leader，再由leader分配给个人，说白了，就是通过关联关系，把所有员工串联起来，借助办公系统，还可以达到半自动化，任务很快就能推动起来）
1、任务流转是公司管理的核心机制，任何人都可以给其他人分配任务，这种机制是跨部门适用的；
2、公司整体机制是，人员可以跨部门调动，或者跨部门任职的，
3、有隔阂的实体部门之间，一定是有某种有效的沟通的，例如跨部门的虚拟组织，或者领导与领导之间的共同组织，所以两点之间一定有一条或者多条连线，通过任务的跨部门流转机制，所有不同部门之间的配合都会变得很容易。
建议：公司成立一些跨部门的虚拟组织（例如xxx领导小组，xxx委员会，xxx管委会，xxx专项小组），将各部门leader和重点负责人紧密联系在一起，责任也一起承担，同呼吸共命运，让高层之间、跨部门之间的沟通顺畅，顺畅到双方的沟通一句话就能达成，顺畅到跨部门的配合能形成默契，通过任务流转机制，任务就能快速发起和执行。
任务的跨部门流转，存在一个细节上的问题：研发人员都通过办公系统做在线任务分发，如果其他部门人员不用这个系统怎么办？解决方案：将在线任务分发系统，推广到全公司使用；至少可以推广到，与研发相关的协作，都通过任务分发系统进行；再退一步，即便其他部门不用这个系统，则可以通过研发部中介人进行任务中转，这个中介人不一定是研发总监或者副总监，研发总监可以安排一个或几个作为对外联系人，这样就可以将其他部门的任务转换成研发系统内部的任务。
某管理岗位如果空缺，则由上上级负责管理，或者指派特定人来临时负责。
通常，某人任某部门经理，就不再任其下级部门的管理岗位（特殊高端岗位除外）。
岗位状态有 正式、临时、自由三种，该岗位的正式、临时成员，受该组织的上级管理，而自由成员，不受该组织的上级管理。一般来说，需要比较长期的参与到某个岗位的工作中，但是却不能受控于这个岗位时，处于该岗位的'自由'状态。
<研发中心.研发管理部>部长 [正式]
<研发中心.技术与架构部.运维技术组>运维架构师 [自由]
职级：P10 - 首席架构师
（技术与架构部 部长空缺，由研发管理部部长直接负责）
<研发中心.技术与架构部.基础技术组>组长 [正式]
<研发中心.技术与架构部.技术管理组>应用架构师 [自由]
<研发中心.技术与架构部.测试架构组>性能测试专家 [自由]
职级：P8 - 高级架构师
<研发中心.产品与体验部.产品研究组>产品研究员 [自由]
职级：P8 - 资深产品经理
注意，上面三个人，职位很高，根据规则，他们不兼任下级部门的管理岗位，但是，在下级部门不完善、人员不足的时候，他们会身兼N多岗位，只不过他们属于这些岗位的“自由”成员而已，比如技术总监，可能亲自担任应用架构师、平台架构师、安全测试工程师、中间件运维工程师等等。
职级：P4 - 工程师
说明：像李某某，这是最底层的开发，只有一个岗位。
<研发中心.技术与架构部.技术管理组>应用架构师 [正式]
<研发中心.技术与架构部.测试架构组>组长 [正式]
<研发中心.产品研发部.会员产品线>技术经理 [正式]
<研发中心.产品研发部.开放平台中心>技术经理 [临时]
职级：P7 - 架构师
说明：像王某某，这种中层技术人员，身兼N多管理和技术专家岗位，这是常态。
1、有人说，应该把测试、前端、大数据、网络等全都独立成部门：测试部、网络部、大数据部等。
回答：不赞同。其实是相对独立的，但不是完全独立的。
完全独立的坏处应该不用多说。把他们分成虚拟组织，其实考虑到他们都是研发团队中的一员，只不过技术方向不同，但本质上都是做技术的。整个研发团队有两部分：1）产品研发团队，2）基础设施研发及创新团队（简称“基创”研发团队），前者的项目按业务区分，后者的项目按技术区分，业务与业务不一定相同，技术与技术也不一定相同，举个例子，产品研发团队有“网上商城”项目和“运营平台”项目，基础研发团队有“容器云平台”项目、“自动化测试平台”项目和“大数据分析平台”项目，把他们放在一起，并没有不妥，并不一定非要按运维、测试、大数据这样来划分部门，部门对管理的危害远远大于项目组。
1、由研发行政管理人员安排和协调，原则上不固定工位（工位都是临时的），但同组织的人最好是坐在一起，方便沟通，一般按 项目团队、岗位性质（产品、测试、开发、运维等）、虚拟组织等因素 划分区域，优先按工作重心来协调工位。行政管理人员根据情况可以随时调整大家的工位。
例1：“理财产品专项组” 的大部分人员集中在B区域，另外，给产品经理、技术经理留一个位置，产品经理、技术经理可以在这里办公，也可以在各自的“总部”办公。
例2：“运维保障部”人员集中在C区域，可以认为这个区域是运维人员的“总部”，但是个别运维人员也可能进驻到项目组。
2、中高层的管理者，建议设独立办公区、或者办公室，可选的人包括：研发中心的技术总监/总经理，副总监，总监助理，以及大部门的经理、副经理。这就好比军队中的统帅，通常不和小兵坐在一起，一来突出领导的威严、地位与特殊性，二来是掩盖领导的隐私、避免重要的谈话被人听到，或者重要的资料被人看到，三来是安静的空间方便领导的思考和决策。
3、一些特殊的岗位，也可以设单独的办公区、办公室，比如专门负责策划和架构的高级架构师，专门负责高精尖技术研究的专家，为这些高级人才、且单兵作战的那种，安排比较安静的空间，另外像负责人力资源、财务方面，需要一定隐私的也应该安排单独的区域。
每个员工，都有一个或多个上级领导，有若干个岗位，每个岗位有一个岗位负责人，对于他的每个岗位，有一个或0个备份人员。
比如，张三，他是一名 中级自动化测试工程师（P5），他目前身兼两个岗位：
岗位1：理财产品项目组 自动化测试工程师，该岗位有一个备份人员 李四。
岗位2：开放平台项目组 自动化测试工程师，该岗位无备份人员。
他的日常工作，主要由这两个项目组的技术经理来安排。
同时，他也是 测试架构组（虚拟组织）的临时成员。测试架构组的组长，也可能会给他安排任务，但如果有冲突，需要和项目组的经理商量。
以上，部分经典参考资料：
《Spotify的敏捷管理（部落、小队、分会和协会）》：
2 研发序列岗位级别设计
参考业界主流做法，比如以腾讯、阿里的标准，这样做认可度和可理解性会比较好。另外，为了让岗位级别看起来更加高大上，让职员更满意，适当把各个级别拔高一点。
管理岗位的层级单独设置，以[M+数字]表示管理岗位级别，例如M1、M2、M5，最基层的管理岗位为M1，最高层的管理岗位为M10（10个层级通常够用了，即使阿里这样的大集团公司，10也基本够用，如果层级超过10，建议尽量扁平化）
除了管理岗位，其他绝大多数岗位都是专业岗位，以字母P代表，为了方便管理，P取值范围定为1~12（12级基本上够用了，即便一年升一级，也要12年，况且该职业的最高级，哪能是随随便便能达到的）。
专业岗位，按职业技能划分多个职业通道（序列），比如行政、财务、设计、运维、开发、运营、产品、科研等。
一个没有任何职业能力的毕业生，可以从这些职业通道的任何一个从1级开始，修炼，打怪升级，直到千万年薪。如同一个完整的人生指引。横轴是X个职业通道，专业技能各不相同，纵轴是P个级别，技能水平各不同。
不同的职业通道，有着不同的级别定义策略。腾讯那种固定4层，每层3个级别的方法不可取，例如工程师序列，包括初级工程师、高级工程师、架构师、资深架构师等，硬生生的划为4层，而且每层3个级别不合适。另外，像工程师这样的序列，大多属于多人协作，到P6就能管理人了，但是像研究员这样的偏个人作战的序列，到P6还只是个初级研究员，真正到P7或者P8才具备一定的管理属性。所以，级别按序列划分，每个序列根据自身的职业特点，定义扁平的P个级别。
另外，不是每个职业序列，都是从1级开始，最终到12级。根据职业特点，可以从1~8级的任意一级开始，从任意一级结束。不同序列的级别，存在一定的映射关系，相同级别应该尽量保持一致的重要性，且能和管理职位级别对应起来（后文列出了一个职位和职级的参考映射表）。
2.2 职业通道（序列）
2.2.1 工程师序列 和 研究员序列
大学教师的职称分为：助教、讲师、副教授和教授四种。
研究员的职称分为：实习研究员、助理研究员、副研究员、研究员四种。
区别是：研究员没有教学任务只承担科研任务，教授既要承担教学任务又要从事科研工作。
研究员与教授都属于正高级职称，副研究员与副教授属于副高级职称。研究员和高级研究员是一个意思，都是正高职称。
在研究所里，通常领导或者是学术带头人才称之为研究员，高级研究员可以说相当于教授，副研究员也相当于是副教授级别。但是在研究所里，研究员都不用教授的职称。
研究员一般在研究所中，掌握着本学科领域内的国际国内最新进展，取得过高水平的研究成果，还要参与国家或单位的重要科研任务。通常研究所中的领导以及学术带头人是研究员的职称，作出贡献后可以被评选为院士。
综合多方面的总结和思考，工程师序列的职级定义如下：
P10及以上的职级都为虚级、荣誉职级，因为他们通常为某领域的领导及技术带头人，职级不过是荣誉的象征，职级是虚衔，岗位才是实衔。
注意年限的限制，设计得是非常宽泛的（下限很低，是考虑到一些特别优秀的人才；上限很高，是为了兼顾用人需求和人才的特殊经历），下限是对这个岗位经验的要求，哪怕是天才，也需要长年的经验积累，而且这个下限已经比较低了，不能轻易松动和违背，如果要破格定级、升级，需要高两级的人保荐才行。
破格的例子：蒋凡，工作4年后创建了友盟，3年后被阿里收购，任阿里高级总监（M5/P10），目前已经是阿里副总裁，M6+的级别。之所以蒋凡升级这么快，是因为阿里集团CEO张勇（M9）的青睐。
容易破格晋升的职业通道包括但不限于：高端技术类，产品类，创意类，然后是普通技术类。
-
P5 助理研究员 - （应届生或工作2年内，建议硕士以上）
-
P6 初级研究员 - （博士毕业生，或硕士工作2~8年，本科工作3~8年）
-
P7 副研究员 - （博士工作2年以上，或硕士工作4年以上，本科工作5年以上）
-
P8 研究员 - （博士工作4年以上，或硕士工作6年以上，本科工作7年以上）
-
P9 高级研究员 - （博士工作6年以上，或硕士工作8年以上，本科工作9年以上）
P10及以上，暂无，待后续有需要时在设置。
P10及以上的职级都为虚级、荣誉职级，因为他们通常为某领域的领导及技术带头人，职级不过是荣誉的象征，职级是虚衔，岗位才是实衔。
-
助理产品经理（P3~P4） - （应届生或工作2年内）
-
初级产品经理（P5） - （工作1~4年，可放宽到6年）
-
中级产品经理（P6） - （工作4~8年，可放宽到15年）
-
高级产品经理（P7） - （工作6年以上）
-
资深产品经理（P8） - （工作8年以上）
-
产品架构师（P9） - （工作10年以上）
P10及以上的职级都为虚级、荣誉职级，因为他们通常为某领域的领导及产品带头人，职级不过是荣誉的象征，职级是虚衔，岗位才是实衔。
管理序列，由于其特殊性，取字母M表示。
-
M3=高级经理（P8）
-
M7=公司总经理（P12）
-
M8=董事长（可以没有）
3、职位和职级对应关系（参考）
1、职级对人才是否有吸引力？
2、职级对新老员工是否公平？
为解决以上问题，我们将每个级别，暗分为3档（不公开），
真正决定你是否能从P6升到P7的，是要看你能否升到P6+，只要能，正常情况下第二年必然到P7。
这样做的好处是：在公司很大很知名的时候，可以在不提高工资的情况下，以更高的职级来吸引人，或者在面试官无法给出更高职级的时候，可以用低一级但较高的工资招收人。另外，对老员工每个职级都有3个档位可以调节，更灵活。
2.4 各级别对应的薪酬
2017年重庆参考薪资（在重庆非常具有竞争力的）：
P5-高级工程师: 19万（17~22万，15k*13） - （点评：工作三四年，核心开发，月薪15k，很有竞争力）
P6-资深工程师(初级架构师): 25万（24~28万，20k*13） - （点评：工作五六年，项目负责人，月薪20k，步入高薪行列）
P7-技术专家(中级架构师): 33万（30~35万，25k*13） - （点评：准大神级人物，经验又比较丰富，25k很优越了）
P8-高级专家(高级架构师): 42万（40~45万，32k*13） - （点评：大神级人物，经验非常丰富，32k 奠定江湖地位）
P9-资深专家(资深架构师): 55万（52~60万，45k*13） - （点评：大神级人物，又具备资深技术管理和架构经验，4万5月薪 无人出其左右）
M5 ~ M7：80万+（点评：企业领军人物，大局为重，大将风采，同企业共存亡）
P10~P12：80万+（点评：职业领军人物，主导一个大的体系，或者是特别稀有的战略级人才）
2.5 职级的补充说明
保密原则：岗级存在，但是不公开，而且是保密的。公开资料上显示岗位名称但是不会显示个人职位级别。如果需要名片或者个人工作介绍需要一个Title时，需要提交OA申请一个临时的对外Title。
隐藏职级的初衷在于公司倡导自由、平等的沟通和工作环境，大家相互之间不比职级，比的是谁成果好、能力强。
同理，个人的公开信息处，不显示员工的学校 学历 年龄，无论学历高低、学校好坏、年龄大小，都不应该成为别人对你的印象。
