Смена подрядчика: как не наступить на старые грабли
К подрядчику, который перенимает продукт, требования намного выше, чем к команде-«первопроходцу». Создать и развивать продукт самому легче, чем переделывать за кем-то. Нужно проанализировать:
🔹чужой код;
🔹что можно переиспользовать (беря во внимание риски);
🔹как довести продукт до ума.
Это трудоёмкий процесс, поэтому сначала предлагаем присмотреться к своей старой команде. Если же присматриваться больше не к кому, следующий пункт в посте можно пропустить.

А может и не стоит менять подрядчика?
Перед принятием решения внимательно изучите:
🔹документы по планированию, оценке затрат, учету рисков;
🔹процессы разработки, коммуникацию в команде;
🔹этапы разработки и наличие специалистов на проекте.
Пример.
Проблема: постоянно нарушаются дедлайны.
Возможные причины:
1. Проект оценивала другая команда, а в новой некоторые специалисты работают над двумя вашими продуктами.
2. В процессе появились новые стейкхолдеры, и они детализировали фичи.
3. На проекте нет аналитика, соответственно, корректной постановки задач. Разработчикам приходится несколько раз переделывать фичи, прежде чем конечный пользователь скажет: «Да, это я и имел в виду».
Возможные решения: переоценка с учетом актуальной специфики проекта, корректировка процессов разработки и управления.

Всё-таки стоит: на что обратить внимание
Вы выбрали несколько компаний по рекомендациям/отзывам, соответствию технического стека и опыту в вашей сфере. Далее присмотритесь к процессам, которые он предлагает вам при перенятии проекта. Схема должна выглядеть следующим образом:
1️⃣ Изучение системы
2️⃣ Аудит
3️⃣ План выполнения задач
4️⃣ Разработка + Аналитика + Тестирование
5️⃣ Релиз
Если подрядчик сразу говорит, что в условный день он готов приступить к работе, вероятность плохого результата возрастает многократно.
Это похоже на смену лечащей компании: вы приходите с болями в области печени в новую клинику. Странно, если вам тут же предложат лечить этот орган. Сначала специалист начнёт сбор анамнеза, изучит ваши жалобы.

Что должен спросить хороший подрядчик до начала работ: изучение системы
Что было
🔹 Причины смены подрядчика
🔹 Боли: что конкретно не устраивает
🔹 Бизнес-потребности: для чего/ кого продукт делается
Что есть
🔹 Отношения со старой командой: можно ли с ними взаимодействовать
🔹 Исходники: где находятся, версионность и т.п.
🔹 Документация и ТЗ
🔹 Отчеты предыдущих исследований
Что будет
🔹 Ожидания клиента от продукта: цели сейчас и на несколько лет вперёд
🔹 Время, которое клиент будет уделять проекту
Эти вопросы определяют надёжную компанию, которая отвечает за результат. Они помогают соотнести реализацию продукта с вашими ожиданиями и требованиями.

Первый этап договорных отношений: аудит
Что входит:
🔹 аудит кода (обязательно);
🔹 аудит функционала (обязательно);
🔹 аудит архитектуры, БД, инфраструктуры;
🔹 UX-аудит
🔹 аудит процессов.
Результаты:
🔹 документ о состоянии продукта;
🔹 рекомендации к исправлению.
❗️Важно! В рекомендации должен входить перечень шагов с их приоритизацией. Правильный подрядчик предлагает несколько вариантов решения проблем. Вы сможете выбрать наиболее подходящий вам, опираясь на бюджет, требования и сроки.
Кроме того, результаты могут быть неожиданными: иногда проще сделать всё с нуля, чем переделать то, что есть. Возможно, после аудита вы поймете, что можно скорректировать что-то в старой команде и не менять её.