Two Pilots, Two Trajectories: Why One Succeeded and the Other Closed
Author: WebGoodPeople
В 2025 году мы делали два пилота с похожими по характеристикам клиентами. Оба — e-commerce на Битрикс, каталоги 40k–60k SKU, TTFB 900–1100 мс. Одинаковая технология, похожая команда, близкие по времени запуски.
Через 3 месяца: один пилот перешёл в полноценное сотрудничество на 4 года. Второй — закрылся на 3-й неделе без продолжения. Клиенты честно признались, что результаты были «нормальные, но недостаточные, чтобы продолжать».
Разница — не в инженерной работе. Разница — в том, как каждый клиент вошёл в пилот. Подробный разбор того, что делает пилот успешным, а что — «нормальным».
Клиент А (успех): чёткая метрика, chosen owner, защищённый scope
Настройка до старта
Метрика определена заранее. До первой строки кода клиент сказал: «Успех = рост конверсии через категорию /electronics/ на ≥3% за 2 недели Canary». Одна цифра, один endpoint, одно окно измерения.
Owner назначен один человек. VP Engineering (не CTO, не продукт, не маркетинг). У него были полномочия принимать решения по scope в процессе пилота без совещаний. Его имя стояло в kick-off-документе.
Scope зафиксирован письменно. Документ на 2 страницы: что входит в пилот (migrate category listing), что не входит (PDP, корзина, checkout), что отдельное обсуждение (любой редизайн, любые SEO-структурные изменения).
Rollback-сценарий прописан. «Если конверсия упадёт > 1% против baseline за 48 часов — автоматический rollback. Решение о продолжении пилота — через 72 часа после стабилизации».
Как проходил пилот
Неделя 1–2: API-слой и Next.js-страница на staging. Без удивлений.
Неделя 3 (Canary): TTFB p95 340мс vs baseline 1050мс. Конверсия через категорию +3.2% за первые 5 дней. Метрика успеха достигнута.
День 12: owner инициировал обсуждение следующего этапа (PDP). Не «будем ли продолжать», а «какая конкретно страница следующая».
Что сделало этот пилот успешным
-
Метрика конкретная до старта. +3% конверсии на одной категории — эту цифру можно проверить за 5 дней, она не допускает двояких толкований.
-
Один owner с мандатом. Когда маппер не обработал вложенные категории (commit 15 в прошлой статье), не было недельного совещания «чьи это полномочия». Owner сказал: «фиксим, реиндекс, продолжаем».
-
Scope не размывался. Маркетинг в середине пилота хотел «добавить баннеры на новую страницу». Owner сказал «обсудим после пилота, scope не меняем». Пилот не размазался.
-
Готовность к росту зафиксирована. Клиент с самого начала обсуждал сценарий «если сработает, что дальше». Это не парализовало пилот, но убрало паузу «надо подумать» после успешного завершения.
Клиент Б (закрытие): размытая метрика, комитет, drift
Настройка до старта
Метрика — «посмотрим, что получится». «Надо, чтобы сайт стал лучше». Когда мы уточняли «что измеряем на 2-й неделе», ответ был «по ощущениям плюс Lighthouse».
Owner — «команда». Решения принимались на еженедельной встрече втроём: CTO, продукт-лид, маркетинг. Любая инженерная проблема ждала вторника.
Scope — устное соглашение. «Мигрируем категорию, и если будет легко — ещё чего-нибудь».
Rollback — «разберёмся по ситуации».
Как проходил пилот
Неделя 1: API-слой. Вопрос: «А может, сразу поиск туда закинуть?» Комитет обсуждал на среде. Решили: «Давайте, но параллельно». +4 дня работы на scope, который не был в изначальной договорённости.
Неделя 2: Next.js-страница + поиск. Но поиск требовал больше времени на настройку synonyms. Вторая дискуссия: «Может, пока без synonyms?» Решили через неделю — «ладно, без synonyms для начала».
Неделя 3 (Canary, на день позже плана): TTFB улучшился с 1080мс до 420мс. Конверсия... не ясно. Потому что метрика не определена. Lighthouse улучшился. Ощущения смешанные.
Неделя 4: обсуждение «продолжаем или нет». Маркетинг: «конверсия не выросла явно». Продукт: «Lighthouse вырос, но пользователи жалуются на мелочи в дизайне». CTO: «технически работает, но непонятно, стоит ли дальше».
Закрытие. Официальная формулировка: «результаты нормальные, но недостаточные для того, чтобы инвестировать дальше».
Что убило этот пилот
-
Размытая метрика. Без конкретной цифры «успех» — субъективное восприятие. Три человека в комитете имели разные критерии успеха. Ни один не был удовлетворён целиком.
-
Комитет вместо owner-а. Каждое решение — неделя. Пилот на 2 недели с 2-недельными задержками на решения превратился в 5 недель.
-
Scope drift. Добавленный поиск распылил внимание. Без него пилот сработал бы по изначальной метрике (которой не было).
-
Нет плана на «если сработает». Даже если бы конверсия выросла — комитет обсуждал бы ещё неделю «что дальше». Отсутствие forward-плана убило momentum.
Универсальный вывод
Пилот — это не только инженерный эксперимент. Это эксперимент по принятию решения. Успешный пилот доказывает две вещи одновременно:
- Технология работает (инженерная часть)
- Организация умеет принимать решения по этой технологии (организационная часть)
Клиент А доказал обе. Мы перешли в 4-летнее сотрудничество.
Клиент Б доказал первое, но не второе. Мы ушли. И правильно сделали — дальше было бы только хуже.
Что фиксировать в пилот-контракте
Минимальный набор для «пилота, который может выстрелить»:
Метрика успеха — одна цифра, одна страница/endpoint, одно окно замера. «Конверсия через /catalog/electronics растёт на ≥3% за 14 дней Canary». Не две метрики, не «или-или».
Owner — один человек с мандатом принимать решения в процессе пилота. Не комитет. Имя в документе.
Scope — 1 страница формата «что входит / что не входит / что отдельное обсуждение». Без устных договорённостей.
Rollback — конкретный триггер и время. «Конверсия падает > 1% за 48 часов → auto-rollback».
Forward-план — что происходит, если метрика достигнута. Не «обсудим», а «переходим к этапу 2 с бюджетом X».
Без одного из этих пяти — риск, что «нормальные результаты» станут причиной закрытия.
48-часовой аудит: что в нём есть про пилот
Аудит возвращает draft пилот-контракта с заполненными 5 полями под ваш стек. Метрика, owner (кандидаты), scope, rollback-критерии, forward-план. Это не коммерческое предложение — это инструмент для вашего внутреннего обсуждения.
Бесплатно, без обязательств. Заберёте — внедрите сами. Захотите обсудить сотрудничество — обсудим.
Read next
Articles on adjacent topics — from real projects.
Do not start a site rewrite without a short discovery
How a founder, CTO or e-commerce lead can evaluate a replatform/headless move without taking a large delivery risk: what to collect before estimation, how to separate base scope from optional work, and why the first step should be a small pilot.
Blog · June 23, 2026The Catalog That Broke Over 48 Hours: An Incident Report, What We Found, What We Fixed
Один из клиентов в начале июня прислал сообщение в пятницу вечером: «С утра каталог отдаёт ошибки, конверсия упала в 3 раза, что делать». Сайт был не на…
Blog · June 17, 2026Bitrix as a Headless API: What It Gives You and What It Does Not
What 1C-Bitrix provides out of the box as a headless backend, what requires custom development, and what is simply not worth the effort.
Newsletter
Headless migrations & AI pilots, unpacked
Every 2 weeks — real cases, numbers and architecture decisions. No marketing noise.