下载掌阅APP，畅读海量书库
立即打开
在复杂的软件研发管理领域，为了更清晰地定义其中的管理概念，我们需要缩小问题规模，在更简洁的上下文中给出准确的定义。通过多年的管理咨询实践，我们归纳出软件研发管理需要关注的3个核心问题：目标管理、人员管理和软件研发管理。
Adapt（Agile Development Agenda for Product Tribe）框架基于这3个核心问题划分出对应的战略规划、人员管理和研发过程管理这3个问题域，本节将进行详细说明。
战略规划域主要关注团队的目标管理和路线规划，同时支撑组织的目标分解和向下同步。在战略规划域中，核心的3个管理概念是产品、系统和项目。
产品是指为满足消费者需求而生产的物品或提供的服务。它可以是有形的实物（如服装、食品、电子产品等），也可以是无形的服务（如保险、咨询等）。
产品作为企业中长期创造客户和业务价值的管理单元，通过合理的分层能更好地帮助企业梳理价值流动网络，制定核心战略。在企业发展规划方面，产品天生具备长期视角，产品的长生命周期鼓励组织思考在较长的时间跨度内应该做什么事情。在资源管理方面，产品作为企业与客户互动的价值载体，可以拉通组织的价值交付主线，协助组织找准发力点，形成行业优势。在人员培养方面，围绕产品建立团队，可以在产品研发过程中沉淀领域知识，在技术创新等方面形成积累。长期磨合的产品团队，其效率远不是临时组建的团队可以比拟的。
虽然推行产品制已慢慢成为企业的共识，但我们发现很多企业中的产品制转型举步维艰。“到底什么是产品？什么是具体的金融产品？什么是系统？手机银行算吗？”是我们在推行产品制的企业一线常听到的声音。如果组织对产品本身的认知都不一致，产品制转型又从何谈起？
在金融组织中，根据面向客户的差异，可以规划可售产品、业务产品和数字产品。
（1） 可售产品 。在金融组织中，我们将具体的、具备金融属性的产品定义为可售产品（如5年定期存款、10年期国债、某一只理财产品、个人首套住宅按揭贷款等）。可售产品拥有在监管机构备案的产品号，在产品报备、资金户/托管户动账、财务记账等一类场景下出现的“产品”指的就是可售产品，这类产品主要用于满足财务、售后、企业日常运作等视角下的精细化管理的最细颗粒度要求。对一个金融组织而言，可售产品的规模通常是十分庞大的，为了便于业务板块管理的管理需求，需要对可售产品进行抽象与归类。可售产品这类产品的产品数量较多，不适合为其设置产品经理。
（2） 业务产品 。在可售产品的基础上进行一定程度的抽象，我们即可获得业务产品，可以将其理解为银行业内经常提及的“金融产品”。例如，许多银行针对中小微企业推出的各种供应链金融产品、针对个人客户推出的各种货币基金产品。每一类业务产品中可能包含许多具体的可售产品，一款业务产品通常适用一套业务流程，里面的可售产品涉及的相关属性（如利率、额度、期限、合约等）是一致的，只不过具体的数值有差异。例如，某款小微企业的融资产品可能对不同的企业利率和额度都有差异，但本质上其业务属性是一致的——都是针对小微企业，都是资产类业务，都适用同一套业务流程。
业务产品作为业务视角下的能力建设单元，其管理目标是通过规划产品能力集合巩固企业生态位，需要配备专门的产品经理来思考长期规划与建设问题。
根据不同的抽象程度，可以划分出不同层级的业务产品。例如，个人贷款这一业务产品就可以涵盖所有的对个人的贷款类产品；而个人信用贷款也属于业务产品的范畴，只是其抽象程度没有个人贷款的高。
（3） 数字产品 。和业务视角下的可售产品和业务产品相对应，科技视角下的能力建设单元是数字产品。随着业务发展和技术提升，越来越多的业务产品需要数字产品的支持，数字产品和业务产品会形成多对多的关系。
在数字产品中，一类是关注科技基础能力建设的技术平台产品。例如，供应链金融产品尽管在业务产品层面会因为客户是供应链中核心企业的上游或者下游而区分出两类业务产品，但是从银行内部研发团队的视角看，不管是上游企业还是下游企业，调用的是同样一套科技交付能力单元。因此，我们会将这两类业务产品背后的能力单元视为一款数字产品，其数字化的特征体现在银行与客户的互动过程中。相较于传统的线下申请、人工层层审批授信的方式，数字产品使用全流程在线操作——在线收集客户数据、系统模型在线分析贷款额度与利率水平、在线放款、“贷前、贷中、贷后”风控体系在线监控。
数字产品作为科技交付能力的基础单元，其管理目标是利用技术手段不断优化价值交付过程，因此同样需要配备产品经理以进行规划和建设。
另一类数字产品是强调支持核心业务与客户经营、提升用户体验的业务平台产品。例如，手机银行App也是典型的数字产品，对内会同时对接许多不同的系统，面向外部客户则提供发生业务往来的平台，具备支撑业务价值快速实现的科技能力。
数字产品和系统都是战略规划域的规划单元。其中，系统是最贴近功能实现的建设单元，在简单的产品体系中也能较好地承担规划单元的职责。随着企业发展，业务产品到系统的映射关系开始变得模糊不清，此时需要增加数字产品作为新的规划单元重建业务和科技间的沟通桥梁。
数字产品作为一种科技能力的抽象，和系统是多对多的关系，即一个数字产品需要多个系统进行支撑，一个系统也可能同时服务于多个数字产品。
在计算机科学中，系统通常指计算机系统，即由硬件、软件和数据组成的整体，它们相互协作以实现计算机应用的功能。计算机系统通常由操作系统、应用、网络等部分组成。
在组织发展的初期，业务模型相对简单，只需有限的系统就能很好地满足业务需求。在这个阶段，业务产品和系统的映射关系十分简单，系统虽然是科技视角下的功能建设单元，此时也能承担规划单元的职责。
随着企业发展，业务场景逐渐趋于复杂，业务产品和系统的映射关系开始难以维护。如果仍然使用系统作为规划单元，在业务边界不清晰的情况下，任何功能都可能在系统上堆砌。长此以往，系统的业务场景和架构越来越复杂，系统和业务产品的映射关系也越来越模糊。系统架构快速腐化，变得难以修改，导致研发团队对业务的响应能力大幅降低。
微服务的兴起使越来越多的研发团队开始重新审视系统的架构和职责范围。研发团队开始尝试设计职责单一的服务单元，将系统承载的复杂业务逻辑进行拆分，构建具有可扩展、支持弹性伸缩的高可用整洁科技架构。虽然微服务概念在科技领域大放异彩，但业务功能和微服务的映射关系仍十分复杂。微服务作为科技视角下的建设单元，尚不能很好地承担“共同语言”的职责，也不适合作为组织的规划和管理单元。
在Adapt框架中，我们建议仅将系统作为研发侧的建设单元，承载产品的基础功能建设。
项目是为创造产品、服务或成果而进行的临时性工作，而项目团队则是为交付项目而组织的跨职能临时团队。
项目作为经典的管理单元，在组织规划和管理中得到了相当广泛的运用，也沉淀了许多成熟的方法论。但在快速变化的软件研发领域，强调计划、预算、分工和人员利用效率等确定性驱动的传统项目管理思维开始受到挑战。由于项目团队通常只是对产品的某一建设阶段负责，这种项目的短期导向导致团队只是疲于应对功能交付，缺少有效的激励和知识沉淀，所交付的产品设计和质量都很难达到高标准。同时，团队只会以立项时确定的时间、成本和范围为交付任务，而不会关注组织产品竞争力建设，没有着眼于业务的长期发展和演进。
为了应对市场的不确定性，保持产品具有不断创新的活力，许多组织开始思考从项目制向产品制转型。产品制以满足客户需求为出发点，组建稳定、高效的团队，致力于产品的创新和持续优化。产品制遵循产品化原则，对客户需求进行优选，聚焦于实现和交付能够为客户带来最大价值且增强产品长期发展能力的功能。同时，产品制也鼓励团队在预算分配上保持灵活性，并采用增量交付的方式，确保产品功能逐步完善和持续改进。
许多互联网企业基于产品制建立了高效的研发团队，并取得了巨大的业务成功。在产品制风靡的同时，项目制的风评急转直下。在追逐转型风潮之前，我们不妨想一想，项目真的是过时的管理单元吗？团队实施产品制后，项目这个概念是不是就可以完全抛诸脑后了？
经过长期的实践，我们发现项目和产品并不是完全对立的管理概念。组织在进行战略规划时，产品由于其长期性，毫无疑问比项目更适合作为管理单元；对于短期内实施的重点任务，项目则可以更充分地发挥其对时间、成本、范围的约束力，保障较短时间尺度上的交付完整性和即时性。
总而言之，项目在软件研发管理中仍是必要的管理单元。只需正确认识项目的短期、临时特性，在合适的场景下使用项目进行规划和管理，就能让项目在产品研发中发挥其应有的作用。团队可以将项目作为装产品需求的篮子，在明确交付规划的同时确定关联的系统。项目作为桥梁建立起产品到系统的映射关系，帮助研发团队在进行紧凑的系统建设的同时明确产品的建设愿景。项目不可或缺，如何正确使用项目进行管理，我们将在第12章进行详述。
综上所述，在战略规划域我们建议构建的战略规划模型如图2-2所示。
图2-2 战略规划模型
业务团队使用业务产品进行生态位的规划，服务好由有特定需求的客户组成的客群；业务团队和产品部落使用数字产品作为沟通的桥梁，规划组织产品能力的长期建设；产品部落使用项目规划短期重点系统功能的建设，并将系统作为研发侧的建设单元进行持续的梳理和优化。
人员管理域主要帮助组织明确“有多少人、能做什么事、以什么单元进行管理”。此外，在设计人员管理域时还需考虑如何支撑职能交错的矩阵型组织阵型。为了降低概念定义的复杂度，我们将人员管理域进一步划分为“职能子域”和“部落子域”。
职能子域是对经典职能组织管理模式的建模，旨在帮助组织梳理人员管理的基本脉络。职能子域中的几个主要概念为成员、科室、部门和中心。
（1） 成员 。人力管理作为组织软件研发数字化管理的基础，要做的第一件事就是人力资源的数字化。我们在与很多组织的管理者的交流中发现，很多管理者对团队的人力资源认识存在严重的不足。当我们问到“有多少人”这个问题时，很多大型组织管理者都无法给出一个准确的答案。在大型组织中，人力资源的数据往往散落在各个团队管理者的Excel里。尤其是研发人力资源涉及外包团队时，实际的人力资源数据往往会与管理者的估计大相径庭。
试问，如果在组织管理中，人力资源都是一个黑盒，软件研发数字化管理又从何谈起？“成员”不仅是职能子域的基本元素，也是软件研发数字化管理的重要基石。
（2） 科室、部门和中心 。定义说明如下。
● 科室 ：指在研发机构或企业中根据不同的专业领域或功能划分的组织单位。每个科室通常负责特定领域的研究、开发或技术支持工作，例如软件研发科室、硬件研发科室、生物技术科室等。科室的规模和组织架构可以根据组织的规模和需求而有所不同。
● 部门 ：在研发机构、大型企业中，部门是大规模的组织单位，负责整个研发工作的管理和组织。一个部门通常包括多个科室，涵盖不同的专业领域或功能，例如研发部门、产品开发部门、工程部门等。部门通常由一位部门经理或负责人领导，并负责战略制定、资源管理和项目协调等工作。
● 中心 ：中心是一个更大规模的组织单位，通常涵盖多个部门和科室，在一个特定的研究领域或技术领域内进行广泛的研究和开发工作。中心可能是跨学科的，汇集了多个专业领域的专家和研究人员。中心的目标通常是推动创新、促进知识交流和成果转化，并在相关领域取得重要的研究成果和技术突破。
科室、部门乃至中心，都是传统职能管理中重要的管理单元。传统职能管理具备清晰的层级架构和职责划分，其在资源分配、人员专业能力培养等方面是十分有效的管理形式。通过科室、部门等管理单元可以帮助组织聚焦战略重点、判断资源配置是否合理，并提供合适的管理单元进行研发效能度量和考核。因此，在大型组织管理领域中，科室、部门、中心作为重要的管理单元，仍是不可忽视的领域概念。
经典的职能管理单元在研发领域的表现往往不尽如人意。例如，由于团队壁垒的存在，不同职能的团队之间形成了严重的信息屏障和不当竞争；每个部门追求自己的目标和优先事项，导致组织中散布着信息孤岛；沟通障碍和协作问题也严重阻碍了跨部门的合作和创新；决策流程过长，导致错过做决策的最佳时机。
同时，研发领域的绩效评估往往比较困难，知识工作者的产出不容易量化和衡量。由于职能管理依赖于定量的指标和绩效评估方法，通常无法全面反映研发团队的贡献和价值。在这种绩效评估背景下，许多基础设施建设和维护工作变得难以开展，团队间的矛盾日益增加。
2012年，亨里克·克尼贝里（Henrik Kniberg）和安德斯·伊瓦尔松（Anders Ivarsson）联合发布了 Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds ，阐述了“部落制”下软件研发管理组织架构和该架构在Spotify公司的应用案例，如图2-3所示。截至2018年年初，Spotify拥有约1.59亿的全球活跃用户数、7000万的付费用户数和46%的付费用户增长率。Spotify是当之无愧的音乐流媒体领域的霸主，排名第二的苹果音乐无论是付费用户还是活跃用户，都只有Spotify的一半。优秀的研发团队管理架构无疑为Spotify获得业务成功提供了有力支持。
图2-3 Spotify部落结构（来源： Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds ）
部落制作为新兴的研发团队管理架构，向人员管理域注入了新鲜的血液。我们结合多年的软件研发管理实践，对部落制进行了进一步改良，旨在建立高度自治的研发团队，更好地支撑业务扩张和探索。Adapt框架部落结构示例如图2-4所示。
（1）
部落
。部落是相同业务领域或平台域（如手机银行）所有小队的集合，为具体的业务/平台能力建设提供稳定的交付能力，一般为30～100人，设置部落长对整体交付过程负责。和传统的项目团队不同，部落是面向特定业务领域而长期存在的研发团队。和项目团队及“人力资源池”相比，部落具备的长期性和稳定性可以让其成员拥有更多的成就感和归属感。同时，基于“邓巴数定律
”，在规模更小的小队中，成员间具有更紧密的联系，这使构建敏捷、高效的协作团队成为可能。
图2-4 Adapt框架部落结构示例
在组建部落时，我们推荐建立面向业务的产品部落——针对组织的重要产品组建对应的研发团队。专属团队在特定的业务领域进行深耕，更能保证业务产品的高效、高质量交付。产品部落的设计原则和技巧我们将在第3章进行更详细的说明。
（2） 小队 。小队是业务端到端交付的最小单位，包含所需业务人员、开发人员、测试人员等，一般约10人。小队主要负责持续、稳定地交付产品或功能。小队可根据实际情况，从产品维度或系统维度进行划分，旨在培养能紧密协作、高效协同的研发团队。
（3） 行会 。行会是统一管理职能或有长期特定目标的跨部落或跨部门组织。行会（如测试行会）由职能部门负责人进行人员管理，通常为职能经理。有长期特定目标的行会（如架构师行会），则由来自组织级、部门级、部落级的人员组成，并长期进行特定领域的建设规划、决策和流程优化。行会主要负责特定职能人员的能力培养，并主导组织的基础设施建设。行会和职能部门的设置可能存在一定重叠，但行会作为一个虚拟组织，可以从更精细的维度进行划分，具备更多的灵活性。
以自动化测试行会为例，该行会主要负责组织中自动化测试平台的规划和建设，以及人员自动化测试能力的培养。在组建行会之前，相关的基础能力建设工作由于其“吃力不讨好”的特性，通常无法得到有力推进。通过建设自动化测试行会明确自动化测试能力建设的必要性，赋能其行会成员在组织中的各个团队进行自动化建设，并确定一定的绩效考核进行驱动，可保障行会建设目标的达成。
（4） 分会 。在大型组织中，只是使用行会进行管理已无法保障各个部落的实施效果。分会作为行会管理的衍生品内嵌到各个部落中，由行会授权部分管理职能。分会由单一部落中相同能力域内拥有相似技能的人员自管理，以保障行会设定的规范和目标能在部落中准确实施。分会长通常由职能团队负责人担任，负责培养员工、反馈分会成员绩效。
（5） 职能线 。职能线为实体职能组织，以专业化为方向，面向员工能力培养和提升，倾向于“养兵”。职能线本质上与行会很类似，由于职能是强实体，因此组织会考虑管理者能力的因素，设置多位职能经理来负责管理各类技能的工作。传统组织的职能线通常既管人又管事，部落里的职能线建议只管人，即人员能力视角，因此部落里的职能线可以规模更大。本书中其他章节提及的职能线，若无特别指出，均指部落里的职能线。
通过梳理人员管理域的概念，我们明确了组织成员的职责范围，以Adapt框架部落结构示例为例澄清了组织阵型涉及的基本概念。为了减少不同职能的团队间的协同摩擦，在此基础上，我们仍需要探索如何合理规划研发过程，以充分释放组织的生产力。
这里需要注意的是，在第3章的职能型组织阵型、项目型组织阵型和矩阵型组织阵型中，产品部落组织隶属于矩阵型组织阵型，在谈到成员组织时，产品部落组织下的小队、分会、行会等仍然会以小队阵型、分会阵型和行会阵型出现，这些术语不是组织的三大阵型，请读者读到相关内容时注意区分。
研发过程管理域主要关注需求层级体系和研发节奏的设计、帮助组织形成稳定的交付能力，让研发过程有序可依。
在需求管理子域中，以用户故事为核心的需求层级体系是经典的需求管理解决方案。在标准的敏捷实践中，用户故事应承载对产品功能的简要描述，并尽可能保持在一个迭代周期内完成的颗粒度，以便团队进行迭代计划和协同开发。
图2-5 用户故事需求层级体系
部分组织在无视颗粒度限制的前提下仅使用用户故事进行需求管理——一句话需求、工单、缺陷等不同颗粒度的需求均作为用户故事被推送到研发团队。需求颗粒度差异过大导致团队容量（单位时间周期内团队能交付的需求数）评估变得极为困难，研发团队的迭代计划形同虚设，需求层级体系濒临崩溃。
部分组织意识到需求分层的必要性，尝试使用图2-5所示的“史诗-用户故事-任务”体系进行需求的分层管理。
在这套需求层级体系中，增加了“史诗”作为产品功能规划单元，可以很好地帮助团队保持统一的用户故事颗粒度，进而保证用户故事的流动速率，以建立稳定的研发节奏。我们在辅导组织进行敏捷转型的过程中发现，“史诗-用户故事-任务”管理模型在小规模试点中能很好地发挥作用，但在规模化推广后往往会陷入泥潭。在大型组织中，不同的团队对“史诗”的认知有所不同，导致相关的需求拆分、案例编写工作量变得难以评估，团队间协作变得困难。同时，与“史诗”相关的度量指标在这种场景下也变得难以使用，评估团队的产出和容量变得十分困难。在SAFe（Scaled Agile Framework，规模化敏捷框架）中，将“史诗”阐释为“重要的解决方案开发计划”，并根据建设目标进一步划分出“商业史诗”和“赋能史诗”。虽然SAFe设计“史诗”模板明确了需求形式，但仍未解决“史诗”的颗粒度界定问题。
综合考虑团队的管理诉求和使用便利性，我们设计了“产品需求-系统功能”两层需求层级体系，如图2-6所示。这个需求层级体系的具体使用方法和优化思路我们将在6.4节中进行详述。
图2-6 “产品需求-系统功能”两层需求层级体系
需求管理子域中存在以下管理概念。
（1） 产品需求 。产品需求应提供完整业务价值，同时细化到能一次发布完整上线的颗粒度。产品需求作为第一层需求应当以业务视角进行划分，限制为一个版本周期能完成的颗粒度，鼓励团队在每个版本周期交付业务价值。在Adapt框架下，我们期望业务人员能通过业务内审和技术评审等活动对产品需求的颗粒度有更准确的认识，并通过横向拆分等方式，让产品需求可以保持在一个版本周期上线的颗粒度。
（2） 系统功能 。系统功能从产品需求拆分而来，和系统一一对应，通常需要细化到能在一个迭代周期内能够完成的颗粒度。系统功能作为第二层需求以科技视角进行划分，限制为在一个迭代周期内可以完成的颗粒度，以支撑团队进行合理的迭代计划。这一层的需求在一个迭代周期内会经历其完整的生命周期，具备良好的流动性，可以作为迭代进度跟踪指标。我们建议在站会上使用系统功能看板对齐研发进度、让研发风险透明化。
（3） 任务 （可选）。任务从系统功能拆分而来，和研发人员的具体工作任务相关，其可以是研发相关的一系列任务，如设计任务、开发任务、测试任务等，通常细化到1~3天的颗粒度。
通常而言，需求层级增加的同时也会增加研发团队理解和维护的成本，我们并不建议使用过多的需求层级进行软件研发管理。但在管理成熟度较低的团队，可能需要使用“任务”层对每个研发人员的日常工作进行记录和跟踪。为了避免“只见树木不见森林”，我们建议任务仅用于研发人员的日常记录，团队管理者则使用系统功能进行进度跟踪。使用任务或许能给管理者带来一定的掌控感，但它同时也是一个“甜蜜的陷阱”——如果事无巨细地使用个人任务进行记录，过多的数据反而会导致团队管理陷入信息超载的失控状态，以下就是错误使用个人任务的两种方式。
（1）某团队使用个人任务记录所有研发工作及其相关沟通事项，并在个人任务上登记研发工时。团队不得不消耗精力去维护数量颇为可观的个人任务状态。过多的任务掩盖了需求本身的优先级，导致个人任务不仅没能帮助研发人员进行工作规划，反而成了他们的负担。
（2）某团队使用个人任务开站会，导致团队没有聚焦于功能交付。站会变成了简单的任务汇报，没有人关注系统功能的研发进度和交付瓶颈。这种形式存在潜在的交付风险——在站会上汇报时每个人看上去都很忙，但需求交付的推动可能已经举步维艰。
第6章将对Adapt框架的需求层级体系进行详细说明。
在研发节奏子域中，常用的两个管理概念是“版本”和“迭代”。
（1） 版本 。版本是特定软件或系统的特定发布状态或标识。它用于区分特定软件或系统的不同变体和改进，并帮助用户和研发人员了解其演变过程和功能变化。版本作为产品需求的规划和上线周期，同样是业务团队需求编写和验证的周期。业务团队可以基于版本节奏建立“试验—收集数据—调整”的改进循环，推进产品功能迭代。缺乏版本管理会导致研发团队丢失交付目标，甚至由于缺乏规范化的需求管理导致需求遗漏，严重破坏研发团队的交付承诺，影响业务团队对研发团队的信任。
（2） 迭代 。我们将迭代定义为重复的研发时间盒。每个迭代周期都包含一系列计划、开发、测试和评估的活动，旨在逐步实现最终目标并增加软件或项目的价值。迭代作为系统功能的研发周期，在限制系统功能颗粒度的同时帮助研发团队建立稳定的交付和改进节奏。研发团队可以利用迭代计划、回顾会等活动构建改进循环，推动团队自治和持续改进。
当系统变得复杂、版本发布成本较高时，团队需要多个迭代后发布一个版本。此时单独使用迭代进行节奏管理会导致团队丢失阶段交付目标、系统分支管理和依赖管理混乱，从而导致生产发布难度升高。因此，在复杂场景下，应采用迭代和版本解耦的策略——使用迭代建立稳定的交付节奏，使用版本进行交付进度和发布管理。版本和迭代的组合管理是一个十分复杂的话题，我们将在第8章进行更详细的阐述。
