В комментариях к прошлой статье один наш с вами коллега написал очень интересное про свою компанию, замечательный пример из лиги Elite-performers в терминологии Dora. Я списался с ним лично и расспросил про его работодателя поподробнее. И там прям есть, что обсудить.
Что выдающегося?
Это компания, где работает больше сотни разработчиков, разбитых на 25 команд. Архитектура микросервисная, продуктовая. Каждая команда отвечает за свой набор микросервисов, работающих поверх инфраструктурного слоя. В целом, архитектура звучит прилично.
На всю компанию одна монорепа с одной веткой - мастером. Все пушат в мастер ежедневно без ПР (кроме новичков). После коммита сервис проходит е2е тесты и улетает в пром. Время от коммита до прома 3-4 минуты для маленьких сервисов. Для самых больших - от 40 минут до нескольких часов. В сутки компания выкатывает в пром 60+ релизов на все сервисы.
В идеологии компании господствует минимализм: если какой-то кусок кода не используется более 2 недель, он сносится. Никаких переусложнений, работы на будущее, никакой работы с отрицательным ROI.
Почему это круто
Для большинства разработчиков во всем мире такие процессы покажутся какой-то несусветной дичью. Но весь цимес в том, что это дефолтные процессы для айти-элиты. Они давно описаны в литературе и зафиксированы в отчётах. Например, общее число респондентов State of Devops, которые подтвердили такие процессы в своих компаниях, составляет около 7% (2018 год).
Уже больше десяти лет мы видим в ежегодных отчётах State of Devops одну и ту же картину: чем меньше время от коммита до релиза и чем чаще поставки, тем выше стабильность систем и выше экономические и нефинансовые успехи компании.
В общем, в BrightData процессы топ, прям по книжечке Accelerate. Если хотите работать, как элита, ориентируйтесь именно на такие компании.
Как сделать такое же?
Вам нужны:
1. Архитектура, позволяющая командам тестироваться (и, как следствие, релизиться) независимо друг от друга. Если вы не можете задеплоиться, пока не потеститесь вместе с другой командой, никаких нескольких релизов в сутки не будет точно.
2. Полностью автоматическое тестирование. Успеть за час (да даже за день) руками протестить все, очевидно, невозможно.
3. Лидеры, которые умеют делать первые 2 пункта. Если они не умеют, то ничего не получится. Они будут нанимать не тех людей, организовывать не те команды, ставить не те задачи.
Ведро дёгтя.
Не могу не заметить, что в этой бочке мёда есть и из-за чего расстроиться. В комментарии нашего коллеги я увидел фразу, которая меня сразу насторожила: если человек начинает систематически косячить, его увольняют одним днём. О психологической безопасности в такой ситуации, боюсь, говорить тяжело.
Судя по тому, что мне удалось узнать, в этой компании весьма такая токсичная культура. Не хочу пересказывать то, что рассказал мне в личку коллега, там не очень страшно, но постоянного стресса и выгорания в таких условиях вы вряд ли сможете избежать.
Насколько это важно?
Для сотрудника - однозначно важнее, чем все эти элитные процессы. Лучше работать в психологическом комфорте, но в менее удачных процессах, чем в постоянном стрессе, но в лучших в мире процессах.
А для компании? Как выяснилось в разных независимых исследованиях, для компаний - тоже. У нас есть 2 основных источника, которые подтверждают, что культура важнее всего. Первый - исследование Гугла под названием "проект Аристотель", которое выяснило, что самый главный предиктор успеха команды - психологическая безопасность. Другой источник - тот же самый State of Devops, который показывает (см изображение), что коэффициент корреляции между культурой и успехами организации в полтора раза выше, чем между IT Performance и успехами организации.
Так что будьте внимательны: хорошая творческая (не патологическая и не бюрократическая) культура в компании гораздо важнее, чем даже самые лучшие технические практики. И об этом я обязательно тоже напишу большой материал, потому что эта тема важнее любой другой технической темы, которую мы уже затронули или собираемся затронуть.
Post #18
1.17K

- ❤ 17
- 🔥 7
- 💯 2