Привет, vc.ru! Я Дмитрий Цапля, СЕО along. pw — студии продуктовой разработки из Иннополиса. В этой статье я расскажу, как не надо заказывать IT-разработку, и почему хороший договор не спасёт вас от отсутствия доверия. В конце - 6 советов для заказчика.
Время и деньги
Начну с главного: никто не знает, сколько реально стоит создать ваше приложение/сайт
Приходя в студии, заказчики оказываются на диком западе эстимирования: оценки даются без аналитики, без понимания продукта и на основе внутренних ощущений.
Студии стреляют в воздух, надеясь попасть в ожидания клиента.
Конус неопределенности
В Agile есть такое понятие — конус неопределенности. Если вы получили оценку на этапе первого погружения в продукт, то будьте готовы к увеличению в 4 раза.
Смета вашего проекта в IT — живой организм. Она должна и будет меняться с течением времени. Это нужно принять и уметь с этим работать. Для этого нужно постоянно общаться с командой и просить обновлять прогнозы.
Условия работы
Многие студии предложат вам стандартную схему:
- написать техническое задание (ТЗ)
- сделать оценку по ТЗ
- подписать договор с фиксированной суммой оплаты
Всё по классике — 50% аванс, N месяцев работы, работу принимаю по ТЗ, остальные 50% в конце.
Кажется, что всё очень просто. Приключение на 20 минут. К сожалению, такой формат не подойдет для создания чего-то сложнее, чем лендинг на тильде. Проблемы начинаются с технического задания.
Техническое задание
Техническое задание — это важно. Без него у вас не получится перевести ваши бизнес-требования на язык разработки. Главная ошибка — подписать ТЗ на самом старте работ, думая что ТЗ — это план.
IT-продукты не создаются по плану — в разработке слишком много неопределенности. Поэтому ТЗ должно и будет меняться, это не страшно. Страшно — это каждый раз согласовывать новые сроки и цену при изменении продукта.
Почему многие студии всё таки предлагают заказчику подписать ТЗ и работать строго по нему? Я считаю, что это происходит от нежелания обеих сторон выстраивать доверительные отношения. Если у вас нет доверительных отношений, то на переговоры и переоценки вы потратите больше времени, чем на сам продукт.
Не прикрывайте отсутствие доверия к исполнителю договорами и ТЗ. Не доверяете исполнителю — просто не работайте с ним.
Про фиксированную оплату
Цена разработки вашего проекта будет меняться. Разработчики узнают реальную цену только в процессе разработки. А вот фиксированная сумма в договоре меняться не будет. Поэтому разработчики либо возьмут с вас лишние 50% за риски, либо будут продавать вам доработки по тройной цене, чтобы отбить потери от неправильной оценки в начале.
Главная проблема в том, что вы не контролируете, сколько у разработчиков уходит времени на задачи и не можете принять правильные решения. Иногда лучше убрать сложную фичу, чем потратить на нее все деньги и не получить продукт.
Формат фиксированной оплаты не требует от заказчика постоянного взаимодействия с исполнителями, что плохо сказывается на продукте. Вы, скорее всего, потратите больше денег, чем в других форматах работы.
Про ТМ
Time&Material (ТМ) — формат работы, в котором вы платите только за реально потраченные разработчиками часы. Вы просто говорите исполнителям, что делать.
Обычно это служебная записка, сообщение в чате или то же тех. задание. Разработчики выполняют задачи, записывают потраченные часы, PM дает отчеты каждую неделю, оплачиваете часы в конце месяца.
При такой модели работы вы:
- Получаете контроль над тратами вашего проектного бюджета (а не отдаете весь бюджет под контроль исполнителя)
- Получаете прозрачную аналитику по трудозатратам и можете принимать продуктовые решения
- Можете быстро менять требования — не нужно заниматься переоценкой подписанного ТЗ
- Контролируете сроки сдачи, так как видите скорость команды в динамике
Какие подводные?
ТМ-формат подразумевает активную работу со стороны как исполнителя, так и заказчика. Вам обязательно нужно:
- Фиксировать задачи, которые вы ставите исполнителям
- Четко и понятно объяснять требования и убедиться, что исполнитель их правильно понял
- Требовать отчеты по часам и демонстрацию прогресса каждые 1-2 недели
И главное — научиться доверять исполнителю. В конце концов, вы никогда не сможете доказать, что у разработчики потратили именно столько часов, сколько они вам сказали.
Моя студия занимается разработкой и запуском IT-продуктов для стартапов, поэтому без гибкости мы бы не смогли делать то, что мы делаем.
6 советов для заказчика
- Работать по ТМ (или хотя бы с оплатой за этапы)
- Быть постоянно включенным в процесс
- Требовать отчеты по трудозатратам
- Просить обновлять оценку с течением времени
- Быть готовому к изменениям и не привязывать всё к ТЗ
- Не работать с исполнителем без доверия
Спасибо, что дочитали до конца! Буду рад со всеми пообщаться и рассказать больше про создание и запуск стартапов — прошу в телеграм: @dimtsaplia
А зачем заказчику вообще весь этой геморой? Он сделал заказ на сайт. Есть ТЗ в котором его дизайн есть. Прописаны все фишки которые должны на сайте быть. Есть цена за это все допустим 40 000 рублей.
И пусть там студия за один день все сделает, главное чтобы все было сделано по ТЗ. Нет результата в нужный срок, проблема студии тут, милости просим аванс обратно.
Если мы говорим про заказа сайта на 40 тысяч, то формат фикс договора работает лучше всего. Но если мы говорим про проект с бюджетом в пару миллионов и бэклогом задач на много месяцев, то формат фикс договора плохо сработает. Бэклог будет слишком часто меняться, а с ним и цена проекта. Вы правы в том, что ТМ, как и фикс, подходит не везде - это всегда tradeoff.
Даже если на 2 000 000. Тут нужно предусмотреть заранее. Иначе заказчик может годами хотелки придумывать. Тут или студия подписывается на хотелки заказчика, или нужно на каждые хотелки ТЗ составлять и дополнения к договору.
Так для этого и существует ТМ формат - чтобы хотелки новые быстро добавлять, а старые изменять. Заказчик будет понимать что каждая его новая хотелка будет стоить денег. При этом на каждую новую хотелку всё равно делается оценка.
С T&M есть одна существенная проблема. Почти любая разработка, для заказчика, это инвестиционный проект. Если заказчик чуть крупнее простого физика с идеей и деньгами - это защита инвестпроекта напрямую перед инвесторами или инвесткомитетом. Любой инвестпроект подразумевает прежде всего сумму инвестиций. Если вы идёте по T&M - у вас нет понимания этой суммы. На этом большинство T&M затей либо сворачиваются либо превращаются в fixprice.
Для инвестора можно сделать оценку разработки за фикс, заложив туда нужные риски. Потом работать по ТМ, и в случае если получится сэкономить, то можно потратить деньги на продвижение сделанного продукта
Неопределенность не уберешь из разработки. Заказчик и исполнитель будут менять бэклог продукта, чтобы подстроиться под бюджет, который у них есть. Стоит понимать, что мы говорим не про неопределенность в рамках нескольких порядков - это разброс в +- х2. По этой же причине чеки даются с запасом, все закладывают эти риски по несколько раз
За такое в каком-нибудь Газпроме расстреляют на месте. Поэтому да, именно так там и делают:
По этой же причине чеки даются с запасом, все закладывают эти риски по несколько разНо в конкурсы частенько забегают лихие ребятки с дисконтом в 80%, выигрывают тендер и попадают потом на большие проблемы.
В корпоративном аутсорсе не привыкли к ТМ, поэтому там просто просят кучу денег. А конкурсы это вообще отдельная тема, у меня больше опыт работы с стартапами, чем с корпоративными заказчиками
Можно снизить. Сначала делается MVP по фикспрайсу. Но прям короткий, не более 2-3 месяцев. За это время подрядчику нужно достичь достаточного уровня доверия заказчика, чтобы перейти на T&M
Да, иногда мы так делали, если не больше 2х месяцев работы и продукт понятен
Проекты в крупных компаниях проходят тендер, и если вы в нем участвуете, то должны назвать сумму Fix за то задание, которое предоставил заказчик. То есть ТМ тут уже не подходит.
Чтобы попасть в оценку с наименьшей погрешностью, стоит перед отправкой коммерческого предложения провести рабочую группу с заказчиком, позвать на нее своих продактов, аналитиков и тим-лидов разработки. Это поможет лучше понять ожидания от продукта, оценить риски и заложить их в стоимость. Такой подход также поможет показать вашу вовлеченность в проект и выстроить доверительные отношения.
Да, это затратно с точки зрения ресурсов, но если заказчик на это согласен, значит и с его стороны есть заинтересованность в найме квалифицированной студии и получении качественного продукта на выходе, значит пробовать стоит.
Я работал в студии разработки. На мой взгляд, ключевая причина непопадания в оценку это не столько новые требования от заказчика, сколько не учтенные работы с точки зрения требуемого функционала и интеграций на входе. Это связано с нехваткой ресурсов студий на проработку коммерческих предложений, так как ребята уже ведут по 3-4 проекта каждый, а сейлз сам просто не вытянет. Поэтому предложения могут отправляться по шаблонам, часто в них заложены огромные риски, что сильно увеличивает стоимость.
Что касается новых требований, которых не было в ТЗ, то их как раз разумно выполнять в рамках развития функционала по ТМ, когда есть команда, уже погруженная в проект и способная вести управление беклогом вместе с заказчиком. Если новые требования необходимо обязательно реализовать, нужно выносить что-то равноценное по объему из MVP, провести "бартер" фич. Или уйти в минус.
Да, тендеры это отдельная история, там другие законы. Мы больше работали с стартапами и средними по размеру проектами
Видел, как студии откидывали оценки и КП даже без единого звонка с клиентом, так что соглашусь что дело не только в ТМ)
При этом, даже при самом качественном КП сильно меньше рисков не станет - на проработку проекта нужно время. Поэтому я всегда объясняю что КП это КП, а проект - живая сущность, в которой может всё меняться. Главное, чтобы эти изменения были предсказуемыми и подсвечивались как можно раньше.
Знаем мы все эти приключения на 20 минут и не только по сериалу
Важный момент, что отчеты по трудозатратам нужны не для того, чтобы выяснять не потратили ли лишние пол часа на какую-то фичу, а чтобы эстимировать дальнейший бэклог задач оценивать общую эффективность команды
Да, согласен, танцы с бубном вокруг оценок никогда ни к чему хорошему не приводили)
Актуальная тема особенно в реалиях любых коммерческих отношений по разработки любого ПО.
А что насчёт оценки перед началом работ которая будет на 99% совпадать с итоговой, это утопия?
Оценка перед началом работ вообще никогда не совпадает с результатом, так что даже не стоит пытаться
Стоит еще отметить, что в работе по ТМ заказчик тоже берет на себя риски того, что всё будет идти не по оценке. ТМ требует большей вовлеченности в проект, но в итоге она окупается втройне
Что-то по любому сольётся, что-то всегда не учитывается
Угвэй
Всегда оплачиваю работу только так: задание / затраченное время. Формат: руб/мин. Очень дициплинирует исполнителей. Проверено!
Тут важно не утрировать и понимать, что работа разработчиков - не только писать код, но и думать. Поэтому вплоть до минуты не следим) Для нас идеальным форматом является почасовой расчет
Кстати, мы тоже не следим. Но формат оплаты для исполнителя всегда озвучиваем.
50 на 50%? Нам исполнитель сказал 90% сейчас, 10 - потом. Тут еще зависит от исполнителя... Если мы хотим определенного товарища, то должны быть готовы и к его условиям...
В таком случае у исполнителя не будет мотивации сдавать вам проект вовремя, он может вообще слиться с 90% бюджета. Если человек просит 90% предоплату, то это тревожный звоночек
Суды по разработке это очень тяжело, особенно для небольших компаний
Я бы советовал работать либо 50 на 50, либо переходить на оплату по этапам (исполнитель сдал этап - вы оплатили)
Про этапы обсуждали. Но! Представьте, если человек сделал главную, несколько внутренних, и тоже бросил? Кто потом захочет разгребать за кем-то? Найти потом вообще будет гораздо сложнее... Так что... ((( Наверное, стоит через гаранта делать...
Тут уже вопрос в вашем доверии к разработчику/студии. Также, вы всегда можете поставить сроки выполнения работ. При этом всё еще можно работать по ТМ
Это-то понятно... Ну как доверие это получить? Мы же сайт заказываем в первый раз в жизни, опыта нет абсолютно. Остается интуиция))
Попросить контакты других заказчиков (а лучше попробовать их найти) и спросить, как работают люди
Также посмотрите портфолио и отзывы (если студия делает много заказов и есть публичные отзывы)
Узнайте, как внутри работает компания - сколько людей в штате, какой топ-менеджмент
Привлеките IT-эксперта со стороны, который проверит оценку в часах и скажет, не накручивают ли исполнители часы
Могу помочь с этим, @dimtsaplia в тг
Ох сколько всего уже написано на VC, CMSmag, Kraftblick и пр. про сравнение разных моделей вознаграждения. Десятки материалов. Даже мы готовили такой и звали экспертов индустрии, чтобы был social-proof так сказать (https://vc.ru/opinions/252643).
Мой опыт подсказывает, что проблема в T&M NTE, т.е. с верхней границей бюджета. Счета выставляются по фактическим часам и по смете одновременно. Это всегда приводит к испорченным отношениям. Потому что заказчик ожидает получить результат, который видел в смете, при чем получить его дешевле чем по фиксе. Я считаю в таких случаях виноват исполнитель, что не отработал с ожиданиями.
Согласен, NTE это условие, которое перекладывает риски на исполнителя, при этом не дает доп. денег за эти риски.
У вас отличная статья, в итоге всё сводится либо к доверию, либо к выкупу команды на месяц фуллтайма и в итоге к тому же доверию. Наверное поэтому сейчас многие переходят на аутстафф, чтобы работать с in-house командой