В сентябре 2025 года в отчете
State of AI-assisted Software Development была представлена первая
модель DORA AI Capabilities, которая определяет ключевые практики, которые усиливают влияние AI на производительность команд. Эта модель является дополнением к давно существующей
DORA Core Model и фокусируется на технических и культурных практиках, которые организации могут развивать, чтобы максимизировать ценность и успех внедрения AI. В дополнение к модели был подготовлен отчет с рекомендациями, в котором для каждой практики даны стратегии внедрения, конкретные тактики для старта, а также методы отслеживания прогресса и поддержания непрерывного улучшения. Авторы рекомендуют использовать модель и отчет для формулирования гипотез, проведения экспериментов и измерения результатов, чтобы определить, что обеспечивает наивысшую производительность в вашем конкретном контексте.
Модель DORA AI Capabilities связывает между собой технические и культурные практики с ключевыми результатами. Семь ключевых практик и возможностей (AI capabilities) включают:
- Явная и донесенная до сотрудников позиция по AI (Clear and communicated AI stance). Явная политика обеспечивает психологическую безопасность, необходимую для эффективного экспериментирования;
- Здоровые экосистемы данных (Healthy data ecosystems). Преимущества AI значительно усиливаются при наличии высококачественных, доступных и унифицированных внутренних данных;
- Внутренние данные, доступные для AI (AI-accessible internal data). Подключение AI к внутренней документации и кодовым базам переводит его из роли универсального ассистента в роль узкоспециализированного эксперта;
- Устойчивые практики контроля версий (Strong version control practices). По мере того как AI увеличивает скорость изменений, практики контроля версий становятся критически важной страховочной сетью, обеспечивающей уверенное экспериментирование;
- Работа небольшими объемами изменений (Working in small batches). Эта практика противодействует риску генерации AI крупных нестабильных изменений, гарантируя, что скорость трансформируется в улучшение продуктовых показателей;
- Ориентация на пользователя (User-centric focus). Фокус на потребностях пользователей необходим для того, чтобы команды двигались быстро в правильном направлении;
- Качественные внутренние платформы (Quality internal platforms). Платформа обеспечивает автоматизированные и защищенные пути, позволяющие масштабировать преимущества AI на всю организацию.
Для оценки влияния AI используются следующие ключевые результаты (Key Outcomes):
- Производительность организации (Organizational performance). Общий успех организации, основанный на таких характеристиках, как прибыльность, доля рынка и удовлетворенность клиентов;
- Производительность команды (Team performance). Воспринимаемая результативность и совместная сила непосредственной команды сотрудника;
- Производительность продукта (Product performance). Успех и качество продуктов или сервисов, создаваемых командой, на основе таких характеристик, как помощь пользователям в выполнении важных задач и обеспечение безопасности данных, а также метрик производительности;
- Пропускная способность поставки (Software delivery throughput). Скорость и эффективность процесса поставки программного обеспечения;
- Нестабильность поставки (Software delivery instability). Качество и надежность процесса поставки программного обеспечения;
- Качество кода (Code quality). Индивидуальная оценка качества кода, лежащего в основе основного приложения или сервиса, над которым работает сотрудник;
- Индивидуальная результативность (Individual effectiveness). Самооценка сотрудником собственной результативности и ощущения достижений в работе;
- Ценная работа (Valuable work). Самооценка сотрудником количества времени, которое он тратит на работу, которую считает ценной и значимой;
- Трение (Friction). Степень, с которой различные ограничения препятствуют работе сотрудника;
- Выгорание (Burnout). Ощущения истощения и пессимизма, связанные с работой.
В отчете приведены основные препятствия для развития каждой практики практики и способы ее измерения.
Явная и донесенная до сотрудников позиция по AI (Clear and communicated AI stance)Основные препятствия для формирования явной позиции по AI:
- Отношение к политике как к статичному документу. Технологии и рабочие процессы, позволяющие AI оказывать влияние на важные результаты, меняются стремительно. Организациям следует использовать уроки, извлеченные из экспериментов с AI, для регулярного обновления своей позиции по AI и политик допустимого использования;
- Слишком частые изменения. Изменения в политике требуют времени для полного усвоения командами. Политика, которая постоянно меняется, может быть хуже, чем полное ее отсутствие. Убедитесь, что у команд есть время и стимул адаптироваться к изменениям в позиции по AI;
- Узкий взгляд на политику. Позиция по AI должна учитывать потребности всех заинтересованных сторон, а не только одной группы.
Наиболее прямой способ измерить AI stance — это опрос команд для оценки восприятия и ясности политики. DORA измеряла эту возможность на основе ответов на следующие вопросы:
- В какой мере политика вашей организации по AI непосредственно применима к вашей работе?
- В какой мере вам понятно, какие AI инструменты вам разрешено и не разрешено использовать на работе?
- В какой мере вы ощущаете, что использование AI на работе является обязательным?
- В какой мере ваша организация поддерживает вас в экспериментировании с AI?
- В какой мере вам понятно, как вам разрешено и не разрешено использовать AI на работе?
Осведомленность о политике также можно измерять, отслеживая количество просмотров страницы с политикой и количество уточняющих вопросов о политике по AI в публичных каналах.
Здоровые экосистемы данных (Healthy data ecosystems)Препятствия для формирования здоровой экосистемы данных
- Данные как побочный продукт. Для создания здоровых экосистем данных необходимы культурные изменения. Руководители организаций должны инициировать переход от отношения к данным как к побочному продукту транзакций к восприятию их как продукта, у которого есть потребители и который требует целостной долгосрочной стратегии;
- Инструмент как силос. Зрелая платформа данных должна уметь управлять различными источниками и их специфическими подходами к хранению и моделированию данных, включая различные инструменты загрузки и схемы.
Прогресс в формировании здоровой экосистемы данных следует оценивать с помощью сочетания перцептивных метрик и объективных показателей, направляя организацию к непрерывному улучшению. DORA измеряла эту возможность на основе ответов на следующие вопросы:
- Насколько легко вы можете получить доступ к внутренним источникам данных, необходимым для выполнения вашей работы, и анализировать их?
- Как часто вы не можете использовать важные внутренние данные из-за того, что они находятся в силосах?
- Как бы вы оценили общее качество данных, на которые вы обычно опираетесь в своей работе?
- Если вам нужен конкретный показатель, насколько вероятно, что вы сможете получить однозначный ответ в течение 1 часа поиска?
Дополнительные сигналы, которые могут помочь измерить здоровье экосистемы данных:
- Своевременность данных (Timeliness of data). Время, затраченное разработчиком на получение доступа к необходимому набору данных для нового проекта. Эта метрика служит ключевым индикатором потока, аналогично измерению срока поставки (Lead time for changes), помогая выявлять и устранять ограничения в процессах предоставления данных и управления доступом;
- Инциденты с данными (Data incidents). Количество ошибок, производственных инцидентов или дефектов, зафиксированных клиентами, которые однозначно связаны с низким качеством данных. Это может служить косвенным показателем незапланированной работы и переработки, демонстрируя прямое влияние дисфункции данных на нестабильность поставки программного обеспечения и операционную производительность;
- Качество данных (Data quality). Процент прохождения автоматических проверок, включая точность, полноту и своевременность;
- Актуальность данных (Data freshness). Метаданные из источника данных (например, временные метки последнего обновления).
Внутренние данные, доступные для AI (AI-accessible internal data)Основные препятствия для обеспечения доступности данных:
- Низкое качество внутренних данных. Многие организации сталкиваются с внутренними данными, которые устарели, неточны и распределены по множеству разрозненных систем. Одна из наиболее распространенных проблем состоит в том, что AI, подключенный к плохим данным, будет выдавать плохие ответы. Как отметил один из участников исследования, многие компании еще даже не достигли того уровня, когда их данные надлежащим образом организованы. AI, подключенный к плохим данным, будет выдавать только плохие ответы;
- Риск загрязнения AI плохими примерами. Распространенный подход — индексировать все репозитории кода для максимизации доступного контекста. Однако это может дать обратный эффект. Если индексы включают устаревшие проекты, экспериментальные ветки и код, нарушающий актуальные лучшие практики, AI будет обучаться на этом плохом коде так же легко, как и на хорошем. Это приводит к некачественным предложениям, воспроизводящим устаревшие паттерны и технический долг;
- Деградация контекста (Context rot). Многие команды исходят из того, что "больше данных — лучше", и стараются предоставить как можно больше контекста. Однако большие языковые модели имеют ограниченные контекстные окна. Перегрузка модели избыточной или нерелевантной или информацией может быть столь же вредна, как и предоставление слишком малого объема. Ключевой, релевантный сигнал может потеряться, что приводит к нефокусированным, некорректным и обобщенным ответам, игнорирующим критически важные детали;
- Проблемы безопасности и контроля доступа. Первостепенная задача — обеспечить соблюдение AI инструментом существующих разрешений и средств контроля доступа к чувствительным данным. Связанным существенным препятствием является контроль над тем, к каким AI сервисам (например, к одобренному MCP серверу) пользователь может подключаться, а также обеспечение безопасности самих этих сервисов.
DORA измеряла доступность внутренних данных на основе ответов на следующие вопросы:
- Как часто вы вводили или предоставляли внутреннюю корпоративную информацию или данные (например, документы, код, таблицы, текст) в AI инструмент?
- За последний месяц работы как часто вы использовали AI в своей организации для получения и использования информации из внутренних источников данных (например, для ответов на вопросы, формирования отчетов или улучшения рабочих процессов)?
- В какой мере модели имеют доступ к внутренним источникам данных (например, базам данных или кодовым базам) и приложениям (например, вики-системам или системам управления задачами)?
- При использовании AI инструмента в работе как часто его ответы или результаты, по вашему мнению, использовали внутреннюю корпоративную информацию или данные в качестве контекста (например, ссылались на конкретные внутренние проекты, данные или терминологию в своих пояснениях)?
- Когда вы задавали AI инструменту вопросы о внутренних корпоративных делах (например, о деталях конкретных проектов, внутренних отчетах), как часто его ответ давал вам основания полагать, что он обращался к внутренней корпоративной информации или данным для формирования этого ответа?
Существуют и другие сигналы, которые могут помочь оценить степень доступности внутренних данных для AI и то, как это способствует улучшению производительности.
- Частота событий извлечения (Retrieval event frequency). Количество раз, когда AI система успешно выполняет RAG запрос;
- Частота обращений к источникам данных (Data source access rate). Какие источники данных используются и как часто;
- Задержка извлечения AI (AI retrieval latency, Time-to-context). Время, прошедшее с момента, когда AI система определяет потребность в контексте, до момента успешного извлечения этих данных;
- Контекстно насыщенные запросы (Context-rich prompts). Доля запросов (Prompts), являющихся контекстно насыщенными, в сравнении с простыми запросами;
- Адаптация новых разработчиков (New developer onboarding). Время до N-го изменения, поставленного в продакшн. Это может быть первое, десятое или любое другое изменение разработчика, которое было поставлено.
Устойчивые практики контроля версий (Strong version control practices)По мере развития практик контроля версий часто возникают два существенных препятствия:
- Ограниченное использование (Limited use). Одна из наиболее распространенных ошибок - хранение в системе контроля версий только исходного кода приложения. Команды должны быть способны воспроизводить тестовые и производственные среды в полностью автоматизированном режиме, используя необходимую инфраструктуру и данные вместе со скриптами, исходным кодом и конфигурационной информацией из системы контроля версий;
- Конфликты слияния (Merge conflicts). Конфликты возникают, когда система контроля версий не может автоматически разрешить конкурирующие изменения в одних и тех же строках кода. Хотя порой они неизбежны, частые или сложные конфликты слияния нередко свидетельствуют о проблемах в процессах. Команды могут снизить этот риск, обеспечивая короткий жизненный цикл веток разработки и внедряя базовые практики, такие как непрерывная интеграция (Continuous Integration) и разработку на основе Trunk-based development.
DORA измеряла практики контроля версий на основе ответов на следующие вопросы:
- Какие из перечисленных активов управляются в системе контроля версий для основного приложения или сервиса, над которым вы работаете? Код приложения, Конфигурации приложения, Код для автоматизации сборки и конфигурации, Промпты (prompts) для AI систем, Системные конфигурации;
- Если говорить о последнем изменении, зафиксированном в основном приложении или сервисе, над которым вы работаете, приблизительно сколько строк было изменено (добавлено, отредактировано или удалено) в рамках этого коммита?
- В период активного изменения кода или конфигурации основного приложения или сервиса, над которым вы работаете, как часто вы фиксируете изменения в системе контроля версий?
- В период активного изменения кода или конфигурации основного приложения или сервиса, над которым вы работаете, насколько сильно вы полагаетесь на возможность отмены, возврата или отката изменений?
Работа небольшими объемами изменений (Working in small batches)Основные препятствия для работы небольшими объемами изменений:
- Избыточный объем функциональности. Это распространенная проблема. Решение в том, чтобы перейти от мышления горизонтальными слоями к вертикальным срезам. Начните с наименьшего возможного фрагмента сквозной ценности, даже если он изначально не виден пользователям. Практика ветвления через абстракцию (Branch by abstraction) является мощным паттерном для поэтапного выполнения масштабных рефакторингов;
- Требование полной готовности функциональности перед выпуском. Это проблема коммуникации и доверия. Одно из решений — использование флагов функциональности (Feature flags). Объясните, что код непрерывно выпускается в продакшн, что снижает риски, но функциональность останется невидимой для пользователей до ее полного завершения и готовности к проверке. Это разделяет техническое развертывание и релиз функционала, предоставляя команде полный контроль над тем, когда функциональность становится доступной.
DORA измеряла эту возможность на основе ответов на следующие вопросы:
- Для основного приложения или сервиса, над которым вы работаете, сколько времени приблизительно требуется разработчику для выполнения работы, назначенной в рамках одной задачи (например, карточки, тикета или пользовательской истории)?
- Для основного приложения или сервиса, над которым вы работаете, сколько приблизительно изменений (например, Pull request, Merge request или списков изменений) объединяется в один релиз или развертывание?
- Если говорить о последнем изменении, зафиксированном в основном приложении или сервисе, над которым вы работаете, приблизительно сколько строк было изменено (добавлено, отредактировано или удалено) в рамках этого коммита?
Дополнительные сигналы, которые могут помочь измерить работу небольшими объемами изменений:
- Срок поставки (Lead time for changes). Время, необходимое для того, чтобы коммит или изменение кода было успешно развернуто в продакшн.
- Частота слияния веток и форков с основной веткой (Frequency of merging branches and forks to trunk). Измеряется либо как бинарное значение (да/нет) для каждой ветки, которая сливается, либо как % веток и форков, сливаемых ежедневно.
- Отделение релизов от развертываний (Decoupling releases). Измеряется количество или % изменений, развернутых в продакшн, но не ставших немедленно доступными для всех пользователей.
Ориентация на пользователя (User-centric focus)Несколько распространенных препятствий способны ослабить связь с конечным пользователем, подрывая ценность работы, ускоренной с помощью AI:
- Конвейерное мышление (Feature factory mindset). Команды сосредотачиваются на измерении количества выпущенного функционала или скорости разработки, а не ценности для пользователей. AI способен усиливать эту дисфункцию, побуждая команды быстро создавать функционал, который не решает реальных проблем пользователей, что приводит к высокой активности при низком эффекте;
- Технологии ради технологий (Technology-centric approach). Команды попадают в ловушку солюционизма (Solutionism) или разработки ради резюме (Resume-driven development), внедряя новые технологии (включая AI) ради самих технологий, а не для решения конкретных проблем пользователя. Это добавляет сложность и уводит фокус от реальных потребностей пользователя;
- Организационные и процессные силосы (Organizational and Procedural silos). Разработчики нередко системно изолированы от пользователей политиками, процессами или структурой команд. Это создает модель Gatekeeper, при которой обратная связь от пользователей фильтруется, лишая разработчиков глубокого контекста и эмпатии, необходимых для создания ценных решений.
DORA измеряла эту практику на основе ответов на следующие вопросы:
- Создание ценности для наших пользователей является нашим главным фокусом;
- Опыт наших пользователей является нашим главным приоритетом;
- Мы убеждены, что ориентация на пользователя является ключом к успеху бизнеса;
- Мы четко понимаем, чего наши пользователи стремятся достичь с помощью нашего приложения или сервиса;
- Мы используем обратную связь от пользователей для непрерывного пересмотра и перестановки приоритетов функциональности.
Дополнительные сигналы, которые могут помочь измерить ориентацию команды на пользователя:
- Успех продукта (Product success). Продуктовые метрики: уровень принятия (Adoption rate), уровень удержания (Retention rate), удовлетворенность клиентов (Customer satisfaction);
- Согласованность команды (Team alignment). Включение пользователя или его целей в такие элементы, как этапы проекта;
- Представление пользователя в артефактах (User representation in artifacts). Проектные спецификации, в которых пользователь занимает центральное место;
- Фокус на пользователе в неформальном проектировании (User focus in ad-hoc design). Как часто пользователь изображается на схемах на доске или в проектных набросках;
- Ценности команды и признание заслуг (Team values and recognition). Достижения, ориентированные на пользователя, которые получают наиболее активное одобрение со стороны коллег и руководства.
Качественные внутренние платформы (Quality internal platforms)По мере того как организации инвестируют в платформенную инженерию (Platform engineering), ряд ошибок способен подрывать ценность платформы, разочаровывать разработчиков и препятствовать получению организацией отдачи от своих инвестиций. Основные препятствия и антипаттерны:
- Антипаттерн Bbuild it and they will come. Это основной симптом отношения к платформе как к техническому проекту, а не к продукту. Команда создает платформу исходя из собственных представлений о потребностях разработчиков, не проводя никакого пользовательского исследования, интервью или валидации. Они полностью сосредотачиваются на технологии и инженерии, предполагая, что ее ценность будет очевидна сама по себе. Такая платформа в итоге оказывается "городом-призраком", поскольку либо не решает реальных и болезненных проблем разработчиков, либо не вписывается в их существующие рабочие процессы;
- Антипаттерн Ivory Tower Platform. Это препятствие возникает, когда платформенная команда диктует архитектуру и инструменты сверху вниз, насаждая жесткие стандарты без сотрудничества и обратной связи. Они выступают в роли гейткиперов технологий, а не инструмента развития разработчиков. Такой подход оставляет разработчиков без полномочий и нередко порождает неофициальные обходные решения (Shadow IT) для обхода ограничений платформы, сводя на нет ее назначение;
- Антипаттерн Ticket-ops trap. В этом случае платформенная команда функционирует как торговый автомат для инфраструктуры, а не как инструмент обеспечения самообслуживания. Их работа полностью реактивна и определяется бесконечной очередью тикетов от разработчиков. Это создает узкое место и добавляет работу как платформенной команде, так и разработчикам. Команда тратит все свое время на разовые запросы и не имеет возможности создать целостные сервисы самообслуживания, которые обеспечивают реальную ценность платформы;
- Антипаттерн Big bang. Некоторые организации пытаются создать всеобъемлющую платформу, решающую все мыслимые проблемы, прежде чем выпустить хоть какую-то ее часть. Эта стратегия сопряжена с высокими рисками, дорогостоящая и откладывает получение ценной обратной связи. К моменту, когда идеальная платформа наконец запускается, потребности разработчиков нередко уже изменились. Продуктоориентированный подход, напротив, поставляет ценность инкрементально и итерирует на основе реального использования;
- Антипаттерн One-size-fits-all. В попытке максимизировать стандартизацию платформенные команды могут создать единую жесткую "золотую клетку" (Golden cage), которая не учитывает разнообразные потребности различных команд разработки. Потребности команды по Data Science, например, сильно отличаются от потребностей Frontend, работающей также и с мобильными приложениями. Успешная платформа предоставляет направляющие ограничения и оптимальные пути (Golden paths) при сохранении гибкости для использования командами подходящих инструментов для их конкретных задач;
- Отсутствие поддержки со стороны руководства (Executive sponsorship). Платформенная инициатива является значительной организационной и технической инвестицией, требующей преодоления существующих силосов. Без четкой, явной и долгосрочной поддержки со стороны руководства платформенная команда может испытывать нехватку ресурсов, сталкиваться с трудностями при получении поддержки (Buy-in) от других подразделений и не иметь полномочий для проведения необходимых кросс-функциональных изменений.
DORA измеряла качество платформа на основе ответов на следующие вопросы:
- Есть ли в вашей организации выделенная платформенная команда?
- Использовали ли вы платформу на работе в течение последних трех месяцев?
- В какой мере ваша платформа демонстрирует следующие характеристики?
- Платформа ведет себя так, как я ожидаю.
- Платформа эффективно абстрагирует сложность базовой инфраструктуры.
- Платформа дает мне четкую обратную связь о результатах выполнения моих задач.
- Платформа помогает мне создавать и эксплуатировать надежные приложения и сервисы.
- Платформа помогает мне создавать и эксплуатировать безопасные приложения и сервисы.
- Платформа помогает мне соблюдать обязательные процессы (например, проверки кода, согласования по безопасности).
- Платформа проста в использовании.
- Платформа предоставляет инструменты и информацию, необходимые мне для самостоятельной работы.
- Платформенная команда реагирует на обратную связь, которую я предоставляю.
- Пользовательский интерфейс платформы понятен и лаконичен.
- Задачи, которые я выполняю на платформе, хорошо автоматизированы.
Фреймворк HEART предоставляет дополнительные сигналы, которые могут помочь измерить практику платформенной инженерии. Кроме того, вы можете оценивать эффект усилий в области платформенной инженерии через метрики производительности поставки ПО и удовлетворенности разработчиков. Пять метрик производительности поставки ПО (Lead time for changes, Deployment frequency, Failed deployment recovery time, Change failure rate, Deployment rework rate) приносят пользу как платформенным, так и прикладным командам:
- Для платформенной команды. Платформенная команда должна использовать эти метрики для измерения собственной производительности, что помогает улучшать скорость и стабильность изменений на платформе;
- Для прикладных команд. Платформа должна предоставлять эти метрики своим пользователям. Автоматически предоставляя эти метрики для каждого сервиса, вы наделяете разработчиков высокоуровневыми данными, необходимыми им для понимания собственной производительности поставки и наблюдения за прямым влиянием платформы на их работу.
Регулярно опрашивайте разработчиков (клиентов платформы) об их удовлетворенности платформой. Используйте простые метрики, такие как оценка удовлетворенности клиентов (CSAT, Customer satisfaction score) или индекс потребительской лояльности (NPS, Net promoter score), в сочетании с качественной обратной связью, чтобы отслеживать динамику настроений и выявлять области для улучшения.
В отчете также даны краткие практические рекомендации по развитию практик:
- Сформулируйте и распространите политику по AI. Неопределенность в отношении AI сдерживает внедрение и создает риски. Разработайте и донесите до инженеров четкую политику в отношении разрешенных инструментов и их использования, чтобы сформировать доверие. Эта ясность обеспечивает психологическую безопасность, необходимую для эффективного экспериментирования, снижает трение и усиливает положительное влияние AI на индивидуальную результативность и организационную производительность;
- Относитесь к данным как к стратегическому активу. Преимущества AI для организационной производительности значительно усиливаются при наличии здоровой экосистемы данных. Инвестируйте в качество, доступность и унификацию внутренних источников данных. Когда ваши AI инструменты могут обучаться на высококачественных внутренних данных, их ценность для организации возрастает;
- Подключите AI к внутреннему контексту. Подключите AI инструменты к внутренним системам, чтобы выйти за рамки универсальной помощи и добиться роста индивидуальной результативности и качества кода. Это означает не просто закупку лицензий, но и инвестиции в инженерные инициативы по обеспечению защищенного доступа к внутренней документации, кодовым базам и другим источникам данных. Это предоставляет специфический для компании контекст, необходимый для максимальной результативности инструментов;
- Укрепляйте страховочные механизмы. AI-assisted разработка может увеличивать объем и скорость изменений, что также способно приводить к большей нестабильности. Система контроля версий является критически важным страховочным механизмом. Поощряйте команды к глубокому освоению функционала Rollback и Revert, поскольку эта практика связана с улучшением командной производительности в среде с применением AI;
- Сокращайте объем изменений. Несмотря на то что AI может повышать восприятие индивидуальной результативности за счет генерации большого объема кода, выводы авторов показывают, что это не обязательно является наиболее важной метрикой. Вместо этого сосредоточьтесь на результатах. Внедряйте практику работы небольшими объемами изменений (Small batches), что улучшает продуктовую производительность и снижает трение для команд, использующих AI;
- Ставьте потребности пользователей в центр продуктовой стратегии. Инженеры при внедрении AI могут значительно повысить свою личную результативность. Однако если потребности пользователей не находятся в фокусе их внимания, они могут двигаться быстро, но в неверном направлении. Авторы обнаружили, что внедрение AI-assisted инструментов разработки может навредить командам, у которых нет ориентации на пользователя. Напротив, сохранение потребностей пользователей в качестве North Star продукта направляет разработчиков, использующих AI, к правильным целям и оказывает исключительно сильное положительное влияние на производительность команд, применяющих AI;
- Инвестируйте во внутреннюю платформу. Качественная внутренняя платформа является ключевым инструментом усиления положительного влияния AI на организационную производительность. Такие платформы обеспечивают необходимые ограничители и общие возможности, позволяющие преимуществам AI эффективно и безопасно масштабироваться на всю организацию.
Основные материалы из отчета DORA AI Capabilities Model приведены ниже: