Что подготовить для оценки ИТ-проекта

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

Хороший brief не обязан быть идеальным. Его задача - дать подрядчику достаточно контекста, чтобы отличить понятный объем от зоны неопределенности. Если вводных хватает, можно оценивать этап. Если не хватает данных о процессах, интеграциях, ролях, API, качестве данных или рисках, честный следующий шаг - discovery, аудит или короткая предпроектная проверка.

Brief обычно достаточен, если задача понятна по границам и не требует большого исследования. Например, нужно доработать существующий личный кабинет, добавить интеграцию с уже описанным API, перенести известный ручной процесс в интерфейс или подготовить MVP с ограниченным набором сценариев.

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

Если проект связан с несколькими системами, brief должен отдельно назвать эти системы, владельцев, источники данных, форматы обмена и текущие ограничения. Названия систем сами по себе не позволяют оценить интеграцию: важны контракты API, доступы, частота обмена, ошибки, SLA и ответственность за справочники.

Вводных достаточно не тогда, когда описано все, а когда понятно, где заканчивается известное и начинается риск. Для оценки полезно прямо разделить факты, предположения и открытые вопросы. Факт: процесс сейчас идет через письма и Excel. Предположение: ERP сможет отдавать остатки по API. Открытый вопрос: кто подтверждает правила округления цены и что делать при расхождении остатков.

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

На первом разговоре не всегда стоит отправлять внутренние схемы, базы, договоры и доступы. Но после NDA полезно приложить материалы, которые уменьшают неопределенность:

• скриншоты текущих интерфейсов или короткие записи рабочего сценария;
• пример документа, заявки, заказа, отчета или другого объекта, с которым работает процесс;
• схему систем и интеграций, даже если она неполная;
• описание API, webhooks, файлового обмена или ручных выгрузок;
• пример ошибок, дублей, расхождений в данных или ручных проверок;
• регламенты по безопасности, доступам, хранению данных и журналированию;
• список людей, которые владеют процессом, системой, справочниками и бюджетом.

Если материалов нет, это нормально. Важно не дорисовывать их задним числом, а честно отметить, что нужно проверить на discovery.

Оценка проекта - это не только вопрос «сколько стоит». На первом обсуждении стоит проверить, как подрядчик работает с неопределенностью и где видит риски.

• Каких вводных достаточно для первичной оценки, а что нужно проверить отдельно?
• Где вы видите главный риск: в процессе, данных, интеграции, ролях, безопасности или сроках?
• Можно ли разбить проект на первый измеримый этап?
• Что будет результатом discovery или аудита, если оценивать сразу нельзя?
• Какие решения можно не принимать до старта, а какие критичны сейчас?
• Какие материалы нужны после NDA, чтобы не увеличивать оценку запасом?

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

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

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

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

Задача: сократить ручную обработку заявок от дилеров. Сейчас менеджер получает письмо, проверяет наличие товара в ERP, вручную переносит данные в CRM и отвечает клиенту.

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

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

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

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

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

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