本文是《IT研发中心管理思路、策略和制度》专题的一部分。
本文针对于中小公司设计，研发人数在50~1千人。
建议提前阅读：
前言：总体思路
打破传统架构那样的一个个封闭的部门和团队，让他们以多元的形式更好地配合，避免冗余和不一致给中后期带来的不利影响。特别是基础能力和技术，非常有必要形成统一的力量。当然，其他的，比如说业务，当业务越来越多的时候，也趋向于凝聚、沉淀成基础的共享能力。
举几个例子：一个叫做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级成员），而且又和产品研发团队同属于开发性质，可共享人力资源池。
完美！
但是经验丰富的人可能会说：组织安排清晰、妥当了，并不代表组织一定能按预期效果运转。是的，还需要与这种组织方式配套的工作流程，绩效管理，人才管理，组织文化等方面共同作用。重点是 与该组织架构配套的 工作流程，每个人做事的方式，和传统的也不一样，但是这篇文章不讨论，本文重点讨论的是组织和岗位设计，其他方面参见其他文章，如《IT研发团队管理、人才治理经验》。
另外，如果研发人数少于50人，则不能照搬，需要精简，但很多思路是相通的，可以参考。
虚拟组织（半虚拟的组织，大多数人是兼职）
虚拟组织工作方式：
1、大多数成员为兼职，仍然要参与产品研发部的日常工作；
除了少数身兼数职或特殊岗位的人员外，绝大多数人都会参与到产品研发团队中。
2、工作安排灵活，可由成员自由发起某项工作，通过评审和领导审批即可去做；
3、虚拟组织内部，设置1个或多个负责人，例如部长、副部长、组长、副组长，主要负责统筹规划和评审等各项工作。
虚拟组织负责人，对其成员的管理，侧重于专业技艺，个人发展和激励等方面，氛围很OPEN。
顶级虚拟组织：研发组织部（0级）、研发管理部（一级）、安全管理部（一级），由研发总监（P10）亲自领导。(后文有详细说明)
一级虚拟组织：产品与设计部，由 资深产品专家 / 副总监兼产品总监（P9） 领导。
二级虚拟组织：产品管理组，产品研究组，UED(用户体验设计)。
产品管理组：由各个项目产品的负责人组成。
产品研究组：负责统一的产品规划和产品体验等研究。
UED(用户体验设计)：由 资深设计师 领导，UI 和 UE 组成。
一级虚拟组织：技术与架构部，由 高级技术架构师 / 副总监（P9） 领导。
二级虚拟组织：技术管理组（由 架构师 / 总监助理P8 领导）
二级虚拟组织：专业技术组（以技术领域区分的 各领域技术专家P6~P8）
专业技术组 包括：
前端技术组，网络技术，安全技术组，测试架构组，Android/iOS技术组，大数据技术组等。
一级虚拟组织：基础服务与创新团队（简称“基创”团队），通常由技术管理组组长（P8）领导
二级虚拟组织：测试服务部，由 测试专家（P7） 领导；
三级虚拟组织：自动化测试组，性能测试组，安全测试组。
（注：安全测试和性能测试 由 技术架构部的安全技术组和测试架构组支撑）
二级虚拟组织：运维管理部，由 运维专家（P7） 领导；
二级虚拟组织：系统运维组，中间件运维组等。
虚拟组织说明
1、研发组织部
类似于“阿里组织部”，主要由各组织的leader组成，每个成员都是一个组织的代表，组织部会定期召开会议。
负责研发管理策略的研究，以及各种研发流程和制度建设，并检查其执行。
积极推动研发能力提升、研发成熟度提升（规范化、可复用、可优化、最佳实践），使各个项目都遵循产品和架构组相关的规范和最佳实践，达到较高的研发水平和标准；推动架构/产品/技术的优化和整改，推动统一技术平台的实施和落地等。
促进和提高队伍的研发能力，强化研发队伍，做好人员招聘，新员工入职引导和培训，积极推动和组织各种技术交流/培训活动。
组成人员：由研发总监直接领导，组成人员包括 副总监/总监助理，各一级虚拟部门的leader，加上少量核心资深的产品经理和架构师，以及一些非技术类“研发管理岗”(下面有介绍) 负责人组成。
2、研发管理部
一个行政事务和综合事务机构，服务于整个研发中心，其事务主要由研发中心负责人和研发组织部下发，比如研发中心的员工招聘、入职引导和培训，活动组织等人力和行政工作，以及跟踪研发流程、制度的执行，考核数据收集整理等综合管理工作。
组成人员： 综合管理，非技术类的“研发管理岗（行政+综合管理，下面有介绍）”，研发总监任部长，可以由副总监主持工作，也可以总监亲自主持工作。
岗位类型：
研发管理岗（组织及管理事务）：（招聘人数1~2人）
负责推动和跟踪各种规章制度的执行；
负责项目的全生命周期进度管理及组织协调，通常会跨部门/中心工作；
负责制定和维护研发相关的表格、文档，管理部分研发相关的系统和数据；
研发管理岗（人事及HRBP）：（招聘人数1~2人）
熟悉IT领域业务知识和人力招聘知识，为业务部门招聘专业人才；
负责研发中心的新员工入职引导，协助办理离职、入职等手续；
对接公司的人力资源及财务部门， 负责薪酬福利方面的工作；
协调员工关系，组织团队建设和培训，关注人才成长并负责绩效辅导。
研发管理岗（行政和综合事务）：（招聘人数1~2人）
对接公司的财务及行政部，为IT部门提供办公用品、财务支持；
负责统计和维护部分数据和内部系统，如考勤、通讯录等；
负责研发中心各类固定资产的管理和维护；
负责会议室管理，工位/办公室管理；
其他行政事务管理：接待，签到，会议组织等。
行政/综合管理的对象包括人、财、务，就像一个大管家。
行政/综合管理岗位也分为初、中、高级，高级行政/综合管理要能站在领导的宏观高度，进行规划、规范、组织、协调和督促。
通用岗位要求：
优秀的人际沟通协调能力、亲和力，有较强的文字表达能力；
诚信正直，品行端正，公正客观；
工作细致认真，做事有条理，责任心强，执行能力强；
大学本科及以上学历，行政管理、汉语言文学、计算机等相关专业优先；
有行政、人力相关工作经验优先；
熟悉研发工作和技术，有过产品、开发、测试、运维等岗位工作经验优先。
2、安全管理部
由安全管理专家担任副部长（主持工作，通常由安全技术组的组长兼任），加上弱技术类的“安全管理岗”1~2位人员组成。
安全管理岗：（偏管理、弱技术岗位，要求具备一点点系统运维知识）
推动安全治理体系、管理体系和技术体系的建设和实施；
负责研发中心重要资料、账号的管理和维护；
研究非信息技术相关的安全问题和风险控制（办公环境安全，法务，管理风险，舆情等）。
岗位要求：
具备很强的安全意识，工作认真细致，做事坚持原则；
具备较好的人际沟通协调能力，具备一定的管理能力；
有过安全测试、运维和DBA(数据库管理员)、法务等岗位工作经验优先。
3、技术管理组
负责各产品线组的日常技术类管理。协调开发人员工作，参与工作量评估、技术方案评审、代码走查等工作，领导解决各产品线组的技术难题，线上故障，并做好防范方案。对研发质量负责，协调测试、安全人员工作。
负责各个系统的架构。使其满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新，并且识别非功能型需求，做好技术选型、技术架构风险识别和评估。
参与各种技术规范和最佳实践的研究和制定，并负责在各个项目组内落地实施，让各项目达到一致的研发水平和标准。
组成人员：应用架构师（需要 有丰富的应用设计经验和资深的技术水平），建议1个架构师服务3~5个产品线，任该产品线组的技术经理。(技术经理，虽然侧重于技术管理，但仍然具有一定的管理性质，需要具备基本的管理能力和责任心）
工作方式：架构师必须得熟悉自己负责的项目使用的技术及重要的功能，对于特别重要的设计，需要多个架构师参与讨论和评审。
技术管理组的应用架构师，相对于传统的一个项目一个技术经理的配置，更能优化和节省高级技术人员，而且他们都隶属于技术管理组，方便交流和沟通。
4、产品管理组
参与筹建产品线组，或者撤销产品线组。
负责各产品线组的日常管理，类似于项目经理，不但要统筹产品研发工作，还要负责管理好团队人员。偏业务和管理，建议从资深/高级产品经理中选拔，业务能力占40%，项目和管理经验占30%，管理能力、责任心等占30%。
负责各个产品设计，并推动产品的研发和落地使用或商业使用。协调产品经理/助理、UI/UE设计师、运营等工作。
组成人员：高级/资深产品经理，建议一个人负责1个产品线组，任该产品线组的项目经理。
工作方式：全权对产品和项目负责，有权组建新产品项目组，在技术经理的辅导下完成对项目组所有团队人员的管理。
5、测试架构组
强技术岗位，由测试专家组成。
建立健全测试体系，将测试意识，测试工具，测试流程，渗透到研发的各个阶段。让测试工作能在研发团队高效的开展。
另外，负责一些复杂的测试，比如白盒测试、性能测试和中间件测试，涉及Linux、网络、各种程序等，需要具备较全面的知识，能参与到系统架构中去，辅助架构设计，参与中间件选型的测试。可以由技术架构师兼职。（注意：安全强相关的测试，放到安全技术组去）。
举个例子：生产环境，有些测试验证很难做，因为生产环境必须要真实数据，比如真实的商户，真实的“新”客户，真实的大额资金转账等。这时，就要论“测试设计，测试数据”的重要性了。比如上面的场景，可以设置一些模拟的接口，模拟真实场景，但是却能区分测试数据，在某些不方便测试的地方，做Mock。或者设计一个反向操作，设计一种方式可以清除测试数据。（只针对核心业务场景，专门设计，其他非核心的暂不考虑）。另一种方案，放入极小部分真实的流量做测试，这时不能在UI上操作，只能在后台看日志，所以关键流程的日志一定要有，而且最好是能聚合在一起方便查看，注意这个方案有一定风险，毕竟是真实客户，出了问题要有处理方案，最好是能控制到放入流量的用户数量。
测试平台，测试模拟器等，也都需要由测试架构组牵头设计和研发。
6、安全技术组
强技术岗位，由信息安全专家组成。需要具备较全面深厚的知识，以及很强的动手能力。
负责研发中心一切信息安全技术相关的事务，比如应用安全、系统安全、中间件安全、网络安全等。（行政相关的工作，则可以通过安全管理部去下发和跟踪落实）
安全专家：熟悉漏洞、病毒原理，会渗透测试，有一定开发能力。
7、网络技术组
强技术岗位，由网络技术专家组成。
负责网络技术研究，对研发中心各个组织（开发）提供网络技术支撑，并主导网络相关的事项。
网络技术专家：熟悉或精通各种网络技术、网络设备，包括公有云网络和网络虚拟化，深入理解网络原理，具备一定编程能力。
8、运维架构组
强技术岗位，由运维架构师组成。
牵头运维自动化、智能化的整体设计和技术研究。包括运维基础设施的自动化管理（参考cmdb、ansible、阿里star-agent等），容器云平台架构，底层存储（参考CephFS、GlusterFS、NAS等），CI/CD及DevOps一体化运维平台，全维监控体系，智能告警、日志采集，运维大数据平台（与大数据技术组共建），使用ChatOps、AIOps技术构建智能运维平台。
注意，这个组做的事情，有些需要其他组的人配合。
9、其他领域的技术组（前端技术组、大数据技术组等）
由该领域的专家领导，该领域的所有专业技术人员均为成员，但几乎都为兼职，日常以自己的项目工作为主。
专业技术组，负责专业领域的技术研究，并将研究结果应用于开发、测试、运维等团队。另外，会定期组织技术分享、培训，也有可能会集思广益，做一些架构研讨。
运维管理部
运维的整体设计思路，借鉴与目前越来越主流的DevOps、微服务运维、容器云运维、AIOps方法，使用各种工具，及自研运维工具，将运维工作减少60%，剩下的20%由研发团队借助自动化、智能化运维工具自己做，最后运维团队只剩20%的工作，这20%主要侧重于管理。运维团队的其他时间，可以用来研究运维相关的底层技术。
另外，将中间件运维单独出来，成立专业的中间件运维组，由精通某中间件的人（可以是运维也可以是开发），负责该中间件及基础平台的运维，例如Kafka、Redis、HDFS、SeaweedFS、MySQL、MongoDB、Etcd、Kubernetes等。
除了中间件运维，其他运维工作（包括简单的网络操作），都由“系统运维组”负责。
注意，这里没有网络组，简单的网络运维操作，比如开策略、简单的路由防火墙配置等，都交给安全管理组、系统运维组做了。为了让网络技术更专业，将成立网络技术组，放在技术架构部下，专门负责网络技术研究，做网络架构及解决网络疑难问题。
PS：我发现知乎上有篇文章《阿里巴巴正在“杀死”运维》，和我的思路比较接近。
“2016年的时候，阿里巴巴技术团队经历了一次非常大的调整：把日常的运维工作交给研发做。
原来的 PE（Production Engineer）要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应的只能黯然离开。
这是阿里运维从工具化到自动化的过程里，最重要的一步。以前运维团队需要支撑集团非常多的BU，干的都是脏活、杂活、累活。”
实际上，阿里也都是学的国外的做法：
Netflix 从一开始就强调开发人员进行自助化运维，他们的理念是：谁构建，谁运维。其运维工作全部由开发人员完成，只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是电商业务还是 AWS 公有云业务，都由开发负责。
我设计的这个运维部，是一个高度自动化运维之后的一个偏产品、研究和管理的组织，他们是真正的运维专家，我期望他们少干脏活儿、累活儿、杂活儿，做这些的时间不超过20%，如果超过这个时间，就得考虑改进，短期内将一些技术含量低的工作，交给外包或者实习生。
系统运维组
1、系统运维（偏应用运维方向）
熟悉或者精通linux系统及常用工具，熟悉网络技术，熟悉虚拟化和容器技术，熟悉shell编程，熟悉监控和问题排查，熟悉各种运维工具，熟悉各种常见应用和中间件的部署和配置（nginx、mysql、redis、tomcat等）。
2、系统运维（偏主机和网络维护）
说明：如果主机和网络维护的工作量不多（小型的数据中心），可以由应用运维兼职！（如果使用云服务器，也可以不招聘这个岗位的人）
中间件运维组
上面已经介绍了，中间件包括MQ、Redis、数据库、分布式存储等，还包括一些大数据的东西。传统的运维人员根本搞不定这么多，得由研发专家、架构师兼职，且优先考虑自动化、智能化运维。某些方面也可以或需要和系统运维结合。
运维岗位的具体定义参见：《 研发中心各个岗位的设计和配合》
基础服务与创新团队
基础设施研发部（Core Infrastructure）
负责实用类技术创新工作，研究和引进新兴技术和工具（包括但不限于前端、后端、大数据、开发、运维等），研发具有自主知识产权的技术类产品，并负责研发和落地实施。
促进运维、测试、开发（后端、前端、移动端、大数据）等相关效率的提升。负责搭建公共技术平台&创新平台，主持研发基础组件、中间件等，包括但不限于 统一配置中心，自动化运维平台，基础大数据平台，基础开发框架，基础UI框架，自动化测试框架等。
组成人员：由系统架构师和各类技术专家组成，副总监/总监助理/高级别架构师担任部长（建议与技术管理组组长为同一人），根据需要，成立临时或长期的项目组，选拔负责人，并分配中高级开发人员。比如：
统一配置中心项目组
基础开发框架项目组
流程引擎项目组
这些临时或长期项目组，都 直属于 基础设施研发部。
另外，可以单独设置平行兄弟机构：创新研究院，专门负责前沿高新技术产品的研究。
无论是基础设施研发部还是创新研究院，都可以承接产品类的研究和开发任务、有产品经理参与。
产品研发团队
包括各产品业务线 或 独立项目团队，负责完整的产品研发（产品设计、开发、测试、运维等）。例如：
--会员产品线
--微商城
--营销产品线
--开放平台中心
--交易平台中心
--....
项目组主要受“产品与体验部-产品管理组”和“技术与架构部-技术管理组”共同管理。产品研发团队成员的日常工作管理和考核，主要由产品项目经理（PO）和技术经理来负责，但他们都不是固定岗位。每个组内，产品、开发、测试等各司其职，由高级的人员带低级的人员，项目计划由产品和开发根据产品部和架构部的指导自己协调。
问题一：产品研发团队与公司的其他部门（销售，运营，管理......），是如何组织的？
答案：以人为单位来看-->
1）人员的组织安排，是以其岗位和职责来确定的，换句话说，他的工作重心在哪里，他就应该在哪里。
举个例子：市场部，张某某，参与辅助产品A的市场推广和运营，属于产品和市场客户之间的一个桥梁，但是他花在产品研究和测试上的时间达到了40%，而且他的工作对研发团队有着巨大的影响。但是张某某的职责还是属于市场推广和运营，他不是产品，也不是测试，而且他也不具备产品或测试的专业能力。市场部觉得他工作做得不好，可以换掉他；产品项目团队觉得他很重要，可以将他借调或者划归过去，甚至可以转岗。
2）跨部门之间的任务协调，如果两个人熟悉，可以直接点对点直接分派任务。如果双方不熟悉，通过双方的共同上级组织和领导，也可以快速分配和执行任务。
举个例子：客服中心，邓某某，时常需要研发团队的支持，或反馈一些问题，研发团队也有跟踪解决，但是邓某某是为客服中心服务的，她和研发团队双方之间的任务推动，可能要经过各自的上级组织和领导进行沟通。（前提是双方的上级，一定是可以顺畅沟通、达成一致的，在这个例子中，邓某某如果对研发组成员熟悉，目标清晰，她也可以直接跟该成员沟通并发起任务，最坏情况下，邓某某对研发组成员不熟，她想要给研发组发起任务，就要通过两个组织的上级关系的连线进行：邓先提交任务给自己的直属领导A，A与研发团队无直接关系，则A自动往上抛，抛到上级运营总监B处，而运营总监B和研发部的几个负责人熟悉，所以他可以直达研发部的许多个负责人，目标明确后，他可以直接把任务转到某个研发部负责人或联络人处，然后再由那个人决定将这个任务分配给具体团队的leader，再由leader分配给个人，说白了，就是通过关联关系，把所有员工串联起来，借助办公系统，还可以达到半自动化，任务很快就能推动起来）
总结：
1、任务流转是公司管理的核心机制，任何人都可以给其他人分配任务，这种机制是跨部门适用的；
2、公司整体机制是，人员可以跨部门调动，或者跨部门任职的，
3、有隔阂的实体部门之间，一定是有某种有效的沟通的，例如跨部门的虚拟组织，或者领导与领导之间的共同组织，所以两点之间一定有一条或者多条连线，通过任务的跨部门流转机制，所有不同部门之间的配合都会变得很容易。
建议：公司成立一些跨部门的虚拟组织（例如xxx领导小组，xxx委员会，xxx管委会，xxx专项小组），将各部门leader和重点负责人紧密联系在一起，责任也一起承担，同呼吸共命运，让高层之间、跨部门之间的沟通顺畅，顺畅到双方的沟通一句话就能达成，顺畅到跨部门的配合能形成默契，通过任务流转机制，任务就能快速发起和执行。
任务的跨部门流转，存在一个细节上的问题：研发人员都通过办公系统做在线任务分发，如果其他部门人员不用这个系统怎么办？解决方案：将在线任务分发系统，推广到全公司使用；至少可以推广到，与研发相关的协作，都通过任务分发系统进行；再退一步，即便其他部门不用这个系统，则可以通过研发部中介人进行任务中转，这个中介人不一定是研发总监或者副总监，研发总监可以安排一个或几个作为对外联系人，这样就可以将其他部门的任务转换成研发系统内部的任务。
具体岗位安排（举例）
注意1：
某管理岗位如果空缺，则由上上级负责管理，或者指派特定人来临时负责。
通常，某人任某部门经理，就不再任其下级部门的管理岗位（特殊高端岗位除外）。
注意2：
岗位状态有 正式、临时、自由三种，该岗位的正式、临时成员，受该组织的上级管理，而自由成员，不受该组织的上级管理。一般来说，需要比较长期的参与到某个岗位的工作中，但是却不能受控于这个岗位时，处于该岗位的'自由'状态。
张莫某
职位/岗位：
<研发中心>研发总监 [正式]
<研发中心.研发管理部>部长 [正式]
<研发中心.技术与架构部.运维技术组>中间件技术专家 [自由]
职级：P10 - 资深架构师
（技术与架构部 部长空缺，由研发管理部部长直接负责）
刘莫某
职位/岗位：
<研发中心>总监助理 [正式]
<研发中心.技术与架构部.基础技术组>组长 [正式]
<研发中心.技术与架构部.技术管理组>架构师 [自由]
<研发中心.技术与架构部.测试架构组>性能测试专家 [自由]
职级：P8 - 架构师
黄某某
职位/岗位：
<研发中心>副总监 [正式]
<研发中心.产品与体验部>部长 [正式]
<研发中心.产品与体验部.产品研究组>产品研究员 [自由]
职级：P8 - 高级产品专家
注意，上面三个人，职位很高，根据规则，他们不兼任下级部门的管理岗位，但是，在下级部门不完善、人员不足的时候，他们会身兼N多岗位，只不过他们属于这些岗位的“自由”成员而已，比如技术总监，可能亲自担任应用架构师、平台架构师、安全测试工程师、中间件运维工程师等等。
李某某
职位/岗位：
<研发中心.产品研发部.会员产品线>Java开发工程师 [正式]
职级：P4 - 工程师
说明：像李某某，这是最底层的开发，只有一个岗位。
王某某
职位/岗位：
<研发中心.技术与架构部.技术管理组>应用架构师 [正式]
<研发中心.技术与架构部.测试架构组>组长 [正式]
<研发中心.产品研发部.会员产品线>技术经理 [正式]
<研发中心.产品研发部.开放平台中心>技术经理 [临时]
<研发中心.运维保障部.中间件运维组>Redis运维工程师 [正式]
职级：P7 - 技术专家
说明：像王某某，这种中层技术人员，身兼N多管理和技术专家岗位，这是常态。
答疑
1、有人说，应该把测试、前端、大数据、网络等全都独立成部门：测试部、网络部、大数据部等。
回答：不赞同。其实是相对独立的，但不是完全独立的。
完全独立的坏处应该不用多说。把他们分成虚拟组织，其实考虑到他们都是研发团队中的一员，只不过技术方向不同，但本质上都是做技术的。整个研发团队有两部分：1）产品研发团队，2）基础设施研发及创新团队（简称“基创”研发团队），前者的项目按业务区分，后者的项目按技术区分，业务与业务不一定相同，技术与技术也不一定相同，举个例子，产品研发团队有“网上商城”项目和“运营平台”项目，基础研发团队有“容器云平台”项目、“自动化测试平台”项目和“大数据分析平台”项目，把他们放在一起，并没有不妥，并不一定非要按运维、测试、大数据这样来划分部门，部门对管理的危害远远大于项目组。
工位形式
1、由研发行政管理人员安排和协调，原则上不固定工位（工位都是临时的），但同组织的人最好是坐在一起，方便沟通，一般按 项目团队、岗位性质（产品、测试、开发、运维等）、虚拟组织等因素 划分区域，优先按工作重心来协调工位。行政管理人员根据情况可以随时调整大家的工位。
例1：“理财产品专项组” 的大部分人员集中在B区域，另外，给产品经理、技术经理留一个位置，产品经理、技术经理可以在这里办公，也可以在各自的“总部”办公。
例2：“运维保障部”人员集中在C区域，可以认为这个区域是运维人员的“总部”，但是个别运维人员也可能进驻到项目组。
2、中高层的管理者，建议设独立办公区、或者办公室，可选的人包括：研发中心的技术总监/总经理，副总监，总监助理，以及大部门的经理、副经理。这就好比军队中的统帅，通常不和小兵坐在一起，一来突出领导的威严、地位与特殊性，二来是掩盖领导的隐私、避免重要的谈话被人听到，或者重要的资料被人看到，三来是安静的空间方便领导的思考和决策。
3、一些特殊的岗位，也可以设单独的办公区、办公室，比如专门负责策划和架构的高级架构师，专门负责高精尖技术研究的专家，为这些高级人才、且单兵作战的那种，安排比较安静的空间，另外像负责人力资源、财务方面，需要一定隐私的也应该安排单独的区域。
管理形式
每个员工，都有一个或多个上级领导，有若干个岗位，每个岗位有一个岗位负责人，对于他的每个岗位，有一个或0个备份人员。
比如，张三，他是一名 中级自动化测试工程师（P5），他目前身兼两个岗位：
岗位1：理财产品项目组 自动化测试工程师，该岗位有一个备份人员 李四。
岗位2：开放平台项目组 自动化测试工程师，该岗位无备份人员。
他的日常工作，主要由这两个项目组的技术经理来安排。
同时，他也是 测试架构组（虚拟组织）的临时成员。测试架构组的组长，也可能会给他安排任务，但如果有冲突，需要和项目组的经理商量。
以上，部分经典参考资料：
《Spotify的敏捷管理（部落、小队、分会和协会）》：
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify