Какие контракты понадобятся для ведения деятельности в сфере IT в Украине?

Правильное оформление договорных отношений с клиентами (заказчиками) и специалистами, то есть  выбор необходимых контрактов, зависит от специфики и масштабности IT компаний.

Самыми популярными в Украине являются сервисные компании, то есть те, формат работы которых, как правило, B2B (Business to Business). Такие компании предоставляют услуги по разработке программного обеспечения (софта) по заказу других компаний. 

Основной “состав” сервисных компаний - это в основном разработчики, примерно 90% всех специалистов. Масштабирование такого бизнеса зависит от количества проектов и, соответственно, от количества нанятых разработчиков которые будут работать над этими проектами. 

Сегодня мы поговорим о том, какие контракты и договора понадобятся для безопасной работы сервисным и другим типам IT компаний в Украине.

Все условия контрактов с заказчиками (клиентами), партнерами должны пересекаться с условиями контрактов с разработчиками (“зеркалить условия”).

Договора (соглашения) в ИТ сфере условно можно разделить на те, которые защищают коммерческие интересы компании и те, которые регулируют отношения между заказчиками (клиентами) и разработчиками, в рамках определенного заказа/проекта. 

Интересно: Налоговая оптимизация IT-проектов в Украине при работе с иностранными Клиентами

Контракты, защищающие коммерческие интересы IT компании

NDA - Non-disclosure Agreement Agreement - соглашение о неразглашении конфиденциальной информации, коммерческой тайны, которая принадлежит компании. Мы уже писали подробно о том, как заключить такой контракт тут.

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

Далеко не все компании задумываются о таком договоре, или воспринимают проблему всерьез, а зря. Мы сталкивались с ситуацией, когда IT компания занималась разработкой специфического продукта, который был главным активом этой компании. Компания заключила договор с разработчиком (ФОП) и не заключила NCA. В процессе работы компания обучила этого специалиста  специфическим знаниям и навыкам, передала всю коммерческую информацию, а разработчик по финалу работы над проектом, забрал все разработки и смог их монетизировать в свою пользу. 

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

NSA - Non-solicitation Agreement - Соглашение о непереманивании, которое запрещает подрядчику, компании конкуренту и/или связанными с ними третьим лицам, переманивать сотрудников компании заказчика (работодателя).

При составлении этого соглашения с заказчиком необходимо заключить с разработчиком (командой), которые работают над его проектом, соглашения NCA, которые бы прямо запрещали им конкурировать. Иначе они смогут добровольно перейти к конкурентам в обход NSA.

Договора, которые регулируют отношения между заказчиками и IT разработчиками 

Выбор формы контракта с Клиентами зависит от выбранной модели сотрудничества: 

• Fixed Price (фиксированная цена); 

• Time & Material (оплата поэтапная, не определена конечная стоимость); 

• Dedicated team (Cost plus) (заказчик полностью управляет командой и оплачивает их работу и фиксированный % IT компании за использования ее разработчиков). 

От выбранной модели зависит цена и распределения рисков сотрудничества, про все модели детально тут.

Риски, которые необходимо учесть при выборе отдельных моделей сотрудничества:

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

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

Time & Material - риски на клиенте (заказчике). Он должен рассчитать силы своего бюджета, и риски выхода за его рамки, в зависимости от сложности и масштабности проекта.

Поговорим подробнее о возможных видах договоров с разработчиками и Клиентами компании.

Интересно: Как релокейтить в Украину свою IT команду?

Договора на разработку программного обеспечения: их отличие от стандартных договоров о предоставлении услуг

Традиционно IT компании работают по договору Software Development Agreement  (Договор на разработку софта) или через договора услуг (Master Service Agreement, Service Agreement и тд.), в которых указаны общие условия сотрудничества и технические задания. 

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

Техническое задание (как неотъемлемая часть Договора услуг) Statement of Work (SoW) должно отображать ту модель, которую заказчик и разработчик выбрали для сотрудничества. 

Для каждой модели сотрудничества SoW должно содержать свои ключевые условия, без которых IT компания может потерять доход. 

Вот что SoW должно содержать, например, для моделей T&M и DT: 

• максимально детальное описание проекта (продукта), техническую его часть и условия оплаты;

• чек-лист результатов выполненных услуг, разработанного проекта или его части;

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

• состав команды (hard skills - профессиональные навыки каждого разработчика и их имена);

• права клиента на смену разработчика (за какой срок клиент предупреждает о желании заменить кого-то из команды, критерии замены, согласование проведения клиентского интервью);

• право сторон и порядок внесения изменений в уже начатый проект;

• порядок предоставления отчетов за выполненную работу, и затраты на их формирование;

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

• право или запрет на выкуп команды заказчиком тех разработчиков, кто работал над проектом (условия и цена выкупа такого заказчика);

• вовлеченность заказчика - порядок коммуникации с клиентом и включение его в процесс;

Как это бывает: допустим клиент иностранец (часовая разница 12 часов) - коммуникация с ним усложнится, если не будет договоренности когда он должен проверять мессенджеры. А это может негативно влиять на общий дедлайн проекта.

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

Договора с разработчиками: выбрать трудовой договор или Договор  с физическим лицом предпринимателем?

Работая с IT специалистами разработчиками, вам необходимо верно зафиксировать взаимоотношения с ними. Это можно сделать через трудовые договора, но большинство IT компаний в Украине предпочитают работать с разработчиками через договора гражданско-правового характера (ГП).

Плюсы работы с разработчиком по форме ГП как с ФОП - это уменьшение налоговой нагрузки и избежание бюрократии трудовых отношений. Но в выборе такой формы сотрудничества есть риски признания такого договора трудовым, и как следствие - доначисление налоговых обязательств и наложение штрафов. 

Критерии по которым Гоструда может признать договор с ФОП трудовым:

• в договоре описан процесс трудовой деятельности и ее организация;

• договор содержит правила внутреннего трудового распорядка;

• в договоре указана определенная квалификация, профессия, должность разработчика;

• разработчику гарнируют заработную плату, гарантии, льготы, компенсации.

Основные принципиальные отличия ГП договора от Трудового:

• в ГП Договорах должен отображаться  результат работы, а не процесс;

• разработчик несет ответственность за организацию своей работы по Договору, и выполняет ее на собственный риск;

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

Кроме все прочих контрактов, ИТ компании иногда используют  Invoice (инвойс) для прямой оплаты как аналог контракта, но мы не рекомендуем пользоваться такой формой договора, так как она не содержит всех его существенных условий.

Интересно: Как организовать договор публичной оферты?

Полный набор договоров, который понадобится IT компании для работы в Украине может состоять из 10-15, а то и больше позиций. Мы предлагаем оптимальное решение: разработку проектов всех нужных документов для работы компании.

Имея свои разработанные формы договоров, вы получите свой стандартизированный процесс работы. 

Вы хотите быть полностью готовы и защищены при ведении бизнеса в сфере IT в Украине? Обращайтесь к нам! Мы поможем как с разработкой нужных договоров, так и с решением более крупных юридических вопросов. 

Не нашли ответ на свой вопрос?

Все о деятельности IT компаний в Украине тут.