Как не слить все деньги, если вы заказали разработку?
Время и деньги
Начну с главного: никто не знает, сколько реально стоит создать ваше приложение/сайт
Приходя в студии, заказчики оказываются на диком западе эстимирования: оценки даются без аналитики, без понимания продукта и на основе внутренних ощущений. Студии стреляют ввоздух, надеясь попасть в ожидания клиента.
Конус неопределенности
В Agile есть такое понятие — конус неопределенности. Если вы получили оценку на этапе первого погружения в продукт, то будьте готовы к увеличению в 4 раза. Смета вашего проекта в IT — живой организм. Она должна и будет меняться с течением времени. Это нужно принять и уметь с этим работать. Для этого нужно постоянно общаться с командой и просить обновлять прогнозы.
Условия работы
Многие студии предложат вам стандартную схему:
написать техническое задание (ТЗ)
сделать оценку по ТЗ
подписать договор с фиксированной суммой оплаты
Всё по классике — 50% аванс, N месяцев работы, работу принимаю по ТЗ, остальные 50% в конце. Кажется, что всё очень просто. Приключение на 20 минут. К сожалению, такой формат не подойдет для создания чего-то сложнее, чем лендинг на тильде. Проблемы начинаются с технического задания.
Техническое задание
Техническое задание — это важно. Без него у вас не получится перевести ваши бизнес-требования на языкразработки. Главная ошибка — подписать ТЗ на самом старте работ, думая что ТЗ — это план. IT-продукты не создаются по плану — в разработке слишком много неопределенности. Поэтому ТЗ должно и будет меняться, это не страшно. Страшно — это каждый раз согласовывать новые сроки и цену при изменении продукта. Почему многие студии всё таки предлагают заказчику подписать ТЗ и работать строго по нему? Я считаю, что это происходит от нежелания обеих сторон выстраивать доверительныеотношения. Если у вас нет доверительных отношений, то на переговоры и переоценки вы потратите больше времени, чем на сам продукт.
Про фиксированную оплату
Цена разработки вашего проекта будет меняться. Разработчики узнают реальную цену только в процессе разработки. А вот фиксированная сумма в договоре меняться не будет. Поэтому разработчики либо возьмут с вас лишние 50% за риски, либо будут продавать вам доработки по тройной цене, чтобы отбить потери от неправильной оценки в начале. Главная проблема в том, что вы не контролируете, сколько у разработчиков уходит времени на задачи и не можете принять правильныерешения. Иногда лучше убрать сложную фичу, чем потратить на нее все деньги и не получить продукт. Формат фиксированной оплаты не требует от заказчика постоянного взаимодействия с исполнителями, что плохо сказывается на продукте. Вы, скорее всего, потратите больше денег, чем в других форматах работы.
Про ТМ
Time&Material (ТМ) — формат работы, в котором вы платите только за реально потраченные разработчиками часы. Вы просто говорите исполнителям, что делать. Обычно это служебная записка, сообщение в чате или то же тех. задание. Разработчики выполняют задачи, записывают потраченные часы, PM дает отчеты каждую неделю, оплачиваете часы в конце месяца. При такой модели работы вы:
Получаете контроль над тратами вашего проектного бюджета (а не отдаете весь бюджет под контроль исполнителя)
Получаете прозрачную аналитику по трудозатратам и можете принимать продуктовые решения
Можете быстро менять требования — не нужно заниматься переоценкой подписанного ТЗ
Контролируете сроки сдачи, так как видите скорость команды в динамике
Какие подводные?
ТМ-формат подразумевает активную работу со стороны как исполнителя, так и заказчика. Вам обязательно нужно:
Фиксировать задачи, которые вы ставите исполнителям
Четко и понятно объяснятьтребования и убедиться, что исполнитель их правильно понял
Требовать отчеты по часам и демонстрацию прогресса каждые 1-2 недели
И главное — научиться доверятьисполнителю. В конце концов, вы никогда не сможете доказать, что у разработчики потратили именно столько часов, сколько они вам сказали. Моя студия занимается разработкой и запуском IT-продуктов для стартапов, поэтому без гибкости мы бы не смогли делать то, что мы делаем.
6 советов для заказчика
Работать по ТМ (или хотя бы с оплатой за этапы)
Быть постоянно включенным в процесс
Требовать отчеты по трудозатратам
Просить обновлять оценку с течением времени
Быть готовому к изменениям и непривязывать всё к ТЗ
Не работать с исполнителем бездоверия
Спасибо, что дочитали до конца! Буду рад со всеми пообщаться и рассказать больше про создание и запуск стартапов — прошу в телеграм: @dimtsaplia