提高研发效率的简介，我不知道从哪里开始和困惑？ALI高级技术专家有一种系统的方法，可以秘密地提高研发性能的效率。
注意：本文是Yunqi会议内容的完成。
近年来，“研发效率”一直是一个热门词，许多组织将启动研发效率的提高项目。我与许多组织进行了深入的交流。实现最终目标的最终目标并不多。通常，高调开始，匆忙结束。为什么这样做？
为了提高研发的有效性，我们必须首先找出要解决的问题，然后解决解决问题的实践方法。否则，问题尚不清楚，很难获得良好的结果。
您需要哪些问题来解决研发的有效性？
我将改善问题以解决问题并总结三个效果。
第一个不等，局部效率不等于有效的交付？
在这一点上，每个人都应该有同样的感觉。当我们问各个部门或个人时，他们觉得他们忙碌而高效。但是，我们询问商业部门或用户，但这是另一回事。他们会抱怨产品研发响应速度很慢，交付迟到，质量不好。
这是组织内部观点的局部效率，并不意味着用户观点的有效交付。这是提高研发效率的主要问题。解决它需要更有效的组织协作，更合理的交付模型，更合理以及更好的过程质量。
下一个问题是，这是足够的有效交付吗？这导致第二效率不平等。
第二个不相等，有效的交付不能连续且有效
有时，为了高效付款，我们可以采取临时行动，例如将一群人聚集在一起并建立一个临时项目。沟通和合作将更加方便，这可能会达到效率。但是，如果缺乏长期的质量思维，当我们进行下一个项目时，我们经常会发现问题。以前的代码和设计中存在各种问题，例如修改和复制。国外，长期效率无法维持。
如何从高效率交付转变为连续效率是解决R＆D效率的第二个问题。IT需要我们的工程，技术能力和实践。
第三个不是平等的，有效的交付并不意味着企业成功
产品交付的目的是支持业务发展和业务创新。我们必须确保交付可以解决用户问题并建立可持续的业务模型，否则交付更多是毫无意义的。
如今，市场和用户的不确定性继续增加，解决此问题并不容易。它要求整个组织都专注于用户问题，快速交付和反复试验，并形成有效反馈的封闭式循环调整。仅通过实现这三点可以使高效效率交付到业务成功中，这是提高研发有效性的第三个核心问题。
我们认为，研发效率的提高的本质是解散上面的三种不合格的表格，以将组织内部的本地效率转化为用户效率高的效率，并确保可持续的效率和业务成功。最终意识到：“连续，平稳，高质量的有效价值。”这是改进的基本目标。
显然，问题是解决他们需要的实用方法的开始。接下来，我们共享这些实用方法。这是我们对过去实践的完善和摘要，并总结了这张照片。
左侧是协作和需求实践。我们调用左侧的合作模式和面向产品的业务驱动需求。以下是下面需求的分析和设计。这部分实践的一部分解决了本地效率如何带来有效的交付。
右边是工程和技术实践。我们将右上角的现场驱动架构和实现称为。中间是标准化的工程基础架构。以下是应用中心的连续交付。在实践的这一部分中解决的问题是如何使我们有效地可持续发展。
中间部分是创新的实践。它包含：如何有效地探索业务，如何继续完成业务交付以及形成有效的反馈和调整封闭循环。解决创新实践的问题是有效交付如何带来业务成功。
接下来，让我们逐步开始查看每个部分的关键效率的实践。
首先，让我们看一下协作需求实践。
在介绍协作之前，我们需要找出协作的背景 - 我们在谈论协作时谈论的是什么。
让我们从需求交付的内部结构开始。
首先，产品的交付源于目标，它可能是用户的目标，例如更有效地完成某项工作；它也可能是业务目标，例如：实现业务增长并增加用户粘性。我们根据用户目标和业务目标计划业务需求。除了业务目标外，客户的特定需求也将转换为业务需求。
产品需要在产品中实现业务需求，并将其分解为产品需求。产品需求将进一步分解为技术任务。产品需求是通过完成技术任务来提供的，并且最终实现了相应的业务需求。
当然，产品需求不一定直接来自业务需求，产品还将制定自己的计划，包括升级和技术重建建筑，或将来前进的技术布局，例如AI算法和区块链平台。产品需求并非来自当前的业务需求，它也可以实现业务目标，但仅是长期和未来的业务目标。
在了解产品交付的结构之后，接下来，我们看到了如何在此结构下实现团队的有效合作。
业务 - 驱动协作模式
以项目为导向的交付的本质是将人们分配为资源。其背后的假设是确定的未来，并且确定的内容是在特定时间内交付的。它强调计划和执行，追求交付的确定性。
当今的决心正变得越来越不现实，组织必须学会与变化一起跳舞。此外，以项目为导向的交付导致短期思维，缺乏工程学和技术长期意识。由于团队的暂时性，不可能继续保持团队的交付效率。
在数字化时代，我们需要从面向项目的交付模型迁移到面向产品的交付模型。面向产品的交付模型本质上是将事物移交给跨职能团队，相对稳定的特征团队继续接受并完成需求的交付。
特征团队负责产品的迭代产品。他们拥抱业务的不确定性并继续发展产品。要维护产品，特征团队必须建立长期思维，关注代码资产和工程资产，并不断提高团队的交付能力和交付流程，以改善交付效率。
但这还不够，因为如果每种产品都是政治性的，那么对任何特征团队的需求都将使之成为整个业务的瓶颈。解决方案是在同一业务领域共享相同的需求列表。当团队中有一个瓶颈时，该团队可以分配给另一个团队，这与“一个队列和多个服务窗口”的本质一致今天的许多服务行业。
从最后开始的分析和设计需求
早些时候，我们说公司的合作模式应该是业务驱动的。团队的交付模型应以产品为导向。他们解决了协同过程的问题，但仅仅没有足够的过程。我们还必须确保输入的质量。
IT行业有一个著名的句子：“输入是垃圾，输出将是垃圾。”需求的输入是交货过程的来源和最关键的部分。如果输入存在问题，则中级有问题交付过程不能顺利。我们应该做什么？
“输入垃圾，输出垃圾”的相反从末尾开始，即，当需求是输入时，团队必须知道该怎么做，并达成业务，产品和技术之间的协议。
那么，结束的结尾是什么？
首先，对于业务需求，我们必须实现明确的业务目标，并根据目标定义清晰的业务流程，以确保业务流程可以支持实现业务目标。这是通过业务分析完成的工作。
其次，对于产品需求，它必须支持业务流程的实现。为此，我们必须根据业务流程来定义产品的功能。对于每个产品功能，我们必须首先阐明用户的交互过程和交互过程。基于接受标准。
第三，阐明业务需求和产品需求之间的结构，即业务需求与产品需求之间的层次结构关系。这对于后续的团队合作非常重要。我们协作和交付的目标不是产品需求，而是业务需求。只有当结构清晰时，我们才知道这些产品需求如何与业务保持一致并满足快速交付业务需求。
总而言之，业务分析和产品设计是金字塔的结构：
需求始终源自业务目标。基于业务目标分析业务流程，根据业务流程分解产品需求，并设计了产品需求。
金字塔的上述两层：业务分析和注意力。我们介绍了基于目标和业务事件的“事件驱动分析”方法，分析业务流程，并根据业务流程分配对产品需求的需求，并分配最小的可行产品（MVP）。
金字塔的以下两层：产品设计有关。在业务流程设计的基础上，产品需求分解和澄清产品需求。澄清和设计需求的最佳方法是解释操作过程和接受规则是什么也就是说，在什么情况下，将获得哪些操作和结果。我们引入了支持此过程的“实例化需求”分析方法。
通过系统的业务分析和产品设计方法，从Gigo到最终的过渡是结束。这是对高效率交付的本地效率的重要组成部分。
下面，让我们从另一个维度解释协作和需求实践。例如，上图的产品屏幕截图就是一个示例。总而言之，我们需要在协作部分需要做的三点：
第一点是我们必须查看最终业务需求的交付过程和管理。我们将其称为前后功能。这些功能可能是业务，产品，开发，测试，部署以及操作和维护。我们希望通过这些功能，以使它们更有效地合作，并让业务需求流程并从左边顺利交付正确。
第二点与左右模块保持一致。业务需求可能被分解为不同的产品。每种产品都有自己的工作流程，产品的交付应与业务保持一致。
我们的目标不是让某个产品忙碌，而是要使业务需求的交付更光滑。包括计划和业务需求的规划，以及实施过程中的一致产品和业务，并立即发现无法对齐的障碍和等待。
第三点是内部施工过程的质量。要求在每个阶段都具有明确的质量标准并将其实现。例如，需求输入的质量必须在最后完成，并且测试和测试要求的质量应是明确的标准。质量应在每个需求的每个阶段建立，而不是依靠最终检测阶段。
我们必须实现前后功能的功能，对齐左右模块，以及内部施工过程的质量。在最后，形成了下图所示的协作模式。
图中的每个节点都是特定的活动。这些活动具有其节奏，负责人，投入和产出以及对实际方法的支持。例如，产品和技术确实形成了整体，以达到如此流畅且高质量的交付业务需求。
我们在技术和工程部分中必须解决什么问题？让我们首先看一下图片。
上面的水平轴是时间，垂直轴是生产效率。我们希望效率能沿绿线一直延伸，但实际上，它可以随着时间的推移而移动，产品变得复杂，并且比例团队将变得更大，效率将降低。
区分这两条线的核心是工程和技术实践。它确定我们是否积累了它们是资产还是债务，并最终确定长期效率。
现场驱动的体系结构和实现
在技术方面，我们必须继续积累和维护该领域的资产，以便易于理解，扩展，维护和重复使用。如今，该行业通常认识到现场驱动设计的重要性，并且愿意投资能源。
现场驱动的设计不仅是设计问题，而且是涉及需求，建筑和实施的系统工程。按需和业务是来源，架构是枢纽，它们都需要进入现实。最重要的是如何连接需求，体系结构和实践以及连接它们的现场模型。
如上图所示，我们开始从业务需求分析业务流程。根据业务流程的分解和设计产品需求，我们将通过实例化的需求来定义接受测试，以澄清和完善产品需求。更重要的是，在需求分析的阶段，我们必须不断提取并参考模型模型。该领域来自每个特定的业务和特定需求，称为“业务领导力建模”。
现场模型应该是应用程序架构设计的基础。基于现场模型，我们对子域进行划分，设置子域的上下文，并根据现场模型定义界面的设计合同，将子域和有限的边界环境划分，并限制微服务的边界，以使微服务成为资产最终保证的上下文和服务合同，因此我们称为“由微服务结构”。场”。
在实施方面，域模型，验收测试和服务设计合同都是高质量代码的限制和指导。您的代码应反映域模型，与体系结构和接口合同一致，并符合相关的接受标准。
同时，首先测试的方法使我们进行了更可靠的自动化测试，并且自动化测试将使我们的重建更加安全。连续重建确保代码资产不会迅速损坏并维持系统健康。
今天，我在概念层面上分享了更多，但我希望能激发每个人的思考计划。除非您认为您可以牺牲长期的质量，您不需要积累长期的重复资产，那么上述内容是必不可少的。
标准化工程基础架构
让我们看一下工程部分。今天，我们看到工程部分的技术趋势正在融合。
首先，我们需要决定部署和发布，部署是技术行为，并且发布是业务行为。我们希望每个应用程序都可以单独部署，因此我们需要使用该应用程序作为单位来确定部署并发布，，以及持续的集成和部署。
但这还不够。应用程序更改来自何处？应用程序来自业务需求，业务需求分配到产品需求中，产品需求对应于一系列应用程序。
每个应用程序的更改都有自己的流程。当业务需求与所有应用程序更改和部署相对应时，也应发布该业务需求。
我们的工具，流程和操作应该能够连接到这些应用程序的更改和产品需求，直到业务需求为止。这样，我们可以以业务需求的单位发布 - 在部署业务需求下的所有更改都将被部署，业务需求可以随时发布。
我们认为，连续交付的最佳形式是更改单个应用程序中的部署，而单一的需求就是单位。在此基础上，我们将有机会建立最快的业务封闭循环。
以上是Yun本地交付的连续交付的形式，即申请单位的连续部署，以及持续发布业务作为需求单位。前提是我们已经统一了开发，运营和维护的基本单位。
总而言之，我们认为Yunyuan出生的Bizdevops的形式是什么？有三点：
效率的提高必须从明确的定义问题开始。
我将总结一下提高研发有效性的基本问题。要解决这三个功效，它需要系统的实践。
首先，让本地效率转化为有效的交付。为此，我们需要由协作模型和面向产品的业务交付来交付，同时，我们必须真正开始需求。
其次，有效的交付可以继续。为此，技术必须在技术上驱动和实现，并不断积累和优化现场的技术资产。在工程学方面，有必要建立标准化的云基础架构，并使用应用程序中心来开放需求开发和运输和连接业务，最后实现了应用中心的持续部署以及业务需求的持续发布。
第三，使有效的交付带来成功。为此，需要建立业务探索和持续交付之间快速执行和反馈的封闭环节。
以上三点的共同点是它们从业务开始。例如：各种链接和部门在业务需求中的有效协作；从业务目标，分析业务流程和分解设计产品开始；连接业务需求和产品应用程序的变化，以达到持续发布业务需求；在交付之间建立业务探索和继续封闭的循环。
着陆的实践必须开放业务（BIZ），开发人员（DEV）以及运营和维护（OPS），以使其成为有效的运营，建立Bizdevops实践系统，增强数字时代组织能力，并加快业务发展和创新。
资料来源：阿里巴巴云。