Договоры в digital: грань между паранойей и безопасностью

Этот материал — небольшая часть курса управления digital-проектами, и будет полезен в первую очередь руководителям проектов, аккаунт-менеджерам и руководителям на стороне агентств.

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

Давным-давно, когда мы были скромной региональной студией, клиенты искали у нас, в первую очередь, низкие бюджеты. В том числе — и крупные клиенты, за которых мы с радостью хватались и старались подстроиться под их требования. Однажды так к нам пришло одно из подразделений Газпрома — естественно, со своим договором. Мы ничего не стали в нём менять, просто внесли наши реквизиты и вернули. Через 2 недели от них пришел протокол разногласий :)

Сейчас мы работаем с клиентами только по своим контрактам.

Откуда берутся договоры

Скорее всего, у вас есть свой шаблон договора, который вы предлагаете клиентам. И скорее всего, вы его изначально взяли где-то в интернете и немного заточили под свои нужды. Мы начинали примерно с того же.

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

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

Рамочный договор: как это работает

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

Первые версии наших шаблонов договоров во многом были основаны на граблях, на которые мы когда-то успели наступить. Мы постепенно меняли документы с учетом изменений в законодательстве и новых подводных камней, на которые натыкались — не переписывали полностью, но добавляли «заплатки». В итоге те стали громоздкими и неудобными.

В 2017 году сделали рефакторинг: навели порядок в шаблонах документов и практически полностью их переработали с помощью юристов RunetLex. Теперь все договоры в студии — типовые, а в юридической безопасности шаблонов мы уверены на 100%, поскольку те максимально закрывают риски, возникающие при наших процессах. Плюс нам удалось организовать процесс работы с документами так, чтобы менеджерам было реально сложно допустить грубую ошибку при подготовке контрактов.

Несколько правил:

• Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
• Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам. Не забывайте периодически проводить ревизию шаблонов и актуализировать их.
• Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.

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

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

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

Правки по договору от заказчика: хорошо или плохо

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

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

Так что уж лучше пусть правки будут :) Главное — не слишком много: так и согласовать проще, и условия контракта останутся выгодными для обеих сторон. Какими бывают правки:

1. Вопросы по процессам. Их обычно задают руководители проектов на стороне заказчика. В ответ можно просто подробно объяснить, что к чему, и вопросы отпадут сами собой.
2. Попытки получить более выгодные для заказчика условия работы. Больше итераций правок, меньше сроки, ниже цены, скидки, а лучше — вообще все вчера и бесплатно. С такими правками мы работаем с позиции логики: объясняем, что стоимость и сроки строятся, исходя из трудоемкости. Надо больше итераций правок — не вопрос, но тогда нужно больше денег и дней. Надо дешевле — предлагаем выкинуть часть строк из сметы.
3. Правочки от юристов заказчика. Обычно направлены на то, чтобы к юридическому отделу заказчика было не прикопаться и чтобы показать, как хорошо юристы работают на благо компании. И вот тут может быть что угодно.

Мы используем ряд адекватных приемов, которые помогают согласовать договор быстро и без ущерба для нашей стороны.

Пожертвовать некоторыми пунктами

Можно предусмотреть в договоре особые «гибкие» пункты, которые помогут подстроиться под особенности конкретного заказчика. Их отсутствие фатально не скажется на трудоемкости, сроках, стоимости, не слишком усложнит работу и не создаст серьезных рисков.

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

Это могут быть положения, дублирующие нормы законодательства, или нюансы работы, которые в целом вам были бы удобны, но и без них процесс не пострадает. Такие пункты специально отмечены у нас в шаблонах, чтобы аккаунт-менеджеры и руководители проектов могли сами решить вопросы по ним с заказчиками.

Предложить альтернативную формулировку

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

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

Пример — в такой формулировке согласовать пункт не удалось:

Заказчик предоставляет Подрядчику право на использование своего имени (наименования), логотипов, товарных знаков, коммерческих обозначений в портфолио и информационных материалах Подрядчика. Заказчик предоставляет Подрядчику право на анонсирование результатов всех работ по Договору.

А в такой — согласовали:

Заказчик предоставляет Подрядчику право на использование своего наименования и логотипа в портфолио и информационных материалах Подрядчика, а также на анонсирование результатов всех работ по Договору при условии предварительного согласования текста анонса с Заказчиком, путем отправки на e-mail ответственного лица Заказчика не позднее, чем за 2 рабочих дня до предполагаемой публикации.

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

Отзеркалить санкции

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

Эскалировать, если согласование затягивается

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

Проверить контрагентов на предмет судебной истории

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

Предосторожность — не паранойя

В процессе документооборота бывает всякое, и потерять бдительность легко (особенно когда вы давно работаете с клиентом). Вот несколько правил, которые снизят риск возникновения проблем при согласовании и подписании документов:

Не давайте юристам заказчика документы в Word. Если по каким-то причинам заказчику обязательно нужен файл, можно отправить договор в формате pdf. Проще самим перенести пункты из протокола разногласий в комментарии в Google.Docs, чем потом полностью проверять текст на наличие не отмеченных изменений.

Сверяйте документы, полученные от заказчиков хотя бы по-абзацно (а лучше целиком). Бывает, заказчики добавляют 2-3 правки в режиме редактирования, а остальные вносят по-тихому, в надежде, что никто не заметит (а может, и с какой-то другой мотивацией). У нас было два таких случая за последний год: менялись сроки, суммы и процессы.

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

Если документы подписывает не генеральный директор — требуйте доверенность. И проверяйте, что она не просрочена. Иначе по суду договор можно признать недействительным, и как бы хорошо вы ни выполнили работу — придется вернуть деньги. С нами такого не случалось, но как только услышали о подобном от одного из коллег — добавили себе в процессы.

Проверяйте подписи. Удостоверьтесь, что подпись на конкретном документе совпадает с образцом подписи в рамочном договоре и вообще имеет что-то общее с именем подписанта. Из-за подписи документы также могут признать недействительными. А дальше — «всем встать, суд идёт» и всё прилагающееся.

И ещё порция лайфхаков

• Если не согласовали документы за 2 итерации — назначайте звонок. Обсуждайте правки голосом, это сэкономит вам часы на переписке и на пару недель сократит переговоры. Удобнее всего созвониться по скайпу с расшаренным экраном, и сразу внести согласованные моменты в договор.
• Если правки по договору от заказчика приходят более 3-4 раз — иногда бывает лучше отказаться от работы по проекту. Хотя для больших компаний это норма. Не так давно мы отказались от проекта, когда поняли, что на обсуждение только рамочного договора потрачено уже более 60 часов (и это без обсуждения приложений к нему).
• Если заказчик просит внести в документ изменения, юридические последствия которых вы не в состоянии просчитать — или консультируйтесь с хорошим юристом (гуглить тут довольно опасно), или просто не соглашайтесь на них.

В остальном — достаточно руководствоваться здравым смыслом и интуицией. Про наши шаблоны документов и лайфхаки по работе с юристами заказчика много информации в блоге. Полный комплект шаблонов договоров для студии можно получить на нашем курсе «Управление Digital-проектами».