Что важно узнать перед входом в новый проект клиента?

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

Почти любая смена подрядчика и/или команды на IT-проекте — это боль. Дорого, долго и зачастую с кучей неожиданностей и нюансов.
— 💀 легаси
— 📄 много/мало документации
— 🤷‍♂️ и всё вытекающее

Если мы заходим в такой проект, стараемся выяснить ключевые вещи — и в идеале делаем это ещё на этапе пресейла. Так и оценка будет адекватной, и отношения крепче.

Что случилось с предыдущим подрядчиком?
Просто так никого не меняют. Это долго и затратно.
Обычно причина — медленно делают, дорого берут, или делают «как-то не так».
Но бывает, что дело не в них: сроки были космические, ТЗ писалось на салфетке, а команду казнили «ритуально». Лучше это знать до входа в проект, а не через пару спринтов.

Доступы к проекту и админке
Git, история коммитов, ветки, .gitignore, админка — это как медицинская карта проекта.
По этим вводным уже можно понять, жив проект или скорее в коме.
Если всё в порядке — круто. Если хаос — значит, закладываем время на реанимацию.

Что на серверах?
Обновлённое ли окружение, какие версии пакетов, насколько всё запущено или хорошо.
Сервер — это не просто железо. Если на нём правят прод через nano — ну, ты понял.
Как обстоят дела с бэкапами.

Есть ли документация?
Вероятнее всего — нет. Но если вдруг есть — это праздник. И повод порадоваться команде, что была до нас.

Кто принимает решения?
ЛПР — лицо принимающее решения. Его нужно найти и познакомиться.
Потому что можно потратить кучу времени на фичу или дизайн, а потом окажется, что согласовывать всё должен человек, которого ты даже в переписке не видел. И всё по новой.

История проекта
Сколько команд уже сменилось? Были ли свои разработчики? Сколько раз всё начинали с нуля?
Контекст важен. Он может объяснить, почему одни фичи «просто есть», а другие «мы не трогаем это с 2018 года».

Какие у проекта цели?
Важно понять, что клиент считает успехом.
Быстрое развитие? Безопасность? Рефакторинг? Чтобы ничего не трогали вообще?
Если ожидания не совпадают с реальностью — беда будет не в коде, а в коммуникации.

Как всё устроено внутри?
Есть ли трекер задач, кто их ставит, есть ли процессы ревью и деплоя?
Бывает, проект выглядит как корабль, но рулит им один человек в шторм и без карты.
Хорошо бы это понять до того, как вы станете штурманом.

Клиент вовлечён или просто «отдал и забыл»?
Если он на связи, быстро принимает решения, участвует — шансы на успех выше.
Если «напишите бота и отпишитесь через месяц» — нужно закладывать время на «ожидание ответа от клиента».

Есть ли техдолг, и что о нём думают?
Технический долг есть почти везде. Но важно: осознают ли это? Хотят ли с ним что-то делать?
Если не хотят — это их право. Главное, чтобы вы знали, с чем работаете, и могли это оценить.

В общем, если вы входите в чужой проект — лучше быть разведчиком, чем сапёром. А если вы клиент — подготовьте поле, чтобы следующая команда не ушла так же быстро, как предыдущая.