#рецепт
Как я усилил свой план погружения и вывел его на новый уровень

Здравствуй, придирчивый читатель!

Представь, что ты приходишь на новое место работы, решаешь кризисный проект или берёшь что-то капитально новое под своё крыло. Казалось бы, всё просто: получил вводные, вник — и вперёд

Но мой опыт показал, что обычного «ознакомления по верхам» недостаточно: иногда корни проблем уходят куда глубже. Поэтому я с годами выработал свой «план погружения» (он же расширенный онбординг), а недавно, после одного модуля на курсе руководителя отдела от стратоплана, прокачал его ещё сильнее

В основе лежал мой старый рецепт включения в новое место. А теперь я дополнил его более системным аудитом. Вкратце:

1. Люди
Начинаю с 1–1 разговоров с руководителями (CTO, CIO, CPO, PM) — минут по 45. Пытаюсь понять их фокусы, проблемы, приоритеты. Затем иду к тимлидам (включая Lead QA, Lead DS): тут планирую около часа, беру сведения у HR, выясняю мотивацию и психотип. После этого говорю с каждым участником команды (30 минут на человека), а заодно со смежниками (DevOps, саппорт, дизайнеры, маркетинг, продажи) — ведь часто затыки именно на стыках. На этом этапе рождаются «карточки сотрудников» и общее понимание «кто есть кто»

2. Производство
Чтобы увидеть реальную картину, провожу Value Stream Mapping (VSM), изучаю Jira, устраиваю, если получится, короткий воркшоп STATIK. Ищу узкие места — «бутылочные горлышки», провисание задач, перегрузы. Иногда открываются просадки, о которых даже лиды не подозревали. В итоге получаем «карту производства» со всеми входами/выходами, правилами и важными метриками

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

4. Метрики
Когда уже понимаю общую канву процессов и команд, подключаю анализ метрик. Смотрю дашборды в Jira, прогоняю доски через инструменты вроде Nave (чтобы найти аномально долгие задачи или сбой в SLA). Но этим не ограничиваюсь:

Финансы. Параллельно стараюсь прикинуть ФОТ (фонд оплаты труда), операционные затраты (подписки, железо и т.д.), общий PnL, юнит-экономику (если последние 2 доступны). Изучаю любые вспомогательные дашборды или отчёты, которые у них есть. Если где-то избыточные расходы или, наоборот, узкое место, это важный сигнал для управленческих решений

5. Финальный свод
Все найденные «артефакты», «проблемы» и «риски» укладываю в структуру «Оперативный план – Стратегический план». Сразу становится видно, что горит и что ждёт более глобальных правок. За счёт такого подхода это не формальный аудит, а именно погружение: люди видят, что ты не боишься вникать в их детали, а значит, охотно рассказывают о настоящих болях.

P.S. Это занимает порядка двух недель фулл, кажется долго. Но зато, когда доходишь до выводов, у тебя в руках не набор «бумажек», а реальное понимание, что происходит и как это чинить. Такой онбординг проще объяснить и своей команде, и руководству: «Мы не только почитали регламенты, но и прожили их рутину, вот почему план сработает»