В прошлом посте мы поговорили о пользе технического времени в продуктовых командах. Сегодня предлагаю поговорить об антипаттерне его применения — так называемых core‑командах.

Иногда компании создают такие группы разработчиков, которым монопольно поручают все технические задачи. На первый взгляд, это кажется логичным: «пусть лучшие занимаются улучшением». На деле же это приводит к серьёзным проблемам: * Монополизация E‑функции (по Адизесу) в руках одного или нескольких человек. Решения принимаются узким кругом, остальные теряют влияние на архитектуру проекта. * Появление «технофашизма» и диктата «технократической элиты». Core‑команда навязывает свои правила, не учитывая мнение продуктовых команд. Например, внедряет модный фреймворк, который не подходит под текущие задачи, или требует переписать код «по канонам», хотя старый работает стабильно. * Разрушение климата в команде. Вместо сотрудничества — конкуренция и зависть. Разработчики из продуктовых команд чувствуют себя «второсортными», их мотивация падает. * Застой развития остальных разработчиков. Их работа скатывается до однотипной и скучной рутины: «просто делай, что скажут из core». Люди перестают расти профессионально и ищут другие места. * Рост текучки. Талантливые разработчики уходят, не желая работать в условиях тоталитарной иерархии. Остаются либо лояльные исполнители, либо те, кто не готов к переменам. * Стратегическое замедление продуктовых команд. Core‑команда становится «бутылочным горлышком»: все запросы на изменения идут через неё, сроки растягиваются, релизы срываются.

В итоге core‑команды приводят к результату, противоположному ожидаемому. Например, я лично наблюдал в некоторых командах (все совпадения случайны 😏), как переписывание с Java на Kotlin, с Objective‑C на Swift, с MVP на MVVM пожирало десятки человеко‑лет без какой‑либо отдачи. А любой бизнес требует не просто возврата инвестиций, а прибыли сверх вложенных средств. Показать прибыль с перечисленных задач практически невозможно. Мы сознательно старались избегать выделенных core‑команд.

Вместо этого: * давали возможность каждому сотруднику участвовать в технических улучшениях — даже если это 20 % времени; * поощряли обмен знаниями: успешные и провальные решения в обязательном порядке презентовались всей команде — это создавало культуру открытости; * делали акцент на коллективной ответственности за архитектуру и процессы — никто не мог сказать «это не моя зона»; * внедрили систему наставничества, чтобы сильные разработчики помогали коллегам расти, а не изолировались в «элитном клубе».

Запомните: технические задачи — это право каждого разработчика, а не привелегия избранных!

А у вас есть core-команды? Сталкивались с перечисленными сложностями наличия таких команд? Как решали их вы?

Я сознательно не стал говорить об ещё одной проблеме, напрямую связанной с core-командами: технический долг. Когда «грязную работу» по исправлению ошибок берёт на себя core‑команда, продуктовые команды теряют ответственность за качество кода — и начинают работать по принципу «сдал быстрее — получил премию, а косяки пусть чинят другие». В следующем посте расскажу, как мы разрушили эту порочную систему и выстроили подход, где каждая команда отвечает за свои решения — с конкретными примерами и результатами. Будет жёстко, честно и по делу!