Самая дешёвая фича — та, которую не пришлось разрабатывать

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

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

Назовите предположение до решения

RAT — Riskiest Assumption Test — подход к проверке рискованных предположений. В изложении Next Move Theory сначала явно записывают условия, от которых зависит инициатива, затем выбирают проверку с учётом последствий ошибки, неопределённости и стоимости получения свидетельств.

Вместо «клиентам нужна интеграция» запишите конкретное утверждение. Например: «Финансовые руководители сетей с еженедельным согласованием закупок готовы оплатить пилот за 40 000 ₽, если смогут передать текущие заявки без повторного ввода». В утверждении появились покупатель, ситуация, цена и наблюдаемое действие.

Теперь можно проверить не только спрос. Доступны ли нужные данные? Кто выдаёт разрешение? Можно ли вернуть результат в существующий процесс? Позволяет ли стоимость запуска заработать на контракте? У инициативы окажется несколько условий успеха, и каждое требует своего свидетельства.

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

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

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

Если же главный риск технический — API не отдаёт необходимые поля или обновляет их слишком редко, — разговоры о ценности его не снимут. Нужна короткая техническая проверка на разрешённом наборе данных. Дешёвый эксперимент полезен лишь тогда, когда отвечает на нужный вопрос.

Не путайте силу разных сигналов

«Звучит интересно» означает, что предложение не было отвергнуто в разговоре. Готовность выделить сотрудника на пилот говорит о большем обязательстве. Согласованный платёж добавляет информацию о бюджете и процедуре покупки. Повторное использование результата позволяет исследовать устойчивость пользы.

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

В карточке проверки полезно иметь пять полей:

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

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

У отказа тоже должна быть причина

Предположим, заказчик согласился с ценой, но отказался передавать файл: выгрузка требует участия IT, а у отдела нет времени. Команда узнала не то, что «продукт никому не нужен». Она обнаружила конкретную зависимость запуска.

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

Важен письменный вывод: какое предположение изменилось и что теперь разрешено считать известным. Без него неудачная проверка через месяц вернётся в backlog под новым названием.

Что сделать с запросом на шесть недель

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

Иногда после этого интеграция всё равно отправится в разработку. Но у неё появятся конкретный сценарий, подтверждённые ограничения и понятный способ приёмки. А иногда окажется, что клиенту достаточно другой выгрузки или готового отчёта. В обоих случаях команда начинает тратить инженерное время с более ясным основанием.