Немного конспектов с выступлений на #uicdev2024 #управление #доклад

Перестройка, перезапуск команд
Рогожников Максим, Т-банк

2022 осень, предложение перейти в команду и перезапустить и перестроить.
Создание из одной команды или множества команд, новой орг структуры.

Как понять, что пора перезапускать?
1.Когда одна большая команда 10-12 разработчиков и они знают всё. Они много держат контекста в голове, что-то точнее держать невозможно.
2.Никто не знает как сделать поставку в срок. Приходится собирать картину у команды. Никакого доверия и предсказания поставки.
3.Бизнес ставит запросы сделать всё!
4.Нет единого человека который бы отвечал за сервис.

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

Варианты:
1.Джон Коттер - 8 шагов модель
Есть мультик, где мишка и айсберг. Что-то идёт не так, делаем команду реформаторов, куда идём и дальше по классике...
2. Adkar осознание, желание, знание, способность, закрепление результата.

Как соотносится с практикой?
Осознание проблемы.
VSM - event storming - визуально показать, как доставляется ценность поставки.
Коммуникации - связи людей в команде, кто лидер, скрытые лидеры, друзья, не друзья и т.д.
И как оно мапится на доставку ценности.

Перестройка - это политическое решение. Нужен спонсор, который доносит почему делаются изменения.
Команде говорим, что грядут изменения. Чем раньше начинается формирование реформаторов, которые лояльны к изменениям.

Куда двигаемся и как?
Зона ответственности команды. Как идёт поставка знаем и какие системы делаем, вот и получаем команду. Общение с лидером и формируются гипотезы проблем.

Архитектура - все её знает, но никто не рисует. С4, стикеры, миро - целевая картина, как что будет разделено и как будет развиваться, иначе комок грязи.
Иначе не получите нужных комитов.

Выбор как будет нарезана команда. Teams topology. Систем, сервисов, платформ и т.п.

Уровень ролей и людей. Какие роли нужны команде, чтобы поддерживать и развивать сервисы. Ролей хватало, чтобы выполнять весь функционал.

Backlog - как разделить на команды. Как в новые команды будет поступать бэклог задач. У кого-то много, у кого-то нет. Нужно управлять потоками задач.

Ритуалы - насколько хорошо решают поставленные задачи и цели. Можно посмотреть по VSM, scrum, kanban - нужно понимать какие минимально нужны ритуалы.

Распределение людей - разделить на команды людей. Какого уровня, кто и что должен делать.

Публичный этап - с 1 числа живём по новому! Сообщить людям и отвечать на вопросы. Куда и как движемся, стоит звать спонсора, который поможет.

Закрепление 1-2 месяца будет хаос, все захотят всё вернуть назад. Нужна команда реформаторов, которая отвечает на вопросы и помогать.

Собирать обратную связь-кто-то будет радоваться, кто-то будет хейтить. Постоянная история и мониторинг за тем, кто что хочет добавить, что работает, что нет.

Что в итоге?
Статистика, всё прекрасно! Но есть другие вещи. В новых командах будет фокус на команду, и сузится контекст, коммуникация будет хороша только внутри, между команд появятся проблема синхронизации, поставок и т.д. Новый пул проблем межкомандного взаимодействия.

Ссылка на презентацию - https://t.me/way_to_cto/6