Посмотрим правде в глаза, большинство программистов, разработчиков и программистов вообще ненавидят думать об административной стороне нашего бизнеса. Тем не менее, чтобы функционировать, мы должны заниматься такими вещами, как бухгалтерский учет, выставление счетов и другие душераздирающие администрирования, которые удерживают нас вдали от нашего (надеюсь, гораздо более приятного) оплачиваемого времени.
Все эти элементы практически не связаны с разработкой и могут быть изучены или усвоены лучшими практиками Google. Но я всегда чувствовал, что контракты, по которым мы работаем, отличаются в том смысле, что они должны быть более специализированными, чтобы отражать особенности нашей среды.
Таким образом, в годы стартапа я потратил много времени, собирая различные передовые юридические практики, языковые фрагменты, собственные идеи / мнения и, вероятно, слишком много посторонней информации в гигантский магнум-опус рабочий контракт. (Поверьте мне, я просмотрел все виды исходных материалов. Я даже нашел опечатку в условиях использования YouTube, которая сохраняется и по сей день - факт, который мне почему-то кажется забавным.)
Я начал использовать свой контракт не только как обязательный документ между моей компанией и моими клиентами, но и как обучающий инструмент для клиентов. Так что он довольно длинный, но и обстоятельный.
Клиенты - даже опытные руководители компаний - обычно не понимают нюансов технологического ландшафта так, как это понимают программисты. Они говорят такие вещи, как будто хотят «владеть» каждой строчкой кода на веб-сайте, даже не учитывая, что это означает (особенно, когда, например, вы используете библиотеки с открытым исходным кодом и CMS).
Конечно, как и многие другие программисты, я не юрист. С точки зрения закона мой контракт мог бы быть полным мусором. То есть, я не думаю, что это так (и, к счастью, у меня нет записей о судебных делах, чтобы проверить это !). Но это, по крайней мере, подкреплено тоннами исследований, изрядным количеством юридических волшебств, усвоенных осмосом фактической работы над публикациями по договорному праву, резкими, но конструктивными отзывами клиентов, которые являются юристами, и, наконец, лучшими намерениями (с которыми, по общему признанию, дорога в ад вымощена).
Получить документ
📁 Вы можете прочитать (и можете свободно разветвлять, копировать, изменять, хвалить, осуждать) точный документ, который я использую, по этой ссылке. 📁 (Никакой рекламы / всплывающих окон / раздражающих странностей - только точный текст, который я использую на странице, где он находится.)
Примечания, квалификаторы и отказ от ответственности
Опять же, я не юрист. Итак, если вы используете это, вы, как и я, сами по себе. Самое главное, я считаю это живым документом. Когда я вижу вещи, которые, как мне кажется, являются хорошей идеей или которые следует включить, я делаю это. Если я вношу существенные изменения, мне нравятся крупные игроки, и я предупреждаю своих «пользователей» (клиентов) о таких изменениях. Если изменения несущественны, я просто вношу их, никого не предупреждая. Пункт № 8 объясняет этот подход. Тем не менее, я считаю, что следующие моменты особенно заслуживают обсуждения.
Общая структура. Я попытался смоделировать это в соответствии с общей структурой юридических договоров. Надеюсь, он содержит все необходимые разделы или пункты, которые необходимы контракту для того, чтобы он был обязательным.
Раздел 1. Срок. Я много думал об этом, так как в большинстве контрактов есть срок. Программистам нравятся границы, но им также нравятся динамические сценарии. Итак, я сказал, что отношения длятся один год, и после этого любая работа, которую мы выполняем, считается продолжением этого. Мне кажется разумным.
Раздел 2: Обязанности. Именно здесь находятся объем и сроки. Здесь я намечаю, какая работа и когда будет выполнена. Затем я вставляю его в эту область. Для более крупных проектов это может занять много времени. Или это может быть просто «Предоставлять текущие консультации по назначению». В любом случае, работает хорошо.
Раздел 3: Сборы. Это, вероятно, то, что вы, вероятно, захотите сильно настроить, так как он хорошо отражает мои собственные процессы, в частности, в отношении разработки веб-сайтов. Но прочтите это внимательно, так как он включает в себя значительные мысли и передовой опыт. По умолчанию в этом документе ничего не живет - такие детали, как указание на то, что суммы указаны в долларах США, на самом деле целенаправленно включены.
Также обратите внимание, что я не всегда включаю все из этих элементов в каждый контракт. (Например, если это работа не с фиксированной оплатой, эта часть не отображается для этих клиентов.) То, что вы видите, - это страница, созданная для отображения всех возможных положений. Я на самом деле разработал небольшую систему, чтобы сделать все это гибким.
Раздел 4: NDA. Я считаю, что лучше всего иметь положение о неразглашении. Обычно с этим ко мне обращаются и более крупные клиенты. Но я давно чувствовал, что чем более открытый и честный клиент будет со мной, тем лучше будет успех проекта. В этой статье я подробнее расскажу о моих необычных мнениях:
Раздел 5. Вот пример того, что я называю обучением клиентов. Здесь я немного подробнее объясняю клиентам, с чем они соглашаются в документе, а что выходит за рамки. Однако обратите внимание, что этот раздел сильно адаптирован к моему собственному взгляду на то, как я подхожу к таким вещам, как IP. Как мелкий игрок, я не хочу заниматься управлением правами на неисчислимые десятки тысяч строк кода для нескольких сотен клиентов. Ваша точка зрения может сильно отличаться от этой точки зрения.
Например, в пункте «Код» Благодарности → Новый код указано, что «Для любого нового кода, разработанного Консультантом… Консультант настоящим предоставляет Клиенту, и Клиент настоящим принимает неограниченное, неограниченное, бесплатное, полностью оплачиваемое, всемирное и неисключительное использование (если такие права не указаны иначе в рамках работы) ».
Это удобный способ сказать «Я могу делать все с кодом, и вы тоже можете». (Думаю, я давно уловил этот язык из примера Я видел на BoingBoing, вероятно, опубликованный Кори Доктороу.)
Обратите внимание, что только потому, что у меня есть доступ к их коду (который я написал), я все еще связан NDA и нормальной этикой. Итак, я не могу раскрывать секреты конкуренции или какую-либо конфиденциальную информацию или процессы (хотя я бы не стал!). Но если я написал, скажем, метод взаимодействия с базой данных, я могу повторно использовать его в другой работе с клиентами - точно так же, как я, вероятно, использовал ранее изученные инструменты и практики в текущей работе.
Программисты со временем накапливают навыки, и я считаю, что мы должны иметь возможность повторно использовать эти навыки, пока мы сохраняем этические нормы. Но точки зрения на этот элемент будут сильно различаться - от положений о том, что клиент «владеет» всем кодом, до положений, которые делает консультант и просто передает его клиенту по лицензии.
Я не утверждаю, что мой подход («Я могу делать все с кодом, и вы тоже») лучший - просто это то, что лучше всего работает для меня.
Разделы 6–10. Все это довольно шаблонные / рутинные вопросы, которые вы найдете в большинстве контрактов. Я настроил их так, как мне казалось, лучше всего отражает мой бизнес.
Раздел 11. Я считаю, что это ключ к контракту на разработку по нескольким причинам. Во-первых, юридическое определение «как есть» предлагает значительную защиту программистам, большинство из которых представляют малый бизнес. Я попытался придумать как можно больше сценариев возмещения убытков в наихудшем случае для большей части этой части ВСЕГО ЗАГЛАВНЫМИ буквами, собранных из множества примеров документов, которые я изучал. Как ни странно, ни один из них не включал гонорары адвоката в этот раздел, поэтому я добавил это.
Раздел 12. Чтобы показать пример продолжающегося развития этого, я только что добавил слово «наводнение», обдумав это с только что произошедшим ураганом Харви.
Раздел 20. В рамках моей работы над публикацией о договорном праве много лет назад я узнал, что для того, чтобы договор был надежным, он действительно должен отражать мысли обеих сторон. Многие контракты, которые не позволяют вести переговоры, очевидно, не имеют юридической силы - например, когда вы записываетесь в тренажерный зал или что-то в этом роде, и вам нужно подписать договор« возьми или оставь (он же договор о присоединении ). Поэтому в этом разделе я помещаю положения, с которыми я согласен с клиентом. Обычно это означает, что у нас есть предварительный NDA. В других случаях клиент может захотеть что-то, что противоречит некоторым стандартным положениям в документе. В этом случае я бы описал эти уступки или изменения здесь.
Печать / подпись
Как только я записываю подробные данные для каждого клиента (обычно элементы в желтых областях), я назначаю им код доступа. Затем они могут получить доступ к своей индивидуальной итерации контракта, используя свой код на странице, которую вы видели, когда взяли текст. После этого у нас обычно есть несколько встреч, пока они не будут готовы подписать.
Я упоминаю это здесь только потому, что хотел напомнить людям, что вы действительно можете адаптировать CSS для печати (вот старый, но актуальный ресурс). Итак, если вы пошли распечатать страницу, которую я показал, вы заметите, что она распечатывается очень хорошо.
Отзыв очень ценится!
Я всегда в поиске предложений по улучшению с любой точки зрения - с юридической точки зрения, других программистов / разработчиков или просто с коммерческой обратной связью. Так что, если у вас есть идея по улучшению этого документа, прокомментируйте. Я с нетерпением жду дальнейшего развития этого документа.
✍🏻 Джим Ди ведет свой личный блог Хоторн Кроу и блог веб-дизайна « Веб-дизайнер | Журнал веб-разработчиков . Он также участвует в различных публикациях Medium.com. Найдите его на JPDbooks.com, на его странице авторов Amazon, Facebook, Twitter, Instagram, LinkedIn, Medium или по электронной почте на сайте Jim [at] ArrayWebDevelopment.com. Его последний роман CHROO доступен на Amazon.com. Если вам нравятся юмористические литературные сказки, возьмите копию!
