Какие варианты оплаты работы программистов существуют?
- Fixed Price: Или фиксированная стоимость. Обычно по такой схеме оцениваются проекты, которые длятся не больше месяца. Или проекты с клиентами из 2000х.
- T&M: Или Time & Material. Так оценивают проекты, которые длятся от 2 месяцев и предполагают оплату за человеко-часы вовлеченных сотрудников.
- Dedicated team: Или выделенная команда. Используют в длительных проектах, требующих постоянного развития. То есть вы планируете постаянную загрузку в виде разработки и поддержки.
Я постоянно сталкиваюсь с тем, что мне приходится рассказывать о плюсах и минусах форм оплат. Но чаще всего — доказывать, что Fixed Price — это сплошная иллюзия. Поэтому решил рассмотреть все варианты на реальных примерах.
Fixed Price
Очевидно, что многим нравится этот вариант оплаты, потому что заранее знаешь, сколько потратишь. Уверен, что не выйдешь из бюджета. Или что тебе не выставят каких-нибудь лишних часов работы.
Да, и с этими убеждениями приходится бороться. Потому что для нас, как для исполнителей, есть только один расклад, когда Fixed Price будет невыгодным — если мы плохо изучили ТЗ и не заметили каких-нибудь приложений. А для клиента — целых три.
- Предусмотреть все: Менеджер, исходя из опыта, попытался учесть любые нюансы (даже те, у которых вероятность 0,01%) и выставил сумму х10. Хотя просчитать все, что больше 100 часов, — это пальцем в небо. И сравните «заложенные риски» на 100 часах 30% или на 600 часах 30%.
- Не предусмотреть все: Клиент со старта не учел все (а он стпудово все не учел), и его ждут допкосты. Ведь фикспрайс подразумевает фиксированные задания. Поэтому в результате получается сумму больше первоначальной.
- Никакой фантазии: Работа строится четко по ТЗ (никаких шагов вправо/влево), каждый новый этап стартует после завершения предыдущего. Придумали в процессе какие-то плюшки? Ждите допкосты, новые сроки, новые согласования документов и т. п.
Time & Material
Такая схема позволяет менять фокус в процессе разработки, реализовывать новые идеи. У клиента не будет каких-то переоцененных рисков, заложенных на старте — он платит столько, сколько каждый конкретный этап стоит. Менеджер не станет закладывать возможные проблемы, которые могут появиться, например, при налаживании интеграции.
- Можно контролировать как верхний порог бюджета, так и какие-то конкретные сроки. То есть клиент ограничивает сумму, которую он готов потратить на проект, а менеджер отслеживает расходование средств. Или, например, один из наших заказчиков хочет готовый проект к декабрю, параллельно он накидывает всяких идей, менеджер оценивает сроки их реализации и советует от чего лучше отказаться, чтобы успеть к дедлайну.
- Можно принимать решение самому в ходе работы, типа оставаться в рамках сметы или делать так, как будет лучше.Это как в ремонте. Например, по смете вы обозначили покраску стен в один слой, а в процессе работы выяснилось, что надо еще что-то подровнять и покрасить в 2 слоя. Вам и предлагают разные варианты: удорожить проект, но сделать идеально. Или делать так, как изначально собирались, поскольку достаточно просто MVP.
- Можно в процессе работы менять ТЗ, смещать приоритеты. В фикспрайсе бы пилили то, что написано и то, что рассчитано. А тут легко двигаться, отказываться от каких-то долгих и дорогих фич в пользу быстрой и более выгодной реализации продукта.
Dedicated team
Ладно, если не Fixed Price, то, наверное, это самый крутой вариант? Для нас — это гарантия постоянной загрузки команд и отсутствия бенча. Для клиента — полноценное внимание к проекту со стороны разработчиков и менеджера. Они трудятся только над его задачами, могут менять приоритеты во время работы, показывают результаты по итогам спринтов. Заинтересованы в результате, поэтому могут отклоняться от ТЗ, чтобы предлагать другие механики и подходы.
В целом ты права. Но, исходя из нашей практики, люди, задействованные только в одном проекте выгорают. У нас был случай, что за год работы с крутым, классным и масштабным клиентом команда устала. Им хотелось новых впечатлений, свежих задач и вообще встряхнуться от рутины. Поэтому пришлось менять ребят и передавать задачи. Но эти человеко-часы легли на наши плечи. Поэтому клиент никак не пострадал.
T&M — наиболее гуманный способ оплаты работы разработчиков.
Как контролировать работу при оплате по T&M?
Если в Fix price и в Retainer клиенты особо не парятся, что их могут кинуть, то формат T&M им кажется наиболее уязвимым. А вдруг обманут? А вдруг больше часов напишут? А вдруг ничего не сделают?
Это определенно так. Плюс вклиниться в процесс и помешать работать могут еще и юристы. Они тоже не понимают, что такое T&M и как потом урегулировать споры. Начинается куча бумажной волокиты, которая сводится к попыткам описать все в ТЗ со старта, заложить риски. И мы все равно возвращаемся к Fixed Price. Юристы ликуют. Но они реально не догоняют, что мы работать в убыток не будем. Поэтому, в случае чего, клиента будут ждать допкосты.
Как наладить взаимодействие при оплате по T&M?
- Перед началом каждого отчетного периода согласовывайте перечень работ, а после их выполнения запрашивайте отчет.
- Согласуйте, как часто менеджер будет информировать вас о ходе работ. Например, раз в неделю вы созваниваетесь, чтобы сверить, что сделано по плану.
- Фиксируйте и обсуждайте промежуточные результаты, чтобы можно было корректировать работу и задачи.
Как еще договориться обо всем на берегу?
- Ограничить бюджет на MVP в рамках договора.
- Обозначить допустимое расхождение часов работы.
- Фиксировать верхний потолок бюджета.
- Проговорить, что входит в стоимость проекта. Например, созвоны и обсуждения с разработчиками тоже считаются. Потому как в некоторых проектах в неделю может выходить до 8 часов звонков. Это тоже работа программиста, и она оплачивается.
- Наладить внутренние процессы по треканию часов и фиксации выполненных работы. Мы трекаем часы, и в каждой отметке разработчик пишет, к какой задаче это относилось, что делал. В результате у вас всегда есть лог работ относительно потраченного времени.
T&M — это модель, при которой заказчик и исполнитель взаимодействуют как партнеры и вместе ищут решение задачи.
Какой формат сотрудничества с разработчиками на аутсорсе выбрать?
сли ваша задача – это лендинг, промосайт или любой другой понятный и простой продукт, выбирайте Fixed Price. Особенно, в случае если есть дизайн, тексты, продумана структура. Мы, например, такие задачи в работу не берем, поэтому и данную форму сотрудничества не рассматриваем. Особенно после одного случая, о котором я рассказывал у себя на Facebook.
Если вы внедряете что-то новое, например, автоматизируете работу sales-менеджеров с помощью создания личных кабинетов, или переводите программу лояльности в формат приложения, лучше выбирать T&M. Это эффективнее и с точки зрения бюджета, и – с разработки.
Если планируете выстраивать глобальную инфраструктуру, в основе которой надо продумать логистику, встроить веб, мобайл и потом еще допиливать сервисы для внутреннего пользования, то лучше уже прибегнуть к выделенным командам. Т.к. они со старта будут вовлечены в проект и смогут со старта предусмотреть все нюансы.
