Такая только у меня и у Майкла Джордана. Как построить команду мечты?

Часть I. Краткий гайд по организационным структурам команд разработки.

1️⃣Начнём с базы на века. Вряд ли IT или какая-либо другая сфера сможет полностью от неё уйти, она древняя, как первые люди. Или еще древнее. Цеховой подход. Он же функциональный. Это там, где есть слово «отдел» или его синонимы. Объединение людей по функциональному признаку (аналитики, разработчики и прочие). Задача передается по принципу конвейера – из одного отдела в другой.

Как и у любого подхода, у него есть плюсы и минусы
➕понятное распределение ответственности
➕высокая эффективность на определенных задачах: крупные долгосрочные проекты, где не важна гибкость реакции, узкоспециализированные и требующие высокой квалификации задачи (всестороннее сложное тестирование, работа с большим техдолгом и т.д.)
➖сложность коммуникации – люди, работающие над одной целью, зачастую друг от друга вообще отключены
➖отсутствие ощущения конечной цели
➖медленная реакция на изменение процессов – для возвращения на предыдущий этап, надо сделать слишком много.

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

2️⃣кросс-функциональным. Если вы остановитесь и чутка подумаете, то легко дадите себе ответ на вопрос, что это такое. Не остановились и не подумали? Ок, сделаю за Вас: это команды, которые включают специалистов по всем необходимым навыкам для конкретного проекта. Они уже идеальнее, поскольку их плюсы закрывают минусы цеховых команд
➕упрощение взаимодействия
➕сфокусированность на общем результате
➕адаптивность к изменениям
➕а еще бонусом идёт горизонтальное развитие специалистов в виду более плотного взаимодействия

Но имеются и свои минусы, куда ж без них
➖повышенные требования к лидеру такой команды, он должен обладать достаточными навыками для синхронизации различных специалистов: как минимум быть авторитетом в своей области (управление) – не принимать идиотских решений, как максимум – обладать знаниями, хотя бы на уровне, позволяющем понимать, о чём говорят профильные специалисты.
➖нечеткие границы ответственности могут привести как к конфликтам внутри команды (особенно, если руководитель команды для галочки), так и в распределении нагрузки.

Появление кросс-функциональных команд с возможностью их перераспределения (именно это важно) – как раз таки следствие появления

3️⃣матричного подхода к управлению. Почему вдруг «матрица»? Очень просто: двумерная матрица это таблица. Каждая ячейка такой таблицы – конкретный специалист, подчинённый своему начальнику «по вертикали» (в рамках функциональной структуры, начальнику своего отдела, как там эту должность не назови), а «по горизонтали» - руководителю (или менеджеру, или как там еще у вас принято) проекта, на котором он занят.

Матрицы делят по полномочиям РП: слабая, сбалансированная, сильная. Если коротко, то на первом уровне функциональному руководителю вообще насрать, чё там происходит на проекте и он может забрать специалиста в любой момент. В сильной РП полностью управляет своими ресурсами.

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

Как мы ранее определили: кросс-функциональные команды - следствие, в том числе, и матричного подхода, поэтому и плюсы с минусами будут похожие. Дополнительно отметим

➕позволяет настроить более эффективное использование ресурсов
➖конфликты между руководителями проектов за ресурсы
➖двойное управление может привести к путанице в подчинении

Team Topologies на очереди

Озвучка в комментариях

#медведьразмышляет #управление