Споры по аутсорсу почти никогда не начинаются во время разработки. Они начинаются через неделю после того, как ушёл последний платёж: заказчик вдруг обнаруживает, что сервер висит на личном аккаунте программиста, рассылка работает на чужом API-ключе, а как выкатывать обновления — нигде не записано.
Дальше — что именно проверять. Список собран со стороны, которая работу сдаёт: студия отправляет его клиенту заранее, ещё до сдачи, чтобы у обеих сторон было одинаковое понимание слова «готово». Работает в обе стороны: заказчик получает конкретный критерий приёмки, подрядчик — дату, а не бесконечное «поправьте ещё одну мелочь».
Почему всё это надо делать до последнего платежа
После оплаты у подрядчика пропадает мотивация, а у заказчика — рычаг. Деньги были единственным аргументом, и он потрачен: любая просьба «доприкрутить» превращается в переговоры о новых деньгах и сроках.
Отдельная история — доступы. Аккаунт на чужое имя это не формальность: домен, база или сервер могут уйти вместе с человеком, который их оформлял. Восстанавливать право на них через поддержку хостинга — то ещё удовольствие.
10 проверок
- Каждая функция — строка в таблице. Перенесите фичи из сметы или ТЗ в таблицу и напротив каждой поставьте «прошло» или «надо править». Бессистемное кликанье по очевидным экранам — самый надёжный способ не заметить половину согласованного.
- Живые устройства и браузеры. Прогоните основные сценарии на том, чем реально пользуются: iPhone с Safari, средний Android, Chrome на десктопе. «У меня работает» приёмкой не считается.
- Неудачные сценарии. Отправьте пустую форму, введите неверный пароль, отключите интернет. Понятное сообщение об ошибке — зачёт. Белый экран или стек вызовов — в правку.
- Аккаунты на имя заказчика. Админка, сервер, база, отправка писем, карты, платежи — везде вход с почты клиента, а не с личного аккаунта разработчика. Пароли меняются сразу после передачи.
- Исходники, репозиторий, домен, сервер. Полный код лежит в репозитории, которым владеет заказчик. Домен и хостинг оформлены на него. Сверяйте построчно с договором — именно построчно, а не по памяти.
- Деплой описан. Установить, настроить, собрать, залить, перезапустить. Если другой разработчик поднимет новую версию только по этому документу — описания достаточно. Секреты передаются отдельным каналом, в README им не место.
- Персональные данные и бэкапы. Что где хранится, хешируются ли пароли, совпадает ли политика конфиденциальности с тем, что код делает на самом деле. И главный вопрос: резервные копии создаются автоматически, но кто-нибудь пробовал из них восстанавливаться?
- Срок бесплатных правок зафиксирован письменно. Сколько дней, с какой даты считать (сдача или приёмка), и что считается багом, а что — новой задачей.
- Лицензии на шрифты, изображения и библиотеки. Список всего использованного: разрешено ли коммерческое применение, нужна ли атрибуция. Картинка из поиска однажды превращается в письмо от юриста, и это не гипотеза.
- Базовая производительность. Скорость первого экрана на мобильном интернете, вес изображений, читаемость текста на телефоне. Если в договоре есть цифры — проверяйте по ним, а не на глаз.
Шпаргалка: что проверять и на чём обычно спотыкаются
| Блок | Что должно быть | Частая проблема |
|---|---|---|
| Доступы | Все аккаунты на почте заказчика | Сервер и админка на личной почте подрядчика |
| Исходники и домен | Репозиторий и регистратор домена в собственности клиента | Репозиторий удалён после сдачи, домен оформлен на разработчика |
| Деплой | Документ, по которому выйдет новая версия | «Я в курсе, как это выкатывать» — устно |
| Данные и бэкапы | Хешированные пароли, работающее восстановление | Копии есть, но ни разу не проверялись |
| Правки после сдачи | Срок и точка отсчёта прописаны в договоре | Срок обсуждали в созвоне, доказательств нет |
| Лицензии | Список шрифтов, фото и иконок с типом использования | Изображения взяты из поисковой выдачи |
| Производительность | Проверка на мобильном интернете по цифрам из ТЗ | Смотрели только на быстром Wi-Fi |
Привязать финальный платёж к приёмке
Это та часть, которая реально снимает споры. В договоре должно быть три вещи:
- срок проверки — например, 7 дней после сдачи;
- форма подачи замечаний: письменно, со ссылкой на строку чек-листа;
- финальный платёж наступает через несколько дней после даты приёмки, а дата приёмки — это день, когда все строки стоят «прошло».
Заполненная таблица становится актом приёмки. Никому не придётся вспоминать, о чём договорились в созвоне позавчера.
Когда список избыточен, а когда его мало
Для проекта на два экрана и одну форму десять пунктов — перебор. Хватит трёх ключевых: доступы, исходники, деплой. А вот если внутри платежи, медицинские данные или база пользователей, пункты про персональные данные и лицензии стоит расширить до отдельного аудита — там цена ошибки другая.
Чек-лист не спасёт, если техзадание нигде не зафиксировано. Сверять таблицу будет не с чем, и разговор снова скатится в «мы же обсуждали». Юридическую сторону договора проверяет юрист, а не разработчик с чек-листом.
И про ключи сторонних сервисов, которые не попадают ни в один пункт. Договаривайтесь заранее, чей это ключ и на чьём аккаунте он создан. Если биллинг привязан к карте подрядчика, после расставания интеграция может отвалиться ровно в момент, когда вы этого меньше всего ждёте.
Приёмка — это процедура с датой и таблицей, а не вежливая просьба посмотреть сайт. И отправлять её подрядчику лучше в начале работ: правок будет меньше, а спорных ситуаций — почти ни одной.
Это общая информация, а не юридическая консультация. Важные договоры стоит показать юристу.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.