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