Что обязательно должно быть передано заказчику: доступы, репозиторий, инструкции
Если вы оплатили разработку, но не получили контроль — вы не купили систему. Вы купили услугу “чтобы оно работало, пока подрядчик рядом”. Это опасно.
Ниже — то, что бизнес должен получить в руки. Не “мы вам потом вышлем”, не “у нас хранится, не переживайте”, а оформлено и проверено.
1) Доступы владельца: “ключи от квартиры”
У вас должны быть:
- админ‑доступ в саму систему (управление пользователями и правами)
- доступ к домену и DNS (если есть сайт/кабинет)
- доступ к хостингу/облаку/серверу, где всё размещено
- доступ к аналитике (если подключали)
- доступ к почтовым/смс‑сервисам, если они используются для уведомлений
- доступ к платежам/кассе (если интеграции есть)
Принцип простой: владение — у заказчика, подрядчик — приглашенный исполнитель.
2) Репозиторий (код) и права на него — даже если вы не технарь
Вы можете не смотреть код никогда. Но он должен быть:
- в репозитории, к которому у вас есть админ‑доступ
- с понятной структурой и актуальной версией (а не “вот архив на почте”)
- с зафиксированной лицензией/правами: что это ваша разработка
Почему это важно: без этого вы не сможете быстро подключить другую команду, а значит — зависимость и диктат условий.
3) Список интеграций и “что с чем связано”
Бизнесу нужна короткая карта:
- какие внешние сервисы подключены (CRM, телефония, платежи, склад, почта)
- что именно передается (заявки, статусы, оплаты, товары)
- в какую сторону идет обмен (туда, обратно, в обе стороны)
- кто отвечает за каждый кусок
Это спасает, когда что-то “вдруг перестало сходиться” и вы ищете, где проблема.
4) Инструкции: минимум, который экономит вам месяцы
Инструкции должны быть не “для программистов”, а для людей:
- для пользователей: как выполнять ключевые операции (5–10 сценариев)
- для администратора: как добавлять пользователей, роли, менять настройки
- для руководителя: где смотреть отчеты/статусы, как контролировать процесс
Если инструкции нет, система превращается в “игрушку, которую знают двое старичков”.
5) Регламент поддержки: куда писать и что считается “поломкой”
После передачи должен быть понятный порядок:
- куда сообщать о проблемах
- какие сроки реакции (хотя бы ориентиры)
- как отличаем баг от доработки
- кто принимает решение “делаем/не делаем”
Это снижает хаос и защищает вас от вечных споров “это не баг”.
6) “Пакет приемки”: чтобы вы могли доказать, что этап закрыт
На практике полезно иметь:
- перечень реализованных функций по этапу
- список известных ограничений (“в этом релизе не делали…”)
- список открытых задач, если они остаются
Тогда никто не переписывает историю через месяц.
Как закрепить передачу правильно: привяжите все пункты к приемке этапов. Оплата этапа — после того, как вам реально передали доступы/инструкции/репозиторий (по мере готовности), а не “в самом конце проекта”.