Сила не только в людях. Сила - в связях. (#пролюдей) По итогам приличного количества услышанных историй про трансформацию команд, сложности и последствия, вот вам моя точка зрения, почему стабильные IT-команды работают лучше, и почему им иногда не нужно мешать. В айтишечке, где технологии меняются быстрее, чем листья календаря, забывается одна простая истина: самое ценное в продукте — не код или эксплуатация систем, а команда, которая его пишет и поддерживает. Имеем парадокс: команды из сильных инженеров, архитекторов и продактов не могут выйти на стабильный ритм и давать прогресс, в то же время другие команды без «звезд» стабильно выпускают качественные фичи, быстро реагируют на инциденты и даже радуются новым вызовам. В чём разница? Не в технологическом стеке и не в уровне скиллов (хотя и в них конечно же тоже). Разница в качестве взаимодействия внутри команды. И это далеко не всегда про качественный менеджмент. Тезис 1: Психологическая безопасность — основа высокой эффективности. Создать ее по распоряжению нельзя. Google проектом Aristotle показал: ключевой фактор успеха IT-команд - психологическая безопасность. То есть среда, в которой разработчик может сказать: «Я не понял архитектуру», SRE - признать, что инцидент вызван его правкой, или продакт предложить откат фичи без риска быть низложенным. Такая культура не создаётся за один ретро-дейли-груминг. Она выстраивается месяцами через доверие, открытость и тысячи незаметных сигналов: кто-то кому-то помог, где-то поддержал, где-то признал свою неправоту. Такие штуки формируют в некотором смысле социальный капитал команды, и его нельзя измерить или посчитать, но это ахрененно важный актив. Тезис 2: Команды в IT не собираются. Они созревают. И делают это не со скоростью сахарной браги. Г-н Койл в своем «Кульурном коде» выдал, что эффективные команды - это не временные проектные группы, а устойчивые социальные системы. В IT это особенно заметно: лучшие результаты показывают долгоживущие и стабильные команды, которые прошли вместе через кучу релизов, инцидентов, кризисов в конце концов. Именно в таких коллективах складываются: - единый язык общения (не только Python или Go), - неформальные каналы координации («Я уже спрашивал у Тани — она в курсе»), - высокая скорость принятия решений («Да, делай, мы доверяем»). Эти патерны поведения нельзя просто так создать или взять и перенести в новую команду. Их можно только вырастить со временем и только совместной работой. Тезис 3: Цена реорганизации - долгий спад после «оптимизации» Частые перестановки разработчиков между командами, «перебалансировка нагрузки», смена тимлидов «для развития» - всё это выглядит логично на организационной схеме. На практике это практически всегда сброс прогресса на ноль. Команда возвращается на стадию forming и storming (Такман не одобрил бы): - снова учится доверять, - восстанавливает коммуникацию, - теряет скорость и предсказуемость, - теряет участников. Результат: - Прогресса не видать, сплошные продолбы, - Рост времени на вливание новых людей, - Повышение количества ошибок, - Снижение вовлечённости, - Выгорание. Скорость и надёжность зависят от слаженности, и такие решения могут стоить компании недель задержек и десятков инцидентов, особенно, если их не планировать как следует с учетом максимального количества рисков. Итогом. Лучшая стратегия для руководителя такого актива - не вмешиваться без острой необходимости. Трансформируй вокруг и встраивай то, что есть в то, что будет. Если команда стабильно дает, что должна, быстро реагирует на инциденты и демонстрирует инициативу, пусть даже и не удовлетворяет отдельным требованиям - это не повод для реорганизации. Это повод для гордости. Стабильность команды - это не инерция и признак застоя. Это конкурентное преимущество. Тот же г-н Койл выдал - "Лучшее, что вы можете сделать для своей команды, - это не вмешиваться, когда она уже нашла свой ритм". Что-то в этом есть, не так ли? А на деле имеем, что име