3.2 协作和管理领域的实践
BizDevOps在管理和协作实践上关注业务、产品和技术持续地目标对齐和快速地运营反馈闭环。
如下图所示，BizDevOps的协作和管理实践是由三个闭环构成有机系统。
这三个闭环分别是：
业务交付和反馈闭环
它的核心关注点是业务的快速响应和交付，以及业务目标的达成。这一层面的核心作业对象是业务需求，并以业务目标牵引，规划业务并统领各个产品交付团队的协同。我们用业务驱动的协同机制，来总结与之对应的实践。
产品交付和反馈闭环
它的核心关注点是产品需求的快速交付、产品的演进，以及产品交付效能的持续提升。这个层面的核心作业对象是产品需求，并以持续高效的产品交付为目标，协同各个应用的技术开发和工程部署。我们用产品导向的团队协作和交付方式，来总结与之对应的实践。
技术开发和应用变更的闭环
3.它的核心关注点是技术及工程能力的持续改进，从而保障应用为核心的持续部署和工程交付能力。这个层面的核心作业对象是应用的变更请求。它的具体实践，体现在工程和技术部分。但在协作与管理实践部分，需要被关注和连接。基于上面的分层结构，以下从产品导向的团队组织和交付方式，及业务驱动的组织协同机制 两大实践体系来阐述BizDevOps实践落地在管理和协作领域的关键。应用层面的协作更多融入到了工程和技术领域实践中。
产品导向的团队组织和交付方式
正如本白皮书第一部分描述，信息技术的发展进化历程，也是技术和业务相互靠近直至融合的历程，技术的交付模式也
随之进化。
在最初技术与业务相对分离的模式下，业务确定要什么，IT就开发什么。而需求确定后，则变成IT开发了什么，业务就用什么。IT通常被当做成本中心看待⸺花费确定的预算交付确定的内容。
在这一模式下，大部分IT交付是以项目的形式进行的。项目的内核是：在特定时间内，以相对确定的预算和人力，交付预先规定的内容。项目追求确定性，注重计划和计划执行。在技术与业务分离的时代，这样划清边界，对双方都有好处。相应的，组织也可以按项目来预先规划、分配和执行IT预算，而这通常是以年度或至少以季度为单位的。
项目在组织方式上表现为，团队的短期性和临时性。人被作为资源分配到确定好内容的项目中，而项目结束后则被回收，准备分配到下一个项目。这样的组织方式不利于技术和工程资产的长期积累和优化，也不利于工程能力及基础设施的持续优化。
数字化时代，技术成为业务发展和创新的核心动力，加之技术和业务的不确定性都越来越高，技术与业务分离的方式越来越不能满足即时响应业务的需要，也无法做到紧密协同下的持续迭代，以及工程及技术资产的持续积累和改进。适应时代变化，在业技协同方面的关键认知转变就是从项目到产品的思维过渡。面向BizDevOps的业务、产品和技术的协同，要求不同职能单元转换视角，形成产品导向的交付模式，面向数字资产的长期演进和持续沉淀而通力合作。我们将项目和产品导向交付模式的关键差异对比如下表。
下图是BizDevOps概念模型中的“技术交付域”及其相关联的部分，它为产品导向团队组织的交付方式提供了基本依据。对应该模型，各产品线定义并维护产品线的愿景和目标，并建设相对稳定的持续交付团队。
各个交付团队：
图3-3：产品导向的团队组织和交付方式定义的技术交付域
虽然交付团队的人员更迭在所难免，但团队在运作过程中应该面向长期目标，寻求可持续发展。同时，团队应关注核心角色的梯队建设，保证产品需求交付相关核心能力的延续性。长期可持续发展的交付团队也是保证产品内部和外部质量的基础。由于对产品交付长期负责，团队就有动力持续保证产品的高质量，类似持续重构这样面向易改变性的质量实践，才能够得到有效落地。
交付团队针对产品需求定义“需求工作流”，承接业务需求分解得到的相关产品需求，并针对下游相关应用，明确变更请求。由于产品和技术上下文的不同，具体的工作方式可以授权团队自己定义，只要团队对最终的交付效能负责。践行产品导向也要求我们拥抱，而不是害怕和忽视不确定性。交付团队需要根据不同的业务和技术上下文，选择合适的迭代频率、制定相应的“迭代计划”，根据一定的优先级策略明确迭代内需要交付的产品需求，并采用合适的敏捷和精益方法，来管理团队的交付。关于敏捷和精益方法的具体操作，已经有很多参考，不在本白皮书范围之内。
以 产 品 为 导 向，组 织 面 向 业 务 目标 的 稳 定 的 产 品 交 付 团 队，持 续迭代产品，提升协作和工程能力，改 进 团 队 交 付 效 能 。这 是 产 品 导向的团队组织和交付方式解决的
核心问题。
业务驱动的组织协同机制
产品导向的团队组织和交付方式，解决的是团队层面和产品交付的问题。然而，产品必须与业务对齐，才能交付有用的价值。
很多企业将业务价值等同于短期经营的财务指标，造成业务和产品、技术无法建立价值视角上的共同语言。此时，产品和技术团队就容易将工作成效定位到内部交付工作上，比如代码的产出、功能交付或缺陷修复数等，造成了产品与业务的价值脱节。
价值最终必须从外部客户和市场的视角定义，业务策略和目标也要源自客户和市场。另一方面数字化时代，业务策略和目标通过数字化的产品才能够实现。只有包括业务和产品技术在内的整个组织协调一致，打通价值的探索、规划和交付链条才能实现真正的高效业务交付。然而，业务和产品应该如何协同？它们之间的关系应该是怎样的呢？
如上图所示：BizDevOps概念模型述了业务与产品的关系，我们称这一关系为：“业务驱动，产品收敛”。其中，业务是规划的驱动源头。但，最终业务的输入需要在产品侧被收敛，才能落地为驱动数字业务进化的具体内容，并完成交付。“业务驱动，产品收敛”，是数字化时代，业务与产品关系的最佳范式。
在整体规划上，各业务线基于客户定位、市场环境、竞对情况等确定业务的战略或策略，并定义业务目标。而产品线也会综合业务的输入和产品技术的规划，定义产品愿景和产品目标。在现实中，一个产品可能需要支持多类业务或客户。但，产品一定要向所支持的业务对齐，也就是产品愿景承接和支撑业务战略，产品目标对齐业务目标。这是在整体规划层面的业务驱动和产品收敛。
在具体的操作层面，业务对产品有两类输入。一类是支持现有业务和客户的较为琐碎的日常需求，它们会被过滤并直接转化为产品的业务需求，并按优先级计划和交付，以支持现有业务的运作。一类是更大粒度的面向未来的需求，我们称之为业务机会。业务机会需要被进一步分析，综合其预期成效、成本、紧迫性等要素，如果这个机会值得投入，则会转化为产品线下的“专题”，进行具体规划和交付。
专题
指的是业务和产品线为抓住业务机会而采取的具体行动。一个业务机会可能产生一个或多个专题，多个关联的业务机会也可能合并成为一个专题。专题与过去的研发项目有类似之处，但又有本质的不同。相对项目，专题更强调拥抱不确定性，基于专题的定位和成果定义，团队动态
规划专题的具体内容，并在过程中持续迭代、反馈和调整。考核专题成功与否的并非是按期交付预先确定的内容，而是达成或超越所定义的成果，以及从中获取有效的产品和业务认知。
BizDevOps概念模型中，规划协同域被分为业务规划子域和产 品 规 划 子 域，这 两 个 子 域 既 相 对 独 立 又 紧 密 协 同，是BizDevOps所倡导的业技协同的重要组成部分.
业务规划子域
在数字化业务中，需要针对业务规划、客户诉求以及市场洞察等持续进行业务机会的发现和识别。在技术日新月异的科技时代，从产品和技术侧的洞察和机会也必须得到重视，因为数字化本质上是用技术在解决业务问题，产品和技术侧的规划也是业务机会的重要输入。
图3-5：业务机会的输入主要来自业务侧，但也包括产品侧的规划
值得注意的是，在梳理业务战略和目标时，需要对业务价值进行分类建模，这样才能驱动后续在产品和技术侧的价值对齐。常见的价值模型需要关注三个不同的视角，也就是：
以上三个视角，可以指导业务或产品发现和定义价值指标，并基于企业的原则设定业务和产品的综合目标。对高不确定性的创新业务，在特定的阶段选取单一指标用于凝聚整个产品和业务团队的方向是常见的做法，这一单一指标被称为北极星指标，它可以帮助团队聚焦核心价值点，并推动更快速和频繁的价值验证闭环。随业务阶段的推进，北极星指标也要随之调整。
图3-6：从三个不同价值视角出发建立价值指标体系模型，融合单一北极星指标模式来明确阶段性重点
《必致（BizDevOps）白皮书2022》——03必致（BizDevOps）实践体系——3.2 协作和管理领域的实践(下） https://developer.aliyun.com/article/1230838?groupCode=tech_library
