Как формируется стоимость ИИ-проекта после брифа

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

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

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

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

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

На оценку влияют не только объем файлов или записей, но и их устройство:

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

Если данные пока не обследованы, эту неопределенность стоит вынести в отдельную диагностическую работу или явно указать как условие оценки. Скрывать ее внутри разработки опасно: после старта она превращается в спор об объеме.

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

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

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

Стенд, облачная среда, гибридная схема и инфраструктура компании требуют разного участия сторон. На оценку влияют сетевые правила, доступы, развертывание, мониторинг, резервирование, требования к внешним моделям и готовность IT-команды клиента.

Контур выбирают по данным и эксплуатации, а не только по удобству разработки. Если решение должно работать внутри компании, это нужно зафиксировать до оценки, а не переносить после демонстрации.

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

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

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

После приемки для воспроизводимых несоответствий согласованному ТЗ предусмотрен 30-дневный период стабилизации. Новые функции, источники и правила не относятся к исправлениям и оцениваются как новый объем.

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

В документах полезно указать владельца аккаунта, порядок согласования расходов, уведомления, лимиты и действия при недоступности или изменении условий поставщика.