Риски IT-проектов и IT-команд

Нехорошая ситуация с 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)


Проблема с ним в том, что последующее трудоустройство и работу нельзя запретить.
Запрет трудоустройства и работы — юридически ничтожен во всех странах. То есть написать его — можно, но никаких правовых последствий эти слова нести не будут.
Однако при этом, 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 своего пакета, и проблема решается (правда не всегда).

"Платежи"&«Налоги»


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

Отдельно и особо надо отрегулировать вопросы перевода средств с безличных карточек и счетов на "белые" карточки сотрудников в банках РФ. Если разработчик снимет в банкомате средства с серой карточки, а потом тут же, в соседнем банкомате внесёт их уже на свой белый счёт, средства — "очищаются". Но если он в целях копеечной экономии на комиссии, перебросит безналом средства на свой личный например сберовский счёт — возможны последующие проблемы, которые могут ударить уже не по данному сотруднику а по остальным.

С налогами — аналогично. По хорошему, всех получателей зарплаты — надо разделить по степени риска от засветки платежей, и разным категориям — платить по разным схемам. До недавнего времени, для получателей в РФ — была удобна форма ИП, но сейчас транзакционные издержки по ней — стали неприемлемыми. (налоговая в любой момент может выставить ИП-шнику перерасчёт за прошлые годы, причём без пояснения и объяснений) Возможно удобной будет схема с т.н. "самозанятыми", но по ней пока очень мало информации.

Продолжение — следует.

Средняя зарплата в IT

110 500 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 7 138 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 21

    0
    Авторское право — распространяется только и исключительно на произведения литературы и искусства.

    статья 1261 ГК РФ

    Авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы), которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код, охраняются так же, как авторские права на произведения литературы.
      0
      1. "… как авторские права на произведения литературы."©
        Литературы. Об этом — и шла речь.
        (после трансляции "текста" программы в исполняемый код, "текст" (то есть объект охраны — исчезает) ("объектный" бинарник — тоже в принципе можно защитить, но вряд ли стоит))


      2. "ГК РФ"©
        РФ. ("Интернет" — не "РФ")


        0

        Есть же понятие производного произведения. Собрав бинарник, к примеру, другим компилятором, вы эту связь не разрываете. Как и переписав на другой ЯП.

          0

          ):-(
          "С этим вопросом, почему-то всё время возникают какие-то сложности. Хотя вопрос — предельно простой. "Авторские права — не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы решения технических, организационных или иных задач"
          Ещё раз: на алгоритмы, форматы данных, способы работы и взаимодействие блоков, и т.д., и т.п., никаких авторских прав — нет. Всё это хозяйство (способы & устройства) — патентоспособная промышленная (но никак не "авторская") собственность (а после регистрации — "нематериальные активы
          ")."©
          Текст "литературного произведения" (к коим и принадлежит текст программ) — защищается и охраняется как текст, то есть как совокупность знаков письменной речи, и слов, собранных в предложения. Как только вы меняете буквы, слова, или порядок их расположения (включая перестановку строк), исходный текст — ИСЧЕЗАЕТ.
          Критерии "уникальности" текстов — давно и подробно изучены и описаны, и для них — уже давно (в рамках SEO-копирайтинга) — созданы инструменты автоматического снятия метрик уникальности (Адвего Плагиатус, Антиплагиат онлайн, и т.д.).
          Если есть какие-то сомнения — подгружайте в них исходник, меняйте в нём порядок строк кода (естественно с сохранением функциональности), и — прогоняйте тест. И таким способом — меняйте до получения нужных вам метрик. Переписывать что-то руками — не надо.

        0
        Например, у разработчика в NDA и в служебной инструкции может быть написано: «запрещается обеспечивать доступ к служебной информации посторонних лиц». (это — конкретный кейс) Если бы там было написано: «запрещается передавать», вопросов бы — не возникало. Но написано то, что написано. При этом сам разработчик — может сидеть в общем зале, а монитор у него может стоять «лицом» к проходу, и быть виден всем мимо проходящим. И/или ему каждый раз необходимо отправлять документы на печать на общий принтер.
        Как-то вот смущает:
        — «обеспечить» = «организовать», «посторонних лиц» = «не сотрудников». Пока этот сотрудник не привел 3ье лицо за свой монитор, нарушение указанного пункта будет сложно доказать.
        Но лучше всего конечно — оформлять всех, кто работает по трудовому на отдельную, специально для этого созданную контору, возможные последующие неприятности которой — не завалят работу по остальным проектам.
        всех сотрудников, работающих по [трудовому] договору, оформлять на «левую» (ок, аффилированную(?)) контору? Объясните, как вам это поможет от нарушения NDA или слива данных?
        Но менеджеры были уже опытными, поэтому аккуратно (но быстро) у них всё забрали, и аккуратно (но быстро) выставили их за дверь.
        Точно опытными? Так-то испытательный срок никто не отменял. Не очень понимаю сложности описанной ситуации.
        Особым пунктом NDA — надо прописать взаимодействие разработчиков с представителями заказчика (если таковое предполагается). Нужен список материалов которые разработчик не должен передавать, и список вопросов, на которые он не должен отвечать.

        Кейс: Разработчик отослал заказчику в тех.службу промежуточную версию куска системы, с заглушками. Там посмотрели и запросили пару модулей которые должны были стать вместо заглушек, и находившихся на промежуточной стадии. Он их им и отослал.
        IMHO, тот факт, что разраб без консультации с менеджером проекта отправил доп модули — это уже по части организации работы, а ни фига не NDA. Когда у вас подписан с клиентом NDA, защищенные им данные уже могут передаваться клиенту. Но вот как раз подстраховать от дурости (процессов ли, отдельных персоналий) может режим КТ, к-рый вы ниже «раскатали».
        Поэтому если в компании нет «секретной» комнаты (с плотно занавешенными окнами), прошнурованного журнала посещений, и прочих голливудских страстей, тогда этого режима — нет, и все слова про «секретные сведения» и «закрытую информацию» — имеют чисто психологическое значение, и в реальном и серьёзном инциденте никакого значения иметь — не будут.
        Подскажите, плз, а где в законе о КТ про «секретную комнату»? А помню/сталкивался с тем, что на документах должен быть гриф «КТ» — иначе не оно. Такая информация должна быть защищена от доступа любым сотрудником (что тоже логично) + ведение учета, имеющих доступ к ней. Сейчас перечитал текст закона в части требований к установке режима КТ — и все равно не нашел.
          0
          Например, у разработчика в NDA и в служебной инструкции может быть написано: «запрещается обеспечивать доступ к служебной информации посторонних лиц». (это — конкретный кейс) Если бы там было написано: «запрещается передавать», вопросов бы — не возникало. Но написано то, что написано. При этом сам разработчик — может сидеть в общем зале, а монитор у него может стоять «лицом» к проходу, и быть виден всем мимо проходящим. И/или ему каждый раз необходимо отправлять документы на печать на общий принтер.

          Как-то вот смущает: «обеспечить» = «организовать», «посторонних лиц» = «не сотрудников».
          Пока этот сотрудник не привел 3ье лицо за свой монитор, нарушение указанного пункта будет сложно доказать.



          Если сотрудник именно что сам привёл 3-е лицо, тогда — будет не "обеспечил", а "произвёл".
          То есть вместо неправомерного бездействия будет действие, а это — уже совершенно другая квалификация деяния.
          (По РФ-ному закону о ком.тайне — есть "доступ к информации" (п.5), есть "передача информации" (п.6), и есть "разглашение — действие или бездействие" (п.9).)
          В универсальных (не (только) для РФ) контрактах в таких случаях пишут (в переводе на русский) "обязан проявлять "должную осмотрительность" для предотвращения… ".
          Хотя конечно лучше будет прямо написать в каких случаях кто и что делает, тогда и толковать ничего не придётся.


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

          всех сотрудников, работающих по [трудовому] договору, оформлять на «левую» (ок, аффилированную(?)) контору?
          Объясните, как вам это поможет от нарушения NDA или слива данных?



          Речь шла — о приёме новых и никому не известных сотрудников.
          Таких — лучше и оформлять на "подстраховочную" контору, и не давать им слишком большой доступ к тому, что они могут слить.
          А уже после прохождения первичного фильтра — можно оформлять их на чистую компанию (что может потребоваться например при последующем оформлении IP), с заключением полного пакета соглашений.


          Но менеджеры были уже опытными, поэтому аккуратно (но быстро) у них всё забрали, и аккуратно (но быстро) выставили их за дверь.

          Точно опытными? Так-то испытательный срок никто не отменял. Не очень понимаю сложности описанной ситуации.



          Испытательный срок на NDA/NCA — не влияет. (если это прямо не описано)
          Сложность — в том, что ПОСЛЕ подписания трудового, (уже нанятый!) сотрудник подписывать NDA/NCA — не обязан.
          И уволить его за такой отказ — нельзя.
          Это — не только и не столько для РФ, а для США/Европы.
          (если разработчики в РФ оформляются на тамошние компании, на которые потом например будут браться инвестиции)


          Особым пунктом NDA — надо прописать взаимодействие разработчиков с представителями заказчика (если таковое предполагается). Нужен список материалов которые разработчик не должен передавать, и список вопросов, на которые он не должен отвечать.
          Кейс: Разработчик отослал заказчику в тех.службу промежуточную версию куска системы, с заглушками. Там посмотрели и запросили пару модулей которые должны были стать вместо заглушек, и находившихся на промежуточной стадии. Он их им и отослал.

          IMHO, тот факт, что разраб без консультации с менеджером проекта отправил доп.модули — это уже по части организации работы, а ни фига не NDA.



          Это — и по части организации работы, и — по части NDA.
          Если в NDA прописан запрет на передачу (а как иначе?), тогда — есть явное нарушение.


          Когда у вас подписан с клиентом NDA, защищенные им данные уже могут передаваться клиенту.

          NDA с сотрудниками, и NDA с любой внешней стороной, это — два совершенно разных NDA.
          По своему (внутреннему) NDA сотрудники ничего передавать вовне — не могут, это им прямо запрещено.
          Даже если начальство им напрямую скажет "передавай", они это сделать — не смогут. (для них это будет прямое нарушение NDA, за которое их смогут сразу же уволить)
          Интерфейс передачи между юр.лицами внутренних конфиденциальных данных — своя большая отдельная тема.
          Примерно год назад проскакивал материал как в Ростехе пытались решить проблему передачи грифованной техдокументации между своими же (в рамках одной группы) юр.лицами.
          И им для этого пришлось оформлять "совместную деятельность", так как без оной это сделать не удалось.


          Поэтому если в компании нет «секретной» комнаты (с плотно занавешенными окнами), прошнурованного журнала посещений, и прочих голливудских страстей, тогда этого режима — нет, и все слова про «секретные сведения» и «закрытую информацию» — имеют чисто психологическое значение, и в реальном и серьёзном инциденте никакого значения иметь — не будут.

          Подскажите, плз, а где в законе о КТ про «секретную комнату»? А помню/сталкивался с тем, что на документах должен быть гриф «КТ» — иначе не оно. Такая информация должна быть защищена от доступа любым сотрудником (что тоже логично) + ведение учета, имеющих доступ к ней. Сейчас перечитал текст закона в части требований к установке режима КТ — и все равно не нашел.



          «Секретная комната» — из инструкций по "секретному делопроизводству" при работе с гостайной.
          Для ком.тайны формальные требования к помещению для работы с "материальными носителями" (без которых режима комтайны нет) — отсутствуют, но если нет отдельного помещения с ограниченным доступом (то есть доступ свободный), может быть несанкционированное разглашение ("действие или бездействие" (см. кейс с монитором повёрнутым экраном к проходу)).


          Но опять же, основываться на нормах (законах и судебной практике) РФ, в контрактах с командами и отдельными разработчиками, делающими продукты и сервисы не для рынка РФ — не совсем правильно.
          (теоретически это — возможно (и даже есть опыт применение в судах США российских норм и даже судебной практики (это возможно при наличии должной судебной оговорки)), но лучше этого не делать, и ссылаться на нормы США (см. выше), тем более что это намного проще и дешевле)

            0
            Если сотрудник именно что сам привёл 3-е лицо, тогда — будет не «обеспечил», а «произвёл».
            То есть вместо неправомерного бездействия будет действие, а это — уже совершенно другая квалификация деяния.
            тогда уж, в случае бездействия, это будет «допустил». Мне было бы интересно, есть ли реальный кейс, когда несоблюдение сотрудником мер безопасности (при том, что безопасность не является его сферой ответственности) трактовалось бы, как «обеспечил»?
            Таких — лучше и оформлять на «подстраховочную» контору, и не давать им слишком большой доступ к тому, что они могут слить.
            Извините, но не убеждает. Вас никто не обязывает предоставлять сотруднику больше доступов, чем надо, до любого момента (прохождения испытательного срока или подписания обязательств кровью). С другой стороны ему из «подстраховочной» конторы никто не мешает слить услышанное в курилке. Да и преследовать в *таком* случае будет сложнее.
              0
              Мне было бы интересно, есть ли реальный кейс, когда несоблюдение сотрудником мер безопасности (при том, что безопасность не является его сферой ответственности) трактовалось бы, как «обеспечил»?

              В именно такой формулировке (у нас) конкретных кейсов — нет.
              Но для самого сотрудника это — слабое утешение, так как в этом случае всё пойдёт — сначала на усмотрение сотрудника правоохранительных органов (который будет разбираться в инциденте), а потом — на "судейское усмотрение".
              (В юрисдикциях прецедентного права — наверняка подберут какой-то близкий случай.)


              Вас никто не обязывает предоставлять сотруднику больше доступов, чем надо, до любого момента (прохождения испытательного срока или подписания обязательств кровью). С другой стороны ему из «подстраховочной» конторы никто не мешает слить услышанное в курилке. Да и преследовать в таком случае будет сложнее.

              Для защиты от "услушать в курилке", любые бумажные (или электронные) документы — не помогут.
              Подстраховочная контора — нужна не для ограничения физического доступа, а для того, что бы при возникновения неприятностей её можно было мгновенно (а самое главное — безболезненно) выкинуть в ближайший мусорный бак, без рисков и последствий для основной работы.

        • НЛО прилетело и опубликовало эту надпись здесь
            0

            Нет, это — не для "морального давления", это — вполне реальные, и вполне рабочие (и работающие) условия.
            В нулевых годах в Москве — был реальный суд, когда фирма покупала "Майбах ", и (по контракту, для работы на этом майбахе) отправляла в Германию водителя для учёбы в фирменном центре.
            А потом он ушёл в другую контору, на другой Майбах, и ему выставили претензии и убытки.
            Это — здесь, в Москве, а на западе это — вообще норма.

            • НЛО прилетело и опубликовало эту надпись здесь
                0

                Речь — не конкретно про "Оплатить стоимость" всей лицензии (хотя и такое в принципе — допустимо (см. далее)), но(!) про выплату штрафа за умышленное причинение компании реальных убытков от:


                1. Простоя (на время поиска/обучения другого сотрудника) рабочего места (ПК + лицензия) (или тот-же Майбах), (как следствие) — простоя других рабочих мест/сотрудников, которые должны были получать результаты работы этого САПР — и(самое главное!) например срыва (из-за этого) поставки продукции или сдачи проекта заказчику.
                2. Затрат на поиск/обучение другого/нового сотрудника.
                  Затраты по п.2 — сравнимы со стоимостью курсов, но вот убытки по п.1 — могут быть КРАТНО выше и затрат на обучение, и размера зарплаты САПР-иста.
                  И (в принципе) — даже стоимости лицензии.
                  Если убытки вызванные будут совсем уж большими — возможно административное/уголовное преследование ДАЖЕ без контракта. (а в рамках например уголовноего дела — отдельный гражданский иск)
                  Но с контрактом — конечно лучше.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0

                    Вам (пока) везёт, вы — очень далеки от судебной (и РФ-ной, и тем более западной) практики по делам подобного рода.
                    Для первичного ознакомления — можно посмотреть практику по ст. 293 УК РФ ("неисполнение или ненадлежащее исполнение должностным лицом своих обязанностей вследствие недобросовестного или небрежного отношения к службе либо обязанностей по должности, если это повлекло причинение крупного ущерба или существенное нарушение прав и законных интересов граждан или организаций")
                    Исправительные учреждения — забиты милыми и добрыми электриками/врачами/водителями/машинистами/бухгалтерами/операционистками, у которых просто не вовремя "живот заболел", или которые "просто отвлеклись".
                    Эта норма — публичная (для ответственности по ней, даже контракт не нужен).
                    Если сотрудник серьёзно накосячил — подаётся заявление на возбуждение уголовного дела.
                    В не зависимости от его результата (если будет отказ — ещё лучше), — подаётся гражданский иск о взыскании причинённых убытков.
                    Если САПР/Майбах покупались под конкретную работу/сотрудника, о чём с ним был конкретный контракт, и стоимость его обучения, и убытки от его ухода (не легального увольнения, а отказа от работы) — будут взысканы (размер — по ситуации, но в любом случае больше затрат на обучение и зарплаты).
                    К слову, "с наследников" — тоже иногда можно что-то стрясти. (а на пресловутом Западе это — вообще норма)

                    • НЛО прилетело и опубликовало эту надпись здесь
                        0

                        Смешались в кучу кони и люди.
                        Увольнение это — трудовые отношения (для РФ — Трудовой Кодекс), нарушение контракта это — договорные/контрактные (гражданско-правовые) отношения (для РФ — Гражданский Кодекс), а причинение убытков это — уголовные или административные отношения возникающие из факта причинения вреда (для РФ — Уголовный Кодекс / Кодекс об административных правонарушениях / и тот же Гражданский). (Для США — UCC и U.S.C. (+ специфика разных штатов).)
                        Это — три совершенно различных (хоть и смежных) области, регулируемые разными законами.
                        Ещё раз, начиная с первоисточника: "Кейс №2: Под конкретного разработчика и конкретный проект — было приобретено дорогое рабочее место с дорогим пакетом (САПР), и его к трудовому контракту — оформили доп.контракт на компенсацию этих затрат в случае его досрочного ухода до завершения проекта."
                        По трудовому он — может увольняться, или брать отгулы и больничные.
                        Но контракт на обучение/закупку — потому и для того и заключается, что бы с него взыскать убытки причинённые отказом от выполнения СВОЕЙ ЧАСТИ контракта.
                        Если он попадёт под машину, сам он — будет освобождён от ответственности, но к тому, кто виновен в аварии — будет иск о возмещении убытков (хоть прямой хоть регресный).
                        Есть даже возможнсть не дожидаться нанесения вреда, а присечь такие попытки (для РФ — см. ст. 1065 ГК).
                        Ещё раз: трудовые отношения к возмещению ущерба никакого отношения — не имеют.

                          0
                          ничего, что вы обсуждаете *трудовой* договор?
                          но к тому, кто виновен в аварии — будет иск о возмещении убытков (хоть прямой хоть регресный).
                          извините, но можете привести хоть один пример такого кейса? я очень сомневаюсь в реальности подобного.
                          «Кейс №2: Под конкретного разработчика и конкретный проект — было приобретено дорогое рабочее место с дорогим пакетом (САПР), и его к трудовому контракту — оформили доп.контракт на компенсацию этих затрат в случае его досрочного ухода до завершения проекта.»
                          это ему купили лично во владение? нет? лесом. и подобный договор (как ущемляющий права работника) оспорен будет на ура.
                          • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0

                            При чём тут "работа" (трудовые отношения)?
                            Речь идёт — о взыскании УБЫТКОВ (ущерб & упущенная выгода)
                            Прогуглите: "взыскание ущерба с наследников" & "судебное дело".

                              0
                              Извините, я старался избежать резких высказываний, но вы пишете абсолютно неверные вещи. Тем хуже это выглядит, когда вы отсылаете оппонентов в гугл с несвязанными вопросами. Наследники наследуют и активы, и пассивы (обязательства). При этом наследник может отказаться от наследства — и тогда не наследует и долги.
                              Еще раз: наследники могут принять наследство — и именно и только в таком случае возмещать ущерб.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое