3.3 组织闭环

大部分研发型组织主要会考虑专业分工和成本利用率两方面，最常见的是如图3.4所示的严格职能型组织架构。一个标准的软件研发流程，从产品经理和用户体验/开发团队讨论新功能想法开始。开发团队再将想法实现为代码，之后代码被移交给测试团队和数据库管理团队，这中间涉及团队之间的沟通和协调。产品上线之后又涉及和运维团队（系统、网络和存储等）的沟通和协调。严格职能型组织很容易产生孤岛效应，或者说竖井效应。每个职能团队都想成为舞台中央的明星团队，各团队容易各自为政和局部优化，所以严格职能型组织有沟通开销大、研发流程缓慢和反馈效率低下的问题。

图3.4

有一些公司会更进一步组建所谓基于产品线的跨职能团队，负责整个端到端的研发活动，如图3.5所示。跨职能团队有助于提升效率并强化反馈环，这也是国内外主流互联网公司采用的组织模型。但只要团队基于单块（monolithic）应用的开发和交付模式，就难免产生跨团队间的移交、沟通和协调活动，整体效率仍然受限。

图3.5

图3.6所示的是Netflix采用的基于微服务和PaaS平台的DevOps组织模型。跨职能的产品团队基于可独立开发、测试和部署的微服务而组建，支持端到端的研发活动；平台团队则在AWS云的基础上提供PaaS基础服务平台，将微服务基础设施、发布和监控等基础能力封装在平台内，支持开发团队进行微服务的自助式（self-service）部署。这个组织模型减少了组织间的孤岛，强化了团队内的反馈闭环，最大化了研发和交付的效率。当然，这个组织模型对技术能力和基础设施的要求更高，需要微服务架构体系、自动化部署和PaaS平台等技术手段的支撑。

图3.6