Модель оценки стоимости и сроков

В IT-инженерии невозможно купить сложную систему как товар с полки. Мы оцениваем не «строчку в прайсе», а конкретный инженерный проект, который внедряется в вашу уникальную инфраструктуру.

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

Стартовые цены на услуги

Как устроена оценка проектов у WEDOLAB

Что является единицей оценки

Мы декомпозируем абстрактную бизнес-задачу на измеримые технические единицы:

Сценарий или процесс: конкретный путь пользователя или данных от триггера до результата.
Компоненты и модули: блоки архитектуры (AI-агент, ядро RAG, парсер, веб-интерфейс).
Интеграции и источники данных: количество систем, с которыми нужно настроить связи, и качество этих связей.
Контур, ИБ и эксплуатация: требования к серверам, информационной безопасности и инфраструктуре.

Этапность оценки

Оценка не возникает из воздуха, она уточняется по мере погружения в проект:

Быстрый первичный скрининг: вы даете вводные данные, мы обозначаем порядок цен (вилку) и принципиальную реализуемость.
Предварительная оценка: формируется после короткого брифа и описания бизнес-процесса.
Уточнение после предпроекта/аудита: если в системе много старых баз или «грязных» данных, мы проводим аудит источников и только после этого даем точный расчет.
Фиксация объема работ по этапам: мы фиксируем стоимость и сроки для конкретного, жестко ограниченного шага (PoC → Пилот → Промышленная эксплуатация).

Что входит в оценку

В итоговую смету этапа закладываются:

Разработка и интеграции: написание кода, настройка LLM, создание API и автоматизированное тестирование.
Инфраструктура и запуск: упаковка в контейнеры Docker, настройка CI/CD, развертывание на серверах.
Эксплуатация и поддержка: настройка систем мониторинга (Sentry / Logfire), SLA и сопровождение (по необходимости).
Ограничения и допущения: мы явно прописываем, что должно быть готово со стороны клиента (доступы, серверы, выделенный владелец процесса), чтобы проект состоялся.

Факторы стоимости

Следующие факторы напрямую определяют объем инженерных часов и итоговую стоимость проекта:

По функциональному объёму

Количество сценариев/процессов: чем больше вариаций и исключений в бизнес-логике, тем сложнее архитектура и шире покрытие тестами.
Количество ролей и прав доступа: сложная ролевая модель (RBAC, ABAC) требует глубокой проработки безопасности на уровне API.
Наличие интерфейса: разработка полноценного личного кабинета, дашбордов или сложной админки существенно увеличивает объем работ фронтенд-команды UI.
Нефункциональные требования: система, которая должна держать миллион запросов 24/7, стоит кратно дороже внутреннего инструмента для десяти менеджеров.

По интеграциям и системам

Количество систем и глубина интеграций: чтение данных настроить дешевле, чем двустороннюю синхронизацию (чтение + запись + обработка событий).
Качество API: наличие современной документации ускоряет работу; закрытые системы и legacy-протоколы требуют долгих изысканий.
Сопоставление справочников: если системы по-разному называют одни и те же объекты, требуется сложная логика нормализации и дедупликации данных.
Нестабильные источники: парсинг сайтов или выгрузка из закрытых порталов всегда дороже в сопровождении, чем работа с официальным API.

По данным

Качество и структура (Data Readiness): если данные структурированы – мы сразу строим логику. Если это хаос из файлов – мы тратим время на очистку.
Оцифровка и форматы: работа со сканами и фотографиями документов требует подключения дополнительных модулей распознавания OCR (компьютерное зрение).
Объём и частота обновления: сбор данных раз в сутки требует простой архитектуры; обработка событий в реальном времени требует брокеров очередей.
Версионность: необходимость хранить всю историю изменений (например, котировок или тарифов) усложняет проектирование баз данных.

По безопасности и контуру

Среда развертывания: развернуть решение в стандартном облаке быстрее, чем в жестко изолированном закрытом контуре компании (on-premise).
Политики ИБ и ПДн: соблюдение 152-ФЗ, шифрование и внедрение контуров аудита требует дополнительных DevOps-часов.
Локальные модели: использование облачных API (OpenAI / Yandex) дешевле на старте; развертывание тяжелых открытых моделей (DeepSeek / Qwen) на серверах клиента требует дорогого оборудования и сложной настройки.

По эксплуатации

Мониторинг и алерты: внедрение продвинутой наблюдаемости (логи, трассировка, метрики) увеличивает стартовую смету, но радикально снижает цену поддержки.
Сопровождение: требования к непрерывной поддержке и жесткому SLA (время реакции) тарифицируются отдельно.

Факторы сроков

Эти факторы влияют на календарное время реализации проекта. Бюджет может остаться тем же, но релиз сдвинется на месяцы.

Организационные зависимости

Выдача доступов: долгое ожидание VPN, тестовых учетных записей или серверов от службы ИБ – главная причина простоя разработки.
Отсутствие владельца процесса: если на стороне клиента некому верифицировать логику и принимать решения, проект буксует на этапе согласований.
Скорость обратной связи: задержки с проверкой результатов этапа (приёмкой) растягивают общий календарный срок.
Согласования контура: долгие бюрократические процессы со службой безопасности смещают дату финального релиза.

Технические зависимости

Сложность интеграций: выявление неочевидных багов в смежных системах заказчика требует времени на совместную отладку.
Качество источников: плохие сканы, противоречивые регламенты и хаос в справочниках требуют ручного вмешательства и удлиняют конвейер обработки.
Объем UI и ролей: чем больше фронтенд-экранов и связей между ролями, тем дольше длится цикл разработки и тестирования.
Требования к надежности: выстраивание конвейеров CI/CD и строгих сред dev / stage / prod требует времени до написания первой строчки бизнес-логики.

Риск-факторы

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

Как мы уменьшаем стоимость и сроки

Мы – сторонники инженерного прагматизма. Чтобы запустить проект быстрее и дешевле, мы предлагаем:

Сузить фокус (MVP): оставить 1–2 самых критичных бизнес-сценария, которые дают 80% ценности, а остальное отложить на второй этап.
Ограничить интеграции: на этапе пилота интегрироваться только с 1–2 главными системами (например, только CRM, отложив 1С).
Начать со статичных данных: на первом этапе обновлять справочники руками (выгрузками), а сложный конвейер автоматизации ETL построить после подтверждения ценности.
Отложить сложный интерфейс: запустить решение в виде Telegram-бота или простого API, а полноценный личный кабинет вынести в фазу развития.
Домашняя работа: если клиент заранее готовит доступы, тестовые данные и выделяет владельца процесса, мы не тратим платные часы на ожидание.

Что нужно от клиента для оценки

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

Суть и боль: какая задача стоит и какого результата вы ожидаете (своими словами).
Источники и системы: с какими программами (CRM, 1С) или форматами предстоит работать.
Безопасность: есть ли жесткие ограничения (только свои серверы, закрытый контур, работа с ПДн).
Примеры из жизни: 5–10 примеров реальных диалогов, документов или операций (обезличенно).
Ответственность: кто будет выступать владельцем процесса со стороны бизнеса и принимать итоговые решения.

Результат оценки и формат

Что вы получаете на выходе:

Декомпозицию проекта по логическим этапам. Обычно это Proof of Concept → Пилот → промышленный запуск.
Прозрачную оценку стоимости и сроков для первого зафиксированного этапа.
Перечень допущений и архитектурных рисков.
Понятный следующий шаг (например, подписание NDA и передача тестовых данных).

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