Аннотация
Введение
ИИ анализирует видео встречи и за 1,5–3 минуты формирует черновик ТЗ со скриншотами по корпоративному стандарту. Представьте: вы — аналитик, и у вас по пять, а то и больше встреч каждый день. После каждой нужно подготовить документ. Вы часами переслушиваете записи, вырезаете скриншоты, мучаетесь с нумерацией картинок в Word и пытаетесь сформулировать брошенные вскользь фразы как требования к базе данных.
В жизненном цикле разработки ПО подготовка документации остаётся самым трудозатратным этапом. McKinsey отмечает, что ИИ эффективно повышает производительность именно здесь. Наш кейс автоматизирует именно этот участок. Система может реально «разгрузить» аналитиков, а не просто пересказать созвон.
Наш Заказчик, столкнувшись с необходимостью обрабатывать десятки совещаний по доработкам систем в неделю, отказался от расширения штата аналитиков. Вместо этого они поставили перед собой инженерную задачу: создать систему, которая автоматически генерирует полноценный документ с описанием требований за 1,5–3 минуты по ссылке на запись видео встречи.
Главная ценность этого решения не в том, что нейросеть «что-то написала», а в синхронизации визуального ряда с контекстом обсуждения. Мы создали не просто «саммари встречи», а промышленный ИИ-конвейер на платформе Epsilon Workspace, который формирует проектный документ — спецификацию требований или ТЗ на доработку.
Система восстанавливает полный контекст встречи, связывает обсуждаемые требования со скриншотами экранов и конкретными словами участников.
ИИ анализирует видео встречи и пишет ТЗ. Краткое описание
Задача
Устранить «бутылочное горлышко» на этапе документирования требований, которое замедляло Time-to-Market ИТ-проектов. Требовалось освободить ведущих аналитиков от 40+ часов рутины в месяц (прослушивание записей, оформление скриншотов, верстка ТЗ) и исключить риск потери данных при передаче знаний от бизнеса к разработке. Ключевое условие — автономность внедрения без привлечения дефицитных ресурсов внутренней ИТ-команды.
Решение
Развёртывание промышленного ИИ-конвейера. Система интегрирована с архивами видеозаписей встреч. С использованием рабочего процесса (включая компьютерное зрение и ИИ-агентов) автоматически формирует структурированные документы. Решение синхронизирует видеоряд с контекстом обсуждения и выдает готовый DOCX-файл с предопределёнными разделами.
Это принципиальный момент. Если ограничиться только транскрипцией, получится текстовая выжимка встречи, но не инженерный документ. Чтобы собрать требования, системе нужно одновременно учитывать визуальный контекст, предметную область обсуждения, терминологию и структуру будущего документа. Поэтому в кейсе решается задача не «распознавания созвона», а восстановления проектного смысла обсуждения.
Результаты
Внедрение ускорило подготовку проектной документации более чем в 100 раз — с 4–8 часов до 3-х минут на черновик одного документа. По оценке Заказчика, это обеспечило высвобождение до 80% времени квалифицированных аналитиков для задач проектирования и валидации. Система формирует документ по корпоративному шаблону (структура, стили, нумерация, подписи), проверяет результат перед экспортом, а также обеспечивает полную прослеживаемость требований от сказанной во время встречи фразы до соответствующего пункта в техническом задании.
Этот проект изменил операционную модель работы с требованиями и обеспечил результаты:
Время автоматической генерации черновика ТЗ объёмом около 15 страниц сократилось до 2–3 минут вместо 4–8 часов ручной подготовки.
Включает 10–25 скриншотов, привязанных к конкретным пунктам обсуждения.
- Выдает стандартизированную структуру документа, например, AS-IS и TO-BE, термины, модель данных и открытые вопросы.
При необходимости интегрируется в ландшафт через REST API, сохраняет документ в Jira или Confluence.
- Система ускоряет не только написание документа, но и его согласование. Когда каждое требование «привязано» к скриншоту и реплике, снижается эффект «испорченного телефона». Это экономит недели на уточнениях и переделках из-за того, что участники по-разному поняли один и тот же созвон
Этот кейс — описание того, как реально «разгрузить» экспертов-аналитиков.
Проблема
Подготовка требований обычно воспринимается как понятная и измеримая часть SDLC (Software Development Life Cycle — жизненного цикла разработки ПО). На практике же заметная доля времени уходит на сопутствующие операции после встреч, и эти часы часто не попадают в оценки. В ежедневной работе возникает отдельная статья расходов, которая редко отражается в планах и планировании напрямую, — неучтённые трудозатраты на подготовку требований после встречи. Они проявляются как потерянные часы работы и замедление Time-to-Market.
Проблема не в том, что нет расшифровки. Самое трудоёмкое — восстановить контекст: какой экран обсуждали в этот момент и какое техническое требование из этого следует. Именно связка «Экран ↔ Речь ↔ Решение» вручную собирается долго и нередко приводит к ошибкам и двусмысленностям.
Это важно потому, что на встрече значимо не только то, что кто-то произнёс, но и то, что команда увидела на экране и как это интерпретировала в момент обсуждения. Во многих случаях требование появляется именно из такой связки: участники смотрят на интерфейс, замечают ограничение, обсуждают его и принимают решение, которое потом должно попасть в документ уже в формализованном виде.
Чтобы увидеть масштаб, рассмотрим типовой цикл после обычного рабочего созвона.
11:00. Завершение встречи. Часовое обсуждение новой фичи в мобильном приложении закончилось. В созвоне участвовало 10 человек: кто-то показывал прототипы в Figma, кто-то — структуру БД на доске, а кто-то демонстрировал действующий экран приложения и объяснял, куда перенести кнопку и какие элементы добавить на экран.
11:15. Начало разбора записи. Аналитик открывает видео. Начинается монотонная работа: переслушать час обсуждения и не упустить нюансы. Приходится поминутно проматывать запись, чтобы найти фрагмент, где архитектор объяснял логику интеграции, а продакт менеджер — критерии готовности.
13:30. Работа с визуальным рядом. Через час аналитик начинает собирать скриншоты: захват экрана, обрезка, вставка в Word, подписи. Нумерация рисунков съезжает, верстка «плывёт», а смысл каждого кадра приходится восстанавливать по памяти: «А что именно мы тут решили по этому чекбоксу?».
15:00. Формализация требований. Самая сложная часть — превратить фразы, сказанные вскользь («ну, дубли как-нибудь почистим»), в строгие пункты ТЗ: правила валидации, ограничения, сценарии ошибок, требования к данным. К этому моменту детали уже начинают стираться на фоне следующих созвонов. Дополнительную сложность создаёт терминология. В обсуждениях разные участники могут называть одну и ту же сущность по-разному, а один и тот же термин — использовать для разных понятий. Например, «отгрузка» в одном контексте означает физическую отправку товара, в другом — комплект отгрузочных документов, а в третьем — момент фиксации операции в системе. Термин «проведение» может означать проведение документа в 1С, запуск связанных расчётов и проводок или подтверждение бизнес-операции в процессе. Поэтому системе нужен не только словарь синонимов, но и контекстный разбор терминов: чтобы правильно связать речь, экран и итоговую формулировку требования.
18:00. Финализация черновика. Прошло 6–7 часов. Первая версия документа на 10–15 страниц готова, но аналитик выполнял роль стенографиста и верстальщика вместо проектирования и валидации требований.
Следующий день. Ревью. Выясняется, что логику поняли неверно. Фраза из записи без привязки к экрану, который видели участники, оказалась двусмысленной. Документ уходит на доработку, и цикл бесполезных трудозатрат запускается снова.
Этот сценарий повторяется после каждой встречи. Так формируются неучтённые трудозатраты на подготовку требований после встречи: непродуктивная рутина, которая превращает высококвалифицированных специалистов в стенографистов.
ИИ анализирует видео встречи и пишет ТЗ. Решение
Мы решили не просто расшифровывать аудио, а построить систему, которая одновременно «видит» видеоряд и «понимает» контекст обсуждения.
Выбор платформы Epsilon Workspace для реализации этого решения был основан на трёх факторах:
Гибкая работа с медиаданными: Возможность встроить алгоритмы компьютерного зрения для глубокого анализа видеопотока.
Архитектура ИИ-агентов: Платформа позволяет распределять задачи между специализированными моделями (планирование, генерация, вёрстка), что критично для качества технического документа.
Информационная безопасность и интеграции: Возможность развёртывания в закрытом контуре (On-premise) и наличие готовых шлюзов для автоматической выгрузки данных в Jira и Confluence.
Целью было создание автономного конвейера, который берёт на себя всю цепочку: от интеллектуальной очистки видеозаписи до формирования финального артефакта SDLC с доказательной базой. Это позволило получить систему уровня сложных Enterprise-решений, сохранив при этом гибкость и высокую скорость внедрения.
Как работает система: от видеозаписи к готовому ТЗ за 3 минуты
«Раньше подготовка проекта ТЗ по итогам встречи занимала несколько часов. Теперь я просто передаю ссылку на запись видео встречи и через несколько минут получаю структурированный черновик ТЗ, в котором уже есть всё необходимое», — отмечает ведущий системный аналитик проекта.
Процесс, который раньше требовал многочасового погружения, теперь полностью автоматизирован и скрыт «под капотом» платформы. Высокоуровнево он выглядит так:
Передача источника. Аналитик просто отправляет ссылку на запись встречи в систему. Не нужно вручную скачивать файлы или делать скриншоты — система забирает данные самостоятельно.
Анализ. Система запускает параллельную обработку видео и аудио. В этот момент ИИ-агенты соотносят сказанное на встрече с тем, что демонстрировалось на экране. Благодаря этому каждое требование в будущем документе получает визуальное подтверждение.
Автоматическая публикация. Через 2–3 минуты после старта система генерирует структурированный черновик ТЗ по корпоративному стандарту. После этого аналитик выполняет проверку и точечные правки. Также документ со всеми разделами и иллюстрациями может автоматически сохраняться в Jira или Confluence, где он сразу становится доступен команде разработки.
В следующем разделе мы подробно разберём, как именно устроены девять этапов этого конвейера: от фильтрации кадров до финальной вёрстки документа.
Заглянем «под капот»: 9 этапов ИИ-конвейера
Надёжность системы строится не на «удачном промпте», а на строгом инженерном конвейере. Система реализована как REST API и для каждого видео выполняет цикл обработки из девяти этапов.
Блок №1: Подготовка данных и визуальный фильтр (Этапы 1–5)
Предположим: на входе у нас час видео — это примерно 108 000 кадров. Задача этого блока — оставить только те кадры, в которых есть смысл для ТЗ.
Этап 1. Метаданные и транскрипция. По URL извлекается ID встречи, запрашиваются метаданные и транскрипция. Мы читаем её в нескольких форматах (основной — JSON), так как API платформ видеосвязи часто не гарантирует единообразия.
Этап 2. Детекция смены сцен. Видео сэмплируется (1 кадр/сек). Кадры сравниваются по метрике структурного сходства (SSIM), чтобы фиксировать именно смену интерфейса, а не мелкие отличия (например, движения курсора).
Этап 3. Дедупликация. Убираем визуально идентичные кадры, которые возникают при прокрутке экрана туда-обратно.
Этап 4. Кластеризация возвратов. Если экран показали в начале и снова через 20 минут, система объединяет эти кадры в один кластер. Конвейер понимает: это одна сущность, обсуждаемая в разные моменты.
Этап 5. Фильтрация портретов. Главный этап очистки кадров от тех кадров, где есть лица участников. Классифицируем кадры: если лицо занимает >15% площади и в кадре низкая плотность контуров — он удаляется. Скриншоты приложений, схемы и другие полезные фрагменты наоборот, содержат линии и текст, поэтому они проходят этот фильтр.
Блок №2: Анализ и генерация контента (Этапы 6–7)
Этап 6. Привязка кадров к транскрипции.
Каждому значимому кадру сопоставляется «окно контекста» — речевое сопровождение за 30 секунд до и после момента на экране. Теперь ИИ видит не просто изображение, а связку «кадр + обсуждение».
На этом этапе происходит нормализация терминов: система соотносит разные названия одной и той же сущности в речи, на экране и в документации. Это позволяет избежать путаницы, когда разные термины описывают один объект, или наоборот — когда одно слово в разных частях процесса имеет разный смысл. Окно контекста здесь служит фильтром, который позволяет ИИ точно восстановить значение термина, исходя из конкретной ситуации на встрече.
Этап 7. Анализ кадра и относящегося к нему текста (3 шага LLM)
Шаг 7.1. Планировщик: формирует структуру ТЗ и привязывает разделы к тайм-кодам.
Шаг 7.2. Исполнитель: параллельно пишет детализированный текст разделов, работая только с релевантными фрагментами.
Шаг 7.3. Верстальщик: управляет размещением скриншотов, подписями и нумерацией.
Блок №3: Контроль качества и экспорт (Этапы 8–9)
Финальная стадия превращения данных в промышленный артефакт.
Этап 8. Постобработка. Все ответы модели проходят через валидаторы. Мы проверяем ссылки на реальность кадров (защита от галлюцинаций), разносим «слипшиеся» картинки и выполняем сквозную перенумерацию «Рис. №». Также выполняем контроль целостности: сущность не попадёт в ТЗ, если она не подтверждена ни речью, ни экраном.
Этап 9. Генерация DOCX и интеграция. JSON-спецификация рендерится в финальный файл. Также при необходимости готовое ТЗ автоматически может сохраняться в Jira (как описание задачи) или в Confluence (как новая страница Wiki).
«Мы превратили вероятностную природу ИИ в детерминированный процесс. Каждый из 9 этапов — это фильтр, который отсекает шум и галлюцинации, оставляет только требования», — отмечает руководитель проекта.
Почему это сработало
Это комбинация трёх решений: правильно выбрали задачу для автоматизации, встроили ИИ-решение в существующий отлаженный процесс и разработали промышленный инструмент, который даёт качество на реальных записях встреч.
1) Удачный выбор сценария для AI-автоматизации: дорогая рутина у квалифицированных экспертов
Компания выбрала «узкое место» в процессе доработки систем и приложений: переход от обсуждений к требованиям. Это классический пример автоматизации дорогой рутины у высококвалифицированных специалистов.
Исполнители: ведущие аналитики, чьё время — дефицитный и дорогостоящий ресурс.
Рутина: разбор записи, поиск нужных фрагментов, нарезка скриншотов, подписи и нумерация, сборка документа, формализация решений в пункты ТЗ.
Почему это важно: компания платит аналитикам не за «часы стенографии», а за часы проектирования, валидации и качества требований.
2) AI, который подстраивается под процесс, а не наоборот: минимум действий и привычные артефакты
Вместо того чтобы менять цикл разработки и переучивать команду под новые инструменты, был выбран путь «невидимого помощника», который адаптируется к привычкам аналитиков.
Минимум действий: аналитику достаточно передать ссылку на запись встречи.
Привычная среда: результат появляется там, где команда уже работает — в ТЗ по корпоративному стандарту, Jira или Confluence.
Корпоративный формат: система формирует документ в типовой структуре, например, AS-IS / TO-BE, с глоссарием, открытыми вопросами и (при необходимости) моделью данных — то есть не «выдаёт текст», а формирует стандартизированный документ.
Это критично для корпоративной среды. Инструменты такого класса внедряются лучше всего тогда, когда не меняют рабочий сценарий команды, а сокращают его самые ресурсоёмкие и рутинные участки. Здесь аналитик не переключается на новую методологию «ради ИИ», а получает привычный результат в привычной среде — только быстрее и с более высоким уровнем прослеживаемости. Этот подход обеспечил быстрое принятие инструмента: команда увидела в системе не «замену», а способ снять ежедневную перегрузку.
3) Правильный инструмент: индустриальный конвейер и готовность для корпоративного внедрения
- Можно ли доверять результату? Да. Конвейер с валидацией публикует только те пункты, которые подтверждены речью или экраном; неподтверждённые требования не попадают в ТЗ (уходят в «требует проверки»).
- Как обеспечить безопасность? Платформа является Enterprise-решением и может быть развернута в закрытом контуре компании (On-premise). Данные о внутренних разработках и архитектуре не покидают периметр безопасности.
- Почему это внедрили быстро? При всей сложности процесс внедрения не требует разработки “с нуля” — настройка логики и интеграций выполняется на платформе.
Резюме: от ручной сборки к стандарту
Этот проект показал: чтобы ускорить разработку и доработку ПО, не всегда нужно расширять штат. Часто достаточно автоматизировать выпуск проектных документов. Результат — не только экономия времени, но и новая дисциплина работы с требованиями.
Результаты внедрения ИИ-конвейера: разгрузили аналитиков и ускорили подготовку ТЗ
Внедрение промышленного ИИ-конвейера принесло компании два типа результатов: прямые, выраженные в экономии сотен рабочих часов, и стратегические, которые устранили «бутылочное горлышко» на старте разработки.
1. Прямая экономия: превратили «часы» в «минуты»
Самым ощутимым итогом стало радикальное сокращение времени на производство проектных артефактов. Теперь компания не оплачивает многочасовую рутину высококвалифицированных экспертов.
Из чего складывается эффективность? Экономия ресурсов — это не просто цифры, а высвобождение потенциала команды:
Сокращение трудозатрат: Время подготовки одного ТЗ объемом 15 страниц сократилось с 4–8 часов до 2–3 минут автоматической генерации.
Прямая экономия бюджета: Автоматизация позволила избежать найма двух дополнительных системных аналитиков при росте портфеля проектов. При средней стоимости на рынке это экономит компании более 6 млн ₽ в год только на ФОТ.
Возврат инвестиций (ROI): По оценке Заказчика, благодаря использованию no-code платформы и отсутствию долгой заказной разработки, проект окупился уже в первом квартале эксплуатации.
2. Стали проектировать, а не «описывать»
Сэкономленное время — почти 30–40 часов в месяц на каждого аналитика — сразу было перенаправлено на задачи с высокой добавленной стоимостью. Команда смогла:
Ускорить Time-to-Market. Черновик ТЗ формируется через 2–3 минуты после встречи, а проверенный документ поступает в работу в тот же день или на следующий рабочий день вместо прежнего недельного цикла. Цикл согласования требований сократился в несколько раз.
Повысить качество артефактов. ИИ не «забывает» детали. В каждом документе теперь есть полная доказательная база из 15–20 скриншотов с точными подписями, что существенно снижает вероятность споров в духе «мы об этом не договаривались».
Самая демотивирующая часть работы — ручной перенос данных и вёрстка в Word — теперь полностью делегирована системе.
3. Бесшовность и сквозной процесс
Главным итогом стала технологическая связность процессов.
Автоматическая интеграция: 9 из 10 документов публикуются в Jira или Confluence напрямую через REST API.
Единый стандарт: Все документы, независимо от того, какой аналитик вёл встречу, выглядят одинаково профессионально и соответствуют корпоративному шаблону.
Прослеживаемость: Любое требование в тексте теперь можно мгновенно соотнести с визуальным контекстом на видео.
«Я всегда с тоской смотрел на записи встреч за день, понимая, что впереди — вечер разбора. Теперь подготовка ТЗ превратилась в проверку черновика, который ИИ собрал за меня» — говорит системный аналитик проекта.
Как посчитать экономический эффект: экономика «одной встречи»
Ценность решения лучше всего видна на уровне обработки одной встречи. Мы не пересчитываем «абстрактных сотрудников», а берём одну видео-встречу и считаем, как меняются затраты на её обработку и выпуск документа по итогам.
Формула расчёта эффекта (на одну встречу)
Экономия = (Время_вручную − Время_системы − Время_проверки) × Стоимость_часа − Себестоимость_запуска
Где:
Время_вручную — время аналитика при ручной подготовке требований (обычно 4–8 часов: переслушивание, скриншоты, вёрстка, формулировка требований).
Время_системы — время генерации системой (обычно 1,5–3 минуты).
Время_проверки — время на проверку и правки (обычно 20–60 минут, зависит от качества видео и сложности встречи).
Стоимость_часа — полная стоимость часа специалиста (зарплата + налоги + накладные расходы).
Себестоимость_запуска — стоимость обработки одной встречи (модель/инфраструктура/вычисления/хранение).
Расчёт ведётся на одну встречу и масштабируется под любую команду. При росте штата меняется не формула, а количество встреч, которые нужно превращать в требования.
Как получить эффект «в месяц» и «в год»
После расчёта на встречу эффект масштабируется линейно:
Экономия_в_месяц = Экономия_на_встречу × Количество_встреч_в_месяц
Экономия_в_год = Экономия_в_месяц × 12
Так можно пересчитать экономику под любую организацию: подставьте свой объём встреч, свою стоимость часа и свою себестоимость обработки.
Как мы фиксируем «до» и «после»
Сравниваем одинаковые периоды:
берём 10–20 встреч до внедрения и 10–20 встреч после;
для времени используем медианное значение;
для очереди задач считаем среднее/медиану за 4 недели.
Нормированные показатели (подходят любой организации)
Экономия времени (часы в месяц)
Экономия_часов_в_месяц = (Время_вручную − Время_системы − Время_проверки) × Количество_встреч_в_месяц
Пример интерпретации: при 10 встречах в месяц один аналитик высвобождает 40+ часов, или «+1 рабочая неделя в месяц» в строгом числовом виде.
Важно: время высвобождается сразу; а финансовый эффект возникает, когда эта время конвертируется в рост пропускной способности или отказ от найма/подрядчика.Скорость выпуска требований (встреча → готовый документ)
Время от завершения встречи до появления готового ТЗ и/или задач в системе управления проектами.
Показатель корректнее считать по медиане: например, с 2 дней до 45 минут.Очередь задач аналитиков
Количество задач по оформлению итогов встреч/требований в статусах ожидания (например, «К выполнению / Ожидает / В очереди»).
Эффект выражается как –X% или “в 2 раза меньше задач в очереди”.Прослеживаемость требований
Доля требований, у которых есть прямая ссылка на источник: таймкод видео + кадр/скриншот. Это снижает споры «мы этого не обсуждали» и уменьшает переделки.
Окупаемость: в месяцах и «в количестве встреч»
Для управленческих решений показываем окупаемость в двух измерениях:
Окупаемость в месяцах
Срок_окупаемости = Затраты_на_внедрение / (Экономия_в_месяц − Ежемесячные_расходы)
где Затраты_на_внедрение — внедрение и интеграции, Ежемесячные_расходы — лицензии/инфраструктура/поддержка.
Окупаемость в количестве встреч
Встречи_до_окупаемости = Затраты_на_внедрение / Экономия_на_встречу
Так можно расчитать: «Система окупится на N-й видео-встрече».
Почему эффект растёт линейно
Экономия не зависит от количества аналитиков напрямую — она растёт вместе с количеством встреч, которые нужно превращать в требования. Если встреч становится больше, эффект увеличивается пропорционально и не требует расширения штата, потому что система масштабируется проще, чем команда.
«6+ млн ₽ в год» — консервативная оценка для средней нагрузки, основанная только на сокращении трудозатрат аналитиков. Реальный эффект обычно выше за счёт ускорения передачи требований в работу и снижения числа ошибок и переделок.
Риски, вопросы и ответы
Вопрос № 1: Что если на встрече много специфического сленга, сокращений и внутренних терминов?
Поддерживается «словарь проектов»: список терминов, сокращений, названий систем, ролей и сущностей. Он используется при нормализации текста и при формировании ТЗ, чтобы сохранять корпоративную терминологию. Если термин не распознан уверенно или может означать разное — такой фрагмент помечается как требует проверки. Спорные места (когда неясно, это синоним или разные сущности) также выделяются для подтверждения экспертом.
Вопрос № 2: Что если качество аудио плохое, много шумов, или люди говорят одновременно?
Мы опираемся на распознавание речи и оценку уверенности. При низкой уверенности система не «додумывает»: такие фрагменты уходят на проверку, а в документ попадают только пункты, которые можно подтвердить. Если разговор пересекается, мы стараемся разделять реплики по участникам; при высоком наложении голосов больше пунктов будет помечено как требует проверки.
Вопрос № 3: Что если транскрипта от платформы видеосвязи нет или он плохой?
Транскрипт может быть получен автоматически из аудио, либо использован встроенный транскрипт платформы — в зависимости от того, что доступно и что даёт лучшее качество. Если качество распознавания ниже порогов, система всё равно формирует документ, но больше пунктов помечаются как требует проверки.
Вопрос № 4: Что если видео размыто, мелкий шрифт на экране, или демонстрация идёт рывками?
Конвейер использует комбинацию сигналов: речь + экран. Если экран нечитаем, требования могут быть извлечены из обсуждения, но элементы, завязанные на визуальные детали (поля формы, подписи, таблицы), будут чаще требовать проверки.
Для стабильного результата мы рекомендуем простые правила записи: читаемый масштаб интерфейса, демонстрация экранов, нормальное качество звука.
Вопрос № 5: Что если во встрече вообще нет демонстрации экрана?
Тогда ТЗ строится по речи и контексту обсуждения. Но полезность иллюстраций снижаются — вместо скриншотов акцент смещается на ссылки на таймкоды и цитаты. Если обсуждение предполагает требования к доработкам пользовательского интерфейса/форм/таблиц, наличие демонстрации экрана существенно повышает качество.
Вопрос № 6: Как система снижает риск галлюцинаций?
Мы не публикуем неподтверждённое. Пункт попадает в итоговое ТЗ только если его можно привязать к источнику (фрагмент речи и/или кадр) и он проходит проверки формата и согласованности.
Вопрос № 7: Что если решения по ходу встречи меняются или звучат противоречия?
Система фиксирует конкурирующие формулировки и помечает конфликт (например, разные сроки, суммы, приоритеты, ответственные). Такой пункт требует подтверждения.
Вопрос № 8: Можно ли настроить структуру и стиль ТЗ под наш корпоративный стандарт?
Да. Итоговый документ формируется по шаблону: структура разделов, стили, нумерация, правила подписей к рисункам, словарь формулировок. Дополнительно можно настроить правила выделения обязательных секций (например, нефункциональные требования, интеграции, роли, SLA, ограничения).
Вопрос № 9: Сколько останется работы останется аналитику?
Эксперт не переписывает документ, а делает проверку: подтверждает высокоуверенные пункты и разбирает спорные случаи. Чем лучше входные данные (звук, экран, словарь проекта), тем выше доля автоматического наполнения ТЗ. Процесс спроектирован так, чтобы ручная работа была контролем качества, а не исправлением результатов работы системы.
Вопрос № 10: Куда выгружается результат и как это интегрируется с процессом разработки?
ТЗ может формироваться в DOCX (для согласования) и параллельно раскладываться по задачам в системы управления работами (например, Jira или Confluence) через интеграцию или API. Если нужно, можно добавлять правила маршрутизации: какой тип требований в какие проекты/компоненты, с какими метками и ответственными.
Вопрос № 11: Что с безопасностью и персональными данными?
Возможен запуск внутри корпоративного периметра. Данные встречи, транскрипт и артефакты могут храниться по правилам Заказчика, с разграничением доступа и аудитом. Если в кадре присутствуют персональные данные (например, лица), применяются правила фильтрации/маскирования — в зависимости от политики безопасности.
Заключение: внедрение ИИ — это спринт, а не марафон
Есть распространённое убеждение, что внедрение ИИ — привилегия компаний с огромными ИТ-бюджетами: годы на «идеальные данные», сложную инфраструктуру и многомесячные проекты без гарантии отдачи.
Этот кейс показывает обратное. Можно перепрыгнуть через длинный путь и получить промышленный эффект быстро — если:
выбрать правильную “боль” (дорогая рутина у экспертов),
встроиться в существующий процесс,
использовать инструмент, который даёт качество и контроль в enterprise-среде (валидации, контур, управляемость).
Вместо того чтобы увеличивать штат и раздувать расходы на «проектную документацию», компания направила ресурсы на автоматизацию конкретного узкого места и получила результат, измеримый в сокращении цикла и себестоимости документа.
И это только начало. Доказав эффективность на подготовке ТЗ, такой конвейер логично масштабируется на смежные документы
- автоматическое создание user stories и постановок задач;
- генерация тест-кейсов и чек-листов на основе TO-BE;
- подготовка проектной документации и регламентов, когда по итогам встреч нужно выпускать формализованные документы.
Если у вас много встреч, по итогам которых нужно регулярно выпускать требования, регламенты или протоколы, — такой конвейер снимает самую дорогую часть работы: ручной разбор записи и сборку документа.
Запишитесь к нам на демо Epsilon Workspace сегодня, и уже на следующей неделе ИИ-система начнёт сама анализировать записи ваших видеоконференций и писать ТЗ по результатам.