Предпроектное обследование (discovery): что это, что заказчик получает на выходе и когда без него можно обойтись

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

Что такое предпроектное обследование?

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

Название пришло из российской практики автоматизации. В действующем стандарте ГОСТ Р 59793-2021 «Автоматизированные системы. Стадии создания» (утверждён Росстандартом 25 октября 2021 года, введён 30 апреля 2022 года) первая стадия — «Формирование требований к АС». Она начинается с этапа «Обследование объекта и обоснование необходимости создания АС», а заканчивается отчётом и заявкой на разработку ТЗ. Национальные стандарты применяются добровольно, и сам ГОСТ разрешает исключать отдельные этапы, но логика у него здравая: сначала разобраться, потом проектировать.

Discovery — то же самое в словаре продуктовых команд. Разница больше в акцентах: продуктовая команда чаще проверяет гипотезы о клиентах и рынке, а обследование под заказную систему разбирает внутренние процессы компании. Для заказчика CRM или кабинета важна вторая часть.

	Бриф	Предпроектное обследование	Техническое задание
Кто делает	Заказчик заполняет сам	Аналитик или ведущий разработчик вместе с сотрудниками заказчика	Исполнитель пишет, заказчик согласует
Откуда сведения	Из головы заказчика	Интервью, документы, выгрузки, работающие системы	Из брифа и результатов обследования
Отвечает на вопрос	Что хотим и зачем	Как устроено сейчас, что мешает, что реально сделать	Что именно делаем и как примем
Объём	Несколько страниц ответов	Отчёт, схемы, список требований, черновая оценка	Документ с ролями, сценариями, данными и критериями приёмки
Юридический вес	Нет	Нет, если не включён в договор	Приложение к договору, по нему принимают работу

Чем оно отличается от брифа и ТЗ?

Бриф заполняет заказчик: что хочет и зачем. ТЗ пишет исполнитель: что делаем и как примем. Обследование стоит между ними: исполнитель сам добывает сведения у ваших сотрудников и из систем, чтобы ТЗ описывало реальную работу, а не представление о ней руководителя.

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

Про бриф подробно — в статье как заполнить бриф на разработку, про ТЗ — в разборе как составить ТЗ без опыта. Ниже — сравнение в одной таблице.

Что входит в обследование?

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

1. Интервью по ролям. Не только с директором, а с каждым, кто будет работать в системе: менеджер, кладовщик, бухгалтер, руководитель отдела. Обычно по 1–1,5 часа на роль. Хорошо работает формат «покажите на экране, как вы это делаете сейчас»: так всплывают таблицы на рабочем столе, ручные пересчёты и обходные пути.
2. Документы и выгрузки. Образцы договоров, счетов, актов, заявок, отчётов, которые сейчас собирают руками. Выгрузка справочников из 1С или таблиц — чтобы увидеть объём и качество данных: сколько клиентов, сколько дублей, заполнены ли ИНН.
3. Карта систем и данных. Какие программы уже есть, что в них хранится, кто главный по каждому справочнику и куда данные должны ходить. Здесь же проверяют, есть ли у систем API или выгрузка, — от этого зависит, будет интеграция стоить день или неделю.
4. Риски и ограничения. Персональные данные и требования к их хранению, доступы, которые оформлены на сотрудников, а не на компанию, нет ответственного за проект, сезонность, когда сотрудникам не до внедрения.
5. Черновая оценка и этапы. Что войдёт в первый запуск, что можно отложить, диапазон цены и срока и от чего он зависит.

Если процесс уже описан вашими силами по схеме «как есть / как будет», обследование идёт быстрее: шаблон для такого описания есть в статье как описать бизнес-процесс перед автоматизацией. Но описание одного процесса не заменяет обследование всей системы: оно не покажет, как этот процесс стыкуется с соседними.

Результат	Что внутри	Как проверить, что он годный
Отчёт «как есть»	Участники, шаги процесса, документы, где теряется время и данные	Сотрудник, который делает эту работу, узнаёт в тексте свой день
Карта систем и данных	Какие программы есть, что в них хранится, кто главный источник по каждому справочнику	По каждой стрелке понятно, что передаётся, как часто и в какую сторону
Список требований	Роли, сценарии, отчёты, интеграции, ограничения; деление на «обязательно» и «потом»	У каждого пункта есть автор со стороны заказчика и понятный критерий «сделано»
Риски и открытые вопросы	Нет API, грязные данные, нет ответственного, юридические требования	У каждого риска есть следующий шаг и срок, а не просто «учесть»
План этапов и черновая оценка	Что входит в первый запуск, что во второй, диапазон цены и срока	Видно, из чего сложилась цифра и что её сдвинет
Прототип ключевых экранов	Кликабельные или статичные макеты главных сценариев	Пользователь проходит по нему свою типовую задачу без подсказок

Что заказчик получает на выходе?

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

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

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

• результаты передаются в редактируемом виде: текст, таблицы, исходники схем и прототипа, а не только PDF;
• вы вправе передавать их другим подрядчикам для оценки и разработки;
• оплата за обследование не обязывает заказывать у этого исполнителя разработку.

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

Бесплатная оценка или платный анализ?

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

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

Как это устроено у нас. Заполнение брифа на сайте ни к чему не обязывает: по нему мы возвращаемся с оценкой срока и цены. Отдельного тарифа «обследование» в прайсе нет: в тарифе веб-приложения или SaaS (от 160 000 ₽, от 10 дней) первый этап — «Бриф и ТЗ: роли, сценарии, модель данных, интеграции», в тарифе интеграций (от 32 000 ₽) — аудит систем, форматов данных и точек обмена. Если задача больше тарифа и ей нужен глубокий анализ, его объём и цену называем после брифа и фиксируем в договоре до старта. Оплата по типовому договору — 50 % предоплата и 50 % после акта.

Чем бы ни закончился разговор, задайте исполнителю три вопроса:

• Какие документы я получу и в каком виде?
• Засчитывается ли стоимость анализа в разработку, если я продолжу с вами?
• Что будет, если после анализа я решу не продолжать?

Сколько времени занимает и кто участвует?

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

Чтобы спланировать календарь, посчитайте сами: по одному интервью на каждую роль, одна встреча по каждой системе с тем, кто её администрирует, и две встречи с руководителем — на старте и на защите результатов. Плюс время исполнителя на отчёт и прототип между встречами.

Со стороны заказчика нужны:

• Ответственный за проект — человек, который собирает ответы, назначает встречи и принимает решения в спорных местах. Без него обследование превращается в переписку с пятью людьми.
• Ключевые пользователи — по одному от каждой роли, причём опытные, а не те, кого не жалко отвлечь.
• Тот, кто знает 1С или текущую программу: штатный специалист или внешний франчайзи.
• Руководитель — на старте задаёт цель, в конце утверждает приоритеты.

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

Когда обследование не нужно?

Когда процессов и интеграций почти нет: лендинг, сайт-визитка, корпоративный сайт на несколько страниц, простой бот заявок. Хватает брифа, согласования структуры и прототипа. Обследование здесь отодвинет запуск и съест бюджет, который полезнее потратить на тексты и дизайн.

Ещё случаи, когда без него можно обойтись:

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

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

Какие ошибки делают заказчики?

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

• Интервью только с руководителем. Директор знает, как процесс должен идти, сотрудник — как он идёт на самом деле. Расхождение между этими версиями и есть самое ценное в обследовании.
• Скрывать «некрасивое». Таблицы на личном диске, ручные пересчёты, обходные пути. Их всё равно найдут после запуска, только дороже.
• Не давать реальные данные. Пустые справочники не покажут дубли и пропуски. Обезличенная выгрузка на сотню строк скажет больше, чем описание словами.
• Всё в первый этап. Обследование соберёт полсотни пожеланий. Задача заказчика — выбрать те, без которых система не нужна, а остальное отложить.
• Не договориться о форме результата. Ждали требования, получили презентацию. Закрепите состав и формат документов до оплаты.

Короткие ответы на частые вопросы

Что такое предпроектное обследование простыми словами?

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

Discovery и предпроектное обследование — это одно и то же?

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

Обязательно ли обследование перед разработкой CRM?

Нет, закон его не требует. Но если в CRM работают несколько отделов и она обменивается данными с 1С или сайтом, без обследования оценка будет гаданием, а спорные вопросы всплывут уже в разработке, когда менять решения дороже.

Можно ли отдать отчёт обследования другому подрядчику?

Можно, если это записано в договоре: оговорите, что отчёт, требования и схемы передаются вам в редактируемом виде и вы вправе показывать их другим исполнителям. Тогда обследование не привязывает вас к тому, кто его провёл.

Сколько стоит предпроектное обследование в Roboweb?

Отдельного тарифа на обследование в прайсе нет. В тарифе веб-приложения от 160 000 ₽ первый этап — бриф и ТЗ с ролями, сценариями и моделью данных; если задаче нужен более глубокий анализ, его объём и цену называем после брифа и фиксируем в договоре до старта.

Нужно ли обследование для лендинга или сайта-визитки?

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

Услуги и кейсы по теме: заказная разработка · веб-приложения и SaaS · цены и сроки