Кейсы

Как мы сократили цикл разработки фичи с месяца до недели?

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

Контекст команды

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

Ранее фичи чаще проходили через последовательную цепочку:
  • получение требований от продаж/маркетинга,
  • проработка бизнес-логики,
  • описание интерфейсов,
  • согласование макетов,
  • постановка отдельных задач разным исполнителям,
  • синхронизация между участниками команды,
  • объединение результатов перед тестированием.

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

Каждый этап был вполне логичным и жизненно необходимым. Но чем сложнее становился продукт, тем больше времени уходило на объяснение одной и той же идеи разным людям. Соответственно, самым длительным (и по факту дорогим в стоимости) оказалась передача контекста между ребятами.

Что изменилось

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

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

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

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

Однако есть важный нюанс: чтобы такой подход работал корректно, необходимо заранее создать базовый дизайн системы и набор основных компонентов.

Такой подход сократил количество передач контекста между участниками команды. Важно: документация не исчезла, но уменьшились ее объем и глубина.

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

Как изменилась роль аналитика

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

На основе заметок со встречи модель может сформировать черновик технического задания, собрать backlog, предложить структуру roadmap, подготовить тест-кейсы или описание API.
Что отнимало много времени
Что оптимизировалось
Детальные контракты заранее
Контракты можно быстрее подготовить и уточнить с ИИ
Отдельные постановки на фронт и бэк
Одна цельная задача на фичу
Полное описание интерфейса
Фокус на ожидаемом поведении
Пояснения для разных исполнителей
Один разработчик держит контекст
Ручная синхронизация ролей
Больше ответственности у владельца фичи
Это позволяет аналитику сосредоточиться на том, что действительно требует экспертизы: понять бизнес-задачу, определить требования, проверить полноту решения и убедиться, что разработанная функциональность соответствует ожиданиям заказчика.
«Самое ценное изменение для меня — это возможность меньше заниматься механической подготовкой документов и больше работать с задачей. ИИ помогает быстро оформить черновик ТЗ или тест-кейсов, но именно аналитик определяет, что действительно нужно пользователю и как это должно работать. В итоге фокус сместился с написания документов на проектирование решения», — Ирина, аналитик команды Docora AI, CodeInside.
ИИ стал инструментом подготовки материалов, но ответственность за их содержание и качество по-прежнему остается за человеком.

Как изменилась роль руководителя проекта

Для руководителя проекта главное изменение — не скорость, а смена единицы управления. Раньше фича распадалась на постановку, задачу на бэкенд, задачу на фронтенд и тестирование, и работа РП во многом состояла в том, чтобы соединить эти части и удержать их в одном сроке. Сейчас единица управления — фича целиком с одним владельцем: разработчик ведёт её от системных требований до фронтенда и бэкенда. Управлять нужно не стыками внутри фичи, а потоком фич, приоритетами и рисками.
Что стало занимать меньше времени?
  • Сборка статуса по частям. Статус фичи виден целиком, а не как «бэк готов, фронт в очереди, интеграция не проверена».
  • Согласование очередности между исполнителями: зависимости фронта и бэкенда ушли внутрь одной фичи и одного человека, снаружи их синхронизировать не требуется.
  • Проблемные коммуникации на стыках. Типовые «не так понял постановку», «договорились устно», «разошлись версии контракта» в значительной части просто не возникают, когда контекст не передаётся между людьми.
  • Регулярные синхронизации. Часть встреч перестала быть нужной, потому что их содержанием была именно передача контекста.
Что стало важнее?
  • Приоритизация и загрузка. Реализация ускорилась, и узким местом становится не разработка, а решение о том, что делать следующим;
  • Контроль сроков сместился с промежуточных точек (готов ли контракт, согласован ли макет) на дату готовности фичи целиком и на сверку результата с исходной целью;
  • Хранение контекста. Решения, принятые внутри фичи одним человеком, должны фиксироваться в задаче, иначе они остаются в переписке и в голове владельца;
  • Управление концентрацией знаний. Владелец фичи знает о ней больше, чем любая документация, поэтому review и краткая фиксация решений становятся обязательными, а не желательными.
«Раньше существенная часть моей работы состояла в том, чтобы соединять людей: донести контекст, согласовать стыки, свести результаты в один срок. Сейчас функционал от системных требований до фронта и бэка делает один человек — и вместе с этими передачами исчезла большая часть проблемных коммуникаций. Управлять стало нужно другим: приоритетами, количеством параллельных фич, и тем, чтобы решения, принятые внутри фичи, не оставались только в голове её владельца», — Павел, руководитель проекта команды Docora AI, CodeInside.

Как изменилась роль разработчика

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

Но вместе с этим возрастает ответственность.

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

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

Всегда есть вторая сторона медали. Все супер удобно, но нужно помнить, что ИИ хорошо готовит черновик, а всю остальную работу проводит сам разработчик. ИИ ускоряет путь к результату, но не знает специфики стенда и не отвечает за итог — это по-прежнему наша зона ответственности», — Иван, AI-инженер команды Docora AI, CodeInside.

Какие артефакты теперь помогает готовить ИИ

Фактические сценарии использования:
  • из сырых заметок со встреч, обсуждений и демонстраций собирается бэклог,
  • формируется roadmap,
  • готовятся задачи для разработки,
  • оформляются Jira-ready задачи по найденным багам,
  • готовятся тест-кейсы и QA-матрицы,
  • выполняются проверки задач из Jira в статусе тестирования,
  • частично выполняется регресс,
  • готовятся ТЗ на крупные изменения,
  • делаются предварительные макеты или HTML-прототипы,
  • описываются API, БД, политики доступа,
  • поддерживается документация,
  • восстанавливается контекст по прошлым обсуждениям.

Примеры из работы за период 25 мая - 1 июня 2026:

Бэклог и roadmap. Из сырых заметок по Docora были собраны задачи, приоритеты, сроки и открытые вопросы.
QA и тестирование. Была подготовлена матрица на 36 тест-кейсов для конструктора агентов. Также проводились проверки Jira-задач в статусе тестирования.
Постановка задач. Были оформлены задачи по багам и улучшениям.
Системные ТЗ. Было подготовлено ТЗ на ABAC-ролевую модель: политики, API, БД, UI, миграция, аудит и тесты.
Прототипирование. Был создан HTML-прототип интерфейса для ABAC.
Анализ конкурентов и стенда. Проводился анализ конкурентных решений и фактического UI стенда Docora.

Ограничения и риски валидации результатов

ИИ не снимает ответственность. ИИ может подготовить задачу, ТЗ, тест-кейсы или отчет, но результат нужно проверять. Финальная ответственность остается у человека.
Не все тестирование автоматизируется. Codex может помочь с API-проверками, подготовкой матрицы, анализом логики, но UI-сценарии, блокеры, нестабильные стенды и неоднозначные кейсы часто требуют ручной проверки.
Появляется иллюзия готовности. ИИ делает аккуратные тексты, таблицы и задачи. Из-за этого черновик может выглядеть как готовый результат. Нужен явный этап валидации.
Растет объем параллельного контекста. С ИИ можно быстрее обрабатывать несколько задач, но становится сложнее удерживать весь контекст. Это создает новую задачу: правильно хранить решения, возвращаться к перепискам, фиксировать выводы и не терять важные договоренности.Проект подтвердил, что ИИ-ассистент может стать полноценным каналом взаимодействия с участниками мероприятий.

Выводы для команд, желающих ИИзировать процессы

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

  1. Где у нас слишком много ручной передачи контекста?
  2. Кто владеет фичей целиком?
  3. Какие документы мы пишем потому, что они реально нужны, а какие - чтобы компенсировать разрыв между ролями?
  4. Какие артефакты можно генерировать через ИИ?
  5. Кто валидирует ИИ-результат?
  6. Где хранится финальный контекст задачи?
  7. Какие проверки нельзя отдавать ИИ полностью?
  8. Как отличить черновик от готового результата?
  9. Как не превратить ускорение в рост хаоса?

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

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