Вы должны использовать контракт.
Мы обсуждали это много раз прежде , но важно задокументировать масштаб проекта и обязанности каждого клиента. С самого начала можно избежать дорогостоящих недоразумений и юридических махинаций.
Краткий и легкий для чтения контракт, как правило, написан вами и подписан обеими сторонами. Однако иногда вы можете обнаружить, что клиент заключает договор, когда вы беретесь за работу в агентстве или взимаете почасовую плату за свои услуги.
Это может показаться очевидным, но: прочитайте это . Дважды.
Контракты являются обязательным соглашением. Никто не будет пытаться поймать вас (надеюсь), но контракты редко пишутся теми, кто имеет опыт разработки программного обеспечения или опыт. Кажущаяся невинной оговорка может нанести непоправимый ущерб вашему бизнесу.
Рассмотрим это утверждение в недавнем контракте, который мне выдан:
Консультант [я] несет ответственность за любые дефекты, возникающие в связи с Услугами [моей разработкой], и должен за свой счет устранить такие дефекты, которые могут быть устранены в течение разумного периода с момента уведомления.
Остальная часть документа состояла из безобидных требований «не кради скрепок и не заглядывай на хитрые сайты», но этот поразительно неопределенный пункт заставил меня нервничать по нескольким причинам:
- Что такое «дефект» ? Что касается программного обеспечения, то это может быть ошибка, отсутствующая функция, недокументированное требование, виджет, который не соответствует 1 пикселю в IE6, или любое количество иррациональных прихотей от генерального директора мании величия.
- Дефект может возникнуть «по отношению» к моей работе. Возможно, новая версия jQuery не поддерживает устаревшее устройство BlackBerry. Возможно, новая версия Firefox изменяет или удаляет функцию, которую я использовал. Возможно, следующее издание языка или фреймворка, которое я использую, несовместимо с предыдущей версией. Возможно, я не написал оскорбительный код, но он все еще относится к моему.
- «Способен на лекарство» ? Это все и вся. Клиенты часто заявляют, что хотят стать следующим Google, Facebook, Amazon или eBay. В амбициях нет ничего плохого, но должны ли разработчики отвечать за исправление фундаментальных проблем, если компания не достигает этих целей?
- Что такое «разумный период» ? Одна неделя? Месяц? Пять лет?
Несмотря на то, что я понимал намерение этого пункта, сложный или требовательный клиент мог ожидать, что я буду работать много месяцев бесплатно, пока их проект не достигнет невозможного уровня совершенства.
Как разработчик, вы понимаете сложности. Программное обеспечение может быть улучшено до бесконечности, и все продукты имеют ошибки. Даже если ваш код совершенен, как насчет библиотек, от которых вы зависите, базы данных, промежуточного программного обеспечения, операционной системы или операционной системы удаленного пользователя или веб-браузера? Вы понимаете, что код, который вы пишете сегодня, не обязательно совместим с программными стеками и браузерами завтрашнего дня.
Ценит ли ваш клиент, что программное обеспечение нуждается в обновлении и обслуживании? Лучше объяснить вопросы до подписания контракта, чем спорить с горячим адвокатом через несколько месяцев.
Я поставил под сомнение жизнеспособность вышеуказанного пункта и отказался подписывать. Агентство было ошеломлено; они много лет использовали один и тот же стандартный документ, и я был первым, кто высказал возражение. Для этого есть три возможные причины:
- Я неправильно понял значение или контекст заявления. Однако договор — это взаимопонимание между двумя сторонами, и вы никогда не должны соглашаться на что-то непонятное.
- Другие разработчики пришли к такому же выводу, но подписали независимо. Возможно, они были обеспокоены потерей работы или суетой, но контракт никогда не должен предъявлять необоснованные требования любой из сторон.
- Самая простая причина: никто больше не читал это . Немногие разработчики имеют юридическую экспертизу, но если вам нужны эти знания, чтобы понять последствия, не подписывайте. В данном конкретном случае документ не был длинным или сложным — разработчикам было лень смотреть на мелкий шрифт.
Контрольный список для чтения контракта
Контракты очень сложны для чтения, но они приносят пользу вам и вашим клиентам. Несколько часов изучения мелких деталей могут сэкономить месяцы усилий.
Выполнение следующих шагов перед тем, как подписать пунктирную линию, поможет вам избежать проблем:
- Всегда читайте свой контракт. Тогда прочитайте это снова. Должным образом. Без пропусков бит.
- Попросите друга или коллегу прочитать это. У них будут разные представления о контексте.
- Не торопитесь и не чувствуйте давление в подписании быстро. Если клиент запугивает вас до того, как вы начнете с ним работать, представьте, как он будет себя чувствовать, когда будет платить!
- Контрактные заявления должны быть однозначными. Не упустите пункты, которые являются расплывчатыми или могут иметь двойное значение.
- Рассмотрим наихудшие сценарии. Например, что может произойти, если клиент не был счастлив? Что если бы мне пришлось покинуть проект преждевременно? Что делать, если я не смог выполнить задачу в срок?
- Спрашивайте каждое неясное утверждение, которое вы не понимаете или с которым не согласны.
- При необходимости измените договор — никогда не принимайте словесные заверения клиента.
- Если договор слишком сложен, запросите более простую альтернативу на понятном языке.
- Если ничего не помогло, проконсультируйтесь с экспертом по правовым вопросам. Предупредите клиента, что эти дополнительные расходы будут списаны с него. Они поймут, если договор обязательно сложный.
- Если у вас есть какие-либо сомнения, не подписывайте и будьте готовы уйти с работы.
Вас просили подписать контракты с нелепыми требованиями или невозможными ультиматумами? Вы решили проблему или подписали в любом случае?