Консалтинг

IT-консалтинг и продуктовый аудит

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

Стоимость: От 50 000 ₽
Сроки: Экспресс-формат — около недели: 2–3 интервью, обзорный аудит и документ с выводами и оценкой на 10–15 страниц. Полный аудит с разбором кода, архитектуры, аналитики и написанием ТЗ занимает 2–3 недели. Для крупных систем с несколькими интеграциями — до 4 недель. Разовая консультация на 90 минут доступна отдельно.

Стартовая цена. Итог зависит от объёма, интеграций и сроков.

Коротко

IT-консалтинг стоит от 50 000 ₽ и занимает 1–3 недели. За это время мы проводим интервью с командой и владельцем продукта, разбираем код, архитектуру и метрики, пишем техническое задание, предлагаем стек и даём оценку сроков и бюджета с разбивкой по этапам. На выходе — документ на 20–40 страниц, с которым можно идти в тендер к любому подрядчику, включая не нас.

Когда консалтинг нужен раньше разработки

Есть несколько признаков, по которым видно, что заказывать разработку рано. Подрядчики дают оценки, различающиеся в 5–10 раз — значит, каждый посчитал свой проект. Внутри команды нет согласия, что именно делаем в первой версии. Существующий продукт работает, но каждая новая фича обходится дороже предыдущей. Или на руках есть идея, но нет ответа, чем она отличается от трёх похожих сервисов на рынке.

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

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

Технический аудит: что мы смотрим

Технический аудит отвечает на вопрос «в каком состоянии система и сколько будет стоить её развитие». Мы читаем код выборочно, но целенаправленно: точки входа, самые изменяемые модули, работа с деньгами и персональными данными, интеграции. Дальше смотрим архитектуру, схему базы, зависимости и их актуальность, тесты, процесс сборки и деплоя, логи и мониторинг.

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

Базовую безопасность мы проверяем всегда: хранение паролей, права доступа в API, валидация ввода, секреты в репозитории, HTTPS и заголовки, обработка персональных данных и требования 152-ФЗ к их хранению. Это не пентест, но 80% типовых проблем обнаруживается именно на этом уровне.

Продуктовый аудит: зачем это всё нужно

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

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

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

Техническое задание и выбор стека

Наше ТЗ — рабочий документ на 20–40 страниц, а не формальность для договора. В нём: цели и метрики продукта, роли пользователей, пользовательские сценарии, функциональные требования по экранам, схема данных, список интеграций и API, нефункциональные требования (нагрузка, скорость, безопасность, хранение персональных данных), требования к админке, критерии приёмки и раздел «что в проект не входит».

Последний раздел люди недооценивают, а он самый полезный: именно граница объёма защищает и заказчика, и подрядчика от бесконечного расширения работ. Когда список исключений записан, спор «это же входило» решается за минуту, а не за неделю переписки.

Стек мы выбираем по четырём критериям: задача (нагрузка, реалтайм, оффлайн, требования к данным), команда (кто будет поддерживать это через год и легко ли найти таких людей в России), стоимость владения (хостинг, лицензии, требования к размещению данных) и сроки. Если задача закрывается готовой CMS или low-code платформой, мы скажем это прямо, даже если это лишает нас заказа на разработку.

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

Роадмап, оценка и что делать дальше

Оценку мы даём вилкой, а не точкой: диапазон обычно ±30% на этапе документа и сужается после проработки дизайна и интеграций. Точная цифра до начала работ — это либо занижение, чтобы выиграть тендер, либо большой запас, зашитый в стоимость. Разбивка идёт по этапам, чтобы вы видели, что можно запустить первым и на чём остановиться, если бюджет закончится.

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

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

Что входит в работу

Отчёт по техническому аудиту с приоритизацией находок: критично, важно, можно жить
Продуктовый разбор: сценарии, узкие места воронки, приоритизированный бэклог
Техническое задание на 20–40 страниц с критериями приёмки и границами объёма
Схемы архитектуры, потоков данных и интеграций
Обоснованный выбор стека: сравнение 2–3 вариантов с оценкой стоимости владения
Оценка сроков и бюджета по этапам с вилкой и объяснением, из чего она складывается
Роадмап на 3–6 месяцев с реестром рисков
Аудит команды и процессов: где теряется время, чего не хватает в найме и регламентах
Финальная встреча на 60–90 минут с разбором документа и ответами на вопросы

Как мы работаем

01
Погружение
Дни 1–4. Стартовая встреча, 3–6 интервью с владельцем продукта, продажами, поддержкой и разработкой. Собираем доступы, документы, аналитику и текущие договорённости с подрядчиками.
02
Аудит
Дни 5–10. Разбор кода, архитектуры, данных, инфраструктуры и безопасности. Параллельно — продуктовая часть: воронка, метрики, бэклог. Промежуточный созвон с первыми находками.
03
Решения и ТЗ
Дни 8–15. Выбираем стек, фиксируем архитектуру, пишем техническое задание и критерии приёмки, согласуем объём первой очереди.
04
Оценка и роадмап
Дни 15–20. Разбиваем работы на этапы, считаем сроки и бюджет вилкой, собираем реестр рисков и план на 3–6 месяцев.
05
Передача
Финальная встреча, передача всех документов в редактируемом виде и, при необходимости, помощь в разборе предложений подрядчиков.

Технологии и инструменты

Miro
Notion
Figma
Mermaid / PlantUML
PostgreSQL
Docker
Sentry
Lighthouse
Яндекс.Метрика
GA4

Примеры работ

NA Consulting

Сайт разработан для консалтингового агентства NA Consulting. Интерактивный лендинг умещает в себя всю информацию об агентстве и его услугах и при этом выглядит минималистично. Цвета успокаивают пользователя, чтобы показать безопасность и серьёзность компании. Разработано Veltos.Tech совместно с Алиёй (finnikkis.github.io/maulaviyevadesign).

Sber — Guardian of Truth

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

MOEX Alpha Autopilot

Автономная торговая система для Московской биржи: анализирует рынок, проверяет идеи и выставляет сделки на реальном контуре MOEX с жёстким контролем риска.

Частые вопросы

Сколько стоит IT-консалтинг?

От 50 000 ₽ за экспресс-формат: 2–3 интервью, обзорный аудит и документ с выводами и оценкой на 10–15 страниц, срок около недели. Полный аудит с разбором кода, архитектуры, аналитики и написанием ТЗ занимает 2–3 недели и стоит от 120 000 ₽. Разовая консультация на 90 минут с разбором вашей ситуации — 15 000 ₽, и эта сумма засчитывается в стоимость аудита, если вы решите его заказать.

Зачем платить за аудит, если можно сразу заказать разработку?

Потому что без ТЗ вы не можете сравнить подрядчиков: три студии дадут оценки в 300 000, 900 000 и 2 500 000 ₽, и это будут оценки трёх разных проектов. Аудит фиксирует объём работ, и дальше вы сравниваете одинаковое. Второй аргумент — переделки: изменить требования на этапе документа стоит в разы дешевле, чем на этапе разработки. Если у вас уже есть детальное ТЗ и понятная архитектура, консалтинг вам не нужен, и мы об этом скажем.

Что входит в техническое задание?

Наше ТЗ — это 20–40 страниц: цели и метрики продукта, роли пользователей, пользовательские сценарии, функциональные требования по экранам, схема данных, список интеграций и API, нефункциональные требования (нагрузка, скорость, безопасность, хранение персональных данных по 152-ФЗ), требования к админке, критерии приёмки и раздел о том, что в проект не входит. Последний раздел не менее важен: он защищает и вас, и подрядчика от бесконечного расширения объёма.

Переписать проект с нуля или дорабатывать существующий?

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

Как вы выбираете технологический стек?

По четырём критериям: под задачу (нагрузка, реалтайм, оффлайн, требования к данным), под команду (кто будет это поддерживать через год и легко ли найти таких разработчиков в России), по стоимости владения (хостинг, лицензии, требования к размещению данных в РФ) и по срокам. Мы не подбираем стек под свои предпочтения: если задача закрывается готовой CMS или low-code платформой, скажем это прямо, даже если это лишает нас крупного заказа на разработку.

Можно ли использовать ваше ТЗ с другим подрядчиком?

Да, документ ваш и передаётся в редактируемом виде вместе со схемами и оценкой. Именно так его чаще всего и используют: заказчик рассылает ТЗ трём-четырём студиям и сравнивает предложения по одинаковому объёму работ. Мы можем помочь на этой стадии — разобрать полученные коммерческие предложения, задать подрядчикам технические вопросы и проверить их план. Это отдельная услуга, но обычно она окупается разницей в цене между первым и третьим предложением.

Обсудим вашу задачу?

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

Оставить заявку Посмотреть все услуги