Что я включаю в договор с клиентом после 400 проектов
Договор — это документ из рубцовой ткани
Мой первый договор занимал две страницы. По сути он гласил: «Я проектирую, вы платите, вот примерно когда». Это была оптимистичная формулировка — такая, какую может написать только человек, которого ещё ни разу не обожгли. Примерно на 40-м проекте клиент попросил «просто немного подправить», что превратилось в шестинедельный редизайн без дополнительной оплаты. Примерно на 90-м кто-то пропал на четыре месяца в середине проекта, а потом объявился, ожидая, что я продолжу ровно с того места, где остановился, по той же цене и в те же сроки. Примерно на 150-м клиент забрал мои файлы из Figma, передал их штатной команде и выпустил продукт, подозрительно похожий на мой неопубликованный концепт — ещё до того, как мне оплатили последний счёт. Каждая из этих ситуаций чему-то меня научила, и договор, которым я пользуюсь сегодня, — это по сути рубцовая ткань, оформленная в виде абзацев. Это не юридический документ, призванный кого-то запугать. Это запись всех способов, которыми проект может пойти наперекосяк, зафиксированная, чтобы это не повторялось дважды одинаково. Я говорю об этом сразу, потому что, как мне кажется, многие дизайнеры подходят к договорам не с того конца. Они скачивают шаблон, вписывают своё имя и ставку — и считают дело сделанным. Шаблоны — неплохая отправная точка, но они рассчитаны на гипотетического среднего клиента, а ваши реальные клиенты никогда не бывают средними. После 400 проектов — некоторые прошли гладко, некоторые были по-настоящему болезненными — я пришёл к конкретному набору пунктов, которых нет в большинстве типовых шаблонов, потому что большинство типовых шаблонов не было рядом, когда всё реально ломалось. В этой статье я разберу, что сейчас есть в моём договоре, и, что важнее, какая именно ситуация привела к появлению каждого пункта. Я не юрист, и это не юридическая консультация — в каждой юрисдикции и в каждых отношениях с клиентом всё по-своему, и перед отправкой договора стоит показать его настоящему адвокату. Но я усвоил: договор, написанный на основе пережитого опыта, даже несовершенный, защищает сильнее, чем идеальный документ, который вы сами не до конца понимаете.
Объём работ должен быть списком, а не абзацем
Самый большой источник конфликтов за 400 проектов — никогда не деньги. Это объём работ. Точнее, разрыв между тем, за что, по мнению клиента, он платит, и тем, что, по мнению дизайнера, он должен сдать. В начале карьеры объём работ в моих договорах описывался текстом: «Дизайн адаптивного маркетингового сайта, включая главную страницу, страницу «о компании» и страницу контактов». Эта фраза кажется точной — пока клиент резонно, с его точки зрения, не спросит: «А как же страница с тарифами? Это же тоже часть маркетингового сайта». Текстовое описание объёма — это заранее запрограммированные переговоры, потому что каждое существительное в нём можно трактовать по-новому. Теперь объём работ в моих договорах оформляется буквально как пронумерованный список, детализированный до уровня экрана или компонента, с явными исключениями. Для сайта это выглядит так:
- Главная страница (десктоп и мобильные брейкпоинты, 1 вариант макета, 2 раунда правок)
- Страница «о компании» (десктоп и мобильная версия)
- Страница тарифов (десктоп и мобильная версия, до 3 тарифных планов)
- Страница контактов (десктоп и мобильная версия)
- Навигация и футер, оформленные единообразно во всех перечисленных разделах
- Не включено: шаблоны блога, экраны личного кабинета/авторизованной зоны, email-шаблоны, печатные материалы, а также любые дополнительные страницы сверх перечисленных выше
Последняя строка — явное исключение — это то, что пропускает большинство договоров, и именно она сэкономила мне больше всего нервов. Клиенты в большинстве случаев расширяют объём работ не из злого умысла — они просто действительно не знают, где граница, пока вы её не прочертите. Формулировка «не включено» вынуждает провести разговор до старта проекта, а не спор на шестой неделе. Я также научился фиксировать число «раундов обратной связи» на каждый результат работы, а не на проект в целом. Однажды клиент истолковал «два раунда правок» как два раунда суммарно на всё приложение из двенадцати экранов, из-за чего один раунд правок на экран становился практически нереализуемым — всю обратную связь тратили на обсуждение цвета кнопок на первых трёх экранах, а потом ожидали безлимитных правок на остальные, потому что «мы же ещё не использовали свои правки». Теперь в договоре правки указаны на каждый результат отдельно: два раунда обратной связи на экран или компонент, всё сверх этого оплачивается по часовой ставке для доп. работ, о которой я расскажу дальше. Текста стало больше, зато исчез целый класс разногласий. Ещё один урок про объём работ случился на проекте, где разговор о «небольшом обновлении логотипа» на стартовой встрече как-то незаметно превратился в ожидание, что я заодно переделаю визитки, подпись в email и шаблоны для соцсетей — «раз уж вы всё равно этим занимаетесь». Ничего из этого не было в подписанном объёме работ. Я не сказал чёткое «нет», а клиент не действовал злонамеренно — неопределённость устного разговора просто незаметно расширила проект. Теперь в договоре есть строка: «Любые результаты работы, явно не перечисленные в разделе «Объём работ» выше, считаются выходящими за рамки проекта независимо от обсуждений на встречах или звонках и оцениваются отдельно». Написанная так фраза звучит почти агрессивно, но за четыре года использования именно этой формулировки ни один клиент ни разу против неё не возразил. А те, кто начинает спорить с такой фразой, — это, честно говоря, именно те, кого полезно распознать до поступления предоплаты.
Доп. соглашения превращают «а можете просто» в оплачиваемую работу
Список объёма работ решает проблему исходной границы, но не решает того, что происходит после старта проекта, когда появляются новые, законные потребности. Клиент вдруг обнаруживает, что ему нужен ещё и флоу оформления заказа, или решает, что страница тарифов из трёх уровней на самом деле должна поддерживать пять, или у стейкхолдера, которого не было на стартовой встрече, внезапно появляются мнения. Это не недобросовестное расширение объёма — это нормальная эволюция бизнеса. Но за нормальную эволюцию бизнеса всё равно нужно платить, и для этого нужен механизм, который не требует каждый раз неловкого разговора о пересмотре условий. Таким механизмом служит пункт о доп. соглашениях — один из наиболее недооценённых инструментов в договорах фрилансеров. У меня он звучит примерно так: любой запрос, выходящий за рамки определённого объёма работ, оформляется как доп. соглашение с кратким описанием работы, оценкой часов и дополнительной стоимостью, и работа по этому соглашению не начинается, пока клиент не одобрит его письменно (достаточно email). В договоре прямо указано, что устного согласия на звонке недостаточно — нужно письменное подтверждение, даже если это просто короткий ответ «да, согласен» на email. Я добавил это требование после звонка, на котором клиент сказал «да, давайте добавим это» про дополнительный экран дашборда. Я сделал работу, а при выставлении счёта мне сказали, что не помнят, чтобы соглашались на что-то сверх изначального объёма. Я верю, что они действительно не помнили — звонок был насыщенным, с шестью пунктами повестки, — но без ничего письменного мне не на что было опереться, и стоимость этого дополнительного экрана я покрыл сам. Теперь каждое доп. соглашение — это короткая письменная переписка до того, как я открою Figma, и весь процесс стал не медленнее, а быстрее, потому что исчезла неопределённость, которая раньше приводила к спорам при выставлении счёта. Ещё одна вещь, которую я научился закладывать в пункт о доп. соглашениях, — это стандартная часовая ставка, которая включается автоматически, вместо того чтобы каждый раз заново обсуждать новую смету. Если моя ставка по проекту фиксированная, в договоре прописана отдельная часовая ставка для всего, что выходит за рамки объёма, — скажем, $150/час, — так что небольшие дополнения не требуют нового цикла согласования предложения. Клиенту, которому нужна ещё одна страница, не нужна трёхходовая переписка с переговорами — он получает быструю оценку в часах по заранее согласованной ставке, подтверждает её, и мы движемся дальше. Этот единственный пункт, пожалуй, спас больше отношений с клиентами, чем любой другой, потому что превращает «а можно ещё одну штуку добавить» из напряжённого момента в письмо из двух строк.
Условия оплаты, которые ничего не принимают на веру
Раньше я выставлял счета по схеме 50% предоплата и 50% по завершении. Это самая распространённая структура в индустрии, и, как я в итоге понял, она устроена так, что защищает клиента гораздо сильнее, чем дизайнера. «По завершении» — это субъективный критерий, который фактически контролирует клиент: если он решит, что работа не «завершена» из-за неразрешённого спора, обратной связи, которую он ещё не дал, или просто общего затягивания, эти финальные 50% могут бесконечно оставаться неоплаченными, хотя вы уже сделали 100% работы. После проекта, где получение финального платежа заняло пять месяцев — несмотря на сданную, одобренную и внедрённую работу, — я полностью перестроил систему оплаты вокруг этапов, привязанных к конкретным результатам работы, а не к размытым состояниям «готовности», и сместил бóльшую долю оплаты на начало. Сейчас для типового проекта это выглядит так:
- 30% предоплата перед началом любой работы, невозвратная после старта
- 30% по сдаче первоначальных концепций/вайрфреймов, до перехода к высокой детализации
- 30% по сдаче финальных дизайнов в высокой детализации, до передачи файлов для разработки
- 10% по финальной передаче и закрытию проекта
Помимо самих процентов, здесь важны две вещи. Во-первых, каждый платёж привязан к конкретному, однозначному результату работы, а не к ощущению «готовности». Во-вторых, я не перехожу к следующему этапу работы, пока не поступил предыдущий платёж. Раньше требовать соблюдения этого правила казалось мне конфронтационным, но я обнаружил, что клиенты, которые платят надёжно, не моргнув глазом соглашаются на это, а те, кто начинает возражать, как правило, всё равно становятся проблемой позже. Это ранний фильтр, а не просто инструмент управления денежным потоком. Я также добавил отдельный пункт о просрочке платежа, который не имеет ничего общего с юридическими угрозами и полностью связан с простой механикой: на счета, не оплаченные после 15 дней, начисляется пеня 1,5% в месяц, а работа по любому счёту, не оплаченному после 10 дней, полностью приостанавливается до поступления оплаты. Пункт о приостановке работы важнее пени — пеню в небольших суммах редко имеет смысл взыскивать, но автоматическая приостановка означает, что я никогда не окажусь в ситуации, когда делаю неоплаченную работу четвёртую неделю подряд в надежде, что счёт за вторую неделю когда-нибудь всё же оплатят. Договор делает приостановку автоматической и заранее согласованной, так что применять её — не конфронтация, а просто то, что документ изначально и предполагал. Наконец, есть пункт о компенсации при досрочном завершении проекта по любой причине — сокращение бюджета клиента, смена направления, реструктуризация компании, что угодно. Если проект завершается после предоплаты, но до окончания работы, клиент оплачивает все завершённые этапы плюс 20% стоимости следующего этапа — это компенсирует работу по приостановке, оформлению передачи и упущенную выгоду от слота в графике, который я для него держал. До появления этого пункта досрочное завершение проектов означало, что я беру на себя стоимость недоделанного проекта и пустого окна в календаре, под которое я уже всё спланировал. Теперь этот риск заложен с самого первого дня, и на практике пункт применяется редко — но сам факт его наличия в письменном виде сделал разговоры о приостановке или досрочном завершении проектов гораздо менее напряжёнными, потому что никому не нужно договариваться о справедливости в моменте: справедливость уже была согласована до того, как кто-то расстроился.
Определение «готово», чтобы правки не стали бесконечными
«Безлимитные правки» — фраза, которую я иногда вижу на сайтах других дизайнеров, обычно как рекламное преимущество, и, по моему опыту, это одно из самых опасных обещаний, которые может дать дизайнер. Не потому, что клиенты по своей природе неразумны, а потому, что без определённой конечной точки не существует естественного механизма, подталкивающего проект к завершению. Однажды я работал с клиентом над логотипом, у которого в раннем тарифном пакете были зашиты «безлимитные правки», и мы прошли через 14 раундов концепций за четыре месяца на проекте, который должен был занять три недели, потому что каждый раунд выявлял мнение нового стейкхолдера, а договорной причины остановить процесс не было. Во всех последующих договорах я указываю точное число раундов правок на каждый результат работы, что именно считается «раундом» и что происходит, когда эти раунды исчерпаны. Раунд, согласно определению в моём договоре, — это одна объединённая порция обратной связи, переданная за один раз, которую я затем обрабатываю в одной обновлённой версии. Это определение важно, потому что клиенты иногда присылают обратную связь пятью отдельными сообщениями за три дня, каждый раз с новыми замечаниями — «ой, а ещё давайте сделаем синий чуть темнее» приходит через два дня после сообщения «утверждено, выглядит отлично». Без чёткого определения каждое такое сообщение можно было бы считать отдельным «раундом». В моём договоре прямо указано, что обратная связь должна быть собрана воедино и передана как единый раунд в рамках установленного срока (я использую пять рабочих дней), а обратная связь, пришедшая после этого срока или по частям, засчитывается в следующий раунд, а не обнуляет отсчёт текущего. Я также добавил конкретное определение того, что происходит, когда раунды правок заканчиваются: дополнительные раунды оплачиваются по стандартной часовой ставке для доп. работ и являются опциональными — клиент также может просто принять текущую версию как финальную. Это убирает любую неопределённость насчёт того, обязан ли я бесплатно продолжать итерации сверх согласованного числа, и снимает неловкость, когда мне пришлось бы поднимать вопрос оплаты в середине процесса правок — договор уже всё решил заранее. Ещё одно дополнение появилось после проекта, где клиент продолжал просить «ещё одну маленькую правку» логотипа, в итоге их набралось одиннадцать отдельных «маленьких правок»: теперь в договоре раунд правок определяется как изменения в рамках одного и того же творческого направления, и отдельно указано, что запрос совершенно нового творческого направления (а не доработка утверждённого) считается новым результатом работы, требующим отдельного обсуждения объёма и оплаты. Это разграничение — доработка против нового направления — оказалось по-настоящему полезным в разговорах, потому что даёт нам обоим общий язык. Я могу сказать: «это больше похоже на новое направление, а не на доработку того, что мы утвердили, так что давайте оценим это как дополнение» — вместо того чтобы просто чувствовать себя загнанным в угол и молча брать на себя лишнюю работу, как я делал раньше.
Права на интеллектуальную собственность не переходят, пока не оплачен счёт
Это пункт, появившийся после худшего отдельного случая за 400 проектов, так что опишу его без прикрас. Я сдал финальные файлы в высокой детализации для редизайна приложения, клиент сказал, что ему всё нравится, а потом на три недели замолчал по поводу финального счёта. За это время молчания приложение было запущено — с моим дизайном, по сути без изменений, — силами внутренней команды, которую клиент, видимо, нанял в середине проекта, не упомянув об этом. В итоге я получил оплату после неприятной переписки, но этот случай вскрыл пробел во всех договорах, которыми я до этого пользовался: ни в одном из них прямо не указывалось, когда право собственности на дизайн переходит к клиенту. Большинство фриланс-дизайнеров предполагают, что право собственности переходит в момент сдачи работы. На самом деле это не так, если договор прямо этого не устанавливает — а даже если устанавливает, слово «сдача» достаточно размыто, чтобы его стоило уточнить предельно конкретно. Теперь в моём договоре прямо указано, что все права интеллектуальной собственности на результаты работы — включая исходные файлы, экспортированные материалы и любые связанные дизайн-системы — остаются за дизайнером до получения полной и окончательной оплаты, после чего права полностью переходят к клиенту. До финальной оплаты клиент получает ограниченную лицензию на просмотр и обсуждение работы исключительно в целях обратной связи — не на внедрение, публикацию или передачу сторонней команде разработчиков. Этот пункт ни разу не пришлось всерьёз применять через какие-либо юридические действия, но он изменил тон нескольких ситуаций с медленной оплатой, потому что я могу указать на конкретную строку, которая по сути говорит: «это ещё не ваше, чтобы это внедрять». Это совсем другой разговор, чем попытка выбить оплату, не имея никаких рычагов влияния. Я также добавил отдельный пункт о том, что происходит с незавершёнными файлами, если проект прекращается досрочно: незавершённые результаты работы остаются собственностью дизайнера и не подлежат передаче, если клиент не оплатил этап, покрывающий именно эту работу. Это появилось после ситуации, когда проект был отменён на середине создания дизайн-системы, и клиент попросил передать наполовину готовый файл в Figma «просто посмотреть, как там дела», что я изначально сделал из доброй воли — а потом больше не получил от него вестей, несмотря на неоплаченный счёт за этап. Наполовину готовая работа имеет реальную ценность; передавать её бесплатно только потому, что проект неловко завершился, — это то, чего я больше не делаю, и договор прямо это оговаривает, а не оставляет на усмотрение в моменте. С другой стороны — и это важно для доверия, а не только для защиты — я также прямо указываю, что клиент ПОЛУЧАЕТ после окончательной оплаты: полное право собственности на финальные результаты работы, права использования без каких-либо ограничений на то, как он коммерчески использует работу, и исходные файлы в редактируемом формате (а не только экспортированные PDF или PNG). В начале карьеры я был неконкретен насчёт форматов файлов, и один клиент решил, что «результаты работы» означают финальные экспортированные изображения, а не редактируемые исходные файлы, и был расстроен, узнав, что за реальный файл в Figma нужно платить дополнительно. Чёткое указание того, что именно переходит и в каком формате, предотвращает подобное разочарование в самый неподходящий момент — когда проект формально уже завершён, а отношения сворачиваются.
Границы коммуникации защищают не только моё время, но и саму работу
Это самая новая категория пунктов в моём договоре, появившаяся лишь в последние пару лет, и она возникла из-за более медленной и коварной проблемы, чем описанные выше драматичные случаи: расползание объёма работ и выгорание, вызванные не каким-то одним плохим событием, а накоплением ожиданий постоянной доступности. Клиент мог написать в 9 вечера «просто быстрый вопрос», потом ещё одно сообщение в 7 утра, потом тред в Slack с участием четырёх человек, которые помечают меня на выходных по поводу решения, которое вполне могло подождать до понедельника. Ничего из этого не было злонамеренным. Просто нигде письменно не было зафиксировано, какая скорость ответа считается разумной, так что ожидание незаметно подстраивалось под то, что я готов был терпеть, — а поскольку мне хотелось выглядеть отзывчивым и удобным в работе, терпимость продолжала расти. Теперь в моём договоре есть небольшой раздел об ожиданиях по коммуникации: основное общение происходит через один согласованный канал (email или инструмент управления проектом, но не личный номер телефона или личные соцсети), время ответа — один рабочий день для несрочных запросов, а работа не ведётся по выходным или вне стандартных рабочих часов, если это не согласовано заранее и не оплачивается как срочная работа по повышенной ставке. Звучит почти мелочно для юридического документа, но я обнаружил, что если прописать это заранее, до того, как сформировалась динамика отношений, это становится нейтральной политикой, а не личной границей, которую я отстаиваю в середине проекта, когда напряжение уже немного выросло. При подписании никто ни разу не возразил против этого пункта. Некоторые клиенты слегка проверяли его на практике — то сообщение поздно вечером, то ещё что-то, — но наличие письменной договорённости, на которую можно сослаться, позволяет спокойно ответить на следующий рабочий день без чувства вины и без объяснений. Я также добавил пункт о частоте встреч, ограничивающий число включённых звонков на этап проекта (я использую два на этап: стартовый и итоговый), а дополнительные встречи сверх этого оплачиваются по часовой ставке либо требуют отдельного согласования графика. Это появилось после проекта с клиентом, который назначал звонки почти каждый день «просто сверить часы», каждый по 30–45 минут, — ни один из них по отдельности не был неразумным запросом, но все вместе они съедали время, которое изначально не было заложено в смету. Встречи кажутся клиентам «бесплатной» коммуникацией в отличие от часов дизайна, но они стоят реального времени и внимания, и теперь договор это отражает. Основной принцип, стоящий за всем этим разделом, — то, что я хотел бы понять раньше: клиенты не ведут себя неразумно, когда прощупывают границы доступности, потому что большинство из них никогда раньше не работали с фрилансером и не представляют, что является нормой. Задача договора не в том, чтобы устыдить их за вопрос, а в том, чтобы ответить на этот вопрос прежде, чем его придётся задавать, — так граница устанавливается нейтральным документом, а не лично мной, говорящим «нет» в реальном времени.
Что бы я сказал тому, кто делает 1-й проект, а не 400-й
Если вы только начинаете во фриланс-дизайне и, читая это, думаете, что вам нужно всё это с первого дня, — это не так, и пытаться с самого начала навесить на первого же клиента договор уровня 400-го проекта, скорее всего, контрпродуктивно: это будет выглядеть враждебно со стороны человека, который ещё не заработал репутацию, позволяющую казаться настолько осторожным, и это замедлит сделки, которые вам действительно нужно закрыть. Честная версия этого совета в том, что договор должен расти ровно с той же скоростью, с какой растёт ваша рубцовая ткань, — и не быстрее. Если бы я заново строил всё с нуля, я бы в первую очередь уделил внимание списку объёма работ и исключениям, потому что именно эта привычка предотвращает больше споров, чем все остальные пункты вместе взятые. Во вторую очередь — структуре платежей по этапам, потому что проблемы с денежным потоком накапливаются и отвлекают от самой дизайн-работы быстрее, чем почти всё остальное. Всё остальное — сроки передачи прав на интеллектуальную собственность, определения раундов правок, границы коммуникации — можно добавлять по мере того, как вы столкнётесь с конкретной ситуацией, заставляющей пожалеть, что этого пункта не было. Вы с такой ситуацией столкнётесь. С ней сталкиваются все. Вопрос только в том, запишете ли вы этот пункт потом — или просто будете молча обижаться на подобных клиентов всю жизнь. Ещё одна вещь, которую стоит сказать честно: такой детальный договор — это не в первую очередь юридический щит. За четыре года использования версии, близкой к этой, мне ни разу не пришлось реально обращаться в суд по поводу какого-либо из этих пунктов. Его настоящая ценность в том, что он проводит неприятные разговоры заранее, нейтральным письменным языком, до того как на кону оказываются деньги или отношения. Никто не чувствует себя задетым, читая список исключений из объёма работ на этапе онбординга. Зато все чувствуют себя задетыми, впервые услышав «это на самом деле выходит за рамки того, о чём мы договорились» на шестой неделе от человека, на которого они в данный момент злятся. Договор просто переносит каждый сложный разговор в тот единственный момент в отношениях, когда его провести дешевле всего, — в начало, до того как кто-то успел вложиться, разозлиться или ждать результата. После четырёхсот проектов мой договор занимает девять страниц и каждый год немного разрастается. Это не признак того, что отношения с клиентами становятся хуже. Это признак того, что я продолжаю сталкиваться с новыми, конкретными способами, которыми всё может пойти не так, — и я предпочитаю один раз записать каждый из них, чем учиться на нём дважды.
