Как не слить все деньги, если вы заказали разработку?

Привет, vc.ru! Я Дмитрий Цапля, СЕО along. pw — студии продуктовой разработки из Иннополиса. В этой статье я расскажу, как не надо заказывать IT-разработку, и почему хороший договор не спасёт вас от отсутствия доверия. В конце - 6 советов для заказчика.

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

Студии стреляют в воздух, надеясь попасть в ожидания клиента.

В Agile есть такое понятие — конус неопределенности. Если вы получили оценку на этапе первого погружения в продукт, то будьте готовы к увеличению в 4 раза.

Смета вашего проекта в IT — живой организм. Она должна и будет меняться с течением времени. Это нужно принять и уметь с этим работать. Для этого нужно постоянно общаться с командой и просить обновлять прогнозы.

Многие студии предложат вам стандартную схему:

Всё по классике — 50% аванс, N месяцев работы, работу принимаю по ТЗ, остальные 50% в конце.

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

Техническое задание — это важно. Без него у вас не получится перевести ваши бизнес-требования на язык разработки. Главная ошибка — подписать ТЗ на самом старте работ, думая что ТЗ — это план.

IT-продукты не создаются по плану — в разработке слишком много неопределенности. Поэтому ТЗ должно и будет меняться, это не страшно. Страшно — это каждый раз согласовывать новые сроки и цену при изменении продукта.

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

Цена разработки вашего проекта будет меняться. Разработчики узнают реальную цену только в процессе разработки. А вот фиксированная сумма в договоре меняться не будет. Поэтому разработчики либо возьмут с вас лишние 50% за риски, либо будут продавать вам доработки по тройной цене, чтобы отбить потери от неправильной оценки в начале.

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

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

Time&Material (ТМ) — формат работы, в котором вы платите только за реально потраченные разработчиками часы. Вы просто говорите исполнителям, что делать.

Обычно это служебная записка, сообщение в чате или то же тех. задание. Разработчики выполняют задачи, записывают потраченные часы, PM дает отчеты каждую неделю, оплачиваете часы в конце месяца.

При такой модели работы вы:

ТМ-формат подразумевает активную работу со стороны как исполнителя, так и заказчика. Вам обязательно нужно:

И главное — научиться доверять исполнителю. В конце концов, вы никогда не сможете доказать, что у разработчики потратили именно столько часов, сколько они вам сказали.

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

Спасибо, что дочитали до конца! Буду рад со всеми пообщаться и рассказать больше про создание и запуск стартапов — прошу в телеграм: @dimtsaplia