Руководителю, который заказывает разработку, знакома эта механика: любая идея превращается в счёт, а сработала она или нет, выясняется потом, когда деньги уже потрачены. На платформе «Аналитика сертификатов» механика другая. За годы сопровождения через нас прошли десятки заказов: реализованные, отложенные, отвергнутые. Этот кейс не про один продукт, а про то, как принимается решение «делать, не делать или сначала проверить» и как мы помогаем клиенту посчитать, стоит ли затея своих денег, ещё до первого счёта. Эпизодов накопилось достаточно, чтобы показать метод на фактах, а не на лозунгах.
Сводка
| Отрасль | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» |
| Формат сотрудничества | Регулярное сопровождение: поток заказов, каждый проходит через оценку и согласование |
| Тип проекта | Метод работы бюро: прототип до счёта, оценка экономики, помощь с выбором, честный статус |
| Что показываем | Девять задокументированных эпизодов из истории проекта, где решение «делать / не делать / сначала проверить» принималось вместе с заказчиком |
| Период | С октября 2021 по сегодня |
| Трудозатраты | Не выносим: кейс про подход, а не про объём конкретной задачи |
| Команда | Антон Херсун (руководитель проекта, оценки и прототипы) и разработчик аналитической панели, ведущий направление с первого дня |
| Статус | Сотрудничество длится, поток заказов открыт |
Метод вместо прайс-листа
Когда задача звучит впервые, мы не тянемся за калькулятором. Сначала — три вопроса. Жизнеспособна ли затея технически? Сходится ли экономика для клиента? И можно ли проверить идею малой кровью, прежде чем вкладываться целиком? Разговор об оценке и сроках начинается после ответов, не раньше.
Ниже четыре приёма, из которых складывается этот метод, и реальные эпизоды на каждый.
Прототип за свой счёт, прежде чем предлагать большую трату
Самая дорогая ошибка в заказной разработке — оплатить полную реализацию идеи, которая на практике не взлетит. Поэтому крупные затеи мы стараемся пощупать прототипом раньше, чем заводим разговор про бюджет.
В июне 2024 года интерес заказчика к искусственному интеллекту только зрел («как-то внедрить в работу ИИ»), и мы по своей инициативе собрали рабочий прототип. За один вечер на сервере поднялся ИИ-аналитик, принимавший запросы к базе сертификатов на естественном языке. Заказчику ушло короткое сообщение: «Запустил прототип искусственного интеллекта на сервере», плюс логин, пароль и примеры обращений. Доступ отдали бесплатно, для тестов и обкатки. Когда прототип захотели показать партнёрам, мы держали его живым, а потом честно прикрыли, «чтобы ресурсы не потреблял».
Прототип сразу обнажил и реальную стоимость затеи, и её слабые места: модель путала оператор сравнения, дообучение на частных вопросах ещё впереди, серверная база под такое стоит серьёзных денег. Заказчик пощупал всё это сам, а не выслушал от нас на словах. Большой заказ так и не оформили, но решение принимал клиент, глядя на работающую вещь. (Сам прототип ИИ-аналитика разобран в отдельном кейсе.)
Тот же приём сработал в 2026 году на системе ценообразования для Битрикс24. Мы разобрали данные из выгрузки заказчика, собрали прототип на своей инфраструктуре и отдали ссылку с короткой просьбой: посмотрите, как работает, пишите, что добавить, что убрать, удобно ли расположение. Логику проговорили явно: «Собираю ваши пожелания, вношу в прототип. После утверждения прототипа оцениваем финально». Прототип устроил — и только тогда мы перешли к общей оценке.
Развилка «полная или демо» как третий вариант
Между «сделать всё целиком» и «не делать ничего» почти всегда есть третий путь — проверить идею на урезанном объёме. Мы стараемся предлагать его явно.
Когда в 2022 году обсуждался Telegram-бот для быстрых ответов менеджерам, мы подготовили не одну смету, а две: полную версию и демо. Из демо целиком убрали самый дорогой этап (лингвистический разбор запросов) и связь с техническим отделом, оставили минимальный диалог на одной учётной записи. Смысл развилки: за меньший объём заказчик проверяет саму механику, прежде чем вкладываться в полную сборку. До боевого запуска бот в итоге не дошёл, согласование на стороне клиента застряло, но выбор был осознанный — с понятной границей между «попробовать» и «сделать как надо». (Подробности по боту вынесены в отдельный кейс.)
Помощь посчитать экономику и право сказать «не делаем»
Иногда самое полезное, что подрядчик может сделать для клиента, — помочь ему отказаться от затеи раньше, чем она съест деньги.
Весной 2026 года по той самой системе ценообразования мы довели прототип до состояния, на котором заказчик смог посчитать экономику вместе с партнёрами. Вердикт партнёров вышел отрицательным, и заказчик сформулировал прямо: для нас одних проект выходит слишком накладным, по прайсу стоп. Важна здесь не остановка сама по себе, а то, что считать было на чём: прототип и оценка уже лежали на столе. Мы тут же предложили вариант, при котором проект не умирает, — доделать за свой счёт и включить стоимость в абонентскую плату, тем более что такая система может пригодиться и другим. Решение осталось за клиентом.
Та же честность работает и в обратную сторону, когда экономика не сходится у нас на глазах ещё до сметы. По одной из доработок конструктора документов заказчик хотел, чтобы при смене основной даты автоматически пересчитывались даты испытаний. Мы даже не стали выносить её в ТЗ: «казалось бы штучка простая, но в реализации стоит как феррари». Новые теги, связи между ними, учёт красных дней календаря — около 30 часов работы ради удобства, которое того не стоило. Отговорили.
Не брать деньги за нежизнеспособное
Самый показательный эпизод связан с проверкой статусов документов. К 2025 году речь шла о массовой сверке статусов по более чем ста тысячам деклараций. Заказчик был готов оформлять ТЗ и платить, но мы притормозили сами: решение виделось одно — построить тестовый стенд с многопоточным парсингом через прокси и неделю-другую смотреть, выживет ли оно на полном объёме документов. Принцип держали прямо:
Увидим признаки жизнеспособности — продолжим ТЗ. Не увидим — не станем его расписывать и брать деньги за то, что проживёт неделю и умрёт.
ТЗ не оформляли и счёт не выставляли, пока не появилась уверенность, что продукт переживёт собственный запуск.
К той же категории относится диагностика, которая сэкономила клиенту покупку сервера. Поиск по реестру у пользователей тормозил, и логичная реакция напрашивалась сама: нарастить мощность железа. Мы сначала разобрались в причине. Люди искали ОГРН с параметром «содержит», а такой поиск идёт мимо индекса: база перебирает строки подряд, проверяя вхождение в каждую. Тот же запрос с параметром «равно» опирается на индекс и отрабатывал за миллисекунду. Вывод мы сформулировали прямо: вопрос не в мощностях и не в новом сервере, достаточно поправить то, что обнаружено. Сервер покупать не пришлось.
Туда же относится отказ от пакетной конвертации документов в PDF. Идея исходила от заказчика, но конвертация давала косяки нумерации страниц — а это документ, который менеджер не глядя отправит в работу. Мы предложили прогнать десяток файлов на тест, и заказчик отказался сам: если уже вылезают такие косяки, смысла нет. Не берёмся за то, что испортит результат.
Честный статус: что доработка, а что просто настройка
Метод работает и на мелочах. Однажды заказчик принял за платную доработку «выдачу свежих номеров», а на деле у одной лаборатории просто не была выставлена галочка использования дат при бронировании. Мы так и написали: зайдите в раздел шаблонов, поставьте флажок, сохраните. Настройка, а не задача — и счёт за неё не появился.
Обратная сторона той же честности — фиксация рисков на своей стороне. По одному из заказов на улучшение парсинга смета была около 56 часов, а по факту вышло 156: первый метод сбора оказался нерабочим, пришлось переделывать. Реакция была короткой: «это мои риски, посмотрим в целом на результат». Оценка дана в фиксированных часах, поэтому перерасход остался на исполнителе, а не лёг на клиента.
Что из этого получает клиент
| Что | Как это выглядит на практике |
|---|---|
| Прототип до большой траты | ИИ-аналитик и система ценообразования собраны и отданы на тест прежде, чем зашёл разговор про полный бюджет |
| Развилка вместо «всё или ничего» | По Telegram-боту подготовлены две оценки: полная и демо, с понятной границей |
| Помощь посчитать экономику | По системе ценообразования заказчик с партнёрами оценил и принял решение не делать, имея на руках прототип и расчёт |
| Защита от лишних трат | Отговорили от автопересчёта дат («стоит как феррари»), от покупки сервера (дело было в операторе поиска), от конвертации в PDF |
| Честный статус задачи | «Свежие номера» оказались настройкой и не стали платной задачей; перерасход по парсингу зафиксирован как риск исполнителя |
Команда
- Антон Херсун, Xaver Pro: руководитель проекта. Прототипы, оценки в фиксированных часах, диагностика, разговор с заказчиком про экономику и приоритеты.
- Разработчик аналитической панели ведёт это направление с первого дня и до сегодня. Любой модуль, написанный годы назад, дорабатывается тем же человеком, поэтому решение «делать или не делать» опирается на знание всей системы, а не на догадки.
Скриншоты и материалы
Не применимо: кейс про метод работы, отдельного продуктового интерфейса у него нет.
Если у вас есть идея, в которой вы сами не уверены, и не хочется платить за полную реализацию вслепую, покажите. Скажем честно, жизнеспособно ли это технически, как проверить её прототипом за минимальный объём и где экономика может не сойтись. Первичная оценка бесплатна.