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

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

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

В этой статье я поделюсь своим опытом: расскажу, как разобраться в сложном проекте, наладить процессы и превратить его в «свой».

Как не утонуть в новом проекте

Каждый новый проект — это немного (или много) стресс. Но он становится управляемым, если знать, за какие нити дергать. Вот несколько шагов, которые помогут.

Задайте вектор: зачем все это? Поймите, зачем вообще существует ваш проект. Продажи? Улучшение UX? Новая функциональность? Тимлид не может быть эффективным, если не понимает конечной цели. Начните с разговора с бизнесом или клиентом, выясните ключевые показатели успеха и постарайтесь мысленно «примерить» эти цели на свою работу. Проясните основные пользовательские сценарии.

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

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

Уберите хаос: матрица доступов. Когда в проекте участвует много людей и систем, хаос доступов — это первое, что нужно упорядочить. Создайте матрицу: укажите, кто и к каким системам должен иметь доступ, а кто — нет. Эта таблица станет спасением при онбординге новых сотрудников и позволит вам экономить время. Новых сотрудников просто прогоняем по матрице доступов и быстро идем к клиенту за новыми, если их не хватает. 

Хэндоверы: секреты успешного наследования знаний

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

Сфокусируйтесь: тематические сессии. Разделите хэндоверы на отдельные темы: архитектура, деплой, QA. Такой подход позволяет сфокусироваться и подготовиться. Перед каждым звонком изучите доступную документацию по теме и подготовьте вопросы. Обязательно поделитесь ими заранее с участниками, чтобы не терять время на пространные обсуждения.

Задавайте неудобные вопросы. Спросите старую команду про типичные ошибки. Какие моменты в проекте вызывают наибольшие сложности? Есть ли важные неочевидные особенности, которые нигде не задокументированы? Какой информации не хватает, если завтра нужно будет залить изменения или запустить тесты? Можно собрать эти вопросы заранее и вручить их заказчику перед звонком – это тоже повысит осмысленность разговора и позволит концентрироваться на сути. 

Не теряйте информацию: записывайте встречи. Записывайте все хэндоверы и сохраняйте их в общем доступе. Это будет полезно, если кто-то из новых сотрудников захочет быстро разобраться в проекте. Даже спустя месяцы вы сможете вернуться к этим записям и восстановить детали. Новым людям на проекте может быть достаточно пересмотреть запись, вместо того, чтобы расспрашивать более опытных коллег бесконечно в чате. 

Планируйте с умом: задачи и приоритеты

Как распределить задачи так, чтобы успеть всё важное и не потратить ресурсы впустую? Ключи — планирование и аудит.

Разберитесь с бэклогом. Просмотрите текущий бэклог. Какие задачи критичны? Какие можно отложить? Например, если вы знаете, что проект через год будет переделан, то работа над обновлением архитектуры может быть лишней. Приоритизируйте задачи, основываясь на глобальных целях проекта.

Проведите аудит: это ваша страховка. Даже если клиент не требует аудита, сделайте его для себя. Оцените архитектуру, интеграции, технический долг. Это поможет выявить слабые места системы и будет вашей страховкой, если что-то пойдет не так.

Аудит изначально формулирует риски и ограничения на проекте. Если вдруг клиенту срочно понадобится реализация, которую система не в силах будет поддержать, всегда будет, что показать такому клиенту. Самая большая проблема здесь обычно – проблема чистого листа – вы не понимаете, сколько это займет времени и что вообще делать в первую очередь. Копаться в коде можно бесконечно долго, но в этом нет смысла. Ориентируйтесь на общие приоритеты. Например, смотрите на моменты, связанные только с текущим бэклогом, ближайшей на реализацию фичей.

Иногда нужно оценить оценку – и это не должно казаться странным ни вам, ни команде, ни заказчику. Есть ситуации неопределенности, когда кажется, что в эстимейте можно сильно промахнуться. Для таких случаев делаем оценку на исследование, а не на реализацию. У клиентов будут реалистичные ожидания – они будут знать, над чем вы работаете сейчас. Разработчики же в это время не будут связаны ложными эстимейтами: работать по ночам или расстраивать клиента незакрытыми задачами.

Экспериментируйте с Proof of Concept (PoC). Если вы не уверены, что выбранный подход к задаче сработает, делайте PoC. Это небольшой эксперимент, который позволяет проверить, будет ли работать ваша идея. Главное — не вдаваться в детали. Помните, что цель PoC — понять, возможно ли реализовать задумку, а не сделать готовый продукт.

Деплой без стресса: настраиваем релизы

Работа с релизами — это еще один ключевой аспект работы тимлида. Не всё, что звучит просто, оказывается таковым на практике.

Автоматизируйте, где возможно. Узнайте, как настроены пайплайны на проекте. Есть ли полностью автоматизированные процессы? Если нет, выясните, какие этапы требуют ручного вмешательства, и постарайтесь оптимизировать их.

Согласуйте окна для релизов. Перед каждым релизом уведомляйте всех участников: команду, клиента, пользователей. Определите фиксированные временные окна для заливок изменений, чтобы минимизировать риски.

Всегда имейте план Б. Держите где-то «под подушкой» план отката. Если релиз привел к проблемам, кто и как будет устранять их? Создайте пошаговый чек-лист действий для таких ситуаций.

Сложности — это возможности для роста

Работа тимлида — это баланс между техникой, людьми и процессами. Главное — не бояться неопределенности. Системный подход, открытая коммуникация и внимание к деталям помогут вам справиться с любыми вызовами. Не забывайте: тимлид — это тот, кто ведет за собой.