下载掌阅APP，畅读海量书库
立即打开
在锚定问题及其原因之后，就可以对症下药了。前文谈到大型组织中当前普遍面临的困境是研发需求拥堵而不自知，这映射出的是组织背后的一系列潜在问题。这些潜在问题归根究底是如何提升研发效能的问题。
企业要提升研发效能，核心思路是“自组织”。自组织不只是简单的“人的自组织”，更关键的是要建立具备自组织能力的组织架构。自组织的组织架构之于传统的组织架构就类似于市场经济之于计划经济，是一种更具活力、更有利于企业资源高效、合理配置的结构。
为了打造具备自组织能力的研发组织，我们主张企业构建由组织阵型、角色体系、需求层级体系、标准流程、优选机制、稳定节奏、度量体系、反馈机制构成的八大支撑，以优化协作基础、驱动自主改进；由协作平台作为底座支撑，使协作过程和交付过程透明化，促进拉通和统一管理；由此来实现提升研发效能的目标。研发效能提升实施框架如图1-3所示。
图1-3 研发效能提升实施框架
基于这个实施框架，本书从组织战略、研发过程、人才体系、度量体系、整合管理、引导技术、技术工具、规模化等层面，深入剖析当下国内企业的研发团队普遍面临的问题和挑战，并结合我们多年的实践经验，提供具备高可落地性的改进策略与建议。
通俗地理解，组织战略就是明确企业应该朝着什么方向发展，以及做哪些事情。要让组织更好地朝着战略方向前行，需要与之匹配的组织架构。
首先，组织架构的设计与构建，第一要义是面向价值交付，只有这样才能适合企业长期发展。“要致富，先铺路”，同样的道理，要让企业里面的人发挥作用，得有顺畅的“道路”基础。当前许多大型企业的组织架构设计沿袭了工业革命以来的职能型组织架构设计。职能划分是顺应历史发展的自然产物，可提升人类创造物质财富的效率。但是随着现代企业规模的不断扩大，在知识劳动者密集的企业中（研发组织就是典型的知识劳动者密集的领域），职能型组织的劣势不断凸显。
为了更快向客户交付价值，需要不同职能的人员紧密协作，而林立的部门墙阻碍了协作。陷入这一困境的企业需要重新思考组织构建的逻辑。组织架构的设计核心原则是顺应价值流走向，明确职责体系。企业将五湖四海的人集中到一个场域内，目的是做成具体的事（做成事的效益是多面的，对外是成就客户，对内是企业盈利，对个人是通过努力而有所回报），因此，围绕“如何让大家更便捷、高效地做成事”去构建组织，同时，明确哪些人做哪些事是合理的。就像铺路的目的是便于人们更便利地抵达目的地，而不是为了铺路而铺路一样，道路也有结构，各司其职，和企业中的职责体系是同样的逻辑——不同的角色有不同的任务。但不论是什么角色，目标都是一致的——更快、更好地向客户交付价值。
其次，战略制定以及关于产品定位的思考。在商业社会中，战略对一个企业而言，就如同自然社会中，生态位对一个物种而言，是安身立命之本。强调战略和产品，核心在于组织要聚焦。因为资源是有限的，所以什么都想做、什么都做，最终只会什么都做不好。战略定位明确之后，要解决如何自上而下分解目标的问题，让整个组织都明确共同的目标，再逐步分解到各自的小目标，从而让员工个人和企业共同奔向最佳业绩。
在构建了基于价值流的组织架构、明确了不同角色的职责体系之后，需要明确大家工作的标的，也就是“具体做什么事”的问题。构建统一的需求层级体系、一套共通的描述任务的语言，有利于组织内的成员高效协同，使大家对处理的任务有一致的认知。不同人对“需求”的认知通常不会是完全一致的（甚至千差万别），尤其是涉及不同专业背景的人，如果企业内部不对“需求层级体系”进行梳理和规范，会徒增内部的沟通、协调成本。
与此同时，研发组织需要建立产品研发价值流。明确价值流，也就是解决“怎么做好每件事”这个问题。不同人完成同样一个任务的方式可能是多种多样的，但是如果放任所有人自由发挥而不加以规范，将会给企业带来高昂的管理成本，尤其随着企业规模的扩大，该情况会愈演愈烈。价值流的明确是为了让大家沿着一个相对合理、高效的路径去完成任务，同时，便于组织建立统一的节奏，降低协同的成本，发挥规模优势。当然，我们强调的是价值流，也就是说，关键在于设置任务流转中的价值形成节点，而非非常细致的、限制性极强的工作步骤，为基层发挥的自由空间保留了充分的尊重。这就类似于交通运输中的一个运输任务可能有下单、收件、打包、运送、送达等一系列的环节。要对产品研发价值流进行可视化，以使任务进展透明，及时发现问题、解决问题，持续优化研发过程管理，从而提高软件研发的质量和效率。
在此基础上建立研发节奏，也就是对研发团队的产出水平以及效率进行合理的规划。稳定的节奏是管理研发团队效能的重要抓手，能够让团队从混乱状态回归到有序状态，让需求可以有秩序地“流动”起来，需求交付也更加可靠。很难想象，倘若火车系统没有规定每列火车能够运载多少乘客或者货物、发车频次等，那会造成多么混乱的局面——乘客永远不知道该什么时候去买票乘车，也不知道能不能乘上车，更不用提什么时候能够到达目的地了。
在厘清“事”之后，还要关注“人”。
以测试团队为例。由于测试人员通常分散在不同领域的研发团队中，要对他们进行长期的能力规划与建设难度很大。因此，我们建议横向拉通，建立测试行会，汇聚测试人员的力量，解决研发组织发展过程中在测试领域面临的共性问题，以提升组织长期的交付能力。
在搭建了一系列体系、流程和方法之后，为了确保组织运行起来且不走样（主要是指偏离搭建机制时的预期目标的行为，而非改善的举措），需要有一支队伍以组织效能提升优化为目标，来维持可持续发展的组织数字化的规模化运行机制，本书称之为效能行会。效能教练是组织管理者很重要的参谋，在研发效能数据解读、组织持续改进方向等方面，可提供专业的建议，以辅助决策，不断驱动组织改进与成长。
在梳理好了“如何做好研发”的基础上，接下来思考的是“如何做得更好”，毕竟，人总是朝着更好的未来前进，由人构成的组织也是一样的。要想成长为更理想的模样，先要对自身当前的状态有清晰的认知，才能够明确改进点在哪里。因此，建立度量体系，以更量化的形式，让组织“看见当下的自己”，洞悉改进方向。度量体系设计的合理性是一方面，但是很多时候大家往往会忽略其背后的许多前提与基础——组织的数字化水平，包括协作、管理等数字化程度，以及数据与事实的贴近程度。前提与基础的可信度，决定了组织看见的是否是真实的自己。如果看见的不是真实的，那么改进的方向往往也不会是对的。通过度量体系，照见自身，寻找改进方向——建立组织复盘反馈机制，即建立一套“分析现状、洞察问题、出具方案、效果检视”的良性循环机制，不断驱动组织有针对性地改进。
前面谈了组织战略、研发过程、人才体系、度量体系等层面的设计原则和逻辑，如何让这些层面有机地结合起来，需要相应的整合管理办法作为动态机制，串接起具体的人、事、信息。由此，本书中引入了敏捷项目管理与版本火车两个概念。
区别于需求层级体系与研发价值流所描述的，针对单一研发需求的管理机制，项目管理的标的是相对宏观的，需要达成某个组织战略目标的任务事项集（不同项目的颗粒度或有所差异）。一个项目范围内的任务事项，可以拆分为许多具体的需求。在任务繁重而人力资源有限的情况下，如何有效整合资源、充分释放效能、高效完成任务以支撑企业战略目标的达成？具体要做些什么？哪些任务优先做？出现变化如何应对？需要怎样的风险防范措施？敏捷项目管理就是用于解决这些问题的。
一个敏捷项目往往需要企业内跨职能、跨团队的紧密配合。而版本火车则是就业务与科技双方之间的融合、力求提升研发交付效率的一个更具针对性的协作机制。通过一系列细致的“买票”“检票”“到站”等环节机制的设计，使需求状态透明、促进需求有序流动，同时规范需求提出方（业务）和需求接收方（研发）对需求的把控：需求提出方提出需求更为精确，需求接收方理解需求更为透彻、开发更为高效，使双方减少摩擦，增进相互理解，进一步促进正向循环。
为了长期保有企业的活力与竞争力，文化的牵引力量也不容忽视。文化的牵引力量之所以强大，在于它能够在无形之中渗透到组织精心设计的各种机制与办法无法覆盖的方方面面。机制与办法再精细与完善，也无法涵盖所有的可能性。人具有主观能动性，文化的作用就是能够在机制无法形成约束的地方，潜移默化地影响人的行为。研发团队处理的是不确定性和复杂度很高的研发工作，需要给予研发人员更充分的发挥空间，企业要基于研发组织的特点，打造与之契合的文化氛围。本书提供了仪式、协作和工作坊等更为落地、开箱即用的有趣实践，以打造文化氛围、强化团队之间的情感联系与组织认同感。
组织要高效运转，除了柔性的引导技术，还离不开一些硬性的技术工具的支撑。事实上，若要顺利落地前文所述的一系列流程办法、度量体系，软件研发数字化管理工具的支持是必不可少的。尤其对大型组织而言，随着业务量的快速增长，如果只依赖人工的推动与统计，不仅要耗费高昂的人力成本，而且收效甚微——数据沉淀不下来、远程无法协同、信息无法及时同步、度量无依据，数据驱动改进更是无从谈起，因此工具是必要的。
此外，引入业内有效的工程实践显然有助于研发效能提升。本书从软件设计、自动化测试、代码评审、版本控制与分支管理、持续集成、数据库变更、容器DevOps（研发运营一体化）实践等方面，为研发团队专业能力提升提供高可落地的实践参考。
本书第九篇将进行总体回顾，帮助读者对软件研发数字化管理能力建设和软件研发数字化管理规模化推广两个主题建立更清晰的全貌认知，快速构建规模化推广路径，并把主要的方法和实践有机地连接起来。
