Салют! Помню своё первое погружение в большой незнакомый проект. Меня посадили, дали доступы к куче систем, скинули ссылку на Confluence где было триста страниц документации и сказали "изучай". Я изучала. Честно. Три дня читала документы и к концу понимала примерно столько же сколько в начале — потому что читала не то и не в том порядке.
С тех пор у меня есть своя система первых двух недель. Делюсь.
День 1-2. Сначала люди, потом документы
Главная ошибка новичков — и моя в том числе — начинать с документации. Документы врут. Не специально — просто устаревают, не обновляются, описывают как должно быть а не как есть.
Первое что делаю на новом проекте — прошу пятнадцать минут с каждым ключевым человеком. Не полноценное интервью, просто познакомиться и задать три вопроса:
— Чем занимаетесь на проекте?
— Что сейчас самое болезненное?
— Без чего проект точно не взлетит?
За два дня таких разговоров получаю картину которую из документов не вытащить за неделю. И сразу понимаю кто реально влияет на решения, а кто формально в списке стейкхолдеров.
День 3-5. Разобраться в предметной области — но не глубоко
Не пытаюсь стать экспертом за неделю. Цель другая — понять достаточно чтобы задавать осмысленные вопросы и не выглядеть человеком с другой планеты на встречах.
Что помогает:
— Попросить кого-то из команды объяснить процесс "как будто я первый раз это слышу". Люди любят объяснять — и в процессе сами замечают что некоторые вещи объяснить сложно
— Найти самый главный объект системы — заказ, пациент, договор, заявка — и понять его жизненный цикл. Вокруг него обычно строится всё остальное
— Посмотреть на схему базы данных если есть доступ. Там видно реальную архитектуру, а не ту которую нарисовали в презентации
День 5-7. Найти где болит прямо сейчас
На каждом проекте есть что-то что горит, раздражает или давно висит нерешённым. Найти это — значит быстро стать полезной.
Не жду пока мне скажут. Спрашиваю напрямую: "Что сейчас мешает команде работать быстрее?" или "Есть что-то что давно хотели разобрать но руки не доходили?"
Иногда это маленькая задача которую можно закрыть за день. Но закрытая маленькая задача в первую неделю — это огромный кредит доверия на старте.
День 7-10. Картина целиком
К этому моменту уже есть кусочки пазла от разных людей. Время собрать их вместе.
Рисую для себя — не для документации, просто для понимания:
— Кто главные участники процесса и как они связаны
— Как выглядит основной сценарий от начала до конца
— Где стыки между системами или командами — там обычно и прячутся проблемы
Этот набросок показываю кому-то из команды и прошу покритиковать. "Я правильно понимаю как это работает?" — один из самых продуктивных вопросов в первые две недели.
День 10-14. Договориться как будем работать
К концу второй недели уже понятно с кем предстоит работать плотнее всего. Самое время договориться о правилах — не потому что я люблю бюрократию, а потому что потом договариваться сложнее.
Как фиксируем требования. Кто финальный ЛПР по спорным вопросам. Как обрабатываем изменения. Где живёт документация.
Пять минут такого разговора в начале экономят часы разборок потом.
Чего точно не стоит делать в первые две недели
— Предлагать "а вот у нас на прошлом проекте было лучше". Даже если правда. Особенно если правда — Брать на себя задачи раньше чем понял контекст — переделывать дороже чем сделать позже но правильно — Молчать когда что-то непонятно. Вопросы в первые две недели воспринимаются как норма. Через месяц — уже нет
Первые две недели задают тон всему проекту. Не потому что за это время нужно всё узнать и всё сделать. А потому что именно тогда формируется первое впечатление — и репутация которую потом долго менять.
Если было полезно, ставьте реакции
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA