Мы занимаемся разработкой сайтов 3 года. Это небольшой срок, но уже за 3 года мы смогли два раза оказаться в досудебке по поводу наших работ. Это не много и в целом мы даже довольны такой статистикой, но все же тратить время/энергию на подобные вещи хочется меньше.
Статья написана на основе нашего последнего дела, в котором нам пришлось возмещать 30% от стоимости договора. Часть материала написана на опыте наших коллег по цеху из Ижевска.
Задача поста - помочь начинающим веб-студиям делать проекты юридически чисто.
Итак, поехали. Если вы разрабатываете сайты, то учтите следующие моменты:
- Имейте оригинал договора и всех допников на руках, независимо от того, есть сканы подписанные в электронном виде (по почте). Даже, если в договоре указано, что сканы имеют юридическую силу. Когда в год 50-70 новых договоров, то всегда есть контрагенты, которые не присылают оригинал договора.
- Если проект затягивается, то сроки переносить дополнительными соглашениями (допниками). У нас в договоре есть пункт: “Если заказчик согласовывает этап дольше 3-х рабочих дней, то течение сроков приостанавливается”. Но на деле это надо еще доказать и поэтому, чтобы этого делать не пришлось, сроки проще менять через допник.
Коммуникацию вести только с тех почт, которые указаны в договоре. Если Заказчик или Исполнитель меняют почты, то составить допник.
- Коммуникация в мессенджерах допустима, если это указано в самом договоре, но все значимые документы отправлять нужно по почте. В суде сложно доказать причастность переписки в мессенджерах к договору, однако, уже стали появляться прецеденты, когда их приобщают к материалам дела. Но, я бы не стал на это сильно надеяться.
- При отправке значимых документов по электронной почте, в письме необходимо писать сопроводительный текст. Пример: “Скидываю вам техническое задание согласно п.2 договора №33 от 01.01.2021 на разработку сайта. Прошу ознакомиться и дать обратную связь.”. В суде будет сложно доказать, что ТЗ в письме относилось конкретно к этому договору.
- Проверять подписи на договоре, ТЗ, актах и прочих документах. Могут расходиться. Причем заказчик (или представитель) это может сделать неосознанно. Если подписи разные, то документ считается недействительным.
- Если делаете сайты и покупаете программное обеспечение, например БУС или шаблоны Аспро для Битрикса, то продавать/передавать их отдельным договором. В будущем, если будет суд, то это может уменьшить пени.
- Работать через Git (с Битриксом сложно, но это лучше, чем бэкапить по 250 гб).
- Работать только на своих серверах (если нет Git). Даже если у заказчика есть свой сервер, то все равно работы проводить на своем, а результат переносить на сервер заказчика. Это усложнит работу, но зато вы будете защищены от вмешательств в код сторонних программистов.
- Если проект касается доработки шаблонного решения (например, доработка Аспро), то ТЗ делается первым этапом в договоре, и,если оно затянулось, то со счетом на 2 этап присылать допник на увеличение сроков. Это важный пункт, потому что на ТЗ иногда уходит много времени.
- Если появляются какие-то сложности в общении или подозрение на недобросовестное отношение со стороны Заказчика, то все документы отправляются согласно условиям договора. У нас это Почта России с описью вложений. И лучше в этот момент нанять юриста, чтобы он начал оценивать риски.
- Если Заказчик поменял доступы, либо вы чувствуете, что он вносит изменения в код сайта, то это все необходимо фиксировать в формате видеозаписи экрана с указанием исходных доступов. Запись должна быть непрерывной, с возможностью идентификации пользователя (IP адрес, системные учетки и тд.)
- Не принимайте оплату по договору наличными, если вы работаете по расчетному счету и нет онлайн-кассы.
Ну и последнее наблюдение.
Если есть возможность решить вопрос до суда, не стоит ей пренебрегать. На сбор доказательств уйдет много времени. Суды не всегда адекватно смогут дать оценку по IT. Качество работ определяется судебной экспертизой, которая может быть не в вашу пользу (тут уж кто больше заплатит). Лучше это время потратить на новые проекты.
Надеюсь, что статья будет полезной для вас и вы сможете сделать свою работу юридически более чистой. Если есть что дополнить - пишите в комментариях свой опыт.
В качестве бонуса тем, кто дочитал статью, готов скинуть шаблон нашего договора, который нам составлял юрист. Там есть договор на продажу программного обеспечения (шаблоны, лицензии Битрикса) и договор на основные работы. Пишите в телеграм @fredizh с пометкой “договор vc.ru”. Ну и кому нужен юрист по подобным делам - также пишите в телеграм, скину контакты.
Тема не раскрыта. Что именно повлекло выплату 30%?
10% мы выплатили пени за то, что не подписали допник на увеличение сроков, хотя по почте и в мессенджерах была активная переписка по проекту вплоть до его сдачи и проект затянул заказчик.
20% мы выплатили за некачественную работу. Ошибки были предъявлены на основании аудита сторонней компанией и около 60% пунктов не соответствовали ТЗ. Причина: заказчик просил изменить ТЗ и вся переписка по этому поводу у нас была в телеграме.
Переписка в месседнджерах может быть заверена у нотариуса (да-да, как с пресловутыми скриншотами) и приложена к делу в суде.
Как это соотносится с неподписанными допниками, впрочем, не подскажу. Лучше все оформлять своевременно.
Да, все верно, но суды у нас в Удмуртии пока неохотно это все принимают к делу. Поэтому тут 50% на 50%.
На суды первой инстанции не имеет смысла надеяться в таких делах - это вне зависимости от региона.
Уже охотно, Стас. Я так телеграмм переписку заверял.
А есть практика, когда другая сторона оспаривала, что аккаунт в мессенджере ей принадлежит, что этот канал связи одобрен сторонами и что (например) его сообщение не подредактировали как-нибудь?
Наверняка есть. Поинтересйтесь у юристов )
Походу "вилами по воде" и этими заверенными нотариально скриншотами можно подтираться (если бумага мягкая конечно).
Можете подтираться, разрешаю )
В целом со своим разрешением можете сделать тоже самое)
Разрешаете? )
Знаю случай, когда парень, доказывая свою непричастность к убийству, заверял скрины переписки соцсетей с убитой, показывая тем самым их позитивное общение, и суд их принял скрины. А ещё суд принял распечатку (не заверенную!) его истории перемещений из акка гугла и историю запуска приложений, тоже их аккаунта гугля, привязанного к телефону, тоже не заверенную. Короче говоря, тут все от судьи зависит и как приподнести эти скрины. Я был как раз типа специалист, который на суде пояснял процесс извлечения этих данных и их происхождения.
А у этой сторонней компании есть какая-то аккредитация на производство аудитов для суда? Если есть, то можете их название скинуть, а то я таких не встречал) От левой конторы суд не должен был никакие аудиты принимать.
Да там похоже тоже зависит от того, будут ли оспаривать такой аудит или нет. Я лет 15 назад примерно тоже для суда какую-то справку заверял как ИП, который занимается разработкой сайтов. Мол сайт по адресу такому-то, недоделан по таким-то признакам, ориентировочные сроки разработки такие-то. Они несколько справок таких собрали, но насколько их приняли в суде (и приняли вообще) - не в курсе, но дело в итоге они выиграли.
В досудебке это не имеет значение. В суде имеет. То есть должно быть именно гос образование, например программист.
Поддерживаю, статья безусловно не самая бесполезная, но заголовок гласит немного о другом
Можно просто с мудаками не работать. Тогда и допниками по каждой запятой обмазываться не придется.
95% проектов именно так и закрывается, но юристы тоже платят ипотеку и берут кредиты.
Не всегда на старте понятно, что контрагент - мудак. Переговоры могут быть прекрасными, Заказчик может показаться душечкой, а потом начнется головомойка. А когда полпроекта сделано - заднюю давать уже поздно
Тут была другая тема. Сменился ЛПР (ген дир) на середине проекта, у которого свое видение на развитие компании. Если кратко по ситуации, то в ней и мы тоже виноваты, мы это прекрасно понимаем.
Был у меня заказчик который орал в суде что ничего не сделано, и вообще я откатов надавал чтоб мне акты подписали :) Весёлая история, от меня прятали акты выполненных работ, шифровались, пугали прокуратурой, звонили юристы заказчика пытались пугать гражданским кодексом, в итоге оказалось что я его лучше знаю и т.д. Когда посчитали количество подписей на документах разных стадий подтверждения работ, оказалось что "в доле" даже новый гендир который больше всех орал, он тоже успел подмахнуть пару бумажек. В догонку пошла распечатка из почты, естественно копии всех документов, ребята сами захотели подробный перечень работ получать каждый месяц. Потом орал что хочет экспертизу и т.д. по итогу граждане оплатили всё в полном объеме, за просрочку платежа влетели на сумму почти от половины договора и суд с них ещё в догонку что-то в бюджет взыскал. Друг с этими же ребятами так же прилип, практически параллельно, но дорожка уже была протоптана в суды, заседания один в один только у меня на месяц раньше. В общем горе заказчик по итогу экономя 1,5 ляма суммарно прилип на 3 через суды. Судиться страшно в первый раз :) потом когда понимаешь как это работает уже не страшно :) но надо адекватного юриста для консультаций иметь вот такого найти уже сложнее :)
Ахахаха, кайф
Почему сложно? Все отправляете в Гит кроме папки bitrix и upload.
Шаблоны и модули храните в папке local которая в корне сайта.
В принципе, и папку bitrix можно в гит, кроме кэшей, бэкапов и dbconn.php,.settings.php. Как раз будет видно, если кто лапы запускает.
Скажу так, в РФ в принципе не существует культуры документооборота. Редкий менеджер следит, чтобы подписи были людей имеющих полномочия подписывать, на нужных документах и вовремя. Значительная часть даже не в состоянии понять, что полномочия описанные в доверенности имеют исчерпывающий характер и какой-нибудь исполнительный директор или коммерческий директор не имеет права подписать договор, если у него в доверенности не прописано явно это право.
Если требовать, чтобы все было четко, количество клиентов уменьшиться. А существующие будут жаловаться на излишний формализм.
Единственный выход вижу в ЭДО.
А как вы ЭДО организуете между подрядчиком и заказчиком? Получается надо, чтоб у обоих было единая ERP?
Контур.Диадок, СБИС ЭДО и прочие подобные облачные сервисы для обмена подписанными ЭП электронными докуменами.
Согласен, на ЭДО мы перешли давно и как раз таки акты последние им по ЭДО отправили. Только тут смущает вопрос, надо ли в договоре прописывать конкретно через что работаем (Сбис или Диадок) или же просто написать, что можем отправлять акты по ЭДО?
А зачем? Законодательством установлено, что ЭЦП - это аналог собственноручной подписи.
Я с каждым договором подписываю доп соглашение на электронный документооборот. У меня диадок, могу выслать его на ознакомление.
Ежики плакали, кололись...
В целом, статья информативна, много потенциальных подводных перечислено.
Но... вот как так-то можно было делать?
Не принимайте оплату по договору наличными, если вы работаете по расчетному счету и нет онлайн-кассы.Я когда статью готовил, то сам был в шоке, как так можно было когда-то сделать :)
Не очень понятно какой изначально заложен жизненный цикл разработки. Кто и на каком этапе писал ТЗ? Если очень утрировать:
1. В большинстве случаев заказчик не в состоянии написать ТЗ, и в основу договора кладутся общие функциональные / технические требования, уже на основе которых в рамках договора подрядчик пишет полную техническую документацию ТЗ/ЧТЗ. Это первый этап договора, по итогам которого ТЗ направляется на согласование (сроки и количество итераций согласования обычно так же прописываются в договоре), по итогам согласования заказчик или согласовывает или не согласовывает документацию, ссылаясь на несоответствие ФТ/ТТ, подрядчик в свою очередь устраняет замечания в заявленный договором срок. Тут уже вопрос к подрядчику - умеет ли он писать грамотные ТЗ.
2. По итогам согласования ТЗ можно пускаться в разработку, но параллельно с разработкой готовится ряд артефактов, которые используются для приемки работ: руководства администраторов/операторов, программа и методика испытаний. Эти документы в обязательном порядке согласовываются с заказчиком, и опять же, приёмка той же методики испытаний должна быть согласована заказчиком с возможностью апелляции только к ТЗ. По итогам согласования методики и реализации проекта уже можно приступать к этапу приемосдаточных испытаний.
3. Приёмка/обучение/тестирование должно происходить на основе не ТЗ, а ПМИ и руководства.
Повторюсь, это очень утрировано, но это базис, без понимания которого вот эти все сборы рабочей переписки в качестве каких-то доказательств - просто пшик. И да, это применимо не только в классическом кас каскаде, но, хоть и с натяжкой, и в ныне модном аджайле.
Сразу видно вы из производства. Не хватает слова "пусконаладка". Мы таких слов не знаем, но в целом так все и делаем теперь. Ключевое слово "теперь".
Я как раз из ИТ, и веба в том числе. К сожалению, в большинстве случаев у компаний, которые позиционируют себя не как интеграторы, а как "просто веб-студии", нет культуры ведения проектов со всеми присущими ИТ проектам артефактами, на близкой дистанции это кажется экономией в части работы аналитика и менеджера (а зачастую это совмещённая позиция, что есть страшная дикость), но в долгую как раз приводит вот к таким случаям, когда приходится судиться и доказывать, что ты не баран и сделал все хорошо и правильно, а ещё зачастую приводит к издержкам, когда клиент говорит на любую неточную формулировку: "а я не это имел в виду - переделывайте". Ну а договор - это просто формализация того принципа управления, который исповедует компания.
Это все мега круто. И всем надо стремится к такому, но вы судите с высоты компании сидящей на денежной подушке. Которая не сильно зависит от стабильных ежемесячных платежей от клиентов. 90% студии же не могут себе позволить растягивать подписание договора и получение оплат за этапы. К сожалению это горькая правда, которой клиенты не редко пользуются.
Вообще не понял комментарий. Если договор поделить на этапы: 1. Проектная документация, 2. Разработка, 3. Тестирование. По итогу закрытия этапа выставлять акт и счёт за весь этап, в чем растягивание то?
Лет 10 назад занимался супер бюджетными проектами, и там стремились к максимальной унификации документов. Да, на старте пришлось потрудиться и сделать максимально подробную документацию, но в последствии под каждый проект требовалось минимум усилий на составление документов: убрать лишнее, добавить уникальный кастом (для бюджетных проектов в большинстве случаев это минимум). Зато на выходе от клиента было минимум вопросов, и разговоры были не на уровне "ну мы же обсуждали", а на уровне "какому пункту документации не соответствует итоговый продукт".
Ну если так, то может и сработает. Если есть рыба и минимум модификации. Хотя это сработает только для студии с конвейерным производством типовых проектов. А вот если студия специализируется на уникальной разработке, да еще и разных направлении, то тут ни какой шаблон не поможет. Разве что описания процесса авторизации и регистрации будет одинаково.
Отличная статья, взял на заметку! Благодарю за описание своего опыта🙏
Выпустить УКЭП, подписывать все доки ею. Средние/крупные компании чаще всего заводят ее в момент открытия, мелким/частникам можно тоже выпустить. Даже не нужно в договоре этот момент отражать, все что подписано УКЭП имеет юридическую силу.
Да, тоже не понял. Кому и за что 30%.
Мы как разработчик сайта выплатили 30% от стоимости проекта обратно Заказчику. По процентам написал выше.
Было бы неплохо еще озвучить что именно было не принято по ТЗ заказчиком. Ну и результат работ показать. А то как-то однобоко выходит. 60% пунктов ТЗ с несоответствием - это серьезно.
Напишу по-другому. В аудите было около 20 пунктов с ошибками. 12 из них были либо вообще выдуманные, либо Заказчик сам попросил эти работы сделать вопреки ТЗ.
8 ошибок были на нашей совести. Но там ошибки были формата "на пиксель левее, чем по ТЗ". То есть реально работ на 7-8 часов.
Это же Битрикс шаблон был, там сложно накосячить прямо и все работы там делаются очень быстро.
Можно работать с заказчиком поэтапно?
Взяли аванс за месяц. Через месяц показываем, что готово. Если заказчику нравится - платит еще за месяц вперед. И так пока не надоест.
Нет, проекты средней сложности делаются сразу с привлечением 3-4 специалистов. Допустим это подбор сервера/настройка, доработка шаблона, разработка структуры сеошником, интеграция с 1С (двусторонний обмен), настройка б24. Если это все делать поэтапно, то проект будет разрабатываться 1.5 года.
Спасибо за кейс, скину запрос. В шаблон договора же внесли правки на основе опыта?
Конечно
У меня ровно два вопроса:
1) Где @$%& кейс?! Что это за методичка менеджера-извращенца? Большинство пунктов пытаются дублировать положения гражданско-правового кодекса об деловых отношениях в очень грубой форме!
2) Если в ходе суда всё не ясно, то какая религия не позволила оспорить в аппеляции?!!