Необходимый минимальный контракт кейс на начальном этапе
Открывая новый стартап, каждый знает, что существуют «подводные камни», о которых все подозревают, но мало кто задумается. Одним из таких «камней» является игнорирование или экономия на юридических аспектах, а ведь они по сути не менее важны, чем сама идея проекта и его реализация.
Все просто. Если не оформить правильно права на продукт, то продукта можно с легкостью его лишиться или не правильно выбранная схема оптимизации налогов, просто съест всю прибыль. Да, и без надлежащего оформления компании и её активов, не получится говорить с инвесторами и «ангелами» о привлечении денег или удачном экзите. Потому что они всегда имеют огромный штат юристов, который может зарубить любую сделку, не позволяя купить «воздух» своему руководителю.
На этапе зарождения и становления необходимо обратить внимание на следующие моменты. Во — первых, это оформление компании и сотрудников/партнеров, а также разработка схемы работы. Во-вторых, создание контракт-кейса.
В этой статье мы рассмотрим, именно ключевые моменты контракт — кейса и что необходимо в него включить, а вот оформление компании, разработку схемы работы и выбор юрисдикции, рассмотрим в следующих статьях.
Зачем мне готовить документы, если я могу скачать их в интернете?
Многие начинающие стартаперы, редко сталкивались с необходимостью юридического оформления каждого своего шага. Если это выходцы из тех.специалистов, то почти все документы им уже предоставили юристы. Но когда открываешь свой проект, то рассчитывать стоить только на себя, у тебя нет за спиной юридического отдела и корпоративный юрист уже не подскажет.
Под термином контракт — кейс, в этой статье мы будем подразумевать необходимый минимум документов. Однако, чаще всего IT компании делятся на два типа, продуктовые и аутсорсовые. У них есть как общие, так и различные виды документов.
Объединяет, продуктовые и аутсорсовые компании, внутренние документы. К ним относятся договора с разработчиками, дизайнерами и любыми специалистами, связанными с созданием интеллектуального продукта. Имейте ввиду, что в мире принята презумпция авторства, то есть, результатом работы, владеет автор, а не компания на которую он работал. Поэтому, дабы не втягиваться в долгие судебные тяжбы, необходимо сразу прописать, что вся созданная интеллектуальная собственность (программный код, дизайн, контент и т.д.) в рамках выполнения трудовых или договорных обязательств, безусловно и в полном объеме, переходят работодателю/заказчику. Это необходимо оформить как пункт в трудовом договоре или если вы работаете без оформления трудовых отношений, в отдельном документе. Но настоятельно рекомендую, не качайте шаблон из интернета, лучше потратить 50 долларов на создание драфта у юриста. Это позволит сэкономить вам кучу времени и нервов.
Также не забываем об ещё одном важном документе — соглашение о не разглашении. Ведь в IT бизнесе огромную роль играет, кто первый запустится, если у вас идея на миллиард, то точно не стоить рисковать. Как показывает история Марка Цукерберга, даже миллиардеры воруют. На практике сам договор у меня занимает всего 8 страниц, но вот приложение с перечнем, что попадает под термин «конфиденциальной информации» более 10. Также с каждым сотрудником устанавливается индивидуальный размер ответственности, но в среднем это годовая зарплата сотрудника плюс компенсация прямых убытков и утраченной прибыли. Но все же в этом вопросе стоит знать меру. Больше чем у человека есть, он не заплатит и суд это понимает. И как бы вы не хотели, суд не пойдет на то, чтобы делать из человека бомжа.
Внешние договора — вообще заслуживают отдельной статьи, но мы постараемся лаконично и по сути описать их ниже.
Поделим их условно на те, в которых мы оказываем услуги и там, где услуги оказывают нам. Основные драфты, которые должны у вас быть, это договора на оказание услуг. Обратите внимание, на тот момент, что в случае, если вам пишут софт или делают какой-либо интеллектуальный продукт, то все права на него должны переходить именно к вам. А не просто право его использовать, это обязательно нужно отразить в тексте договора. Обязательно, как можно детальнее описывайте, что именно вы покупаете, вообще ТЗ должен быть как приложение.
Если вам пишут софт, то должен быть оговорен период на тест и выявления «багов». В настоящее время исполнители не гнушаются срывать и затягивать. Для предупреждения этого прописывайте четкие временные рамки с конкретными датами. И тем более, если это поэтапная сдача проекта. Уточняйте каким образом передается результат работы (на физическом носители или посредством онлайн-передачи), и мотивирующую часть: ответственность, штрафы, и т.д. Но не переусердствуйте, так как явно завышенные штрафы, суд может порезать, как нарушение равенства сторон.
Отдельно стоить упомянуть СЕО.
Абсолютное большинство исполнителей в своих договорах на продвижение, указывают, что они не гарантирую результат. Поэтому настаивайте, на уточнении четких саксес-метрик, иначе можете лишиться денег и не получить результат.
В договорах по которым вы оказываете услуги, мы сейчас не об публичных офертах, о них напишем отдельную статью, главный акцент сделайте на обязанностях заказчика. К примеру, предоставлять информацию в указанный сроки и способ, утверждать дизайн, установив лимит на переделку и прочее. Всё, что вам необходимо от него, опишите, а также укажите, как именно заказчик должен вам передавать эту информацию. Помните и о ТЗ, оно должно быть полным и четким, никакого двоемыслия или недосказанности. В любых спорах — это будет ваш главный аргумент!
Чтобы не лить воду, подытожим. Первое, у вас под рукой должны быть трудовые договора и договора конфиденциальности, которые часто подписывают просто как с физическим лицом ещё на этапе собеседования, а также минимум два вида договора на оказание услуг, где вам оказывают или где оказываете вы. Второе, скупой платить дважды, если не деньгами, то временем и нервами, поэтому — закажите индивидуальные драфты и всегда настаивайте на них. О причинах, я писал в предыдущей статьи. О дальнейших юридических нюансах с которыми сталкивается IT расскажем в следующих статьях.
© Megamozg
