28 апреля 2026 г.

Константин Попандопуло

Разговор об ИИ в разработке постепенно становится менее восторженным и более практичным. Почти все команды уже почувствовали ускорение, особенно там, где речь идет о генерации и доработке кода.

И это подтверждается исследованиями: по данным McKinsey & Company, в ряде сценариев генеративный ИИ может ускорять выполнение задач разработки почти в 2 раза, особенно на уровне рутинного кодинга и рефакторинга.

Но чем больше мы смотрим на реальные проекты, тем очевиднее становится: ускорение само по себе не гарантирует бизнес-эффекта. Сроки релизов не всегда сокращаются, а количество возвратов и доработок не всегда падает пропорционально ожиданиям. И тогда закономерно возникает вопрос: если код писать стали быстрее, почему сквозной процесс не ускорился так же заметно? Ответ все чаще смещается в одну точку — в этап до разработки, туда, где формируются требования и принимаются ключевые продуктовые решения.

С Константином Попандопуло, техническим директором Umbrella IT, разбираемся, как искусственный интеллект смещает основной эффект разработки в этап discovery и влияет на качество требований, количество ошибок и скорость вывода продуктов.

Где на самом деле теряется время

Если посмотреть на разработку как на систему, становится видно: кодинг — это лишь часть процесса, и далеко не самая затратная. По разным оценкам, он занимает около 20-25% общего времени.

Остальное — это работа с требованиями, согласования, обсуждения, тестирование и возвраты. Причем значительная часть задержек возникает не внутри этапов, а на их стыке: команда ждет уточнений, пересобирает постановку, возвращается к уже принятым решениям.

В результате реальная скорость разработки определяется не тем, насколько быстро пишется код, а тем, насколько стабилен вход в разработку. И именно этот вход чаще всего оказывается слабым звеном.

Почему баги начинаются не в коде

Ошибки, которые мы фиксируем как баги, часто являются следствием более ранних решений. Проблема возникает не в момент реализации, а в момент постановки задачи.

Типичная цепочка выглядит так:

  • требование сформулировано неполно или неоднозначно;

  • разные участники процесса по-разному его интерпретируют;

  • реализация формально корректна, но не соответствует ожиданиям;

  • расхождение выявляется на тестировании или в продакшене;

  • задача возвращается на доработку.

Каждый такой возврат — это дополнительные затраты времени и ресурсов. При этом сама ошибка могла быть устранена значительно раньше — еще до начала разработки.

По данным IBM, стоимость исправления дефектов может вырастать в десятки раз по мере продвижения по жизненному циклу разработки — от этапа требований до продакшена. В свою очередь, исследования McKinsey & Company показывают, что значительная часть потерь в разработке связана не с низкой скоростью выполнения задач, а с возвратами, переработками и некачественной проработкой требований на ранних этапах.

В реальных проектах это проявляется достаточно типично. Например, в продуктах электронной коммерции требования к логике скидок и промокодов часто формулируются на уровне «поддержать комбинирование условий». Без детальной проработки это приводит к разночтениям: одни сценарии допускают суммирование скидок, другие — нет. В результате команда реализует логику, которая формально соответствует требованиям, но не совпадает с ожиданиями бизнеса.

Такие расхождения обычно выявляются уже на этапе тестирования или после релиза и требуют переработки части функциональности — хотя сама проблема изначально находилась на уровне формулировки.

Этап проработки требований как точка максимального влияния

Этап проработки долгое время воспринимался как подготовительный. Однако на практике именно здесь формируется большая часть будущих характеристик продукта.

На этом этапе определяются:

  • логика работы системы;

  • пользовательские сценарии;

  • ограничения и допущения;

  • критерии готовности.

Любая ошибка в этих элементах масштабируется на весь проект. И наоборот: качественная проработка требований снижает нагрузку на все последующие этапы.

Именно поэтому сегодня discovery становится ключевой точкой приложения ИИ.

Как ИИ работает на этапе проработки требований

В отличие от кодинга, где ИИ в первую очередь ускоряет выполнение задач, на этапе проработки требований он выполняет функцию проверки и уточнения.

Анализ требований

ИИ помогает выявлять:

  • логические противоречия;

  • пробелы в описании;

  • неявные зависимости.

Это позволяет заранее устранить часть проблем, которые в противном случае проявились бы уже в реализации.

Расширение сценариев

ИИ позволяет системно подходить к проработке сценариев:

  • добавлять крайние и нетипичные кейсы;

  • проверять граничные условия;

  • учитывать поведение системы в нестандартных ситуациях.

Это снижает вероятность «сюрпризов» на поздних этапах.

Практически это уже используется в командах, работающих с высоконагруженными пользовательскими сценариями. Например, при проектировании онбординг-флоу ИИ может автоматически сгенерировать десятки альтернативных пользовательских путей — включая нетипичные: прерывание регистрации, повторный вход с другого устройства, частично заполненные данные.

Часть таких сценариев редко попадает в ручную проработку, но именно они часто становятся источником дефектов в продакшене. Их ранняя валидация позволяет избежать доработок уже после запуска.

Работа с гипотезами

На этапе проработки требований важно не только сформулировать решение, но и проверить его устойчивость.

ИИ позволяет быстрее:

  • формулировать гипотезы;

  • рассмотреть альтернативные подходы;

  • выявить слабые места.

Это снижает вероятность того, что в разработку попадут заведомо неудачные решения.

Как это влияет на экономику

Ключевое изменение при использовании ИИ на этапе проработки требований — это влияние не на скорость отдельных задач, а на общую структуру затрат.

Снижение количества возвратов

Чем точнее требования, тем меньше вероятность доработок. Это сокращает количество повторных циклов разработки и делает процесс более предсказуемым.

Снижение стоимости изменений

Исправление ошибки на этапе требований обходится существенно дешевле, чем изменение уже реализованной функциональности. Это классический эффект, который усиливается при масштабировании проектов.

Ускорение вывода продукта на рынок

Скорость выхода на рынок определяется количеством итераций. Чем меньше возвратов, тем быстрее команда проходит путь от идеи до релиза.

В этом смысле ИИ на этапе проработки требований влияет не на локальную производительность, а на итоговый результат.

В одном из типовых сценариев продуктовой разработки пересмотр требований с использованием ИИ на этапе проработки требований позволил выявить несколько противоречий в логике обработки пользовательских состояний еще до начала реализации. В результате команда отказалась от части первоначальных решений и упростила архитектуру.

Если бы эти несоответствия проявились на этапе тестирования, это потребовало бы переработки уже реализованных компонентов. В данном случае изменения были внесены до начала разработки, что позволило избежать дополнительного цикла и сократить общий срок вывода функциональности.

Метрики: как измерить эффект

Один из сложных вопросов — как зафиксировать влияние ИИ на ранних этапах.

На практике команды начинают отслеживать:

  • количество возвратов на доработку;

  • долю изменений требований после старта разработки;

  • среднее время прохождения задачи от постановки до релиза;

  • стабильность спринтов (объем незавершенных задач).

Именно эти метрики лучше всего показывают эффект от улучшения качества требований.

Ограничения и риски

ИИ не устраняет проблемы процесса автоматически. Он делает их более заметными.

Если требования сформулированы слабо, ИИ:

  • генерирует избыточные варианты;

  • усиливает неопределенность;

  • усложняет принятие решений.

Поэтому ключевым остается навык формулирования задач. ИИ работает тем лучше, чем точнее задан контекст.

Что это меняет для команд

Смещение фокуса на этапе проработки требований приводит к изменениям в работе команд:

  • усиливается роль аналитики;

  • возрастает значимость продуктового мышления;

  • повышаются требования к качеству постановки задач.

ИИ становится не заменой специалистов, а инструментом, который усиливает их работу на ранних этапах.

Итог

ИИ уже доказал свою эффективность в ускорении разработки. Но основной эффект проявляется не там, где его чаще всего применяют.

Фокус постепенно смещается на этап проработки требований — туда, где формируется сама логика продукта и закладывается качество будущей реализации.

И в этом контексте ключевой вопрос меняется: не «как быстрее писать код», а «как изначально формулировать задачи так, чтобы не приходилось его переписывать». Именно здесь ИИ начинает влиять на результат всей системы разработки.

Источник: Константин Попандопуло, техническиq директор Umbrella IT