#management #structure
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.
Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:
- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.
Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.
Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.
Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.
Внизу — диаграмма для визуала.
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.
Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:
- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.
Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.
Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.
Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.
Внизу — диаграмма для визуала.
❤1👍1