Рынок IT-аутсорсинга эволюционирует, чтобы соответствовать росту компетенций на стороне клиента. Несмотря на это, «полной открытости» и «тесному взаимодействию» мешает жесткая граница между заказчиком и поставщиком услуг, которая отражается в договоре.
Ожидается, что заказчик и исполнитель будут учитывать общие интересы, но контракт часто демонстрирует обратное. Большинство рисков перекладываются на сторону поставщика, однако, когда что-то идет не так, в большей степени страдает заказчик.
Многие считают, что контракты с фиксированной ценой волшебным образом уберегут от непредвиденных перерасходов, но вместо этого они замедляют вывод продукта на рынок, цикл проверки гипотез и сбора обратной связи, а также препятствуют росту бизнеса. Ниже подробно рассмотрим, как это происходит.
Проблемы Fixed Price контрактов
Помимо того, что такие контракты обходятся дороже из-за буфера, который партнер закладывает на риски, есть еще ряд взаимосвязанных сложностей:
Отсутствие гибкости
Начнем с очевидного — клиенты настаивают на фиксированном бюджете, потому что точно знают, каким должен быть конечный продукт. Или, вернее сказать, думают, что знают. Разработка сложных IT-продуктов занимает время, за которое неизбежно меняются ожидания пользователей и ситуация на рынке. Если не корректировать приоритеты с учетом этих изменений, проект, скорее всего, потерпит неудачу.
IT-индустрия долго шла к тому, чтобы снизить неопределенность, и научилась разрабатывать продукт итеративно, быстро получая обратную связь от рынка. При работе с внешними исполнителями этот коллективно накопленный опыт почему-то часто забывается.
Медленный старт
Поскольку в процессе активной разработки ничего изменить не получится, программистам необходимо получить четкое представление о продукте, прежде чем они начнут писать код. Поэтому даже самые мелкие нюансы нужно обсуждать заранее: все функции должны быть описаны в спецификациях. Иногда для определения точных результатов требуются предварительные исследования. Если разработка займет больше полугода, то сбор, формализация требований и согласование займут несколько месяцев, и все равно полностью не избавят от недопониманий.
Чтобы оценить объем, поставщик должен привлечь опытного разработчика для составления сметы. В зависимости от толщины ТЗ и количества макетов, на это уходит до нескольких десятков часов. Не все компании выделяют столько ресурсов на пресейл, а значит, более востребованные поставщики просто откажут на этапе заявки, а менее востребованные пришлют сметы разной детализации и проработки. Пул потенциальных исполнителей сократится, но какой ценой.
Неверные оценки
В условиях неуклонно растущей популярности SaaS-платформ, коробочных решений и ноукод-конструкторов, запустить MVP порой можно и без программистов. И мы настоятельно рекомендуем использовать готовые решения, доказавшие свою эффективность.
Задачи, для которых готовых решений нет, требуют индивидуальной разработки. А в современных реалиях индивидуальное равнозначно уникальному. Даже для того, чтобы повторить подсмотренный у конкурента функционал, в итоге потребуется интеграция с вашей средой, бэк-офисом, системами аналитики, девопс и пр. Это делает каждую задачу непредсказуемой по трудозатратам из-за множества взаимосвязанных элементов.
Низкое внутреннее качество
При изначально неверной оценке клиент в ходе проекта столкнется с просьбой либо расширить смету, либо сократить объем, либо сдвинуть сроки. Если в этой ситуации закрыться договором и не пойти на уступки, то в попытке сократить потери подрядчик может заменить дорогостоящих специалистов на менее опытных и предоставить минимум, который формально будет соответствовать требованиям.
Защититься от такого сценария не поможет ни один договор — так как есть параметр, который невозможно количественно измерить и зафиксировать. Речь о внутреннем качестве, которое, как правило, скрыто от глаз заказчика. И если оценка оказалась неверной, то шансы получить стабильную и масштабируемую кодовую базу низки.
Дорогое сопровождение
Софт — это не оборудование, которое один раз купил и забыл. Любое приложение нужно поддерживать. И если разработка велась по заранее определенными требованиями без учета меняющихся условий, то вскоре после первоначального выпуска потребуется обновление. Фиксированная стоимость каждой доработки выльется в чрезмерную бюрократизацию, что затянет решение срочных проблем.
Если при первоначальной разработке исполнитель понес убытки, то в лучшем случае он попытается «отыграться», завышая стоимость сопровождения. В худшем — откажется от проекта из-за низкого качества кода, которым пришлось пожертвовать, чтобы сдать проект. Последний вариант в итоге приведет к долгим поискам новой команды и полному переписыванию проекта.
Если же ни один из рисков не срабатывает, то клиент просто переплачивает за спокойствие. Именно поэтому некоторые конвейерные компании, которые занимаются разработкой типовых решений, могут эффективно работать по фиксированным контрактам. С разработкой индивидуальных решений достигнуть такого уровня операционного совершенства невозможно, поэтому Fixed Price для них не работает даже на коротких дистанциях.
Почему работа по модели Time & Materials, лучше Fixed Price
Итак, в условиях неопределенности у заказчика нет уверенности в требованиях, а у исполнителя в оценке трудозатрат, а значит, четко договориться о результатах сотрудничества невозможно. Выход — оплата по часам.
Модель Time & Materials (T&M) — это контракт, по которому клиент оплачивает время, затраченное исполнителем на выполнение проекта. Термин пришел из строительства, поэтому если говорить о материалах в IT, то это дополнительные затраты исполнителя на оборудование, сопутствующие лицензии, аренду серверов и т.д.
Если объем проекта меняется, возникают новые потребности, или клиент решает изменить направление, то он платит за трудозатраты, а не за результат. При T&M можно описывать конечные результаты примерно или даже точно, но поставщик не несет полную ответственность за их выполнение. Этот нюанс вполне оправданно вызывает дискомфорт.
Что здесь пугает? В первую очередь, на ум приходят преднамеренное затягивание сроков и посторонние занятия в оплачиваемое время.
Очевидно, если оплата производится стабильно и вовремя, то у исполнителя нет стимула быстро завершить работы, — а речь об IT, где в каждом втором офисе столы для пинг-понга, плейстейшены, гамаки и смузи-бары, — справедливо возникает опасение, а не будет ли как в том анекдоте — солдат спит, служба идет?
Рекомендуется прописывать в договоре ограничение бюджета или допустимое расхождение часов работы, что еще известно как T&M NTE (not to exceed). Это сомнительный подход, так как подрядчик по-прежнему выставляет счет на основе затраченных усилий, но только до определенного момента. При превышении бюджета работы просто прекращаются.
Можно запрашивать сверх подробную отчетность. Считать, сколько раз программист нажимал по клавиатуре, сколько строк кода написал за день, автоматически делать скриншоты экранов и активных окон. Но, во-первых, это оказывает психологическое давление на разработчика, а во-вторых, опираться на такие данные — это все равно что оценивать процесс создания самолета по его весу.
В реальности, у порядочного исполнителя всегда есть стимул завершить проект и принести клиенту пользу, чтобы дальше стабильно с ним сотрудничать, увеличить объемы или перейти c T&M на Retainer, фиксированную абонплату.
Какие рекомендации все же можно дать? Спросили у экспертов рынка
— Начните с психологической подготовки, почасовая оплата потребуют доверия и решительности;
Даже ознакомившись со всеми недостатками фиксированных контрактов, принять решение о работе с партнерами по системе T&M непросто — условия кажутся небезопасными. Если у вас не было негативного опыта с подрядчиками, то продолжая работать по фиксированным бюджетам, вы лишаете себя ряда преимуществ, и скорее всего переплачиваете.
Мы изначально использовали модели Fixed Price и T&M под разные задачи. В последнее время склоняемся в большей степени к последней, по ощущению это пришло с уровнем продуктовой зрелости компании
Если же негативный опыт имеется, то это повод сделать шаг навстречу переменам.
К переходу на T&M чаще всего приводят переговоры с исполнителем из-за сдвига сроков при утвержденных объемах, переоценок и расширений смет
— Обращайте внимание на квалификацию специалистов, а не регалии компании;
Преимущество T&M в том, что поставщик не скрывает от вас программистов. Но так как на рынке существует разное понимание градации специалистов, следует провести техническое собеседование, чтобы проверить компетенции привлекаемого персонала.
В случае с T&M обращаю внимание исключительно на опыт сотрудников, так как разработчики интегрируются в продуктовую команду как полноценные сотрудники компании. Иногда человек с нужным опытом и компетенциями требуется на определенный срок, и важнее закрыть позицию в моменте, даже если стоимость немного выше рынка
— Рассчитывайте бюджет исходя из полного выкупа часов нужных специалистов;
Почасовой формат вознаграждения предполагает, что клиент обеспечит минимальный объем, в противном случае придется оплачивать простои.
Возможный минус — необходимость оплачивать время простоев разработчиков, если нагрузка на функционального заказчика и аналитиков большая, то разработка может простаивать из-за отсутствия задач. Можно искусственно загрузить команду задачами и обеспечить объем работ, но столкнуться с тем, что в один момент времени разным разработчикам понадобится один и тот же объект системы
Но тщательная подготовка окупается высокой вовлеченностью разработчиков.
Если в бэклоге продукта есть большое количество задач, то простои возникать не должны. А полный выкуп часов дает определенность и спокойствие всем участникам — заказчик уверен в неплохом уровне погружения разработчика в процесс, партнер спокойно планирует загруженность специалиста, а сам сотрудник испытывает меньше стресса
— Договоритесь о понятных метриках прогресса;
Заранее установите команде четкие критерии готовности и согласуйте формат отчетности. Это могут быть ежедневные и еженедельные отчеты по статусу работ разной степени детализации.
Фиксирую максимальный бюджет в месяц, обсуждаю план работ на каждую неделю и отслеживаю прогресс — коммиты в репозиторий и промежуточные демонстрации результатов
Все аутсорсинговые компании обязательно отслеживают время затраченное программистами на выполнение коммерческих задач.
В детальной отчетности нет большой проблемы — зачастую исполнитель использует таск-менеджеры для контроля задач и фиксирует время выполнения
— Оцените долю затрат на IT от общего оборота компании;
Бюджет на проект — это лишь одна ячейка в экселе, которую хочется зафиксировать. Но есть и другие — прогноз прибыли, общий бюджет на развитие и т.д. Все они взаимосвязаны, и нельзя их рассматривать в отрыве друг от друга.
Несмотря на то, что утверждать в финансовых подразделениях проще фиксированную цену, T&M очень полезно практиковать. Однако для того, чтобы избежать злоупотреблений со стороны исполнителей, требуется хорошо знать специфику работы, быть уверенным в партнёрах. При принятии решений я держу в памяти совокупный объем затрат на IT в долях от оборота бизнеса. Если затраты на проект превышают лимит, ищу более экономичное решение. Небольшой овердрафт можно позволить, чтобы техническое решение было слегка «на вырост»
— Помните — ни один контракт не идеален, паритетность требует взаимных усилий;
Договор — это лишь попытка зафиксировать на бумаге отношения с партнером, чтобы они были справедливыми. После подписания обеим сторонам предстоит много работы, чтобы сделать эти отношения действительно взаимовыгодными.
Везде свои подводные камни. Time & materials может выливаться в затратные по нервам дискуссии с обеих сторон — сколько же часов заняла каждая задача и почему. При этом заказчик часто думает, что ему продали лишнее, а исполнитель может не выставлять все понесенные затраты, не получая выгоду и уменьшая стабильность своей компании. В случае с Retainer обе стороны уверены, что месяцы, в которые «игра» была не в их пользу, компенсируются другими месяцами. Но если несколько месяцев недополучает подрядчик, то он захочет увеличить стоимость абонентского обслуживания. А если клиент несколько месяцев не пользуется услугами в полном объеме, то он предложит пересмотреть условия в сторону уменьшения оплаты
— Поддерживайте общение с исполнителем. Постоянно.
Для некоторых привлекательность фиксированных проектов в том, что они требуют от заказчика минимум управленческий усилий. С T&M напротив, нужен высокий уровень вовлеченности. Но только так можно создавать и развивать действительно востребованные продукты.
Все сводится к пресловутым soft skills, которые, вопреки распространенному мнению, разработчикам очень важны. Лучше потратить немного времени на переговоры, чтобы заказчик и исполнитель лучше поняли друг друга, чем потом разгребать проблемы, порожденные взаимными недоразумениями
Фиксированные договоры всегда ставят одну из сторон в положение зависимой. Из-за этого складывается не самая здоровая динамика, похожая на перетягивание каната. Это вредит общим интересам.
T&M делает отношения более размеренными, поровну распределяя риски между заказчиком и исполнителем, и позволяет при соблюдении вышеприведенных условий добиться той синергии, которая необходима для запуска успешных продуктов.
