Спайк: как проверить главный риск проекта за несколько дней и не платить за весь проект

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

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

Что такое спайк

Спайк это маленький платный шаг, который проверяет главный технический риск проекта. Не фичу, а доступ.

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

Один разработчик, несколько дней, работа на реальной системе заказчика, а не на выдуманных данных.

Зачем это заказчику

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

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

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

Зачем это подрядчику

Мы не называем твёрдую цену со сроком до спайка. Это выглядит менее уверенно, чем «сделаем за месяц», и именно поэтому работает: до проверки доступа неизвестно главное.

Типичные вопросы, которые спайк закрывает за несколько дней: даст ли учётная система доступ по API или придётся выгружать файлы руками, в каком виде там лежат данные, есть ли у заказчика человек, который может выдать доступы, нет ли юридического запрета на передачу этих данных.

Любой из этих ответов может увеличить объём проекта вдвое. Узнавать это после подписания фикс-прайса дорого.

Как оформляется

Короткое предложение на одну страницу: что входит, сколько дней, критерий завершения, цена.

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

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

Когда спайк не нужен

Если задача типовая и все внешние системы знакомы обеим сторонам, проверять нечего, и лишний этап только растягивает срок.

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

Где ещё это работает

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

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

Общее правило: если в проекте есть вопрос, на который ни одна из сторон не может ответить уверенно, он стоит несколько дней работы сейчас и половину бюджета потом.

Обсудить спайк для вашей задачи