Хабрахабр

[Из песочницы] Риски 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).

Это — не только сразу же даст "+100 к карме", но и резко снизит вероятность последующих недопониманий при приёме и оплате работы (заказчик — будет знать, что оформление команды делается грамотно, то есть люди — в теме, и просто так, их — уже не обманешь (даже если захочется)). Патч 2.: Если заказчик, или кто-то из топов команды — из США, тогда вместо трипса — лучше сразу ставить "Defend Trade Secret Act" & "Economic Espionage Act" (американские законы про ком.тайну и ком.шпионаж).

"Соглашение о неконкуренции" (NCA/CNC)

Проблема с ним в том, что последующее трудоустройство и работу нельзя запретить.
Запрет трудоустройства и работы — юридически ничтожен во всех странах. То есть написать его — можно, но никаких правовых последствий эти слова нести не будут.
Однако при этом, NCA/CNC — работает в иных конкретных случаях, а именно в случаях:

  • предотвращения нанесения компании ущерба путём несанкционированного использования сотрудником служебной информации после увольнения;
  • несанкционированного раскрытия и распространения сотрудником технологического опыта компании;
  • умышленного нанесения компании ущерба путём отказа сотрудника от трудовой деятельности после оплаченного компанией внешнего или внутреннего корпоративного обучения.

То есть, в первом варианте — взыскивается упущенная выгода, во втором — заключается свободный возмездный контракт со взаимными обязательствами сторон, а в третьем — взыскивается стоимость обучения (как при обычном целевом обучении, например в ВУЗе).

после увольнения — платились денежные компенсации (это — не зарплата (они — уже не сотрудники)). Кейс №1: С ключевыми разработчиками — заключались отдельные персональные контракты с указанием конкретных позиций в конкретных компаниях-конкурентах в которые сотрудник не может устроиться на работу и сроков (не более 4 мес.), прописывался запрет на открытие своего бизнеса и ИП по теме проекта, и по этим контрактам, в течении этих 4 мес.

Кейс №2: Под конкретного разработчика и конкретный проект — было приобретено дорогое рабочее место с дорогим пакетом (САПР), и его к трудовому контракту — оформили доп.контракт на компенсацию этих затрат в случае его досрочного ухода до завершения проекта.

"Расписка об отсутствии препятствий для полноценной работы на новом месте"

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

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

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

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

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

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

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

"Запрет на использование/распространение информации, и споры после увольнения"

Здесь — во первых ещё раз дублируется всё, что уже было в NDA&(NCA/CNC), но при этом применимо не только во время, но и в период после прекращения работы. Если есть проблемы с бумагой и принтерами, тогда этот запрет — можно "интегрировать" в текст основного NDA&(NCA/CNC). Однако экономия на трёх лишних абзацах — не стоит большого количества нервов и времени, необходимых на последующее длительное доказывание того, что "интегрированный" текст относится и ко времени работы по проекту, и ко времени после её окончания. Экономия одного листа бумаги таких рисков — не стоит.

Во-вторых, здесь (пусть всего одним, но важным абзацем) прописывается запрет на последующее распространение негатива о проекте/компании, а вторым — ситуации предъявления к компании судебных исков (и своих, и участие (соистцом) в чужих).

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

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

"Служебная разработка"

Кейсов — море, но после Nginx-а — всё уже было обговорено сотни раз, и уже не нужно никому ничего объяснять.

Разве что стоит ещё раз повторить, что в контрактах на проекты, предназначенные для использования вне РФ — не стоит ссылаться на законы и юридические нормы права РФ.

"Не противодействие использованию решения"

Кейс: При работе по проекту — создано новое решение, которое подаётся на патентование. Сроки патентования в США например клиент-серверных решений — могут занимать до трёх лет, а архитектуры/весов/методик по нейронным сетям — до пяти лет (чем горячее тема, тем больше заявок, соответственно дольше сроки экспертиз). А к тому времени проект — уже давно закроется, и сам разработчик — не просто уволится, а уже успеет поработать в паре других проектов. А без его подписи некоторые вещи при патентовании сделать не получится. Поэтому, опять же — отдельный контракт, пусть и на 1/4 страницы. Естественно подписываемый строго до начала работы по проекту. (возможно — уже после принятия на работу по трудовому, или "рамочному" фрилансерскому, но — строго до начала проекта, в рамках которого и будет подаваться заявка)

"Запрет на неявное использование внешней информации"

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

Разработчик, где-то на сайте для программистов — увидел решение, подходящее для проекта, и его в проект вставил. Кейс 1. Потом этот кусок из проекта пришлось долго и нудно выпиливать. Выяснилось это уже незадолго до сдачи проекта.

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

Разработчик — увидел вывеску "опенсорс", и набрал там полную тачку халявы.
Однако — не существует ни одной Open Software License, в тексте которой было бы слово "халява". Кейс 3.

В "свободной" лицензии — может быть указано: "Бесплатно только для использования в собачьих приютах", а в вашем конкретном случае, приют может быть — не собачьим, а смешанным (собаки и кошки), значит вы — вышли за рамки условий лицензии.
Для личного некоммерческого использования — можно использовать вообще всё что угодно, хоть запатентованное, хоть авторское, хоть ещё какое. (Про ОпенСорс на Хабре — уже писали)
Опен-сорс, это — "открытый" исходный код, но это — не про деньги. Нарушение условий лицензий опенсорс — очень частый кейс. Но как только софт даже абсолютно бесплатный (и уж тем более платный) будет по такой лицензии поставлен хотя бы на один ПК не-собачьего приюта — произойдёт нарушение условий лицензии, со всеми административными и уголовными последствиями.

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

Разработчик — накачал модулей из "бесплатной" библиотеки интела для обработки изображений, и поковырявшись в коде, из их кусков соорудил пару своих блоков. Кейс 4. Однако интелловская "бесплатная" библиотека, это — отнюдь не "халява". Улучшил и оптимизировал. Блоки в проекте конечно оставили, но разработчика попросили больше так не делать. У неё — очень чёткие и жёсткие условия использования.

"Обязанность проверки собственных разработок на новизну"

Если разработчик сам что-то придумывает, это — очень хорошо. Проблема только в том, что если это смог придумать он, значит есть ненулевая вероятность того, что тоже самое (или нечто близкое), до него уже мог придумать и кто-то другой. А кто первый встал — того и тапки.
Соответственно это новое — надо занимать пока это не сделал кто-то другой. Что бы разработчик этим занялся (вместо сдельного кодинга), его — надо стимулировать или премиями (в рамках трудового договора), или дополнительными контрактами выплатами.

"Обязанность фиксации новых решений"

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

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

"Права на разработки"

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

При этом, само это "право" — состоит только и исключительно в праве называть себя автором текста. Авторское право — распространяется только и исключительно на произведения литературы и искусства. Всё — как в издательском деле, издательство — заказывает книгу, автор — пишет, имя автора — указывают на обложке, но сам текст — принадлежит издательству. Никаких иных прав на использование этого текста, авторское право — не даёт.

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

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

Если местные разработчики придумывают что-то новое — подаётся патентная заявка, первым автором в которой — всегда указывается иностранный сотрудник российского офиса. Кейс: Во многих действующих в РФ зарубежных центрах разработки — принято следующее правило. Это — снимает многие риски.

"Техника безопасности"

Практически вся российская софтовая разработка, идущая за пределы РФ — находится в "серой" зоне. При работе в интернете, и посредством интернета, государственная и таможенная границы РФ — проходят по поверхности монитора. Всё, что находится за ней — уже не совсем РФ. А часто — совсем не РФ. (облачные сервисы Амазона, или Гугла — гарантированно вне РФ).

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

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

"Взаимодействия с клиентом"

Уже было ранее, но ещё есть некоторые моменты. Много скрытых рисков находится в зоне взаимодействия разработчика с заказчиком при длительной сдаче проекта, и/или его техподдержке при дальнейшей эксплуатации. Если в компании вдруг есть своя внутренняя CRM-система, тогда в ней для подобных взаимодействий надо предусмотреть отдельный режим. Но в любом случае от клиента должна быть получена "бумага" о том, что действием исполнителя (то есть компании) считается только то, что исходит (или идёт с второй "подписью") от менеджера отвечающего за взаимодействие с клиентом.

Его с контактами сотрудника клиента переслали разработчику. Кейс №1: От клиента в США — был получен запрос на решение проблемы. Клиент — предъявил претензию в связи с якобы отказом в техподдержке. Разработчик (чуть ли не через вотсап) связался с сотрудником, и через некоторое время прервал общение, попутно дав тому ценные сведения о его профессиональных и умственных способностях.

Менеджер — передал его разработчику, и посчитав вопрос закрытым, поставил отметку об исполнении. Кейс №2: От клиента в США (уже другого) — был получен запрос на решение проблемы. Клиенту от откладывании — не сообщили. Был конец рабочего дня, и разработчик подумал, что "завтра сделаем". Клиент — предъявил претензию в связи с нарушением тайминга техподдержки. Сотрудник клиента в свой срок ответ не получил, и не смог решить уже свою задачу, о чём и сообщил наверх.

Патчится — собиранием всех потенциально рисковых фич проекта в один перечень, и передача его клиенту "под подпись". Если проект делается не для использования непосредственно самим заказчиком, а для (после настройки/дополнения/изменения) передачи третьим лицам, тем более физикам, тогда всё претензии этих лиц по пакету — клиент будет навешивать на исполнителя. Клиент просто ставит этот перечень в User Agreement своего пакета, и проблема решается (правда не всегда).

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»