Разработка без ТЗ: как управлять проектом, когда задача превращается в исследование

Классическая схема «утвердили ТЗ — разработали — сдали» даёт сбой в момент, когда задача из категории «сделайте нам сайт» переходит в категорию «мы не знаем, сработает ли это». Когда заказчик приносит не требования, а боль: сотрудники часами вручную переносят данные из сотен нестандартных документов. И вы вместе с ним не знаете, насколько распознаваемы его сканы, можно ли доверять готовым сервисам и какой процент точности вообще достижим. В этот момент проект становится исследованием. И требует другой системы управления.

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

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

Оборотная сторона — страх неопределённости, который парализует запуск. Компания годами откладывает автоматизацию, потому что «невозможно описать все входящие форматы» и «мы не знаем, какой процент точности реален». В результате бизнес продолжает нести операционные издержки, которые кратно превышают стоимость любого пилотного проекта.

Три типичные ошибки, которые превращают исследовательский проект в проблемный актив:

1. Полное ТЗ до начала работ. В исследовательской задаче оно фикция. Стороны подписывают документ, описывающий идеальный мир, который рухнет при первом контакте с реальными данными. Дальше начинается игра в угадайку: подрядчик закладывает риски в смету, заказчик требует фиксированную цену, и оба делают вид, что объём понятен.

2. Ожидание, что всё сделает одна модель. Попытка решить сложную задачу одним инструментом — «дадим нейросети картинку, она вернёт готовую таблицу» — лишает команды точек контроля. Вы не знаете, на каком шаге теряется точность, и не можете адресно исправлять ошибки. Проект превращается в чёрный ящик, внутри которого что-то происходит, а снаружи растёт тревога.

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

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

Принцип 1. Честная разведка на старте

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

На этом этапе также проверяются готовые альтернативы. Команда протестировала платный сервис за 20 долларов в месяц: границы таблиц он рисовал неплохо, но ошибался в содержании — пропускал цифры, путал надписи. Для процесса, где одна ошибка грозит финансовыми потерями, это неприемлемо. Результат такой разведки — не абстрактный отчёт, а конкретное решение: строим собственный пайплайн.

Принцип 2. Поэтапная архитектура как каркас управляемости

Разбивка на конвейер — это не только инженерное, но и управленческое решение. Каждый этап даёт промежуточный артефакт, который можно показать заказчику и проверить качество:

• После этапа детекции и OCR — сырой текст. Видно, насколько корректно система «увидела» таблицу на скане.

• После нейросетевого сопоставления — заполненная структура. Видно, как система поняла смысл колонок и распределила данные.

• На экране верификации — финальный результат, готовый к выгрузке.

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

Принцип 3. Экран верификации как процессная страховка

Ни одна система в мире не даёт 100% точности на нестандартных сканах. Обещать это — значит закладывать мину замедленного действия. Вместо этого в процесс встроен страховочный пояс: пользователь видит, что система распознала, сверяет с исходной картинкой и может точечно поправить ошибки — удалить лишнюю строку, переименовать колонку, подставить пропущенное значение. Это делается за секунды, а не за час ручного переноса.

У этого решения двойной эффект. Для заказчика — гарантия, что финальный документ корректен, даже если машина на каком-то шаге ошиблась. Для команды разработки — снятие неподъёмного обещания и возможность честно говорить о реальных ограничениях технологии. Проект перестаёт быть игрой в «кто виноват», если точность оказалась не 100%, и становится совместной работой над минимизацией ручного остатка.

Принцип 4. Прототип как стратегия, а не вынужденная мера

В нешаблонных проектах мы осознанно начинаем с прототипа. Это не «упрощённая версия» и не «эконом-вариант» — это инструмент быстрой проверки ключевой механики. Никаких жёстких требований к дизайну, удобству интерфейса и масштабируемости на этом этапе нет — только точность распознавания и корректность выгрузки. Такой подход позволяет двигаться быстро и не перегружать первый этап лишними трудозатратами.

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

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

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

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

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

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

Результат: время обработки документов сократилось в 5–7 раз. Московский заказчик, годами делавший это руками, был готов к 30% точности — мы превзошли этот порог. Подробное описание проекта — в кейсе: «ИИ для работы с документами: как мы заменили ручной перенос данных на ИИ-конвейер и ускорили разработку с помощью генерации кода».

Если вы запускаете проект, где конечный результат неочевиден:

• На старте требуйте не план работ, а план проверки гипотез. Что именно мы проверим в первую неделю? Как поймём, что гипотеза подтвердилась или провалилась? Какое решение примем в каждом случае?

• Фиксируйте промежуточные артефакты. Договоритесь: «через N дней мы увидим сырой результат распознавания на пяти реальных сканах и примем решение о следующем шаге». Это даёт контроль без жёсткого ТЗ.

• Честно обсуждайте ограничения. Если 100% точности технологически невозможно, проговорите это в самом начале и заложите в процесс механизм компенсации — экран верификации, ручную коррекцию. Это снимает будущие конфликты.

• Начинайте с прототипа. Это не экономия, а стратегия: проверить ключевую механику до того, как вкладываться в масштабируемый продукт. Дни вместо месяцев, конкретные данные вместо предположений.