Нехорошая ситуация с Nginx — даёт повод вспомнить другие кейсы про неприятности при работе с командами проектов, тем более что исправлять ошибки в оформлении команд — намного сложнее чем ошибки в коде. (кейсы идут — не по «важности» а в порядке вспоминания)
NDA&NCA (Non-Disclosure & Non-Competes agreement)
Стандартная, как правило бессмысленная бумага, скачанная девочкой-юристкой из сети, и кидаемая в общую кучу бумаг на подпись при приёме новых разработчиков. В 99% случаев — никем и никогда после подписания не читается. Но в оставшемся 1% — может вызвать проблемы.
Например, у разработчика в NDA и в служебной инструкции может быть написано: "запрещается обеспечивать доступ к служебной информации посторонних лиц". (это — конкретный кейс) Если бы там было написано: "запрещается передавать", вопросов бы — не возникало. Но написано то, что написано. При этом сам разработчик — может сидеть в общем зале, а монитор у него может стоять "лицом" к проходу, и быть виден всем мимо проходящим. И/или ему каждый раз необходимо отправлять документы на печать на общий принтер.
В результате, в один прекрасный (но не для него) день у него на входе в офис — не сработает брелок-пропуск, после чего охрана вынесет ему коробку с его любимым кактусом (и сменными тапочками), и даст на подпись приказ об увольнении по «однократному грубому нарушению трудовых обязанностей» в виде "нарушения должностной инструкции" и "разглашения служебной информации" (при заказной разработке — контракт, при оформлении — Ст.81 п.6В Трудового Кодекса). Если менеджеры всё оформят правильно, оспорить это будет невозможно…
Впрочем, в эту игру — можно играть и вдвоём. Если разработчик твёрдо решил уходить, или он как в случае Nginx (насколько можно судить по ситуации) на работе пилит свой проект, тогда он — может взять карандашик, и внимательно прочитать что же написано в этом NCA скачанном девочкой-юристкой из нета NDA&. После чего — накатать служебку о том, что он категорически не может выполнять выдаваемое ему задание, в связи с непредставлением ему работодателем или заказчиком условий, прописанных в инструкции и NDA, и необходимых для выполнения требований безопасности.
Весь цимес ситуации состоит в том, что уволить его за такой отказ — нельзя, и зарплату (ставку/повременную) ему будут вынуждены платить до тех пор, пока или не предоставят ему необходимые условия; или не переведут на проект, не требующий работы с закрытыми данными; или же не договорятся с ним об отступных. Это именуется "Итальянской забастовкой" ("Формально не прекращая работу, работники парализуют её бессмысленными требованиями неукоснительного соблюдения всех предписанных им формальностей.")
При этом, если разработчика нанимают не на проект, а в штат (по трудовому), тогда его найм (и начисление фиксированной ставки) — начинается и исчисляется с даты договора, а не с даты фактического начала работы.
Кейс: При приёме, паре разработчиков — дали подписать стандартную пачку бумаги (трудовой, должностную инструкцию, штатное расписание, NDA&NCA, технику безопасности, и т.д.), которую они вроде бы всю подписали.
Так как людей набирали много, проверку и разбор всех бумаг — делали на следующий день, в который выяснилось, что что-то подписано по два раза, а что-то пропущено. Со всеми остальными людьми всё быстро исправили и пропатчили, а эта пара, за ночь — видимо передумала, и начала что-то мутить.
Но менеджеры были уже опытными, поэтому аккуратно (но быстро) у них всё забрали, и аккуратно (но быстро) выставили их за дверь. А в должностную инструкцию секретарше конторы, крупным шрифтом — приписали пункт, о том, что она сначала проверяет подписи на всех остальных документах, и только потом штампует печатью непосредственно сам трудовой договор (который тут же прячет в сейф, выдавая страждущим ксерокопию).
Но лучше всего конечно — оформлять всех, кто работает по трудовому на отдельную, специально для этого созданную контору, возможные последующие неприятности которой — не завалят работу по остальным проектам.
Особым пунктом NDA — надо прописать взаимодействие разработчиков с представителями заказчика (если таковое предполагается). Нужен список материалов которые разработчик не должен передавать, и список вопросов, на которые он не должен отвечать.
Кейс: Разработчик отослал заказчику в тех.службу промежуточную версию куска системы, с заглушками. Там посмотрели и запросили пару модулей которые должны были стать вместо заглушек, и находившихся на промежуточной стадии. Он их им и отослал.
Эти модули — делались на большом инструментальном пакете, который в промежуточные версии записывает свои логи. При сдаче проекта, весь этот мусор естественно вычищается, но он чистится руками, поэтому в рабочих версиях его не трогают. Тех.служба заказчика — увидела серийники и логи, и передала их своему начальству, начальство — связалось с производителем пакета, который сообщил, что этот экземпляр пакета, в РФ — не поставлялся. Было много шума и гама.
На другом проекте, разраб — три дня устанавливал и настраивал пакет у заказчика, где были юные и восторженные девушки, которым он с высоты своей великой мудрости поведал, что боятся им нечего, так как большая часть этого пакета — уже успешно работает у предыдущего заказчика. Клиент позвонил и поинтересовался, почему с него взяли полную цену за то, что до этого уже было кому-то продано. Отделались мелким скандалом. Но если бы клиент вдруг связался с первым, и намного боле важным заказчиком, проблемы — были бы намного большими.
Первая проблема с ком.тайной состоит в том, что никакой коммерческой тайны в РФ — нет. Закон 2004 года о ком.тайне, это — калька с закона о гос.тайне, и в нём всё привязано к материальному носителю, без наличия которого все действия и процедуры — не работают. Поэтому если в компании нет "секретной" комнаты (с плотно занавешенными окнами), прошнурованного журнала посещений, и прочих голливудских страстей, тогда этого режима — нет, и все слова про "секретные сведения" и "закрытую информацию" — имеют чисто психологическое значение, и в реальном и серьёзном инциденте никакого значения иметь — не будут.
Вторая проблема с ком.тайной состоит в том, что пока в конкретно инциденте нет доказанного, то есть должным образом задокументированного факта передачи, то есть конкретного действия какого-то лица по получению передаваемого (или нет собственноличного признания нарушителя), никакого нарушения — нет. Ещё раз: для "передачи" — необходимо не только "отдание", но и "принятие", нет получения — нет и передачи (то есть размещение в интернете "для всех" — не есть "передача").
Однако это компенсируется возможностью внутрикорпоративной фиксации факта нарушения должностных инструкций (логи сервера, правильно оформленная видео-запись с внутренних камер, и т.д.). А после фиксации — уже возможны выговор, лишение премии, и увольнение уже по обычной трудовой статье, или, если оформление было не по трудовому, а по разовому заказу — по грубому нарушению контракта (но тогда надо смотреть что было написано в контракте).
Кейс: Если в контракте или трудовом указана конкретная сумма заработной платы, уменьшить её штрафами — предельно сложно (транзакционные издержки — кратно превысят размер удержанного) зарплата сотрудников — даже не включается в конкурсную массу при банкротстве. Но если там указана базовая ставка, а за например соблюдение режима защиты информации положена премия, тогда при нарушении этого режима, снять премию (точнее не назначить) — будет намного легче. Если на проект набирается достаточно пёстрая команда, из лиц раньше вместе не работавших, тогда оформление всех по одному и тому же трудовому/контракту, с общими для всех условиями — верный путь к провалу проекта. Условия найма и оформления Junior-а и Lead-а — не могут быть одинаковыми. (если джиниор не в штате, а например на испытательном, тогда никакой ком.тайны у него — вообще быть не может)
И наконец третья проблема с ком.тайной состоит в том, что если этот режим будет в компании реально установлен, компания — не сможет работать. Речь идёт — не про "Итальянскую забастовку", а про несогласованность бизнес-процессов.
Кейс: Разработчику — нужно было утвердить макеты страниц заказного сервиса у заказчика, а девочка-юристка, на весь продукт до даты сдачи/принятия — поставила гриф "ком.тайны". И разработчик — спрашивает: "А как же мне их тогда заказчику переслать?". Занавес.
Патч: Что-бы не ковыряться в местных российских законах, и российской же судебной практике (которая во первых отсутствует (из-за отсутствия в РФ механизма судебного прецедента), а во вторых вне РФ (для зарубежных заказчиков) не применима) в тех случаях, когда надо как-то закрыть ком.тайну, можно писать, что вся внутренняя информация — регулируется правилами ТРИПС (TRIPS (Agreement on Trade-Related Aspects of Intellectual Property Rights). Это — удобные, внятные и понятные правила действующие во всём мире (включая и РФ).
Патч 2.: Если заказчик, или кто-то из топов команды — из США, тогда вместо трипса — лучше сразу ставить "Defend Trade Secret Act" & "Economic Espionage Act" (американские законы про ком.тайну и ком.шпионаж). Это — не только сразу же даст "+100 к карме", но и резко снизит вероятность последующих недопониманий при приёме и оплате работы (заказчик — будет знать, что оформление команды делается грамотно, то есть люди — в теме, и просто так, их — уже не обманешь (даже если захочется)).
Проблема с ним в том, что последующее трудоустройство и работу нельзя запретить.
Запрет трудоустройства и работы — юридически ничтожен во всех странах. То есть написать его — можно, но никаких правовых последствий эти слова нести не будут.
Однако при этом, NCA/CNC — работает в иных конкретных случаях, а именно в случаях:
То есть, в первом варианте — взыскивается упущенная выгода, во втором — заключается свободный возмездный контракт со взаимными обязательствами сторон, а в третьем — взыскивается стоимость обучения (как при обычном целевом обучении, например в ВУЗе).
Кейс №1: С ключевыми разработчиками — заключались отдельные персональные контракты с указанием конкретных позиций в конкретных компаниях-конкурентах в которые сотрудник не может устроиться на работу и сроков (не более 4 мес.), прописывался запрет на открытие своего бизнеса и ИП по теме проекта, и по этим контрактам, в течении этих 4 мес. после увольнения — платились денежные компенсации (это — не зарплата (они — уже не сотрудники)).
Кейс №2: Под конкретного разработчика и конкретный проект — было приобретено дорогое рабочее место с дорогим пакетом (САПР), и его к трудовому контракту — оформили доп.контракт на компенсацию этих затрат в случае его досрочного ухода до завершения проекта.
Вещь — важная. Нужна для защиты от нарушения прав третьих лиц. Во первых — страхует от последствий использования информации (и нарушения NCA/CNC) с прежних (бывших до этого) мест работы, во вторых — страхуется притаскивание в компанию чужих (включая и свои собственные) проектов (кейс Nginx-а — наглядный пример).
Мы это поняли после двух неприятных инцидентов с удалёнными зарубежными фрилансерами, сливавшими в наши проекты (и наверняка ещё в несколько других) куски проектов с прежних мест работы (что выяснилось уже потом). Сама по себе расписка — естественно не препятствует притаскиванию в проект внешней грязи, но она нужна компании для подтверждения добросовестности (были приняты все необходимые меры предосторожности), и соответственно защиты от возможных последующих претензий третьих лиц.
В качестве замены (или дублирования) такой расписки, некоторые проекты — иногда превентивно вывешивают в сети информацию о приёме потенциально проблемных разработчиков (типа "в наш дружный коллектив наконец то влился ..."), но проще (и надёжнее) сделать явную бумажную расписку на три абзаца.
Были случаи, когда выяснялось, что разработчики использовали в коммерческих проектах свои собственные решения, описания или идеи которые они тем не менее до этого — "светили" в популярных нынче "хакатонах", и в заявках на конкурсы и гранты, о чём они руководителям проектов своевременно не сообщили. Однако во многих хакатонах, конкурсах и грантах — есть положения относительно прав организаторов-устроителей на последующее использование присылаемых материалов, как минимум в образовательных целях.
А например в описаниях яндексовских и сберовских хакатонов — напрямую указано о возможности изучении присылаемого материала на предмет применимости в бизнесе. Соответственно засвеченное таким образом решение, будучи реализовано в коммерческом проекте — несёт потенциальные риски. (Случай, когда разработчик тащит на хакатон кусок своего текущего проекта — подпадает под нарушение NDA (см. выше).)
Отдельным (и как это ни странно частым) случаем нужности расписки об отсутствии препятствий — являются ситуации, в которых разработчики — сами не знают (хотя — могли бы) о наличии у них подобных ограничений.
Кейс: В один из проектов, на ведущую позицию пришёл человек, незадолго до этого отработавший год по теме проекта в британском университете по гранту на научный обмен. До этого случая мы с подобными ситуациями не сталкивались, поэтому не обратили на неё внимания. Но потом зарубежный соинвестор проекта — объяснил нам что мы не совсем правы. Когда в самом университете взяли нужные документы, выяснилось, что у человека — действительно ещё не закончился "карантинный" год, прописанный и в грантовом контракте, и во внутренних документах университета. Причём условия там оказались намного более жёсткими, чем можно было ожидать.
Здесь — во первых ещё раз дублируется всё, что уже было в NDA&(NCA/CNC), но при этом применимо не только во время, но и в период после прекращения работы. Если есть проблемы с бумагой и принтерами, тогда этот запрет — можно "интегрировать" в текст основного NDA&(NCA/CNC). Однако экономия на трёх лишних абзацах — не стоит большого количества нервов и времени, необходимых на последующее длительное доказывание того, что "интегрированный" текст относится и ко времени работы по проекту, и ко времени после её окончания. Экономия одного листа бумаги таких рисков — не стоит.
Во-вторых, здесь (пусть всего одним, но важным абзацем) прописывается запрет на последующее распространение негатива о проекте/компании, а вторым — ситуации предъявления к компании судебных исков (и своих, и участие (соистцом) в чужих).
По первому пункту: Обязательство не говорить гадости о компании и проекте, взятое односторонне и самостоятельно, столь же односторонне и самостоятельно отменятся. Поэтому при увольнении — надо заключать контракт "о тишине", с взаимными обязательствами и выплатами компенсаций (в обе стороны).
По второму пункту: Обязательство "не подавать в суд" — юридически ничтожно, и не стоит бумаги, на которой написано. Патчится эта проблема — опять же контрактом с чёткими взаимными обязательствами и компенсациями/штрафами. В реальности, срока "тишины" в полгода — вполне достаточно. Это всё — выглядит страшно и монструозно, но в реальности — занимает четверть листа (правда мелким шрифтом).
Кейсов — море, но после Nginx-а — всё уже было обговорено сотни раз, и уже не нужно никому ничего объяснять.
Разве что стоит ещё раз повторить, что в контрактах на проекты, предназначенные для использования вне РФ — не стоит ссылаться на законы и юридические нормы права РФ.
Кейс: При работе по проекту — создано новое решение, которое подаётся на патентование. Сроки патентования в США например клиент-серверных решений — могут занимать до трёх лет, а архитектуры/весов/методик по нейронным сетям — до пяти лет (чем горячее тема, тем больше заявок, соответственно дольше сроки экспертиз). А к тому времени проект — уже давно закроется, и сам разработчик — не просто уволится, а уже успеет поработать в паре других проектов. А без его подписи некоторые вещи при патентовании сделать не получится. Поэтому, опять же — отдельный контракт, пусть и на 1/4 страницы. Естественно подписываемый строго до начала работы по проекту. (возможно — уже после принятия на работу по трудовому, или "рамочному" фрилансерскому, но — строго до начала проекта, в рамках которого и будет подаваться заявка)
Всё, что вставляется в проект откуда то извне — должно проверяться очень внимаетльно, и монтироваться (если без этого совсем уж нельзя) с возможностью быстрой замены или полного удаления (если нельзя быстро заменить).
Кейс 1. Разработчик, где-то на сайте для программистов — увидел решение, подходящее для проекта, и его в проект вставил. Выяснилось это уже незадолго до сдачи проекта. Потом этот кусок из проекта пришлось долго и нудно выпиливать.
Кейс 2. Разработчик — увидел полезное решение, опубликованное самим его (решения) автором. Автор — раздаривал решение всем желающим, так как патент на решение — уже прекратил действовать (по неуплате пошлины), а сама компания — находилась в процессе банкротства.
Кто успел воспользоваться этой щедростью — не известно, зато известно, что чрез полгода банкротство завершилось, а новая компания все патенты — восстановила.
Кейс 3. Разработчик — увидел вывеску "опенсорс", и набрал там полную тачку халявы.
Однако — не существует ни одной Open Software License, в тексте которой было бы слово "халява".
(Про ОпенСорс на Хабре — уже писали)
Опен-сорс, это — "открытый" исходный код, но это — не про деньги. В "свободной" лицензии — может быть указано: "Бесплатно только для использования в собачьих приютах", а в вашем конкретном случае, приют может быть — не собачьим, а смешанным (собаки и кошки), значит вы — вышли за рамки условий лицензии.
Для личного некоммерческого использования — можно использовать вообще всё что угодно, хоть запатентованное, хоть авторское, хоть ещё какое. Но как только софт даже абсолютно бесплатный (и уж тем более платный) будет по такой лицензии поставлен хотя бы на один ПК не-собачьего приюта — произойдёт нарушение условий лицензии, со всеми административными и уголовными последствиями. Нарушение условий лицензий опенсорс — очень частый кейс.
Полностью свободным — является только тот софт, идеи (способы работы) которого попали в общее достояние (патенты прекратились и не могут быть восстановлены), и текст исходника которого писал автор, умерший 70/75/80 (в разных странах по разному) лет назад. Во всех остальных случаях, у опенсорса — могут быть (и скорее всего есть) подводные камни. Ещё раз: "открытый" исходный код, это — не ничейный код.
Кейс 4. Разработчик — накачал модулей из "бесплатной" библиотеки интела для обработки изображений, и поковырявшись в коде, из их кусков соорудил пару своих блоков. Улучшил и оптимизировал. Однако интелловская "бесплатная" библиотека, это — отнюдь не "халява". У неё — очень чёткие и жёсткие условия использования. Блоки в проекте конечно оставили, но разработчика попросили больше так не делать.
Если разработчик сам что-то придумывает, это — очень хорошо. Проблема только в том, что если это смог придумать он, значит есть ненулевая вероятность того, что тоже самое (или нечто близкое), до него уже мог придумать и кто-то другой. А кто первый встал — того и тапки.
Соответственно это новое — надо занимать пока это не сделал кто-то другой. Что бы разработчик этим занялся (вместо сдельного кодинга), его — надо стимулировать или премиями (в рамках трудового договора), или дополнительными контрактами выплатами.
Если (на предыдущем шаге) была установлена новизна созданного решения, значит её — надо фиксировать. Или патентами, или (если до полноценного патента не дотягивает по новизне) хотя бы открытой публикацией (по принципу "Так не доставайся же ты никому!"). По практике, если в проектах инозаказчиков патентные заявки вообще не подаются (или прекращают подаваться), заказчики -начинают нервничать и проверять проект. Это — в лучшем случае. В худшем они думают, что этот код люди делают "за еду", и ставят ценник меньше индусов. Поэтому заявки, или как минимум хотя бы публикации (подойдёт любой публичный ресурс) — строго желательны.
Здесь, однако есть один важный и "чувствительный" момент. Разработчику — платят за код, а патент — достанется или заказчику, или компании. Соответственно, если разработчик перейдёт потом в другую компанию, он сам, это решение (где он автор) на своей новой работе, использовать — уже не сможет. Не сможет — не просто из-за неконкуренции (NCA/CNC), а из-за целого полновесного патента, автором по которому — является он сам. По этой причине, разработчики часто саботируют процесс подготовки и подачи патентных заявок, ссылаясь на загруженность по основному проекту. Патчится этот баг — отдельными контрактами и внятными выплатами премий по факту подачи заявок. (разборки по принадлежности патента между заказчиком и компанией — своя отдельная грустная песня)
С этим вопросом, почему-то всё время возникают какие-то сложности. Хотя вопрос — предельно простой. "Авторские права — не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач"
Ещё раз: на алгоритмы, форматы данных, способы работы и взаимодействие блоков, и т.д., и т.п., никаких авторских прав — нет. Всё это хозяйство (способы & устройства) — патентоспособная промышленная (но никак не "авторская") собственность (а после регистрации — "нематериальные активы").
Авторское право — распространяется только и исключительно на произведения литературы и искусства. При этом, само это "право" — состоит только и исключительно в праве называть себя автором текста. Никаких иных прав на использование этого текста, авторское право — не даёт. Всё — как в издательском деле, издательство — заказывает книгу, автор — пишет, имя автора — указывают на обложке, но сам текст — принадлежит издательству.
При этом, применение авторского права к программному коду — есть абсолютная глупость. Если в софтовом проекте просто переставить местами блоки кода, проект как литературное произведение — исчезнет, соответственно исчезнет и авторское право на него. Если код откомпилирован, тогда исходный "текст" — вообще исчезает. Юристы (как правило) — не пишут программ, не собирают пакеты из блоков, не тестируют их, и т.д., и т.п., и всего этого — не знают, поэтому всё время и пишут про "авторское".
Что касается т.н. "служебной" разработки. Обычно риски последующих разборок снимаются достаточно просто. Архитектура продукта или сервиса, и основные технические вопросы его построения и работы (пусть и с предварительной проработкой на уровне конечных исполнителей) — утверждаются на уровне руководства проекта, и оформляются в виде базового ТЗ, которое и передаётся в работу. В этом случае, все права — заземляются на уровне ТЗ, и риски возможных последующих претензий — снимаются (автор — тот, кто выдал ТЗ).
Кейс: Во многих действующих в РФ зарубежных центрах разработки — принято следующее правило. Если местные разработчики придумывают что-то новое — подаётся патентная заявка, первым автором в которой — всегда указывается иностранный сотрудник российского офиса. Это — снимает многие риски.
Практически вся российская софтовая разработка, идущая за пределы РФ — находится в "серой" зоне. При работе в интернете, и посредством интернета, государственная и таможенная границы РФ — проходят по поверхности монитора. Всё, что находится за ней — уже не совсем РФ. А часто — совсем не РФ. (облачные сервисы Амазона, или Гугла — гарантированно вне РФ).
Соответственно, если разработчик посылает файл проекта в соседнее здание, проблем — не возникает, но если он посылает этот файл например в США, тогда в момент нажатия им кнопки "отправить", файл проекта — одновременно пересекает и государственную, и таможенную границы РФ! Соответственно при пересечении первой границы — возникают риски "экспортного контроля", а при пересечении второй — таможенной "контрабанды" (разработчик же таможенную декларацию на передаваемый файл — не оформлял).
Поэтому, со всеми, кто в рамках работы по проекту будет или может контактировать с зарубежными адресатами — надо проводить инструктаж, и выстраивать схему работы, минимизирующую риски. (Патчится — созданием микро-компании в стране заказчика, а российский офис — оформляется как представительство, или сервисная служба.)
Уже было ранее, но ещё есть некоторые моменты. Много скрытых рисков находится в зоне взаимодействия разработчика с заказчиком при длительной сдаче проекта, и/или его техподдержке при дальнейшей эксплуатации. Если в компании вдруг есть своя внутренняя CRM-система, тогда в ней для подобных взаимодействий надо предусмотреть отдельный режим. Но в любом случае от клиента должна быть получена "бумага" о том, что действием исполнителя (то есть компании) считается только то, что исходит (или идёт с второй "подписью") от менеджера отвечающего за взаимодействие с клиентом.
Кейс №1: От клиента в США — был получен запрос на решение проблемы. Его с контактами сотрудника клиента переслали разработчику. Разработчик (чуть ли не через вотсап) связался с сотрудником, и через некоторое время прервал общение, попутно дав тому ценные сведения о его профессиональных и умственных способностях. Клиент — предъявил претензию в связи с якобы отказом в техподдержке.
Кейс №2: От клиента в США (уже другого) — был получен запрос на решение проблемы. Менеджер — передал его разработчику, и посчитав вопрос закрытым, поставил отметку об исполнении. Был конец рабочего дня, и разработчик подумал, что "завтра сделаем". Клиенту от откладывании — не сообщили. Сотрудник клиента в свой срок ответ не получил, и не смог решить уже свою задачу, о чём и сообщил наверх. Клиент — предъявил претензию в связи с нарушением тайминга техподдержки.
Если проект делается не для использования непосредственно самим заказчиком, а для (после настройки/дополнения/изменения) передачи третьим лицам, тем более физикам, тогда всё претензии этих лиц по пакету — клиент будет навешивать на исполнителя. Патчится — собиранием всех потенциально рисковых фич проекта в один перечень, и передача его клиенту "под подпись". Клиент просто ставит этот перечень в User Agreement своего пакета, и проблема решается (правда не всегда).
То же самое, что и в предыдущих пунктах, но относится к механизму оплаты. Если разработчикам (тем более фрилансерам) делаются счета на пейпеле или пейонере, проблемы которые могут возникнуть с одним из этих счётов/кошельков — не должны доставлять проблемы другим людям и проектам. А если людям оформляются личные карточки, привязанные к одной корпоративной офшорной, тогда на общем счёте — не должны одновременно скапливаться средства нескольких получателей.
Отдельно и особо надо отрегулировать вопросы перевода средств с безличных карточек и счетов на "белые" карточки сотрудников в банках РФ. Если разработчик снимет в банкомате средства с серой карточки, а потом тут же, в соседнем банкомате внесёт их уже на свой белый счёт, средства — "очищаются". Но если он в целях копеечной экономии на комиссии, перебросит безналом средства на свой личный например сберовский счёт — возможны последующие проблемы, которые могут ударить уже не по данному сотруднику а по остальным.
С налогами — аналогично. По хорошему, всех получателей зарплаты — надо разделить по степени риска от засветки платежей, и разным категориям — платить по разным схемам. До недавнего времени, для получателей в РФ — была удобна форма ИП, но сейчас транзакционные издержки по ней — стали неприемлемыми. (налоговая в любой момент может выставить ИП-шнику перерасчёт за прошлые годы, причём без пояснения и объяснений) Возможно удобной будет схема с т.н. "самозанятыми", но по ней пока очень мало информации.
Продолжение — следует.
"Соглашения о неразглашении и неконкуренции"
NDA&NCA (Non-Disclosure & Non-Competes agreement)
Стандартная, как правило бессмысленная бумага, скачанная девочкой-юристкой из сети, и кидаемая в общую кучу бумаг на подпись при приёме новых разработчиков. В 99% случаев — никем и никогда после подписания не читается. Но в оставшемся 1% — может вызвать проблемы.
Например, у разработчика в NDA и в служебной инструкции может быть написано: "запрещается обеспечивать доступ к служебной информации посторонних лиц". (это — конкретный кейс) Если бы там было написано: "запрещается передавать", вопросов бы — не возникало. Но написано то, что написано. При этом сам разработчик — может сидеть в общем зале, а монитор у него может стоять "лицом" к проходу, и быть виден всем мимо проходящим. И/или ему каждый раз необходимо отправлять документы на печать на общий принтер.
В результате, в один прекрасный (но не для него) день у него на входе в офис — не сработает брелок-пропуск, после чего охрана вынесет ему коробку с его любимым кактусом (и сменными тапочками), и даст на подпись приказ об увольнении по «однократному грубому нарушению трудовых обязанностей» в виде "нарушения должностной инструкции" и "разглашения служебной информации" (при заказной разработке — контракт, при оформлении — Ст.81 п.6В Трудового Кодекса). Если менеджеры всё оформят правильно, оспорить это будет невозможно…
Впрочем, в эту игру — можно играть и вдвоём. Если разработчик твёрдо решил уходить, или он как в случае Nginx (насколько можно судить по ситуации) на работе пилит свой проект, тогда он — может взять карандашик, и внимательно прочитать что же написано в этом NCA скачанном девочкой-юристкой из нета NDA&. После чего — накатать служебку о том, что он категорически не может выполнять выдаваемое ему задание, в связи с непредставлением ему работодателем или заказчиком условий, прописанных в инструкции и NDA, и необходимых для выполнения требований безопасности.
Весь цимес ситуации состоит в том, что уволить его за такой отказ — нельзя, и зарплату (ставку/повременную) ему будут вынуждены платить до тех пор, пока или не предоставят ему необходимые условия; или не переведут на проект, не требующий работы с закрытыми данными; или же не договорятся с ним об отступных. Это именуется "Итальянской забастовкой" ("Формально не прекращая работу, работники парализуют её бессмысленными требованиями неукоснительного соблюдения всех предписанных им формальностей.")
При этом, если разработчика нанимают не на проект, а в штат (по трудовому), тогда его найм (и начисление фиксированной ставки) — начинается и исчисляется с даты договора, а не с даты фактического начала работы.
Кейс: При приёме, паре разработчиков — дали подписать стандартную пачку бумаги (трудовой, должностную инструкцию, штатное расписание, NDA&NCA, технику безопасности, и т.д.), которую они вроде бы всю подписали.
Так как людей набирали много, проверку и разбор всех бумаг — делали на следующий день, в который выяснилось, что что-то подписано по два раза, а что-то пропущено. Со всеми остальными людьми всё быстро исправили и пропатчили, а эта пара, за ночь — видимо передумала, и начала что-то мутить.
Но менеджеры были уже опытными, поэтому аккуратно (но быстро) у них всё забрали, и аккуратно (но быстро) выставили их за дверь. А в должностную инструкцию секретарше конторы, крупным шрифтом — приписали пункт, о том, что она сначала проверяет подписи на всех остальных документах, и только потом штампует печатью непосредственно сам трудовой договор (который тут же прячет в сейф, выдавая страждущим ксерокопию).
Но лучше всего конечно — оформлять всех, кто работает по трудовому на отдельную, специально для этого созданную контору, возможные последующие неприятности которой — не завалят работу по остальным проектам.
Особым пунктом NDA — надо прописать взаимодействие разработчиков с представителями заказчика (если таковое предполагается). Нужен список материалов которые разработчик не должен передавать, и список вопросов, на которые он не должен отвечать.
Кейс: Разработчик отослал заказчику в тех.службу промежуточную версию куска системы, с заглушками. Там посмотрели и запросили пару модулей которые должны были стать вместо заглушек, и находившихся на промежуточной стадии. Он их им и отослал.
Эти модули — делались на большом инструментальном пакете, который в промежуточные версии записывает свои логи. При сдаче проекта, весь этот мусор естественно вычищается, но он чистится руками, поэтому в рабочих версиях его не трогают. Тех.служба заказчика — увидела серийники и логи, и передала их своему начальству, начальство — связалось с производителем пакета, который сообщил, что этот экземпляр пакета, в РФ — не поставлялся. Было много шума и гама.
На другом проекте, разраб — три дня устанавливал и настраивал пакет у заказчика, где были юные и восторженные девушки, которым он с высоты своей великой мудрости поведал, что боятся им нечего, так как большая часть этого пакета — уже успешно работает у предыдущего заказчика. Клиент позвонил и поинтересовался, почему с него взяли полную цену за то, что до этого уже было кому-то продано. Отделались мелким скандалом. Но если бы клиент вдруг связался с первым, и намного боле важным заказчиком, проблемы — были бы намного большими.
"Коммерческая тайна"
Первая проблема с ком.тайной состоит в том, что никакой коммерческой тайны в РФ — нет. Закон 2004 года о ком.тайне, это — калька с закона о гос.тайне, и в нём всё привязано к материальному носителю, без наличия которого все действия и процедуры — не работают. Поэтому если в компании нет "секретной" комнаты (с плотно занавешенными окнами), прошнурованного журнала посещений, и прочих голливудских страстей, тогда этого режима — нет, и все слова про "секретные сведения" и "закрытую информацию" — имеют чисто психологическое значение, и в реальном и серьёзном инциденте никакого значения иметь — не будут.
Вторая проблема с ком.тайной состоит в том, что пока в конкретно инциденте нет доказанного, то есть должным образом задокументированного факта передачи, то есть конкретного действия какого-то лица по получению передаваемого (или нет собственноличного признания нарушителя), никакого нарушения — нет. Ещё раз: для "передачи" — необходимо не только "отдание", но и "принятие", нет получения — нет и передачи (то есть размещение в интернете "для всех" — не есть "передача").
Однако это компенсируется возможностью внутрикорпоративной фиксации факта нарушения должностных инструкций (логи сервера, правильно оформленная видео-запись с внутренних камер, и т.д.). А после фиксации — уже возможны выговор, лишение премии, и увольнение уже по обычной трудовой статье, или, если оформление было не по трудовому, а по разовому заказу — по грубому нарушению контракта (но тогда надо смотреть что было написано в контракте).
Кейс: Если в контракте или трудовом указана конкретная сумма заработной платы, уменьшить её штрафами — предельно сложно (транзакционные издержки — кратно превысят размер удержанного) зарплата сотрудников — даже не включается в конкурсную массу при банкротстве. Но если там указана базовая ставка, а за например соблюдение режима защиты информации положена премия, тогда при нарушении этого режима, снять премию (точнее не назначить) — будет намного легче. Если на проект набирается достаточно пёстрая команда, из лиц раньше вместе не работавших, тогда оформление всех по одному и тому же трудовому/контракту, с общими для всех условиями — верный путь к провалу проекта. Условия найма и оформления Junior-а и Lead-а — не могут быть одинаковыми. (если джиниор не в штате, а например на испытательном, тогда никакой ком.тайны у него — вообще быть не может)
И наконец третья проблема с ком.тайной состоит в том, что если этот режим будет в компании реально установлен, компания — не сможет работать. Речь идёт — не про "Итальянскую забастовку", а про несогласованность бизнес-процессов.
Кейс: Разработчику — нужно было утвердить макеты страниц заказного сервиса у заказчика, а девочка-юристка, на весь продукт до даты сдачи/принятия — поставила гриф "ком.тайны". И разработчик — спрашивает: "А как же мне их тогда заказчику переслать?". Занавес.
Патч: Что-бы не ковыряться в местных российских законах, и российской же судебной практике (которая во первых отсутствует (из-за отсутствия в РФ механизма судебного прецедента), а во вторых вне РФ (для зарубежных заказчиков) не применима) в тех случаях, когда надо как-то закрыть ком.тайну, можно писать, что вся внутренняя информация — регулируется правилами ТРИПС (TRIPS (Agreement on Trade-Related Aspects of Intellectual Property Rights). Это — удобные, внятные и понятные правила действующие во всём мире (включая и РФ).
Патч 2.: Если заказчик, или кто-то из топов команды — из США, тогда вместо трипса — лучше сразу ставить "Defend Trade Secret Act" & "Economic Espionage Act" (американские законы про ком.тайну и ком.шпионаж). Это — не только сразу же даст "+100 к карме", но и резко снизит вероятность последующих недопониманий при приёме и оплате работы (заказчик — будет знать, что оформление команды делается грамотно, то есть люди — в теме, и просто так, их — уже не обманешь (даже если захочется)).
"Соглашение о неконкуренции" (NCA/CNC)
Проблема с ним в том, что последующее трудоустройство и работу нельзя запретить.
Запрет трудоустройства и работы — юридически ничтожен во всех странах. То есть написать его — можно, но никаких правовых последствий эти слова нести не будут.
Однако при этом, NCA/CNC — работает в иных конкретных случаях, а именно в случаях:
- предотвращения нанесения компании ущерба путём несанкционированного использования сотрудником служебной информации после увольнения;
- несанкционированного раскрытия и распространения сотрудником технологического опыта компании;
- умышленного нанесения компании ущерба путём отказа сотрудника от трудовой деятельности после оплаченного компанией внешнего или внутреннего корпоративного обучения.
То есть, в первом варианте — взыскивается упущенная выгода, во втором — заключается свободный возмездный контракт со взаимными обязательствами сторон, а в третьем — взыскивается стоимость обучения (как при обычном целевом обучении, например в ВУЗе).
Кейс №1: С ключевыми разработчиками — заключались отдельные персональные контракты с указанием конкретных позиций в конкретных компаниях-конкурентах в которые сотрудник не может устроиться на работу и сроков (не более 4 мес.), прописывался запрет на открытие своего бизнеса и ИП по теме проекта, и по этим контрактам, в течении этих 4 мес. после увольнения — платились денежные компенсации (это — не зарплата (они — уже не сотрудники)).
Кейс №2: Под конкретного разработчика и конкретный проект — было приобретено дорогое рабочее место с дорогим пакетом (САПР), и его к трудовому контракту — оформили доп.контракт на компенсацию этих затрат в случае его досрочного ухода до завершения проекта.
"Расписка об отсутствии препятствий для полноценной работы на новом месте"
Вещь — важная. Нужна для защиты от нарушения прав третьих лиц. Во первых — страхует от последствий использования информации (и нарушения NCA/CNC) с прежних (бывших до этого) мест работы, во вторых — страхуется притаскивание в компанию чужих (включая и свои собственные) проектов (кейс Nginx-а — наглядный пример).
Мы это поняли после двух неприятных инцидентов с удалёнными зарубежными фрилансерами, сливавшими в наши проекты (и наверняка ещё в несколько других) куски проектов с прежних мест работы (что выяснилось уже потом). Сама по себе расписка — естественно не препятствует притаскиванию в проект внешней грязи, но она нужна компании для подтверждения добросовестности (были приняты все необходимые меры предосторожности), и соответственно защиты от возможных последующих претензий третьих лиц.
В качестве замены (или дублирования) такой расписки, некоторые проекты — иногда превентивно вывешивают в сети информацию о приёме потенциально проблемных разработчиков (типа "в наш дружный коллектив наконец то влился ..."), но проще (и надёжнее) сделать явную бумажную расписку на три абзаца.
Были случаи, когда выяснялось, что разработчики использовали в коммерческих проектах свои собственные решения, описания или идеи которые они тем не менее до этого — "светили" в популярных нынче "хакатонах", и в заявках на конкурсы и гранты, о чём они руководителям проектов своевременно не сообщили. Однако во многих хакатонах, конкурсах и грантах — есть положения относительно прав организаторов-устроителей на последующее использование присылаемых материалов, как минимум в образовательных целях.
А например в описаниях яндексовских и сберовских хакатонов — напрямую указано о возможности изучении присылаемого материала на предмет применимости в бизнесе. Соответственно засвеченное таким образом решение, будучи реализовано в коммерческом проекте — несёт потенциальные риски. (Случай, когда разработчик тащит на хакатон кусок своего текущего проекта — подпадает под нарушение NDA (см. выше).)
Отдельным (и как это ни странно частым) случаем нужности расписки об отсутствии препятствий — являются ситуации, в которых разработчики — сами не знают (хотя — могли бы) о наличии у них подобных ограничений.
Кейс: В один из проектов, на ведущую позицию пришёл человек, незадолго до этого отработавший год по теме проекта в британском университете по гранту на научный обмен. До этого случая мы с подобными ситуациями не сталкивались, поэтому не обратили на неё внимания. Но потом зарубежный соинвестор проекта — объяснил нам что мы не совсем правы. Когда в самом университете взяли нужные документы, выяснилось, что у человека — действительно ещё не закончился "карантинный" год, прописанный и в грантовом контракте, и во внутренних документах университета. Причём условия там оказались намного более жёсткими, чем можно было ожидать.
"Запрет на использование/распространение информации, и споры после увольнения"
Здесь — во первых ещё раз дублируется всё, что уже было в NDA&(NCA/CNC), но при этом применимо не только во время, но и в период после прекращения работы. Если есть проблемы с бумагой и принтерами, тогда этот запрет — можно "интегрировать" в текст основного NDA&(NCA/CNC). Однако экономия на трёх лишних абзацах — не стоит большого количества нервов и времени, необходимых на последующее длительное доказывание того, что "интегрированный" текст относится и ко времени работы по проекту, и ко времени после её окончания. Экономия одного листа бумаги таких рисков — не стоит.
Во-вторых, здесь (пусть всего одним, но важным абзацем) прописывается запрет на последующее распространение негатива о проекте/компании, а вторым — ситуации предъявления к компании судебных исков (и своих, и участие (соистцом) в чужих).
По первому пункту: Обязательство не говорить гадости о компании и проекте, взятое односторонне и самостоятельно, столь же односторонне и самостоятельно отменятся. Поэтому при увольнении — надо заключать контракт "о тишине", с взаимными обязательствами и выплатами компенсаций (в обе стороны).
По второму пункту: Обязательство "не подавать в суд" — юридически ничтожно, и не стоит бумаги, на которой написано. Патчится эта проблема — опять же контрактом с чёткими взаимными обязательствами и компенсациями/штрафами. В реальности, срока "тишины" в полгода — вполне достаточно. Это всё — выглядит страшно и монструозно, но в реальности — занимает четверть листа (правда мелким шрифтом).
"Служебная разработка"
Кейсов — море, но после Nginx-а — всё уже было обговорено сотни раз, и уже не нужно никому ничего объяснять.
Разве что стоит ещё раз повторить, что в контрактах на проекты, предназначенные для использования вне РФ — не стоит ссылаться на законы и юридические нормы права РФ.
"Не противодействие использованию решения"
Кейс: При работе по проекту — создано новое решение, которое подаётся на патентование. Сроки патентования в США например клиент-серверных решений — могут занимать до трёх лет, а архитектуры/весов/методик по нейронным сетям — до пяти лет (чем горячее тема, тем больше заявок, соответственно дольше сроки экспертиз). А к тому времени проект — уже давно закроется, и сам разработчик — не просто уволится, а уже успеет поработать в паре других проектов. А без его подписи некоторые вещи при патентовании сделать не получится. Поэтому, опять же — отдельный контракт, пусть и на 1/4 страницы. Естественно подписываемый строго до начала работы по проекту. (возможно — уже после принятия на работу по трудовому, или "рамочному" фрилансерскому, но — строго до начала проекта, в рамках которого и будет подаваться заявка)
"Запрет на неявное использование внешней информации"
Всё, что вставляется в проект откуда то извне — должно проверяться очень внимаетльно, и монтироваться (если без этого совсем уж нельзя) с возможностью быстрой замены или полного удаления (если нельзя быстро заменить).
Кейс 1. Разработчик, где-то на сайте для программистов — увидел решение, подходящее для проекта, и его в проект вставил. Выяснилось это уже незадолго до сдачи проекта. Потом этот кусок из проекта пришлось долго и нудно выпиливать.
Кейс 2. Разработчик — увидел полезное решение, опубликованное самим его (решения) автором. Автор — раздаривал решение всем желающим, так как патент на решение — уже прекратил действовать (по неуплате пошлины), а сама компания — находилась в процессе банкротства.
Кто успел воспользоваться этой щедростью — не известно, зато известно, что чрез полгода банкротство завершилось, а новая компания все патенты — восстановила.
Кейс 3. Разработчик — увидел вывеску "опенсорс", и набрал там полную тачку халявы.
Однако — не существует ни одной Open Software License, в тексте которой было бы слово "халява".
(Про ОпенСорс на Хабре — уже писали)
Опен-сорс, это — "открытый" исходный код, но это — не про деньги. В "свободной" лицензии — может быть указано: "Бесплатно только для использования в собачьих приютах", а в вашем конкретном случае, приют может быть — не собачьим, а смешанным (собаки и кошки), значит вы — вышли за рамки условий лицензии.
Для личного некоммерческого использования — можно использовать вообще всё что угодно, хоть запатентованное, хоть авторское, хоть ещё какое. Но как только софт даже абсолютно бесплатный (и уж тем более платный) будет по такой лицензии поставлен хотя бы на один ПК не-собачьего приюта — произойдёт нарушение условий лицензии, со всеми административными и уголовными последствиями. Нарушение условий лицензий опенсорс — очень частый кейс.
Полностью свободным — является только тот софт, идеи (способы работы) которого попали в общее достояние (патенты прекратились и не могут быть восстановлены), и текст исходника которого писал автор, умерший 70/75/80 (в разных странах по разному) лет назад. Во всех остальных случаях, у опенсорса — могут быть (и скорее всего есть) подводные камни. Ещё раз: "открытый" исходный код, это — не ничейный код.
Кейс 4. Разработчик — накачал модулей из "бесплатной" библиотеки интела для обработки изображений, и поковырявшись в коде, из их кусков соорудил пару своих блоков. Улучшил и оптимизировал. Однако интелловская "бесплатная" библиотека, это — отнюдь не "халява". У неё — очень чёткие и жёсткие условия использования. Блоки в проекте конечно оставили, но разработчика попросили больше так не делать.
"Обязанность проверки собственных разработок на новизну"
Если разработчик сам что-то придумывает, это — очень хорошо. Проблема только в том, что если это смог придумать он, значит есть ненулевая вероятность того, что тоже самое (или нечто близкое), до него уже мог придумать и кто-то другой. А кто первый встал — того и тапки.
Соответственно это новое — надо занимать пока это не сделал кто-то другой. Что бы разработчик этим занялся (вместо сдельного кодинга), его — надо стимулировать или премиями (в рамках трудового договора), или дополнительными контрактами выплатами.
"Обязанность фиксации новых решений"
Если (на предыдущем шаге) была установлена новизна созданного решения, значит её — надо фиксировать. Или патентами, или (если до полноценного патента не дотягивает по новизне) хотя бы открытой публикацией (по принципу "Так не доставайся же ты никому!"). По практике, если в проектах инозаказчиков патентные заявки вообще не подаются (или прекращают подаваться), заказчики -начинают нервничать и проверять проект. Это — в лучшем случае. В худшем они думают, что этот код люди делают "за еду", и ставят ценник меньше индусов. Поэтому заявки, или как минимум хотя бы публикации (подойдёт любой публичный ресурс) — строго желательны.
Здесь, однако есть один важный и "чувствительный" момент. Разработчику — платят за код, а патент — достанется или заказчику, или компании. Соответственно, если разработчик перейдёт потом в другую компанию, он сам, это решение (где он автор) на своей новой работе, использовать — уже не сможет. Не сможет — не просто из-за неконкуренции (NCA/CNC), а из-за целого полновесного патента, автором по которому — является он сам. По этой причине, разработчики часто саботируют процесс подготовки и подачи патентных заявок, ссылаясь на загруженность по основному проекту. Патчится этот баг — отдельными контрактами и внятными выплатами премий по факту подачи заявок. (разборки по принадлежности патента между заказчиком и компанией — своя отдельная грустная песня)
"Права на разработки"
С этим вопросом, почему-то всё время возникают какие-то сложности. Хотя вопрос — предельно простой. "Авторские права — не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач"
Ещё раз: на алгоритмы, форматы данных, способы работы и взаимодействие блоков, и т.д., и т.п., никаких авторских прав — нет. Всё это хозяйство (способы & устройства) — патентоспособная промышленная (но никак не "авторская") собственность (а после регистрации — "нематериальные активы").
Авторское право — распространяется только и исключительно на произведения литературы и искусства. При этом, само это "право" — состоит только и исключительно в праве называть себя автором текста. Никаких иных прав на использование этого текста, авторское право — не даёт. Всё — как в издательском деле, издательство — заказывает книгу, автор — пишет, имя автора — указывают на обложке, но сам текст — принадлежит издательству.
При этом, применение авторского права к программному коду — есть абсолютная глупость. Если в софтовом проекте просто переставить местами блоки кода, проект как литературное произведение — исчезнет, соответственно исчезнет и авторское право на него. Если код откомпилирован, тогда исходный "текст" — вообще исчезает. Юристы (как правило) — не пишут программ, не собирают пакеты из блоков, не тестируют их, и т.д., и т.п., и всего этого — не знают, поэтому всё время и пишут про "авторское".
Что касается т.н. "служебной" разработки. Обычно риски последующих разборок снимаются достаточно просто. Архитектура продукта или сервиса, и основные технические вопросы его построения и работы (пусть и с предварительной проработкой на уровне конечных исполнителей) — утверждаются на уровне руководства проекта, и оформляются в виде базового ТЗ, которое и передаётся в работу. В этом случае, все права — заземляются на уровне ТЗ, и риски возможных последующих претензий — снимаются (автор — тот, кто выдал ТЗ).
Кейс: Во многих действующих в РФ зарубежных центрах разработки — принято следующее правило. Если местные разработчики придумывают что-то новое — подаётся патентная заявка, первым автором в которой — всегда указывается иностранный сотрудник российского офиса. Это — снимает многие риски.
"Техника безопасности"
Практически вся российская софтовая разработка, идущая за пределы РФ — находится в "серой" зоне. При работе в интернете, и посредством интернета, государственная и таможенная границы РФ — проходят по поверхности монитора. Всё, что находится за ней — уже не совсем РФ. А часто — совсем не РФ. (облачные сервисы Амазона, или Гугла — гарантированно вне РФ).
Соответственно, если разработчик посылает файл проекта в соседнее здание, проблем — не возникает, но если он посылает этот файл например в США, тогда в момент нажатия им кнопки "отправить", файл проекта — одновременно пересекает и государственную, и таможенную границы РФ! Соответственно при пересечении первой границы — возникают риски "экспортного контроля", а при пересечении второй — таможенной "контрабанды" (разработчик же таможенную декларацию на передаваемый файл — не оформлял).
Поэтому, со всеми, кто в рамках работы по проекту будет или может контактировать с зарубежными адресатами — надо проводить инструктаж, и выстраивать схему работы, минимизирующую риски. (Патчится — созданием микро-компании в стране заказчика, а российский офис — оформляется как представительство, или сервисная служба.)
"Взаимодействия с клиентом"
Уже было ранее, но ещё есть некоторые моменты. Много скрытых рисков находится в зоне взаимодействия разработчика с заказчиком при длительной сдаче проекта, и/или его техподдержке при дальнейшей эксплуатации. Если в компании вдруг есть своя внутренняя CRM-система, тогда в ней для подобных взаимодействий надо предусмотреть отдельный режим. Но в любом случае от клиента должна быть получена "бумага" о том, что действием исполнителя (то есть компании) считается только то, что исходит (или идёт с второй "подписью") от менеджера отвечающего за взаимодействие с клиентом.
Кейс №1: От клиента в США — был получен запрос на решение проблемы. Его с контактами сотрудника клиента переслали разработчику. Разработчик (чуть ли не через вотсап) связался с сотрудником, и через некоторое время прервал общение, попутно дав тому ценные сведения о его профессиональных и умственных способностях. Клиент — предъявил претензию в связи с якобы отказом в техподдержке.
Кейс №2: От клиента в США (уже другого) — был получен запрос на решение проблемы. Менеджер — передал его разработчику, и посчитав вопрос закрытым, поставил отметку об исполнении. Был конец рабочего дня, и разработчик подумал, что "завтра сделаем". Клиенту от откладывании — не сообщили. Сотрудник клиента в свой срок ответ не получил, и не смог решить уже свою задачу, о чём и сообщил наверх. Клиент — предъявил претензию в связи с нарушением тайминга техподдержки.
Если проект делается не для использования непосредственно самим заказчиком, а для (после настройки/дополнения/изменения) передачи третьим лицам, тем более физикам, тогда всё претензии этих лиц по пакету — клиент будет навешивать на исполнителя. Патчится — собиранием всех потенциально рисковых фич проекта в один перечень, и передача его клиенту "под подпись". Клиент просто ставит этот перечень в User Agreement своего пакета, и проблема решается (правда не всегда).
"Платежи"&«Налоги»
То же самое, что и в предыдущих пунктах, но относится к механизму оплаты. Если разработчикам (тем более фрилансерам) делаются счета на пейпеле или пейонере, проблемы которые могут возникнуть с одним из этих счётов/кошельков — не должны доставлять проблемы другим людям и проектам. А если людям оформляются личные карточки, привязанные к одной корпоративной офшорной, тогда на общем счёте — не должны одновременно скапливаться средства нескольких получателей.
Отдельно и особо надо отрегулировать вопросы перевода средств с безличных карточек и счетов на "белые" карточки сотрудников в банках РФ. Если разработчик снимет в банкомате средства с серой карточки, а потом тут же, в соседнем банкомате внесёт их уже на свой белый счёт, средства — "очищаются". Но если он в целях копеечной экономии на комиссии, перебросит безналом средства на свой личный например сберовский счёт — возможны последующие проблемы, которые могут ударить уже не по данному сотруднику а по остальным.
С налогами — аналогично. По хорошему, всех получателей зарплаты — надо разделить по степени риска от засветки платежей, и разным категориям — платить по разным схемам. До недавнего времени, для получателей в РФ — была удобна форма ИП, но сейчас транзакционные издержки по ней — стали неприемлемыми. (налоговая в любой момент может выставить ИП-шнику перерасчёт за прошлые годы, причём без пояснения и объяснений) Возможно удобной будет схема с т.н. "самозанятыми", но по ней пока очень мало информации.
Продолжение — следует.