当开发与软件维护相结合时，DevOps 的理念对任何人来说都不足为奇。 一种新趋势正在蓄势待发——DevOps 2.0 或 BizDevOps。 它已经将三个组件合并为一个整体：业务、开发和支持。 就像在 DevOps 中一样，工程实践构成了开发与支持之间联系的基础，因此在业务 DevOps 中，分析扮演着将开发与业务结合在一起的“粘合剂”角色。
我想马上承认：我们得到了一个真正的 bizdevops，我们现在才知道，在阅读智能书籍之后。 由于员工的主动性和不可抑制的改进热情，它以某种方式发展起来。 今天，分析是开发生产过程的一部分，大大减少了反馈循环并定期提供见解。 我会详细告诉你我们是如何安排一切的。
经典 DevOps 的缺点
当构思新的客户产品时，企业会创建一个理想的客户行为模型并期望良好的转换，在此基础上建立其业务目标和结果。 就开发团队而言，它努力编写非常好的、高质量的代码。 另一方面，支持希望流程完全自动化，以方便维护新产品。
现实通常以这样一种方式发展：客户收到相当复杂的流程，业务依赖于低转化率，开发团队在修复后发布修复，并且支持淹没在客户的请求流中。 熟悉的？
这里的罪恶根源在于流程中嵌入的漫长而质量差的反馈循环。 业务和开发人员在冲刺期间收集需求和接收反馈的同时，与有限数量的客户进行沟通，这极大地影响了产品的命运。 通常对一个人来说重要的东西根本不是整个目标受众的特征。
了解产品的开发是否在正确的方向上是在发布几个月后的财务报告和市场研究结果。 而且，由于样本量有限，它们没有提供在大量客户身上检验假设的机会。 总的来说，结果是冗长、不准确且效率低下。
战利品工具
我们找到了摆脱这种情况的好方法。 一个过去只帮助营销人员的工具，我们进入了企业和开发人员的手中。 我们开始积极使用网络分析，以便实时查看流程，了解此时此地发生的事情。 基于此，规划产品本身，将其推广给大量客户。
如果计划进行某种产品改进，您可以立即看到它与哪些指标相关联，以及这些指标如何影响销售以及对业务很重要的特征。 所以你可以立即剔除效果不佳的假设。 或者，例如，向统计上显着数量的用户推出一项新功能并实时监控指标，以了解一切是否按预期进行。 不要等待请求或报告形式的反馈，而是立即监控并及时纠正创建产品的过程。 我们可以推出一项新功能，在三天内收集统计上正确的数据，再在三天内做出更改——现在一个很棒的新产品在一周内就准备好了。
你可以跟踪整个漏斗，所有接触过新产品的客户，找出漏斗急剧变窄的点，了解原因。 开发人员和企业现在都在关注这一点，这是日常工作的一部分。 他们看到相同的客户旅程，他们可以一起产生改进的想法和假设。
这种业务和开发的集成，加上分析，使得持续创建产品、不断优化、寻找和查看瓶颈、整个过程成为可能。
一切都与复杂性有关
当我们创建新产品时，我们不会从头开始，而是将其构建到已经存在的复杂服务中。 试用新产品时，客户通常会接触多个部门。 他可以与联络中心的员工沟通，与办公室的经理沟通，他可以联系支持人员，使用在线聊天。 在指标的帮助下，我们可以看到，例如，联络中心的负载是多少，如何最好地处理传入的请求。 我们可以了解有多少人来办公室，并建议如何进一步建议客户。
信息系统也是如此。 我们的银行已经存在了 20 多年，在此期间创建了大量的异构系统并且仍在运行。 后端系统之间的交互有时是不可预测的。 例如，在某些古老的系统中，对某个字段的字符数有限制，有时这会使新服务崩溃。 使用标准方法跟踪错误非常困难，但使用网络分析是基本的。
我们已经到了开始获取和分析来自所有相关系统并显示给客户的错误文本的地步。 事实证明，他们中的许多人已经过时了，我们甚至无法想象他们以某种方式参与了我们的过程。
使用分析
我们在同一个房间里有网络分析和 SCRUM 开发团队。 他们不断地相互交流。 必要时，专家会帮助设置指标或上传数据，但基本上团队成员自己使用分析服务，没有什么复杂的。
例如，如果需要某些依赖项、针对有限类型的客户端或源的额外过滤器，则需要帮助。 但是在目前的架构中，我们很少遇到这种情况。
有趣的是，引入分析并不需要安装新的 IT 系统。 我们使用营销人员以前使用过的相同软件。 只需要在业务和开发中协调使用并实施即可。 当然，我们不能只拿营销有的东西，我们必须重新配置一切，让营销进入一个新的环境，让他们和我们在同一个信息领域。
将来，我们计划购买改进版的网络分析软件，以应对不断增加的已处理会话量。
我们还积极整合来自 CRM 和会计系统的网络分析和内部数据库。 通过合并数据，我们可以在所有必要的部分中全面了解客户：按来源、客户类型、产品分类。 帮助可视化数据的 BI 服务将很快提供给所有部门。
我们最终得到了什么？ 事实上，我们将对其进行分析和决策制定作为生产过程的一部分，这产生了明显的效果。
分析：不要踩耙子
最后，我想分享一些技巧，帮助您避免在构建 bizdevops 的过程中遇到障碍。
- 如果分析不能快速完成，那么你就做错了分析。 您需要从一种产品开始遵循简单的路径，然后进行扩展。
- 您必须拥有一个非常了解未来分析架构的团队或人员。 您仍然需要在岸上决定如何扩展分析、将其集成到其他系统以及重用数据。
- 不要生成额外的数据。 Web 统计数据除了提供有用的信息外，还是一个包含低质量和冗余数据的巨大垃圾场。 而这些垃圾如果没有明确的目标，就会干扰决策和评估。
- 不要为了分析而分析。 首先，目标，工具的选择，然后才是 - 仅在会产生影响的地方进行分析。
该材料与 Olga Chebotar ().
来源： habr.com