- Мы все оплатили. Почему новая команда не может просто забрать проект?
- Потому что репозиторий, домен и доступы оформлены на подрядчика. В договоре это не прописано.
Такой разговор у меня был в прошлом году с компанией из логистики. Они заказали B2B-платформу, заплатили около 3,8 млн ₽, но по факту владели только актами и счетами. В IT это частая история: проект вроде купили, а управлять им не могут.
Договор показывает, как подрядчик ведет проект
Я смотрю на договор как на схему управления работой. Если в нем нет этапов, приемки, правил изменения задач и передачи результата, проект почти всегда уходит в ручной режим. Потом спор идет уже не о качестве кода, а о том, что именно было обещано.
У нас был аудит договора для сервиса бронирования на Laravel 11 + PostgreSQL 16. В предмете работ стояло только «разработка сайта под ключ». Подрядчик считал, что его зона - верстка, формы и публикация на сервере. Клиент ждал личный кабинет, amoCRM, события в Яндекс.Метрике и базовую SEO-настройку. Текста на 2 строки хватило, чтобы каждая сторона поняла проект по-своему.
Простой признак зрелости - приложения к договору. Именно там должны быть ТЗ, этапы, SLA, критерии приемки, список доступов и порядок передачи результата. Короткий договор с нормальными приложениями почти всегда работает лучше, чем 15 страниц общих формулировок.
Самая дорогая ошибка - расплывчатый результат
Фраза «сделать сайт» не защищает ни заказчика, ни подрядчика. Рабочая формулировка описывает модули, роли, интеграции, ограничения и место размещения проекта. Если продукт еще не собран в голове у заказчика, мы обычно выносим discovery в отдельный этап на 1-2 недели. Это дешевле, чем переделывать архитектуру в середине проекта.
Плохо:
Предмет договора: разработка сайта компании.
Лучше:
Исполнитель создает корпоративный сайт из 12 шаблонов страниц,
форму заявки, интеграцию с CRM Bitrix24, подключение Яндекс.Метрики,
адаптивную верстку для desktop/tablet/mobile и размещает код
в Git-репозитории заказчика.
Мы сами однажды взяли проект со слишком общим описанием. На 6-й неделе выяснилось, что под «личным кабинетом» заказчик имел в виду еще и биллинг, и роли менеджеров, и историю документов. Это была наша ошибка на входе: мы не зафиксировали расшифровку предмета работ. С тех пор в сделку без такой детализации не идем.
В приемке должны быть сценарии проверки, место хранения кода, определение бага и срок ответа со стороны заказчика. Новые функции, которые появились по ходу проекта, в приемку лучше не включать. Для них нужен отдельный порядок изменений.
Код, доступы и лицензии надо делить по списку
Самый неприятный сюрприз для бизнеса возникает после оплаты, когда проект нельзя забрать целиком. Причина почти всегда одна и та же: в один список смешаны кастомная разработка, open source, лицензии CMS, SaaS, платные модули и доступы к инфраструктуре. У каждого из этих активов своя логика владения.
Был проект в e-commerce на Laravel 11, PostgreSQL 16 и Vue. GitHub-репозиторий, хостинг и домен были оформлены на подрядчика. После расторжения перенос занял 5 недель, часть доступов восстанавливали через поддержку, а маркетинг в это время не мог быстро менять посадочные страницы.
Мы используем простое правило:
- репозиторий, домен, облако и аналитика сразу оформлены на клиента;
- права на код и дизайн переходят поэтапно, после оплаты этапа;
- лицензии и SaaS перечислены поименно: что покупает клиент, что арендуется у подрядчика.
Самая полезная защита для бизнеса - контроль над инфраструктурой. Штрафы в договоре редко помогают на практике, доступы помогают каждый день.
| Вопрос | Слабая схема | Рабочая схема |
|---|---|---|
| Репозиторий | у подрядчика | у клиента с первого дня |
| Домен и облако | временно на исполнителе | аккаунты клиента, роли доступа |
| Деплой | вручную, без инструкции | регламент, CI/CD, список secrets |
| Передача проекта | 4-6 недель | 2-5 рабочих дней |
Сроки сгорают там, где нет правил для изменений
Большинство конфликтов появляется не из-за кода. Меняется объем работ, но это никто не фиксирует. В итоге проект на 12 недель превращается в 22 недели, и каждая сторона уверена в своей правоте.
У нас был кабинет дилеров на Node.js 20 + NestJS. Заказчик семь раз менял требования к личному кабинету, все обсуждали в мессенджере, а команда продолжала делать, чтобы не тормозить релиз. Через три месяца обе стороны были уверены, что их обманывают. Проблема была не в людях, а в том, что не было Change Request.
Часто забывают и про зависимости от клиента: доступы, тексты, юридические документы, обратную связь по макетам, участие продуктовой команды. Если этого нет в договоре, подрядчик отвечает за сроки, на которые не влияет.
В Change Request достаточно зафиксировать новую задачу, оценку в рублях, сдвиг по срокам и подтверждение с двух сторон. Этого обычно хватает, чтобы проект не превратился в бесконечную цепочку «еще одной небольшой доработки».
Проверка за 30 минут
Если я быстро проверяю договор перед стартом, то смотрю на пять вещей:
- что именно делаем и что получаем на выходе;
- как проходит приемка;
- кому принадлежат код, макеты, домен и доступы;
- как оформляются изменения;
- как передается незавершенный результат при расторжении.
Если хотя бы на 3 из 5 пунктов ответ размытый, риск уже в сделке. Самые дорогие проекты ломаются не на разработке, а в момент смены команды. Поэтому при обсуждении договора с подрядчиком я советую задать один вопрос: если через три месяца вы решите уйти, за сколько дней получите код, доступы и незавершенный результат - и устроит ли вас этот ответ?
