Этот материал — небольшая часть курса управления digital-проектами, и будет полезен, в первую очередь, руководителям проектов, аккаунт-менеджерам и руководителям на стороне агентств.
Поделиться своим опытом мы решили неспроста: неприятные кейсы от коллег по отрасли и самостоятельно набитые шишки подсказывают, что эта тема — больная для многих (причём, не только в IT). Читайте в материале, какую структуру договора выбрать при работе по SCRUM (и почему), а главное — как отстоять её у юристов заказчика. Лайфхаки при согласовании, 5 правил предосторожности, пара реальных историй, а также процесс документооборота в студии Сибирикс изнутри — здесь.
Мало кто пишет договор под каждого клиента с нуля. Практически у каждой компании есть какой-то шаблон, чаще всего, взятый из интернета и отредактированный. Мы начинали примерно с того же. При работе по водопадной модели с документооборотом было просто: работы сразу оценивались и фиксировались в договоре на этапе продажи.
Лет 8 назад мы начали работать по SCRUM — первые в web-разработке (отдельный пост с холиваром по этому поводу уже в архиве ;). Это было очень круто, но наш привычный и уютный шаблон договора плохо вязался с новыми процессами.
Ключевой стала идея сделать рамочный договор плюс приложения к нему на каждый этап разработки. Такой договор определяет общий порядок и условия работ, при этом риски и мы, и клиент несем только в рамках текущего Приложения — иными словами, в рамках одного этапа работ.
В этот шаблон мы постепенно вносили правки и дополнения, исходя из всех набитых нами же шишек. Он постепенно разросся, стал сложным для чтения и понимания. На проверки, правки, согласования стало уходить неприлично много времени. Встал вопрос «а не нужен ли нам юрист»?
Мы очень хорошо понимали, что не хотим заводить юриста в штате (он же ничего не производит, а значит будет бесить директора). Что у менеджеров не так много времени на работу с документами. При этом нам очень хотелось сделать документооборот безопасным. Поэтому мы провели рефакторинг шаблонов с помощью юристов Runetlex, и ввели специальные регламенты, которые очень сильно сократили и трудоемкость, и вероятность ошибок.
Например:
Самое неприятное, но неизбежное — это правки от юристов Заказчика. И их тоже надо проверять и оценивать на потенциальные риски. Выход — иметь проверенный шаблон контракта для каждого вида услуг и контрольный список для работы с возражениями (своим шаблоном мы делимся здесь). Тогда для ведения переговоров надо не так много времени и достаточно здравого смысла.
Бывает три типа правок, по работе с которыми мы пользуемся разными алгоритмами:
Первый шаг — заранее предусмотреть в договоре пункты, специально предназначенные, чтобы проявить гибкость и подстроиться под особенности конкретного заказчика. Это могут быть положения, дублирующие нормы законодательства, или регламентирующие нюансы работы, удобные для вас, но не принципиальные. Те пункты, чем вы готовы поступиться. Их отсутствие не слишком повлияет на трудоемкость, сроки, стоимость, процессы или риски. Так что, если юристы заказчика будут очень просить, можно спокойно их исключить, предварительно защищая.
В наших шаблонах такие пункты выделены цветом, и менеджеры могут принимать по ним решения самостоятельно
К сожалению, кроме пунктов, которые вы заранее не очень-то и хотели, в документах есть и другие. Для вас они не просто важны, а принципиальны. Когда юристы заказчика пришлют правочки по ним — придется договариваться. Тут нет, и не может быть единого алгоритма, это всегда процесс переговоров.
По таким пунктам, в первую очередь, стоит предлагать альтернативную формулировку. Даже если другая версия содержит только незначительные уступки или уточнения, и в целом почти не отличается от прежней, зачастую её пропустят.
Сравните — эту формулировку юристы не согласовали:
А эту — пропустили:
Ещё лучше предварительно составить список пунктов, по которым часто возникают разногласия, и заранее приготовить альтернативы. Бонус такого списка — он позволяет частично делегировать обсуждение правок аккаунт-менеджерам и руководителям проектов.
Если какие-то пункты вы никак не можете согласовать, можно попробовать перевести переговоры на уровень выше. Часто достаточно сказать, что у вас не хватает полномочий, и решить вопрос можно только через генерального директора. Эскалация — всегда ресурсоемка для обеих сторон, поэтому по некритичным пунктам скорее всего вопросы решатся без нее.
Если заказчик просит добавить в договор санкции — например, за просрочку работ, — задумайтесь, не может ли он сам точно так же просрочить. Если да — добавляйте два зеркальных пункта: для себя, и для него. Мы не против ответственности за те параметры, которые полностью в нашей власти. Но ответственность — штука обоюдоострая. И это повод еще раз переоценить риски и, возможно, отказаться от санкций вообще.
В Картотеке арбитражных дел есть судебная история заказчика. Много исков к поставщикам? Да, может ему действительно постоянно не везет, но скорее его юридический отдел приносит пользу и зарабатывает деньги на лазейках в документах. Учтите это при оценке рисков и прибыльности проекта, а также при согласовании правок. Например, это важный аргумент при согласовании пункта о подсудности.
Кроме скриптов по согласованию правок, в наших регламентах есть ряд правил предосторожности, которые будут полезны в любой отрасли:
Правило 1. Никаких документов в Word. Заказчику мы отдаем документы в режиме редактирования в гуглодоках, либо (если юристам заказчика обязательно нужен файл) файл в формате pdf. Проще перенести пункты из протокола разногласий в Google.Docs, чем полностью проверять текст из ворда на наличие не отмеченных изменений.
Правило 2. Сверять документы. Бывает, заказчики добавляют 2-3 правки в режиме редактирования, а остальные вносят по-тихому, в надежде, что никто не заметит. У нас было два таких случая: менялись сроки, суммы и процессы.
Правило 3. Проверять версии оригиналов от заказчика. Они внезапно могут отличаться от согласованного документа. К сожалению, в нашей практике несколько раз встречался и такой вариант.
Правило 4. Требовать доверенность, если договор подписал не гендиректор. И проверить, что она не просрочена. Иначе по суду договор можно признать недействительным, и как бы хорошо вы ни сделали свою работу, придется вернуть деньги. Кейс не вымышленный (поделились коллеги).
Правило 5. Проверять подписи. Подпись на конкретном документе должна совпадать с образцом подписи в рамочном договоре (и в учредительных документах компании, вы же запрашиваете у контрагентов их копии, да?) и иметь что-то общее с именем подписанта. Из-за сомнительной подписи документы также могут признать недействительными.
Мы считаем, что договор должен максимально-точно отражать реальные договоренности и правила игры. Он не должен мешать работать. В случае спорных ситуаций махать перед носом бумажками — слабая и сомнительная идея. Но порядок в документах должен быть. В остальном — достаточно руководствоваться здравым смыслом и интуицией.
Поделиться своим опытом мы решили неспроста: неприятные кейсы от коллег по отрасли и самостоятельно набитые шишки подсказывают, что эта тема — больная для многих (причём, не только в IT). Читайте в материале, какую структуру договора выбрать при работе по SCRUM (и почему), а главное — как отстоять её у юристов заказчика. Лайфхаки при согласовании, 5 правил предосторожности, пара реальных историй, а также процесс документооборота в студии Сибирикс изнутри — здесь.
Мало кто пишет договор под каждого клиента с нуля. Практически у каждой компании есть какой-то шаблон, чаще всего, взятый из интернета и отредактированный. Мы начинали примерно с того же. При работе по водопадной модели с документооборотом было просто: работы сразу оценивались и фиксировались в договоре на этапе продажи.
Лет 8 назад мы начали работать по SCRUM — первые в web-разработке (отдельный пост с холиваром по этому поводу уже в архиве ;). Это было очень круто, но наш привычный и уютный шаблон договора плохо вязался с новыми процессами.
Ключевой стала идея сделать рамочный договор плюс приложения к нему на каждый этап разработки. Такой договор определяет общий порядок и условия работ, при этом риски и мы, и клиент несем только в рамках текущего Приложения — иными словами, в рамках одного этапа работ.
В этот шаблон мы постепенно вносили правки и дополнения, исходя из всех набитых нами же шишек. Он постепенно разросся, стал сложным для чтения и понимания. На проверки, правки, согласования стало уходить неприлично много времени. Встал вопрос «а не нужен ли нам юрист»?
Мы очень хорошо понимали, что не хотим заводить юриста в штате (он же ничего не производит, а значит будет бесить директора). Что у менеджеров не так много времени на работу с документами. При этом нам очень хотелось сделать документооборот безопасным. Поэтому мы провели рефакторинг шаблонов с помощью юристов Runetlex, и ввели специальные регламенты, которые очень сильно сократили и трудоемкость, и вероятность ошибок.
Например:
- Новый договор всегда должен готовиться из шаблона, а не из договора от предыдущего заказчика. Извиняться за чужое название в документах — уже неприятно, а ведь еще бывают работы по NDA....
- Места, где могут меняться данные, выделены цветом: это реально экономит процентов 20 времени при подготовке документов из шаблонов.
- Перед отправкой договора заказчику, его в любом случае надо еще на раз проверить. И очень желательно — другим человеком. Проблема, что такой человек обычно в компании один. А документов может быть много (например, у нас больше 400 в год).
- И не только — регламент на самом деле немаленький.
Самое неприятное, но неизбежное — это правки от юристов Заказчика. И их тоже надо проверять и оценивать на потенциальные риски. Выход — иметь проверенный шаблон контракта для каждого вида услуг и контрольный список для работы с возражениями (своим шаблоном мы делимся здесь). Тогда для ведения переговоров надо не так много времени и достаточно здравого смысла.
Бывает три типа правок, по работе с которыми мы пользуемся разными алгоритмами:
- Уточнения по процессам. Чаще всего поступают от руководителей проектов на стороне заказчика. Обычно достаточно еще раз рассказать, почему работа будет построена так, а не иначе и какие преимущества это дает клиенту.
- «Выбивание» более выгодных условий. Больше итераций правок, меньше сроки, ниже цены. Что делать? Подключать здравый смысл, показывать, что стоимость и сроки напрямую зависят от трудоемкости. Надо больше итераций правок — ок, но потребуется больше денег и дней. Надо дешевле — сокращаем скоуп работ: всегда можно выкинуть часть функций из сметы. Бесплатно работать — грех.
- Правочки от юристов заказчика. Их бывает много, точнее МНОГО.Особенно в тех случаях, когда юрист старается не решить какую-то реальную проблему, а создать видимость работы. Правки могут быть не особо рациональны и понятны. Давайте, посмотрим, как с этим работать, чтобы согласовать документы с минимальными потерями.
Первый шаг — заранее предусмотреть в договоре пункты, специально предназначенные, чтобы проявить гибкость и подстроиться под особенности конкретного заказчика. Это могут быть положения, дублирующие нормы законодательства, или регламентирующие нюансы работы, удобные для вас, но не принципиальные. Те пункты, чем вы готовы поступиться. Их отсутствие не слишком повлияет на трудоемкость, сроки, стоимость, процессы или риски. Так что, если юристы заказчика будут очень просить, можно спокойно их исключить, предварительно защищая.
В наших шаблонах такие пункты выделены цветом, и менеджеры могут принимать по ним решения самостоятельно
К сожалению, кроме пунктов, которые вы заранее не очень-то и хотели, в документах есть и другие. Для вас они не просто важны, а принципиальны. Когда юристы заказчика пришлют правочки по ним — придется договариваться. Тут нет, и не может быть единого алгоритма, это всегда процесс переговоров.
По таким пунктам, в первую очередь, стоит предлагать альтернативную формулировку. Даже если другая версия содержит только незначительные уступки или уточнения, и в целом почти не отличается от прежней, зачастую её пропустят.
Сравните — эту формулировку юристы не согласовали:
Заказчик предоставляет Подрядчику право на использование своего имени (наименования), логотипов, товарных знаков, коммерческих обозначений в портфолио и информационных материалах Подрядчика. Заказчик предоставляет Подрядчику право
на анонсирование результатов всех работ по Договору.
А эту — пропустили:
Заказчик предоставляет Подрядчику право на использование своего наименования и логотипа в портфолио и информационных материалах Подрядчика, а также на анонсирование результатов всех работ по Договору при условии предварительного согласования текста анонса с Заказчиком, путем отправки на e-mail ответственного лица Заказчика не позднее, чем за 2 рабочих дня до предполагаемой публикации.
Ещё лучше предварительно составить список пунктов, по которым часто возникают разногласия, и заранее приготовить альтернативы. Бонус такого списка — он позволяет частично делегировать обсуждение правок аккаунт-менеджерам и руководителям проектов.
Если какие-то пункты вы никак не можете согласовать, можно попробовать перевести переговоры на уровень выше. Часто достаточно сказать, что у вас не хватает полномочий, и решить вопрос можно только через генерального директора. Эскалация — всегда ресурсоемка для обеих сторон, поэтому по некритичным пунктам скорее всего вопросы решатся без нее.
Если заказчик просит добавить в договор санкции — например, за просрочку работ, — задумайтесь, не может ли он сам точно так же просрочить. Если да — добавляйте два зеркальных пункта: для себя, и для него. Мы не против ответственности за те параметры, которые полностью в нашей власти. Но ответственность — штука обоюдоострая. И это повод еще раз переоценить риски и, возможно, отказаться от санкций вообще.
В Картотеке арбитражных дел есть судебная история заказчика. Много исков к поставщикам? Да, может ему действительно постоянно не везет, но скорее его юридический отдел приносит пользу и зарабатывает деньги на лазейках в документах. Учтите это при оценке рисков и прибыльности проекта, а также при согласовании правок. Например, это важный аргумент при согласовании пункта о подсудности.
Кроме скриптов по согласованию правок, в наших регламентах есть ряд правил предосторожности, которые будут полезны в любой отрасли:
Правило 1. Никаких документов в Word. Заказчику мы отдаем документы в режиме редактирования в гуглодоках, либо (если юристам заказчика обязательно нужен файл) файл в формате pdf. Проще перенести пункты из протокола разногласий в Google.Docs, чем полностью проверять текст из ворда на наличие не отмеченных изменений.
Правило 2. Сверять документы. Бывает, заказчики добавляют 2-3 правки в режиме редактирования, а остальные вносят по-тихому, в надежде, что никто не заметит. У нас было два таких случая: менялись сроки, суммы и процессы.
Правило 3. Проверять версии оригиналов от заказчика. Они внезапно могут отличаться от согласованного документа. К сожалению, в нашей практике несколько раз встречался и такой вариант.
Правило 4. Требовать доверенность, если договор подписал не гендиректор. И проверить, что она не просрочена. Иначе по суду договор можно признать недействительным, и как бы хорошо вы ни сделали свою работу, придется вернуть деньги. Кейс не вымышленный (поделились коллеги).
Правило 5. Проверять подписи. Подпись на конкретном документе должна совпадать с образцом подписи в рамочном договоре (и в учредительных документах компании, вы же запрашиваете у контрагентов их копии, да?) и иметь что-то общее с именем подписанта. Из-за сомнительной подписи документы также могут признать недействительными.
Мы считаем, что договор должен максимально-точно отражать реальные договоренности и правила игры. Он не должен мешать работать. В случае спорных ситуаций махать перед носом бумажками — слабая и сомнительная идея. Но порядок в документах должен быть. В остальном — достаточно руководствоваться здравым смыслом и интуицией.
Шаблон рамочного договора и приложения к нему — можно скачать здесь.
IT-Tiger
Отличная статья! К сожалению, все нюансы разработки не получается зафиксировать в договоре, поэтому приходится полагаться на порядочность подрядчиков, рейтинги, «сарафанное радио» и т.д.
zevvssibirix Автор
Предусмотреть вообще всё, увы, невозможно :)