Caira может проверить ваш контракт за 3 клика:

• Получите предложенные изменения и комментарии, добавленные прямо в ваш файл

• Сгенерируйте сводку по email, чтобы отправить другой стороне

Зарегистрироваться на бесплатную пробную версию можно менее чем за 30 секунд. Кредитная карта не требуется: Начать бесплатную пробную версию

«Работает на моей машине»: почему веб-разработчикам нужны лучшие контракты

Мир веб-разработки поражён «разрывом ожиданий».

Вы поставляете код, который соответствует спецификации. Клиент открывает его на iPhone 6 2014 года и кричит «Он сломан!»

Вы создаёте CMS, которую они просили. Через шесть месяцев они звонят вам и требуют исправить баг, вызванный плагином, который они установили.

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

Вот юридические баги, которые нужно исправить в ваших Условиях ведения бизнеса.

1. Чёрная дыра «совместимости с браузерами»

Сценарий: Вы создаёте стильный сайт на React. Он летает в Chrome и Safari. CEO клиента открывает его в Internet Explorer 11 в офисе. Сеточная верстка ломается. Они удерживают оплату, пока «всё не заработает».

Юридическая реальность:

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

Решение:

Пункт о поддерживаемых браузерах.

Будьте конкретны. «Веб-сайт предназначен для работы в двух последних версиях Chrome, Safari, Firefox и Edge. Совместимость с устаревшими браузерами (например, IE11) не включена, если иное прямо не согласовано в Спецификации.»

2. Тестирование при приёмке (триггер «запуска»)

Сценарий: Вы заканчиваете сайт. Отправляете ссылку. «Дайте знать, что вы думаете.»

Тишина на 3 недели.

Потом: «Можем изменить шрифт?»

Потом тишина на 2 недели.

Потом: «Вообще-то, можем передвинуть логотип?»

Вы уже на 3 месяца просрочили дедлайн и не получили оставшиеся 50% оплаты.

Юридическая реальность:

Без определённого «периода приёмки» проект находится в режиме зомби. Он не завершён и не незавершён.

Решение:

Пункт о «приёмке по умолчанию».

«У Клиента есть 7 дней с момента передачи для тестирования программного обеспечения. Если в течение 7 дней в письменной форме не сообщено о конкретной 'Ошибке' (определяемой как сбой/критический отказ), программное обеспечение считается принятое, и подлежит оплате окончательный остаток.»

Это заставляет их проверить его — или заплатить вам.

3. Расширение объёма работ («всего одно небольшое изменение»)

Сценарий: Вы называете цену за 5 страниц. Ближе к середине клиент присылает тексты. Их 12 страниц. «Я просто разделил страницу About на части, это же не так страшно, да?»

Это очень важно. Это логика навигации, влияние на мобильное меню и время добавления контента.

Решение:

Перестаньте оценивать «сайт». Оценивайте «объём работ».

• Строго определённые результаты: «5 статических страниц. 1 контактная форма.»

Пункт об изменениях: «Любые конкретные запросы вне этого Объёма будут оплачиваться по нашей стандартной почасовой ставке £[X]. Разработка приостанавливается, пока изменение не будет согласовано.»*

4. Кому принадлежит код? (права ИС)

Сценарий: Вы используете свою стандартную «стартовую тему» или библиотеку вспомогательных функций, которые написали много лет назад. У клиента с вами портятся отношения. Они требуют «полной передачи авторских прав» на весь код.

Если вы передадите всё, вы по закону не сможете использовать свою стартовую тему для следующего клиента. Вы продали «инструменты», а не только «дом».

Решение:

Разграничьте «индивидуальный код» и «фоновую ИС».

«Разработчик передаёт Клиенту авторские права на индивидуальный дизайн и текстовую компоновку после полной оплаты.»*

«Разработчик сохраняет права на всю 'фоновую ИС' (повторно используемые библиотеки/фреймворки) и предоставляет Клиенту бессрочную, неисключительную лицензию на их использование для этого веб-сайта.»*

5. Исправление багов «на всю жизнь»

Сценарий: Сайт запущен. Два года спустя выходит обновление WordPress. Сайт ломается. Клиент звонит: «Вы это сделали — вы это и чините.»

Решение:

Период гарантии.

«Мы предоставляем 30-дневный гарантийный период после запуска для исправления багов, присутствовавших на момент запуска. Любые проблемы, возникшие после 30 дней или вызванные обновлениями сторонних сервисов (плагины/изменения браузеров), оплачиваются как обслуживание.»

Почему проверка контракта — это ваша документация

Вы комментируете свой код. Вы должны комментировать и свои деловые отношения.

ИИ-проверка контрактов разбирает ваше dev-соглашение. Она проверяет, не пообещали ли вы случайно «пригодность для конкретной цели» (высокий юридический стандарт) вместо «разумной квалификации и заботы». Она следит за тем, чтобы ваш процесс «приёмки» был непробиваемым. Она помогает вам сдать проект и получить оплату, без накопления технического долга.

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