Договор на ИТ-аутстаффинг: как не обжечься самому и не подпалить клиента

Привет! Меня зовут Глеб Корсунов, я директор по развитию Holyweb, евангелист ИТ-аутстаффинга и разработки на Golang. Уже четыре года мы выводим на проекты клиентов продуктовые команды и отдельных программистов, чтобы ускорить релиз или закрыть недостающие компетенции инхаус-отделов.

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

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

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

Юристы Runetlex отвечают:

Заемный труд запрещен. Так говорит ст. 56.1 Трудового кодекса. При этом под заемным понимается труд работника, выполняемый под управлением и контролем другого лица (не работодателя). «Занимать» труд работников могут только компании, которые прошли аккредитацию.

Многие считают, что аутстаффинг — это «аренда сотрудников», и поэтому относятся к нему с опаской. Но у работы по такой модели есть особенности, которые отличают ее от заемного труда. На них следует обратить внимание в договоре:

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

Договор с базовыми условиями. Там указан предмет, порядок согласования заданий, условия об интеллектуальной собственности, ответственность и прочие стандартные условия. Его смотрят и правят только юристы.

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

Большинство ИТ аутстафф-агентств используют шаблоны, которые изначально были написаны для разработки по аутсорс-модели. Их легко распознать по ключевым словам: создать, разработать, передать, результат, качество.

В ИТ-аутстаффинге исполнитель не может взять на себя ответственность за конечный результат. Заказчик самостоятельно руководит процессом разработки: может изменить задание, прекратить разработку, которая для него больше не актуальна и запустить новую. Поэтому стандартный договор с предметом «разработать и передать права на ПО» несет в себе потенциальные риски для ИТ-аутстафферов.

Наш шаблон разработан по модели оказания услуг: исполнитель берет на себя обязательство выполнять задания, которые ставит заказчик, за что тот платит.

Перед началом работы аутстафф-сотрудникам нужно получить доступы к системам заказчика: репозиторию, таск-трекеру, внутренним сервисам.

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

Чтобы не оказаться в ситуации, когда программист не может работать из-за проблем с доступом, мы предусмотрели следующие обязанности:

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

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

Чтобы избежать конфликтов на тему «мы этого не просили» или «мы просили не этого», задания должны быть письменно согласованы сторонами.

Но мы понимаем, что постановка задач исключительно через таск-трекер возможна только в идеальном мире. Поэтому для себя выбрали такую систему постановки:

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

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

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

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

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

К одному договору можно подписать неограниченное количество приложений. Например, в тестовом формате заказчик поработал с одним Go-разработчиком — заключаем приложение №1. Ему все понравилось и он решил собрать команду уже из троих — подписываем приложение №2.

Наше приложение — это аутстафф-абонентка.

Основной формат — это выделение всего рабочего времени разработчика в месяце (фултайм). Заказчик платит за то, что специалист закреплен за его проектом. Он может ставить любое количество задач — на цену это не влияет.

Ежемесячная стоимость зависит от количества рабочих дней. Например, в марте 22 рабочих дня, а в мае — 18, и приложение это учитывает.

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

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

Объем услуг

В этом разделе перечислите специальности выделяемых сотрудников.

Таблица со ставками

В таблице вы указываете стоимость рабочего дня (для фултайма) и стоимость часа (для овертайма) по каждой услуге, которую перечислили выше.

Предлагая расчет по ставкам вместо фиксированной стоимости месяца, мы делаем ценообразование более гибким. Однако некоторых заказчиков при согласовании может смутить отсутствие конкретной цены. Чтобы избежать такой ситуации, мы предусмотрели в приложении максимальную стоимость — ее мы считаем, умножая стоимость дня на количество рабочих дней в месяце. Так мы получаем цифру, больше которой заказчик точно не заплатит (если не брать в расчет овертайм).

Системы

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

Представители

Укажите имя и контакты представителей обеих сторон. Только не пишите рядом с именем специальность, чтобы это не было похоже на аренду людей.

Действие приложения

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

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

Этот пункт — крайняя мера, который стоит реально применять только если одна из сторон столкнулась с непредвиденными обстоятельствами. Чтобы отношения были предсказуемыми для всех, мы выстроили систему скоринга. Так мы следим за качеством услуг и мониторим ситуацию на проекте. Со стороны исполнителя подобная система может включать в себя:

По окончании месяца мы направляем заказчику акт об оказанных услугах с расчетом стоимости месяца.

Если в текущем месяце овертаймов не было, в акте указывается реальное количество рабочих дней и расчет стоимости услуг. Если кто-то из команды уходил в отпуск или брал больничный, мы уменьшаем количество рабочих дней для конкретной услуги (вид, грейд).

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

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

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

Если остались вопросы — можно написать мне в Телеграм или коллегам из Runetlex: руководителю проектного отдела Алине Сундетовой, юристу Диане Кудряшовой. Также выражаю им огромную благодарность за подготовку договора и помощь в создании этой статьи.

Буду рад обсудить в комментариях ваши шаблоны договоров и опыт их согласования с клиентами.