Чек-лист как оформить трудовые договоры с разработчиками или как не сойти с ума вводя режим служебных произведений
Мы много раз писали, что одной из больших проблем IT является нежелание правильно оформлять права на разработки.
А ведь это реальные риски, которые потом мешают получать инвестиции, вносить ПО в реестр отечественного ПО и становится причиной конфликтов внутри коллектива.
Но поговорив с большим количеством предпринимателей мы поняли причину – все боятся погрязнуть в бумажных процессах и бюрократии.Мы составили понятный алгоритм, который поможет все правильно оформить и не потратить тонны бумаги и время.
Когда нужно этим заняться
Чаще всего предприниматели начинают заниматься оформлением, когда появляется внушительный штат разработчиков (тех, кто внутри компании работает на трудовых контрактах).
До тех пор пока в штате 1-2 человека, а остальная команда на ГПХ как СМЗ или ИП считается, что нет смысла заниматься я введением в компании каких то процессов.
На самом деле это не так. Если начинать заниматься оформлением спустя время, то нужно:
1. Оформить задним числом то, что уже создано. А это не всегда просто (кто-то уволился, кто-то отказывается подписывать).
2. Ввести процессы для большой команды.
Если же вводить порядок работы с самого начала, то при увеличении команды нужно будет его лишь соблюдать.
Зачем
Зачем оформлять должно быть понятно) Задача получать от сотрудников исключительные права на то, что они создают (будь это тексты, картинки или код).
К сожалению одного факта работы сотрудника по трудовому договору недостаточно для передачи прав. Мы ранее описывали реальный кейс, когда компания выплатила разработчику компенсацию на 700 000 руб. Читайте подробнее
Мы не раз писали о том, что важно правильно оформлять отношения с разработчиками в компании. Среди прочего всегда много споров возникает вокруг рекомендации «выплачивать вознаграждение за отчуждение прав на созданные разработки отдельно от зарплаты». Противники такого подхода ссылаются на то, что заработная плата включает в себя и все и ничего…
Что делать
Самое важно правило – понять как фактически работает команда разработки и положить это на «бумагу».
Поэтому определитесь:
- как разработчики ставят задачи и обсуждают их;
- как передают результаты работ
Также будет важно периодически сверяться-:
какие объекты стоят в плане на разработку;
- что будете ставить на учет как НМА;
- что из разработок коммерциализируете;
- получаете ли налоговые льготы, связанные с использованием НМА
Вводим режим служебных произведений
Шаг 1 Разработать Положение о служебных произведениях.
Это основной документ, который будет регулировать порядок создания служебных произведений (т.е разработок, которые создаются работниками в рамках своих должностных обязанностей).
В Положение нужно включить:
- кто из сотрудников создает результаты интеллектуальной деятельности (проверьте по штатному расписанию кто может что-то создавать);
- как ставятся служебные задания (тут опишите как реально ставятся задачи. Например, если разработчики коммуницируют через Trello или Jira , то пусть эта переписка и будет служебными заданиями);
- как передаются созданные разработки. Тут тоже описывайте порядок, применяемый фактически – в какой репозиторий все складывается.
Шаг 2 Ознакомьте с Положением всех работников. Новые работники должны быть ознакомлены с Положением в момент заключения трудового договора.
Проверяем трудовые договоры
Шаг 3. В Положении вы указали сотрудники на каких должностях могут создавать результаты интеллектуальной деятельности.
В договорах на эти должности нужно зафиксировать:
- что в должностные обязанности входит создание РИД (только тогда созданное будет считаться именно служебным произведением);
- размер вознаграждения, которое выплачивается работнику за отчуждение прав на созданное. Об этом поговорим ниже, но главное запомните – это не может быть заработной платой.
Должностные инструкции
Шаг 4. Если должностная инструкция есть, то в ней можно детализировать какие именно РИД создаются.
Акты
Шаг. 5 Мы все привыкли, что при создании чего то нам важно две контрольные точки:
- идентификация объекта (в нашем случае это постановка служебного задания);
- факт передачи объекта. И вот это факт принято фиксировать актом.Но когда разработка это постоянный непрерывный процесс и особенно, когда в компании создается одновременно несколько объектов составлять акты крайне затруднительно.
Нужно понять:
- кто и что делал;
- положить это на бумагу;
- потратить время на составление;-
все подписать (особенно сейчас, когда большая часть работает вне офиса).Поэтому лучше фиксировать в Положении, что фактом передачи является фактическая передача.
Тут важно определить что это:
- направление кода в репозиторий;
- отчет и результат по электронной почте и тд
Для передачи прав этого будет достаточно.
Но возникает вопрос с бухгалтерией – именно ей нужны акты. Возможные варианты опишем ниже.
Выплаты
Шаг 6.
1. Выплата за отчуждение прав должна быть отдельной от заработной платы. Т.е нельзя писать в трудовом договоре, что зарплата 100 руб. и туда включено все.
2. Размер выплаты может быть любым и определяется трудовым договором.
3. Базой для выплат может быть конкретный объект. Например «1 картинка – 1 руб». Но для разработки это практически нереально (придется вычленять объекты, а это занимает время). Поэтому еще один вариант определить размер вознаграждения за конкретный период.
Постановка в качестве НМА
Если вы прошли все шаги, то права на разработки вы получили. Постановка в качестве НМА для принадлежности прав не важна. Но есть ряд причин по которым постановка важна:
- если вам важна капитализация компании или важно показать затраты на разработки;
- вы планируете отчуждение прав впоследствии;
- вы используете льготы в IT
Чтобы поставить на учет НМА нужно собрать затраты на его создание (прежде всего это заработная плата). Для этого бухгалтер должен знать:
- чью зп собирать на эти затраты (т.е кто принимает участие в разработке).
- что ставить на учет (описание объекта);
- когда ставить (т.е в какой момент разработка закончена).
Для определения этого бухгалтер может использовать:
- Акты, которые составляются ежемесячно из и которых видно кто из сотрудников что делал. На практике при масштабной разработке составление актов становится проблемой;
- Приказы о начале и окончании разработки, которые в том числе фиксируют кто был занят в этих разработках.
Процессы
Если у вас будут меняться:
- порядок постановки задач;
- репозиторий;
- перечень должностей
важно оперативно менять описание в документах.
Вывод
Вывод довольно простой:
1. Чем раньше начнете все правильно оформлять – тем меньше затрат и рисков нести;
2. Оформление должно быть на основании уже существующих процессов – тогда их будут соблюдать
Если у Вас есть вопросы по оформлению и использованию прав на разработки – пишите.