Я — Антон Марунько, лид в продуктовых компаниях уже более пяти лет, помогаю строить и обучать команды в сфере IT.
В чём проблема
Срочные баги, горящие задачи, стратегическое планирование, синки с командой — как не сойти с ума?
Часто сталкиваюсь с тем, что начинающие тимлиды берут на себя много ответственности, быстро выгорают, упускают важные метрики или в принципе не знают о них. В этой статье расскажу, как этого избежать.
Как решать?
Помню, я прочитал в книге «От разработчика до руководителя» (советую всем, кто хочет идти на управленческие позиции в разработке) — чем выше позиция, тем больше пожаров у тебя будет ежедневно, но важно запомнить: тушить их все необязательно. Тушить их нужно по приоритету. При этом не забывать часть времени уделять стратегическим вещам и тому, что вы сами считаете важным. Например, для меня очень важная часть работы — 1:1. На этих встречах я максимально по-человечески взаимодействую с коллегами, узнаю, чем они живут, как думают и зачем им вообще нужен я, компания, эта работа и в целом, как стать для них чуть полезнее и интереснее.
Молодые тимлиды сталкиваются с большим стрессом от того, что надо тушить очень много пожаров: пламя загорается почти каждый день и очень долго тушится. Многие, делая кучу задач, до важного так и не добираются:
«Вот сейчас релиз выпустим и сделаю»
«Сейчас квартал закроем и сделаю»
«Сейчас, сейчас…только фичу помогу допинать коллеге».
Сфокусируйтесь на важном, а до остального вы когда-нибудь доберётесь. Ну а если не доберётесь, то скорее всего оно и не было так важно, или влияет на жизнь вашей команды / бизнеса не так сильно. Физически невозможно сделать и решить всё. Поймите это, примите и без стресса решайте важное.
Как же понять, что важно
Поговорите с руководителем
Он часто обладает такой информацией и может объяснить вам как за этим важным следить, почему за ним необходимо следить и какие проблемы это может доставить (или какие проблемы были в прошлом — низкое качество кода, очень большие сроки реализации функционала и тд.).
Определите ключевые метрики
Приготовьтесь найти/настроить метрики. Если у вас их нет и не осталось от предыдущего руководителя, то постройте в JIRA, обратитесь к аналитикам, если они занимаются внутренними задачами, или к проджект-менеджеру. Поверьте, эти ребята и девчата тоже обычно погружены во внутренние процессы и инструменты и могут помочь вам вытащить то самое нужное.
Важно понимать, что метрик может быть много. Необходимых метрик обычно всего две-три. И это то, что можно держать в фокусе даже в состоянии вечных пожаров.
А какие метрики вообще бывают?
Давайте сначала рассмотрим общий случай, не применительно к IT или конкретно к разработке.
Метрики для эффективности процессов в организации могут быть:
Время выпуска продукта/детали/юнита
Количество одновременно выпускаемых продуктов/деталей/юнитов
Стоимость производства одного юнита
Уменьшение стоимости производства/обслуживания на эффекте масштаба (насколько быстро уменьшается при увеличении выпуска)
Заменяемость и скорость замены компонентов при условии выхода из строя.
Теперь уточним те же метрики и раскроем их для команд разработки:
Сервисные:
Crash-free users — доля пользователей, у которых мобильное приложение ни разу не упало за неделю;
Uptime — отношение успешных запросов к общему числу запросов на бэк;
Cкорость отрисовки экранов — время отрисовки экранов на клиенте в разбивке по платформам;
SLO по исправлению критичных багов — скорость исправления багов и инцидентов уровня крит и мэйджор.
Процессные:
Количество критичных инцидентов в продакшене — показывает, сколько критов случилось за определенный период времени;
Change fail rate — отношение количества найденных ошибок к зарелизенным задачам. Вместе с предыдущей метрикой они позволяют понять, насколько наши процессы готовы поставлять качественные решения;
Time to market — время от момента когда задачу взяли в работу, до ее релиза;
Deployment frequency — количество выпущенных задач с кодом за период (от 2х до 4х недель), деленное на количество разработчиков, сделавших эти задачи. Ведь нам, помимо качества, важно ещё оценивать и скорость, с которой мы разрабатываем, а также насколько быстро мы способны выпускать новый функционал;
Reopen rate — количество переоткрываемых задач на этапе тестирования.
Отдельно стоит сказать про bus factor. Грубо говоря, это общее количество людей, при выводе которых эффективность команды (например, любая из вышеприведённых метрик) опустится ниже приемлемого значения.
Какие именно метрики использовать — зависит от ситуации в отделе и компании. Можно посмотреть на метрики департамента, на то, что в первую очередь поможет вашей команде решить проблемы:
Если болят проблемы с качеством — нужно смотреть краши, uptime и т.п.
Если задачки задерживаются на тестировании — то reopen rate — то, что обязательно нужно внедрить.
Если говорить про стандарты индустрии, то time to market, crash free, reopen rate должны быть точно. Начните с них, если не знаете, какие метрики нужны именно вам.
Ага, понятно, а что дальше?
Настройте мониторинг ключевых метрик
Чтобы они не потерялись из виду, настройте алерт в системах аналитики (Redash, например) на аномалии, напишите скрипт или поищите его в интернете. Многие руководители до вас работали с теми же инструментами и, скорее всего, уже делали что-то подобное. Да просто поставьте встречу в календаре или напоминание в чате раз в неделю/спринт/квартал «ПРОВЕРИТЬ МЕТРИКИ».С помощью мониторинга, например, можно до возникновения критической ситуации выявить неэффективно работающую команду или ее руководителя.
Подключите алерты или запланируйте контроль метрик
Допустим, метрики мы настроили, в Redash/Jira/Youtrack/whatever, но нужно не забывать их смотреть: можно настроить алерты об аномалиях — это упростит и сэкономит время в перспективе, только если автоматизация не займёт у вас месяц. Второй вариант: поставить напоминание в приложение/календарь или, ещё лучше, занять слот в вашем рабочем расписании на регулярной основе. Алерты часто выручали меня. Например, у меня был случай, когда один алерт оповещал о неправильно связанных задачах в JIRA — это как минимум нарушало регламент, как максимум — такая задача могла потеряться в автоматизации и не быть включенным в отчет или не быть прикрепленной к релизу. Алерт оповещал о таких аномалиях для моих сотрудников. Я не представляю, сколько времени хотя бы пару раз в неделю заняла бы проверка 5 команд с 24 разработчиками для выявления таких задач при формировании отчетов.
Не метриками едиными
Планируйте регулярные события
Таким же способом, как в предыдущем пункте, можно напоминать (и закладывать время) на отчёты и многое другое. Во-первых, так вы об этом не забудете, во-вторых, у вас будет достаточно времени, чтобы сделать отчёт. Особенно это помогает для подготовок к демо и другим событиям, которые случаются раз в 1-4 месяца — такое легко упустить из горизонта. Поставьте напоминалку в слот за неделю до демо, и ваша презентация будет не из одного слайда с md репозиториям :) (я такое встречал). В одной из предыдущих компаний я всегда получал плюс в карму от руководителя за своевременный отчет о работе команды за неделю, потому что слот в календаре был напоминанием, а заложенного времени всегда хватало, чтобы его подготовить.
Важное — утром
Банальная рекомендация, которую вы можете найти в многих книгах по управлению и развитию, — делайте стратегические/сложные/важные дела с утра. С начала рабочего дня. Почты у вас, как у руководителя, будет всегда достаточно. Разбирать её можно подходами по три-четыре раза в день.
А начать день нужно с планирования каркаса будущего спринта/составления индивидуального плана развития сотрудника и тд. То есть с чего-то, где нужна включённая голова и не истощённое творческое мышление. Тем более, что скоро в онлайн придут коллеги и не отвлекаться будет довольно сложно...
Делегируйте
Нет, серьёзно. Делегируйте! Делегируйте то, что не успеваете. Если некому делегировать, обучите, наймите и делегируйте то, что реально можно и нужно делегировать.
У вас 5+ человек в команде, а вы всё ещё онбордите каждого нового? Это точно необходимо делать именно вам или вы можете провести вводную встречу и передать наставничество коллеге, который, к тому же, очень хотел развивать эти навыки?
Совет банальный, но скажу по своему опыту: вы не поверите, сколько молодых руководителей не делают этого или боятся делать. Боятся отпустить релизный процесс, боятся отдать собеседование в руки опытного коллеги или срочно хотят помочь починить вот этот вот очень важный баг. Как показывает практика - ваше время стоит очень дорого, намного лучше, если вы будете делать жизнь команды и каждого в ней участника удобнее, эффективнее и с более ожидаемым для бизнеса результатом, а с багом справится коллега.
У вас есть минутка поговорить о стратегии и культуре?
После того, как вы добавили метрики, посмотрите на стратегию компании — на квартал, год, три. Это поможет вам узнать видение стратегии руководителя и посмотреть на конкурентов. Подумайте, что вы можете сделать, чтобы улучшить работу команды для достижения стратегических целей в будущем.
Последнее на что хочу обратить внимание — это культура компании. Если она описана, пройдитесь по пунктам, примерьте её на свою команду. Если всё совпадает, у вас идеальные собеседования и подбор — отлично! Заглядывайте туда периодически.
Если нет, то подумайте и спланируйте, что можно сделать, чтобы ей соответствовать или для начала, чтобы ваша команда начала её осознавать.
Культура компании, оформленная и выстроенная — это палочка-выручалочка любого руководителя, потому что в спорных ситуациях, разногласиях и отказе следовать общепринятым ценностям к ней всегда можно аппелировать до эскалации проблемы к руководителям высшего звена.
Вывод
Подходите к пожарам осознанно, с уверенностью в себе и своих силах, измеряйте основные показатели и спокойно управляйте процессами в своей команде, без выгораний и с минимумом инцидентов. У вас всё получится ;)
Делитесь любимыми инструментами и способами контроля метрик в комментариях! А ещё историями, как вам удалось пережить пожары и наладить свой быт руководителя. Думаю, такие истории помогают начинающим руководителям.