Как передать MVP на поддержку: чек-лист сдачи проекта

Три месяца назад к нам обратился основатель FinTech-стартапа с неожиданной просьбой: «Помогите разобраться, что вообще происходит в нашем продукте». MVP сделала другая команда, разработчики ушли, а новый подрядчик не мог понять архитектуру. Деплой — загадка. Переменные окружения — нигде не описаны. База данных — без схемы. Вопрос «как передать MVP на поддержку» оказался риторическим: никто это не делал.

За неделю мы разобрались. Но потеряли время, которое стоило денег. Этого можно избежать — если правильно принять работу у разработчика с самого начала.

Почему передача MVP превращается в хаос

Рассмотрим, как как передать mvp на поддержку работает на практике.

Стартаперы редко думают о передаче проекта в момент, когда его создают. Разработчики — тоже. У всех одна цель: запуститься как можно быстрее. Документация, доступы, инфраструктура — это «потом».

«Потом» наступает в худший момент: когда команда разработки уходит, когда нужно срочно починить баг, когда инвестор просит технический due diligence. И оказывается, что:

• Все пароли лежат у разработчика в голове (или в его личном 1Password)
• Деплой умеет делать только один человек, которого уже нет
• Репозиторий на личном аккаунте разработчика, не компании
• README — пустой файл с «TODO: add documentation»
• Мониторинга нет, ошибки находят пользователи

Это не злой умысел. Это нормальная человеческая лень в условиях дедлайна. Но ваша задача — не дать этому случиться. Принять MVP по чек-листу, а не на веру.

Блок 1 — Документация (5 пунктов)

Вопрос как передать mvp на поддержку заслуживает детального анализа.

Документация — это первое, что нужно проверить. Не потому что вы собираетесь её читать каждый день, а потому что её наличие говорит о культуре разработки команды.

README с архитектурой. Не «как запустить локально», а что за продукт, из каких сервисов состоит, почему принято то или иное архитектурное решение. Хороший README объясняет не только «как», но и «почему».

API-документация (OpenAPI/Swagger). Для FinTech MVP это критично — вы почти наверняка будете интегрировать новые сервисы. Без актуальной документации каждая интеграция начинается с изучения кода, а не спецификации. Потеря времени — от нескольких часов до нескольких дней.

Описание переменных окружения (.env.example). Файл с примером всех переменных: ключи API, строки подключения к базе данных, URL внешних сервисов. Без него поднять локальную копию невозможно. Проверьте: `.env.example` должен быть в репозитории, реальный `.env` — в gitignore.

Схема базы данных. ERD-диаграмма или хотя бы миграционные файлы с историей изменений. Для EdTech с десятками типов контента и для FinTech с транзакциями это обязательно. Без схемы каждый новый разработчик тратит несколько дней только на понимание структуры данных.

Инструкция по локальному запуску. Пошаговый гайд: поставить зависимости, применить миграции, запустить сервисы. Проверяется просто — дайте инструкцию человеку, который не участвовал в разработке, и засеките время. Если за час не запустил — документация неполная.

Блок 2 — Доступы (4 пункта)

Именно как передать mvp на поддержку определяет результат для бизнеса.

Это самый болезненный блок. Разработчики часто не задумываются, что работают с чужими ресурсами. Проверяйте каждый пункт лично.

Все credentials в password manager. 1Password, Bitwarden или хотя бы Notion с ограниченным доступом. Не в Telegram-переписке, не в Google Docs без пароля, не в Excel на компьютере разработчика. Список должен включать: все API-ключи внешних сервисов, логины от хостинга и баз данных, ключи от платёжных систем, административные пароли.

Репозиторий на аккаунте организации. GitHub или GitLab репозиторий должен быть под аккаунтом вашей компании, не личным аккаунтом разработчика. Если это не так — потребуйте перенос до подписания акта сдачи. Это занимает 15 минут, но разработчики часто «забывают» это сделать.

Облачная инфраструктура на аккаунте клиента. Yandex Cloud, AWS, GCP, DigitalOcean — всё должно быть зарегистрировано на вашу почту с вашей банковской картой. Если сервер арендован на карту разработчика — однажды он просто перестанет платить. Прецеденты есть.

Домен и DNS под контролем клиента. Регистратор домена, доступ к панели управления DNS — у вас. Классическая история: разработчик купил домен «для удобства», потом начался конфликт, и домен оказался заложником ситуации.

Блок 3 — DevOps (3 пункта)

Для MVP это зона особого риска. Разработчики часто настраивают деплой «на коленке» — работает, и ладно. Но «работает» перестаёт работать, когда нужного человека нет рядом.

CI/CD pipeline задокументирован. GitHub Actions, GitLab CI, или что у вас — должна быть понятная схема: что происходит при push в main, как запускаются тесты, как происходит деплой. Если CI/CD нет вообще — это красный флаг: деплой делается вручную, что означает риск ошибок и зависимость от конкретного человека.

Процедура деплоя описана. Пошаговая инструкция: откуда деплоить, что проверить до деплоя, как откатиться если что-то пошло не так. Для FinTech с платёжной функциональностью — особенно важно. Деплой без процедуры — это рулетка.

Мониторинг настроен и доступен. Sentry для ошибок, Grafana или аналог для метрик — вы должны иметь доступ к этим системам и понимать что там происходит. Базовый вопрос: как вы узнаете, что сервис упал? Если ответ «пользователи напишут» — мониторинга нет.

Блок 4 — Передача знаний (3 пункта)

Документация — это хорошо. Но есть знания, которые сложно задокументировать: почему выбрали именно этот подход, какие грабли уже обошли, что планировалось но не вошло в MVP.

Сессия передачи знаний с записью экрана (2–3 часа). Разработчик проводит обзор системы с демонстрацией: архитектура, основные сценарии, нетривиальные места. Всё записывается — это ваша страховка. Через полгода вы вернётесь к этой записи и поймёте решения, которые казались очевидными сейчас.

Список технического долга. Что сделано «не идеально» ради скорости, что планировалось рефакторить, какие компромиссы приняты осознанно. Честный список — признак профессионала. Отсутствие списка означает, что либо технического долга нет (редкость), либо его скрывают (чаще).

Контакты для экстренной связи на 30 дней. После сдачи проекта оговорите: разработчик доступен в течение 30 дней для ответов на вопросы (в разумных пределах — часа два в неделю). Фиксируйте это в договоре. Это не гарантийный период в юридическом смысле — это человеческая договорённость.

Красные флаги при передаче

Есть сигналы, которые должны вас насторожить:

Разработчик не хочет отдавать доступы — любые объяснения («я отдам когда вы оплатите» после акта сдачи, «это сложно передать» для облачного аккаунта) — повод зафиксировать это письменно и при необходимости обратиться к юристу.

Нет тестов вообще. Для MVP можно смириться с минимальным покрытием, но полное отсутствие тестов означает: любое изменение — это риск поломать что-то другое. Следующий разработчик будет бояться трогать код.

Нет `.env.example`. Это занимает 20 минут. Если разработчик не сделал этого за несколько месяцев работы — либо ленив, либо намеренно создаёт зависимость от себя.

«Я объясню устно». Устное объяснение — не документация. Вы не запомните половину, вторая половина через месяц забудется. Всё должно быть зафиксировано.

Что должно быть в договоре

Чек-лист бесполезен без юридического основания. Несколько пунктов, которые стоит включить в договор на разработку с самого начала:

• Гарантийный период 30–60 дней — разработчик устраняет баги, выявленные после сдачи, безвозмездно (в разумных пределах)
• Передача прав на исходный код — должно быть явно прописано, что все права передаются заказчику
• Список deliverables — что именно сдаётся (код, документация, доступы, инфраструктура)
• Акт сдачи-приёмки — подписывается только после выполнения всего чек-листа

В IT2BE все эти пункты включены в стандартный договор. Мы передаём MVP с полным пакетом документации, сессией передачи знаний и 30-дневным гарантийным периодом — это часть фиксированной цены до 900 000 рублей. Потому что MVP, который нельзя поддерживать без создателей, — это не MVP, а хобби-проект.

Итог

Передача MVP на поддержку — это не формальность. Это момент, когда продукт перестаёт быть проектом разработчика и становится вашим активом. Или не становится — если не проверить 15 пунктов выше.

Сохраните этот чек-лист. Используйте его как часть акта сдачи-приёмки. И если подрядчик отказывается выполнять хотя бы один пункт — это повод для серьёзного разговора до оплаты финального счёта.

Если вам нужен партнёр, который сдаёт MVP с полным пакетом документации и не исчезает после релиза — запишитесь на бесплатный Zoom-колл с командой IT2BE. Расскажем о процессе передачи подробнее и ответим на вопросы по вашему продукту.