Привет, Хабр! Меня зовут Кирилл Веркин, я Senior QA в СберМаркете. Эта статья о том, как за 1,5 года моя команда прокачала уровень инженерной культуры с нуля до самого высокого среднего балла в компании среди 105 команд. (Да, у нас есть уровни инженерной культуры!)
Хочу рассказать, как мы их оцениваем и повышаем, почему это круто бустит развитие и как соревновательный аспект делает жизнь инженера гораздо интереснее. А ещё это история о том, как у меня получилось повлиять на командный результат будучи тестировщиком — на заметку тем, кто хочет не только расти сам, но и «менять мир».
Что было на старте (спойлер: ничего)
Полтора года назад я перешел в новую команду внутри СберМаркета, которая работала над реферальной программой и акциями по привлечению новых клиентов. Эта команда только зарождалась: тогда в ней было 3 бэкендера, совсем недавно появился тимлид, а пятым стал тестировщик (это я).
В тот момент в СберМаркете запустилась Модель оценки зрелости команд — инструмент, с помощью которого каждая команда могла определить свой уровень инженерной культуры и наметить план развития. Уровни нужно было «защищать» — показывать результаты и внедрять стандартизированные подходы.
Точкой отсчета стал... нулевой уровень. Звучит обидно. И очень мотивирует что-то менять. Поэтому по договоренности с тимлидом я взял на себя ответственность за прокачку команды по нескольким показателям.
Что такое модель зрелости команд и зачем она нам понадобилась
Team Maturity Model (Модель зрелости команд, дальше TMM) — это список инженерных практик с описанием базового уровня для всех команд разработки. Цель внедрения TMM — сильная инженерная культура: синхронизация и достижение бейзлайна по ключевым инженерным метрикам для всех команд.
Это универсальная практика, которую каждая конкретная компания адаптирует под себя, свои цели и особенности. Напрмер, в СберМаркет Tech в TMM включены 3 метрики, каждая из которых состоит из нескольких направлений:
Эксплуатация — оценивает вклад команды в работу над устойчивостью сервисов.
Дежурства и практики инцидент-менеджмента. Метрика оценивает, насколько зрелы практики по реагированию на инциденты, как решаются проблемы и проходит работа над ошибками.
Observability. Оценивает, насколько хорошо команда знает и видит состояние своих систем, имеет ли список действий на заранее известные проблемы.
Security — уровень информационной безопасности.
Образование и культура в сфере ИБ. Оценивает уровень Security-грамотности всех членов команды и актуальность знаний.
Развитие безопасности. Оценивает динамику применения Security-практик и снижение появления новых уязвимостей.
Delivery — как команда планирует сроки выполнения задач, насколько эффективно доставляет фичи в прод.
ТММ помогает системно прокачивать команды на основе прозрачных правил. Все метрики имеют уровни от 0 до 3 (кроме Delivery, там их 4), где 2 — это целевое значение, к которому все должны стремиться.
Например, вот уровни метрики «Дежурства и практики инцидент-менеджмента» в рамках «Эксплуатации».
Уровень | Описание |
0 | В команде нет процесса дежурств. |
1 | Настроен график дежурств и цепочка эскалации. |
2 (Бейзлайн) | Команда поддерживает актуальность информации о своих сервисах. Все в команде знают, кто такие NOC, что такое инцидент и что делать, если он случается. |
3 | В случае инцидента команда самостоятельно проводит разборы, заполняет постмортемы и заводит проблемы. |
Процесс прокачки уровня в рамках каждой из метрик строится следующим образом:
Раз в квартал по каждой из метрик проходит встреча встреча тимлида с экспертом — техническим лидером, отвечающим за развитие инженерной культуры в компании. На ней обсуждают текущий уровень команды и экшен-айтемы для дальнейшего роста команды.
Далее команда выполняет запланированные шаги и растет по TMM в течение квартала. Если возникают вопросы или нужна помощь, призывают на помощь опять же внутренних экспертов. Каждый участник команды может взять на себя лидирование зрелости по категориям ТММ в команде.
По окончании квартала команда может попробовать «защитить» получение нового уровня.
Как мы прокачивали метрику Delivery
Я загорелся идеей повысить уровень инженерной культуры своей команды и договорился с тимлидом, что попробую себя в роли лидера по прокачке одной метрики.
Пока мы выбирали, какая метрика это будет, в компании объявили большое соревнование: нужно первым достичь 3-го уровня метрики Delivery.
Мы решили, что стоит сфокусироваться именно на ней. К тому же, Delivery ближе всего к бизнесу. Казалось, что починить её можно настройкой пары процессов и взаимодействия в команде. В общем, все виделось относительно несложным.
Когда прокачивается Delivery, ускоряется выпуск новых функций и исправлений, сокращаются временные задержки и растет производительность команды. Снижается вероятность возникновения ошибок и проблем, сокращаются затраты на разработку и обслуживание продукта. А команда становится более адаптивной к изменениям и может быстрее на них реагировать.
На момент старта в нашей команде были следующие проблемы:
Мы не оценивали сложность задач и брали в спринт всё «без разбора».
Как следствие — брали больше задач, чем могли выполнить.
Задачи были не декомпозированы: мы не разбивали крупные таски на более мелкие — в итоге на ревью нужно было просматривать большие фрагменты кода, что увеличивало сроки.
Мы не обсуждали, что в спринте прошло хорошо, а что не очень, и не проговаривали, на каком этапе возникают повторяющиеся проблемы.
Я понял, что нам нужно внедрить регулярные ретро, и записался на внутреннее обучение у скрам-мастеров — это был дневной мастер-класс с теорией и практикой, после которого у меня остался готовый фреймворк и набор шаблонов в Miro.
Теперь я был во всеоружии и готовился к тому, что ретро сможет решить большинство наших проблем — и мы быстро получим первый уровень Delivery, деньги и славу.
Внедрили ретро
Мы начали проводить ретро в команде в конце каждого спринта. Выделили 2 цели:
Развитие командной рефлексии — начать обсуждать проблемы, анализировать их и выделять экшен поинты для развития.
Сделать это регулярной практикой. Мы будем потихоньку предпринимать новые шаги, которые помогут завоевать 1-й уровень Delivery. Например, один из пунктов, чтобы его получить — смотреть дэшборды с командными метриками. Эту практику внедрили в первую очередь.
Подробнее об IT-метриках в СберМаркете наши tech-менеджеры рассказывали в подкасте «Люди и код».
На ретро мы начали смотреть на такие диаграммы:
сгорание задач — с какой скоростью закрывались задачи в течение двух недель;
управление — на каком этапе зависали задачи;
производительность — какой процент задач, заявленных на спринт, выполнен в конце двух недель.
Вскоре стало понятно, что обсуждение графиков само по себе не особенно двигает процесс от слова к делу, и я начал заводить задачки по результатам ретро. Мы выносили экшен-поинты о том, как можно улучшить процесс, что будем делать и кто из команды ответственен за конкретный пункт. Пример такого экшен-поинта:
Зафиксировать на странице Командные соглашения: для того, чтобы реквест считался проверенным, нужное как минимум два апрува от команды. 15.09.2023. Ответственный — Иванов Иван Петрович.
Как стратегия: мы всей командой пытались предотвратить проблемы, которые возникли в прошлом спринте. А я стучался к ответственным за отдельные шаги и отслеживал, идёт ли работа по ходу спринта. Дальше в новом спринте мы разбирали новые проблемы. Постепенно процессы стали улучшаться: мы начали более равномерно закрывать задачи в спринте и, как следствие, следы прогресса мы увидели и в оцифрованном виде — на графиках.
Это заняло больше времени, чем планировалось изначально. Ключевой сложностью стало научиться корректно оценивать сложность задач.
Вписались в новый челлендж
За 10 месяцев мы достигли сразу второго уровня! Именно столько времени нам понадобилось, чтобы не только изменить процесс, но и показать результат на реальных данных. 2-й уровень нам выдали, когда по итогам квартала мы стали закрывать 70% запланированных задач.
Через пару месяцев после этого у нас в команде появилась проджект-менеджер, и работа по этому направлению перешла к ней. Уже под её чутким руководством мы достигли 3-го уровня, хотя и не стали в этом первыми в компании. Она помогла нам навести порядок с документацией — мы стали лучше описывать задачи и еще точнее их оценивать.
Однако совсем скоро стартовал новый челлендж. Теперь команды должны были достичь среднего уровня в 2,8 по всем метрикам (балл за Security и Эксплуатацию считается как среднее арифметическое нескольких метрик, поэтому может быть дробным). На тот момент мы достигли второго уровня по всем метрикам и решили ворваться ещё и в эту игру.
Как взялись за следующую метрику и что из этого вышло
За несколько месяцев до объявления конкурса тимлид предложил мне лидировать рост ещё одной метрики — Security. А точнее — одной из её составляющих: обучения и развития культуры ИБ. Для этого было необходимо, чтобы все члены команды регулярно были в курсе свежих изменений в практиках ИБ в компании и своевременно проходили обязательные курсы.
В команде назначают Security Champion’а — ответственного за метрику Security. Он посещает воркшопы по безопасности, а затем транслирует информацию на команду и следит за тем, чтобы эти знания применялись на практике.
Уровень 2 по этой метрике присваивается команде, когда все члены команды успешно прошли онбординг-курс, в команде назначен как минимум один Security Champion, никто еще не прошел тестирование по материалу от Security Champion’а.
У нас Security Champion’ом назначили меня — я ходил на обучение от команды ИБ, а затем доносил ключевые мысли до команды с помощью воркшопов. После я следил, чтобы необходимые Security-практики использовали при разработке.
Чтобы защитить нужный уровень по этой метрике, мы предоставляли записи проведенных командных воркшопов. Всем членам команды нужно было пройти обязательные курсы, я лично составил с каждым план по прохождению и поддерживал в этом процессе. В итоге мы достигли 3-го уровня Security через 4 месяца после получения 2-го.
В итоге всего за 1,5 месяца со старта конкурса мы стали первой командой, которая достигла среднего уровня инженерной культуры 2,8 по всем трём метрикам!
Что в итоге
В каждой практике есть уровни и их описание — это добавило элемент геймификации: как будто подталкивало собирать ачивки и помогло нам поэтапно развить инженерную культуру с разных сторон.
Как команда мы прокачали профессиональные скилы и укрепили работу в команде. Например, я примерил на себя лидерские функции, повысил грейд и получил крутой опыт — понял, что хочу быть тимлидом и мне это нравится. А ведь многие инженеры хотят получить менеджерскую роль просто потому, что так принято — а потом разочаровываются в этом. Мне повезло протестировать это на себе заранее)
Расскажите, а как у вас в компаниях оценивают инженерную культуру? Можете ли вы повлиять на процессы, будучи специалистом, а не тимлидом?
Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
