Как сменить подрядчика на разработку и забрать проект без потерь

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

Сроки срываются уже третий раз подряд. На каждый вопрос о статусе — «почти готово». Новые функции ломают старые, исправление одной ошибки порождает две новые, а оценка простой доработки внезапно занимает месяц. Или проще: подрядчик сменил приоритеты, команду, которая делала проект, перевели на другого клиента, а новые люди разбираются в коде медленнее, чем бизнес успевает придумывать задачи. Решение сменить подрядчика редко даётся легко. Страшно потерять код, доступы, знания о системе, получить месяцы простоя и в итоге оказаться с новой командой, которая тоже не справится. Эти страхи обоснованы: смена команды — рискованная операция. Но риски хорошо известны и управляемы. Ниже — как понять, что менять действительно пора, что проверить до разговора с текущим подрядчиком, как забрать проект со всеми доступами и знаниями и как организовать переход без остановки работы. Если вы на этапе выбора первого подрядчика, полезнее будет статья о выборе подрядчика на разработку . Здесь речь о ситуации, когда команда уже работает и её нужно заменить. Когда менять подрядчика, а когда — договариваться Не каждая проблема требует смены команды. Смена стоит денег и времени, и иногда проблему дешевле решить в текущих отношениях. Проблемы, которые часто решаются без смены Размытые требования. Если задачи ставятся устно, приоритеты меняются каждую неделю, а критерии приёмки не определены, новая команда столкнётся с тем же. Сначала стоит навести порядок в постановке задач. Нет регулярного процесса. Демонстрации результата раз в квартал вместо каждых двух недель, отсутствие плана и отчётности. Это можно потребовать и изменить. Разные ожидания по объёму. Заказчик считает, что работы входят в договор, подрядчик — что нет. Это решается пересмотром договора и порядка изменений. Признаки, что смена оправдана обещания систематически не выполняются, и откровенный разговор о причинах ничего не меняет; качество падает: растёт число ошибок после каждого выпуска, возвращаются ранее исправленные проблемы; подрядчик не даёт доступа к коду, инфраструктуре или документации и не объясняет почему; команда, знающая проект, ушла, а новые люди не справляются; подрядчик не может объяснить архитектуру и технические решения или объяснения не выдерживают независимой проверки; стоимость и сроки доработок растут непропорционально их сложности; технологии или компетенции подрядчика перестали соответствовать задачам продукта. Если совпадает несколько пунктов из второго списка, а разговор с руководством подрядчика не дал результата, продолжение отношений обычно обходится дороже смены. Этап 1. Тихая подготовка До того как объявлять о смене, важно понять, что именно вы можете забрать и в каком состоянии проект. Если начать с конфликта, а потом выяснить, что доступов у компании нет, переговорная позиция окажется слабой. Проверить права и договор Исключительные права на результат. Переходят ли права на код, дизайн и документацию к заказчику, и в какой момент — после подписания актов, после оплаты этапа, после завершения всего проекта. Сторонние компоненты. Использует ли подрядчик собственные библиотеки или платформу, права на которые остаются у него. Без лицензии на такие компоненты код может оказаться непригодным для передачи. Порядок расторжения. Сроки уведомления, оплата выполненных работ, обязательства по передаче. Обязанности при передаче. Предусмотрена ли передача кода, документации, доступов и консультации новой команде. Инвентаризировать доступы Составьте список всего, от чего зависит работа продукта, и отметьте, у кого находится управление: репозиторий кода — на чьём аккаунте, есть ли у компании права администратора; хостинг, облачные аккаунты, серверы — на кого зарегистрированы, кто оплачивает; домены и DNS — владелец домена должен быть компанией, а не сотрудником подрядчика; SSL-сертификаты; аккаунты разработчика в магазинах приложений; базы данных и резервные копии; почтовые сервисы, SMS-шлюзы, платёжные провайдеры, внешние API — ключи и учётные записи; системы аналитики, мониторинга, отслеживания ошибок; системы управления задачами и документация. Самые опасные ситуации — домен, облачный аккаунт или аккаунт разработчика в магазине приложений, зарегистрированные на подрядчика или его сотрудника. Их перевод на компанию нужно начать как можно раньше, пока отношения ещё рабочие. Сохранить копии Если у компании уже есть доступ к репозиторию и базам данных, стоит сделать независимые копии кода и данных до начала переговоров. Это не проявление недоверия, а обычная предосторожность. Этап 2. Независимый аудит Прежде чем передавать проект новой команде, нужно понять, что именно передаётся. Аудит отвечает на вопросы, от которых зависят и решение, и план перехода. Что проверяется Полнота кода. Собирается ли проект из репозитория, есть ли в нём всё, что работает в промышленной среде, или часть изменений существует только на сервере. Архитектура. Понятна ли структура, соответствует ли она задачам и нагрузке, насколько сложно её развивать. Качество кода. Читаемость, дублирование, наличие тестов, устаревшие зависимости, известные уязвимости. Инфраструктура. Как устроено развёртывание, есть ли автоматизация, резервное копирование, мониторинг, описана ли инфраструктура. Безопасность. Хранение паролей и ключей, права доступа, защита персональных данных. Документация. Есть ли описание архитектуры, API, процессов развёртывания, бизнес-логики. Соответствие договору. Реализовано ли то, что оплачено. Какие выводы возможны Проект в нормальном состоянии — проблема была в процессе или команде, новая команда продолжит развитие. Проект требует оздоровления — продолжать можно, но первые месяцы уйдут на тесты, обновление зависимостей, автоматизацию и исправление критичных проблем. Проект проще переписать частично или полностью — такой вывод требует особенно тщательного обоснования, потому что переписывание почти всегда оказывается дороже и дольше, чем кажется. Аудит стоит заказывать у команды, которая может взять проект, но с явным пониманием, что его результат принадлежит заказчику и может быть использован при выборе другой команды. Это снижает риск, что аудитор преувеличит проблемы ради большого контракта на переделку. Этап 3. Разговор с текущим подрядчиком Даже если отношения испорчены, разумно провести переход цивилизованно: от сотрудничества уходящей команды зависит скорость передачи знаний. сообщить о решении письменно в соответствии с порядком, предусмотренным договором; согласовать план передачи: что, в каком виде и в какие сроки передаётся; согласовать период консультаций — ответы новой команде на вопросы в течение нескольких недель, оплачиваемые отдельно, если договор этого не предусматривает; урегулировать оплату выполненных работ, чтобы финансовый спор не блокировал передачу; зафиксировать передачу актом со списком переданного. Удержание оплаты как рычаг давления иногда кажется разумным, но часто приводит к зеркальному ответу — задержке передачи доступов. Лучше заранее разделить вопросы: оплата выполненного — по договору, передача — по плану, спорные работы — отдельно. Этап 4. Передача знаний Код можно передать за день. Знание о том, почему код устроен именно так, где спрятаны неочевидные зависимости и какие части лучше не трогать без подготовки, передаётся неделями — или теряется. Что нужно получить описание архитектуры: компоненты, их связи, внешние интеграции; инструкцию по развёртыванию проекта с нуля — её стоит проверить, развернув проект силами новой команды; описание сред: промышленная, тестовая, их отличия и данные; перечень внешних сервисов и ключей; список известных проблем, технического долга и незавершённых задач; бизнес-логику, которая не очевидна из кода: расчёты, исключения, особые правила для отдельных клиентов; историю инцидентов: что ломалось и как чинили. Как передавать Сессии разбора. Уходящая команда проводит для новой разбор архитектуры, ключевых модулей и процессов, с записью. Совместное выполнение задач. Первые задачи новая команда делает с консультациями уходящей. Самостоятельное развёртывание. Новая команда разворачивает проект в своей среде по полученной инструкции. Всё, что не получилось, — пробелы в документации, которые нужно закрыть до окончания периода консультаций. Этап 5. Переход без остановки работы Период параллельной работы Самый безопасный вариант — несколько недель, когда обе команды работают одновременно: уходящая поддерживает промышленную среду и отвечает на вопросы, новая осваивает проект и берёт первые задачи. Это стоит дороже, но резко снижает риск простоя. Заморозка крупных изменений На время перехода стоит отказаться от крупных новых функций и изменений архитектуры. Задачи этого периода — поддержка работоспособности, исправление критичных ошибок и освоение системы новой командой. Перехват промышленной среды Смена паролей и ключей, отзыв доступов уходящей команды, перевод мониторинга и оповещений на новую команду. Делается по чек-листу в согласованный момент, после того как новая команда подтвердила, что умеет разворачивать и откатывать систему. Первые задачи новой команды настроить автоматическое развёртывание, если его нет; настроить мониторинг и оповещения; проверить резервное копирование, включая восстановление из копии; закрыть критичные уязвимости и обновить опасно устаревшие зависимости; покрыть тестами самые критичные сценарии, прежде чем что-то в них менять. Эти задачи не видны бизнесу как новые функции, но именно они определяют, будет ли дальнейшее развитие быстрым и безопасным. Как устроены такие практики, мы разбирали в статье о сокращении time-to-market . Из чего складывается стоимость смены Решение о смене подрядчика стоит принимать, понимая полную цену перехода, а не только ставку новой команды. Основные статьи затрат: Аудит. Разовая работа, которая окупается уже тем, что превращает смутное недовольство в конкретный список проблем и план. Период консультаций уходящей команды. Часы на ответы и разборы, если договор не обязывает их к передаче знаний. Параллельная работа. Несколько недель, когда оплачиваются обе команды. Самая заметная статья, но и главная страховка от простоя. Погружение новой команды. Первые недели новая команда работает медленнее, чем будет работать через пару месяцев: изучает код, бизнес-логику, инфраструктуру. Оздоровление. Автоматизация развёртывания, мониторинг, тесты, обновление зависимостей — работа, которой не было, но без которой дальнейшее развитие будет медленным и рискованным. Восстановление недостающего. Документация, которую не вели, доступы, оформленные не на компанию, изменения, внесённые прямо на сервере. Чем хуже было состояние проекта, тем больше эта статья. Время бизнеса. Участие сотрудников компании в передаче знаний о бизнес-логике и приёмке, заморозка новых функций на период перехода. Сравнивать эти затраты нужно не с нулём, а с ценой продолжения: сорванные сроки, потерянные продажи из-за отложенных функций, инциденты, растущая стоимость каждой доработки. Если продолжение обходится дороже, смена оправдана даже с учётом всех статей. Если подрядчик не сотрудничает Худший сценарий — подрядчик отказывается передавать код и доступы или исчезает. Юридическая позиция. Договор, акты, переписка, счета — основа для требований о передаче результата, права на который перешли к заказчику. Здесь нужен юрист. Восстановление доступов. Доступ к домену восстанавливается через регистратора, к облачным аккаунтам — через провайдера, если аккаунт оформлен на компанию. Если на сотрудника подрядчика — процесс заметно сложнее. Работающая система как источник. Если доступ к серверу есть, код и данные можно получить оттуда, хотя без истории изменений и документации. Реконструкция. В крайнем случае система восстанавливается по работающей версии и знаниям пользователей. Это дорого, и главный урок этого сценария — доступы должны быть у компании с первого дня. Как не оказаться в зависимости снова Смена подрядчика — хороший момент, чтобы исправить то, что сделало переход болезненным. репозиторий, облачные аккаунты, домены, аккаунты магазинов приложений — на компании,