Разведчики и сапёры 💣

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

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

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

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

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

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

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

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

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

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

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

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

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