Прыжок веры: почему не нужно бояться работать с IT-поставщиками по модели Time & Materials

Контракты с фиксированными сроками и бюджетами снижают эффективность разработки. Однако заказчики по привычке продолжают придерживаться этой практики. Рассмотрим, что не так с Fixed Price моделью, и почему оплата по часам — это сложный, но единственно верный выбор.

Рынок IT-аутсорсинга эволюционирует, чтобы соответствовать росту компетенций на стороне клиента. Несмотря на это, «полной открытости» и «тесному взаимодействию» мешает жесткая граница между заказчиком и поставщиком услуг, которая отражается в договоре.

Ожидается, что заказчик и исполнитель будут учитывать общие интересы, но контракт часто демонстрирует обратное. Большинство рисков перекладываются на сторону поставщика, однако, когда что-то идет не так, в большей степени страдает заказчик.

Многие считают, что контракты с фиксированной ценой волшебным образом уберегут от непредвиденных перерасходов, но вместо этого они замедляют вывод продукта на рынок, цикл проверки гипотез и сбора обратной связи, а также препятствуют росту бизнеса. Ниже подробно рассмотрим, как это происходит.

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

Начнем с очевидного — клиенты настаивают на фиксированном бюджете, потому что точно знают, каким должен быть конечный продукт. Или, вернее сказать, думают, что знают. Разработка сложных IT-продуктов занимает время, за которое неизбежно меняются ожидания пользователей и ситуация на рынке. Если не корректировать приоритеты с учетом этих изменений, проект, скорее всего, потерпит неудачу.

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

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

Чтобы оценить объем, поставщик должен привлечь опытного разработчика для составления сметы. В зависимости от толщины ТЗ и количества макетов, на это уходит до нескольких десятков часов. Не все компании выделяют столько ресурсов на пресейл, а значит, более востребованные поставщики просто откажут на этапе заявки, а менее востребованные пришлют сметы разной детализации и проработки. Пул потенциальных исполнителей сократится, но какой ценой.

В условиях неуклонно растущей популярности SaaS-платформ, коробочных решений и ноукод-конструкторов, запустить MVP порой можно и без программистов. И мы настоятельно рекомендуем использовать готовые решения, доказавшие свою эффективность.

Задачи, для которых готовых решений нет, требуют индивидуальной разработки. А в современных реалиях индивидуальное равнозначно уникальному. Даже для того, чтобы повторить подсмотренный у конкурента функционал, в итоге потребуется интеграция с вашей средой, бэк-офисом, системами аналитики, девопс и пр. Это делает каждую задачу непредсказуемой по трудозатратам из-за множества взаимосвязанных элементов.

При изначально неверной оценке клиент в ходе проекта столкнется с просьбой либо расширить смету, либо сократить объем, либо сдвинуть сроки. Если в этой ситуации закрыться договором и не пойти на уступки, то в попытке сократить потери подрядчик может заменить дорогостоящих специалистов на менее опытных и предоставить минимум, который формально будет соответствовать требованиям.

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

Софт — это не оборудование, которое один раз купил и забыл. Любое приложение нужно поддерживать. И если разработка велась по заранее определенными требованиями без учета меняющихся условий, то вскоре после первоначального выпуска потребуется обновление. Фиксированная стоимость каждой доработки выльется в чрезмерную бюрократизацию, что затянет решение срочных проблем.

Если при первоначальной разработке исполнитель понес убытки, то в лучшем случае он попытается «отыграться», завышая стоимость сопровождения. В худшем — откажется от проекта из-за низкого качества кода, которым пришлось пожертвовать, чтобы сдать проект. Последний вариант в итоге приведет к долгим поискам новой команды и полному переписыванию проекта.

Если же ни один из рисков не срабатывает, то клиент просто переплачивает за спокойствие. Именно поэтому некоторые конвейерные компании, которые занимаются разработкой типовых решений, могут эффективно работать по фиксированным контрактам. С разработкой индивидуальных решений достигнуть такого уровня операционного совершенства невозможно, поэтому Fixed Price для них не работает даже на коротких дистанциях.

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

Модель Time & Materials (T&M) — это контракт, по которому клиент оплачивает время, затраченное исполнителем на выполнение проекта. Термин пришел из строительства, поэтому если говорить о материалах в IT, то это дополнительные затраты исполнителя на оборудование, сопутствующие лицензии, аренду серверов и т.д.

Если объем проекта меняется, возникают новые потребности, или клиент решает изменить направление, то он платит за трудозатраты, а не за результат. При T&M можно описывать конечные результаты примерно или даже точно, но поставщик не несет полную ответственность за их выполнение. Этот нюанс вполне оправданно вызывает дискомфорт.

Очевидно, если оплата производится стабильно и вовремя, то у исполнителя нет стимула быстро завершить работы, — а речь об IT, где в каждом втором офисе столы для пинг-понга, плейстейшены, гамаки и смузи-бары, — справедливо возникает опасение, а не будет ли как в том анекдоте — солдат спит, служба идет?

Рекомендуется прописывать в договоре ограничение бюджета или допустимое расхождение часов работы, что еще известно как T&M NTE (not to exceed). Это сомнительный подход, так как подрядчик по-прежнему выставляет счет на основе затраченных усилий, но только до определенного момента. При превышении бюджета работы просто прекращаются.

Можно запрашивать сверх подробную отчетность. Считать, сколько раз программист нажимал по клавиатуре, сколько строк кода написал за день, автоматически делать скриншоты экранов и активных окон. Но, во-первых, это оказывает психологическое давление на разработчика, а во-вторых, опираться на такие данные — это все равно что оценивать процесс создания самолета по его весу.

В реальности, у порядочного исполнителя всегда есть стимул завершить проект и принести клиенту пользу, чтобы дальше стабильно с ним сотрудничать, увеличить объемы или перейти c T&M на Retainer, фиксированную абонплату.

Даже ознакомившись со всеми недостатками фиксированных контрактов, принять решение о работе с партнерами по системе T&M непросто — условия кажутся небезопасными. Если у вас не было негативного опыта с подрядчиками, то продолжая работать по фиксированным бюджетам, вы лишаете себя ряда преимуществ, и скорее всего переплачиваете.

Если же негативный опыт имеется, то это повод сделать шаг навстречу переменам.

Преимущество T&M в том, что поставщик не скрывает от вас программистов. Но так как на рынке существует разное понимание градации специалистов, следует провести техническое собеседование, чтобы проверить компетенции привлекаемого персонала.

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

Но тщательная подготовка окупается высокой вовлеченностью разработчиков.

Заранее установите команде четкие критерии готовности и согласуйте формат отчетности. Это могут быть ежедневные и еженедельные отчеты по статусу работ разной степени детализации.

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

Бюджет на проект — это лишь одна ячейка в экселе, которую хочется зафиксировать. Но есть и другие — прогноз прибыли, общий бюджет на развитие и т.д. Все они взаимосвязаны, и нельзя их рассматривать в отрыве друг от друга.

Договор — это лишь попытка зафиксировать на бумаге отношения с партнером, чтобы они были справедливыми. После подписания обеим сторонам предстоит много работы, чтобы сделать эти отношения действительно взаимовыгодными.

Для некоторых привлекательность фиксированных проектов в том, что они требуют от заказчика минимум управленческий усилий. С T&M напротив, нужен высокий уровень вовлеченности. Но только так можно создавать и развивать действительно востребованные продукты.

Фиксированные договоры всегда ставят одну из сторон в положение зависимой. Из-за этого складывается не самая здоровая динамика, похожая на перетягивание каната. Это вредит общим интересам.

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