Как стать автором
Обновить

Горизонтальные связи и ролевая модель большой команды

Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров5.7K
Всего голосов 16: ↑14 и ↓2+12
Комментарии9

Комментарии 9

На новом месте, при изменении с 15 человек подчинённых на 40, насколько сложным был это переход? Вы "вкатывались" самостоятельно, или был ментор / старшие товарищи, которые помогали освоиться?

Сначала действительно было сложно, но помогали старшие коллеги. Плюс выработала для себя такой принцип: проще сначала погрузиться в работу одной, самой проблемной команды — и потом постепенно «осваивать» работу остальных в каком-то разумном приоритете.

Выглядит как-будто вы пришли к матричной системе управления. В нашей компании что-то похожее с вашей на 60 разработчиков и это работает замечательно, а еще снимает кучу боли с людей которых в системе в этой быть не должно )

Да, это чем-то похоже на матричную структуру управления (когда человек одновременно подчиняется начальнику отдела в линейной иерархии и руководителю проекта) — но не совсем она. Здесь речь не про подчинение, а про горизонтальные связи и горизонтальное взаимодействие по определенным принципам. Руководит все-таки тимлид.

да да, я понял. У нас похожая история, чтобы два рука было у одного человека, но именно руководит один, второй по факту как подстраховка или для решения спорных моментов

Да, для подстраховки своей экспертизой.

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

Я думаю, что если «повесить» слишком много команд на одного тимлида, то управляемость упадет. По моим личным ощущениям, это до 15 человек в непосредственном подчинении, лучше — не более 7. Если больше человек в непосредственном подчинении, то желательно, чтобы эта ситуация была временной.

Здесь смысл в том, что тимлид не может быть одинаково сильным специалистом во всех областях - и разработка, и аналитика и все остальное. Отдельные лидирующие роли (аналитик стрима или центра технической компетенции) могут помочь конкретному участнику команды.

А, например, релиз-менеджер стрима нужен, чтобы разгрузить меня как ИТ-лидера стрима и не дать «просесть» важной организационной задаче выпуска релизов.

вы прежде чем разбираться с шариками, разобрались хотя бы что такое бэклог? есть определение?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий