Итак вы захотели оценить положение дел в команде. Оказались только что назначенным лидом или выдохнули после первого сданного проекта, который сделали не только собственными руками. Прежде чем бросаться за новый проект, задумались:
Теперь продукт работы, как тимлида – больше не только код, не количество закрытых задач в срок и даже не изящность или скорость решений.
Вы уже попытались или пытаетесь управлять этими параметрами напрямую и выяснили, что живые разработчики это не чистые функции, которые получают на вход задачи и дают новые функции и исправления, потому что попробовали управлять входом, добиваться кристально ясных требований и декомпозицию – бери кубики и собирай продукт, что конечно фантастика.
Теперь вы не только пишете код в большее количество рук. Вы ищете внутри команды технических лидеров и даете им реализовать свои амбиции, что дает рост людей. Чувствуете разницу?
Чувства в этом аспекте могут быть как полезны, для того что бы понять других. Они же могут исказить вашу картину мира. Сданный проект, премия, изменения в компании, неоднозначные события – упрощают гамму оценок – «у нас все хорошо», «все плохо, тонем», «нормально». Такая оценка в заметках не даст понимания, того, что было год назад и не поможет решить проблему.
Углубляя это понимание, хочу оттолкнуться от предпосылки, что продукт работы тимлида – здоровье команды. Давайте попробуем оценить его, посмотрев под несколькими углами на свою команду.
Этап развития команды
Если вы только что наняты или переведены, то попробуйте применить одну из моделей – например модель групповой динамики Такмена. В четырех словах: формирование команды, притирка, работа над принятыми ранее ролями, но уже конструктивно и собственно работа над задачами.
Если же вы сами набрали команду, то не стоит подразумевать, что путешествие по стадиям формирования будет происходить само собой, оставляя вас наблюдателем, потому как путешествие по модели, допустим, Такмена это далеко не вот этот график:
Скорее вот такой:
С моделью на первом графике в голове легко соблазниться идеей, что раз команде пару лет, то можно не держать в голове текущее состояние – вы «перформите». Далее конфигурация команды меняется в следующем проекте, и производительная после первой победы команда может не переварить взаимодействия с внешним миром в следующих проектах. А еще может заглушенный на этапе притирки конфликт создать мнимый эффект роста мощности, а затем всплыть в новых условиях.
Как строить кривую? Получить оценку внутри команды : «что мы смогли», «насколько мы мощные», «что нас сбивает», затем оценка снаружи обычно QA первым видит изменение производительности или качества, далее – заказчик. Иногда это HR-отдел, который разбирается в настроениях команды отстраненно от рабочего процесса. Но главное, почему определяется стадия – реакция на решение групповой задачи. Описание стадий и реакций.
Что с этим делать? В первую очередь это инструмент рефлексии. Не столь важен ответ, сколько попытка построить кривую и попутно понять, что происходило с вами в последние месяцы.
Отпуски, переработки, дежурства
Эти составляющие выносятся за скобки рабочего процесса, считая что отпуск отнимает пропорциональный кусок ресурсов, а переработки дают прирост на 150–200% и требуют только компенсации в разумный срок. На деле нелинейность складывается не только из первого порядка причин вроде «батарейка разряжается» или «вливание в работу после отпуска», но и второго – страдающей групповой работы людей разного состояния. Уставший менеджер не тянет бодрого аналитика, выгорающий бэкендер не может договориться с полным энтузиазма фронтендером.
Что тут важно? Если вы лид пришедший из вне или давно не смотрели по сторонам — важно не только посмотреть на планируемые отпуска, но и заглянуть назад, а лучше поговорить про отклонения от графика в прошлом с каждым участником команды и с командой целиком.
Последнее важно, потому как команда может по кругу сходить в отпуск, но сохранить общую усталость, например из-за отсутствия отсечек между проектами.
Предыстория побед и поражений
Предыдущие пункты скорее всего уже дали вам ясность, но все же. Даже на уровне лида вы уже можете потерять ощущение реальности того, что считается победой. Бэк и фронт вместе расследовали и победили баг, достававший год, группа разработчиков добила рефакторинг, который не впишешь в достижения продукта, но он существенно упростил рутинные изменения.
В чем ваша роль? Говорить с командой, выискивать достижения за пределами задач, приходящих из вне и фиксировать их. Если вы только возглавили команду — узнать историю и мифологию команды и продолжить ее. Нет ничего более разрушающего, чем менеджер перечеркивающий историю в момент прихода. Перечеркнутая история — это отсутствие мотивации творить ее, это по сути новая команда.
Что делать? Добавлять новых героев в свой эпос, интересоваться не только решением задач, но и тем, как и какими эмоциями эти задачи были решены.
Текущие конфликты
Конфликт в контексте здоровья команды – это не болезнь. Конструктивный конфликт ведет к движению, поиску решения и росту. Это естественный источник изменений, когда пара сцепившихся в поиске подходящего решения разработчиков без внешней мотивации искренне хотят найти его.
А вот иррациональные конфликты или полный штиль – повод присмотреться.
Как искать? Конструктивные искать обычное не нужно, участники сами готовы привлекать внимание к проблеме и погружать в нее. Скрытые – встречами, вопросом «а что еще ты думаешь?», внезапно открывающим поток мыслей, которые человек не знал когда будет уместно выразить, поиском причин, по которым человек не может выразить свою мысль открыто .
Цели и задачи стоящие перед командой и отдельными участниками
Бывает что компания устроена чуть сложнее чем просто иерархически, да и роль лида может не предполагать подчинения и единой точки концентрации всех обязательств. Иногда эти задачи не отследить в трекере задач.
Это могут быть задачи развития от HR, всякие наследованные KPI, задачи на аналитику или обучение от соседних отделов, цели гильдии, например бэкендеров, выступления.
Для команды это могут быть OKR реализуемых проектов, внешние договоренности.
Контролировать ли личные цели? Это ваш личный стиль, кто-то погружается в детали и перехватывает контроль, кто-то растит самостоятельность – но интересоваться определенно полезно.
Цели команды — если вы не участвовали в их принятии полезно прояснить и договориться заново. Есть шанс что они отпали автоматически, но мы говорим о здоровье команды и не хотим подцепить амнезию :-)
Договоренности и обязательства
Процесс исполнения обязательств – обычно длительный. Что если предыдущий лид ушел, радостно забыв обязательства? Что если вы сами их забываете? Что если участники команды обещают друг-другу ревью или время на обучение, но забывают об этом?
Компания могла пообещать новый ноутбук или рост, а контроль за этим лежал на лиде, он ушел, а разработчик демотивирован.
Что делать? Как и в прошлом пункте, узнайте договоренности, вспомните свои и зафиксируйте. Не можете исполнить сейчас? Обсудите, выберете стратегию решения – главное не игнорируйте. Необязательность вредит организму команды.
Самостоятельность
По большей части самостоятельность это мера обратно пропорциональная вашей авторитарности. Как и необязательность – зависимость от решений разрушает связи внутри команды. Зачем решать что-то вместе, если можно обратиться к начальнику?
Что измерять?
Представим рычаг, груз авторитета с одной стороны и независимость – с другой. Где вы? Даже команда с высокой степенью зрелости может быть задавлена высокой авторитарностью. Куда будет двигаться опора – решать вам, но текущее положение можно оценить по принимаемым решениям и вашем положении (или вашего предшественника) в них.
Искренность и токсичность
Можно много ссылаться на индустриальные стандарты «токсичности», профессиональный юмор и критическое мышление, но кто будет спорить с тем, что команда верящая в свою пользу, более функциональна?
Что важно? Отслеживать вектор демотивации и не делать преждевременных действий. Вытаскивать конструктивную критику из юмора и трезво смотреть на нее.
Неформальные взаимодействия
О да, это попытка понять результат того самого тимбилдинга. Когда вы последний раз выдыхали и общались об отвлеченным? Насколько это спонтанно было? Витает ли некоторое напряжение или команду саму тянет собраться после работы?
Предостерегаю от попыток это искусственно регулировать. Это область человеческих взаимоотношений и прямолинейные методы тут могут навредить. Будьте собой, слушайте людей, делитесь лидерством и растите его в других, даже если это просто желание организовать поход в бар.
Обучение
Уточните планы и ресурсы для обучения в компании. Наблюдайте за тем, как разработчики делится идеями и новостями индустрии. Ваше восприятие обучения зависит от роли и опыта.
Старший разработчик увидит еще одну точку зрения на вопрос, а младший – руководство к действию. С вашей точки зрения можно пропустить эти процессы. Проясняйте это.
Так же важен вопрос подкованности в soft-skills. Популярность этого вопроса дает ощущение осведомленности, но на деле важно синхронизировать понимание между участниками.
На что смотреть? На штиль, рябь или волны идей внутри команды. На планы развития.
Концентрация знаний
Речь о повышении bus-фактора, который относится к проектам и системам, но влияет на здоровье команды, сигнализируя о том концентрации опыта на конкретных участниках.
Стоит беспокоиться? Это не повод для суеты и насильного обмена опытом со всеми участниками. Можно как минимум осведомлять о существования атланта который держит важный сервис своей спиной, а еще лучше фасилитировать обмен опытом внутри команды.
Трансформация
Запущена ли трансформация ролей, процессов? Она может быть формальная – например изменение оргструктуры, либо неформальная, когда вы приходите в новую команду и проясняете текущее положение дел, собираетесь пойти думать и вдруг кто-то вспоминает: «А! Мы тут задумали перепилить воркфлоу, так что все что я говорил с понедельника станет не актуально. Предыдущий лид был согласен, ты же знаешь?».
Для чего? Выждать если необходимо или возглавить изменения. Иногда это повод для того, что бы отложить выводы о состоянии команды до окончания изменений.
Производительность
Итак ваш продукт – это здоровье команды. Еще недавно вы как разработчик передавали готовую задачу и послеживали, как она уходит на боевой сервер. Теперь вы управляете тем, как взаимодействуют участники команды и этот результат конвертируется в производительность. Это внешняя метрика, значение которой обладает некоторой инерцией.
Зачем измерять? Изменение этого показателя, может быть стимулом пройтись по этому списку и попытаться понять причины, оставаясь в рамках своей роли, без соблазна «поднажать» и применить дешевые способы мотивации.
Возвращаясь к моделям в начале – распространим это и на статью. Быть может в вашей команде есть составляющие, которые в данный момент влияют сильнее, чем все вместе взятое выше.
Также из оценки здоровья команды в целом намеренно убран вопрос прояснения состояния отдельных участников – для фокуса на групповом взаимодействии, однако если вы только погружаетесь в команду, подразумевается, что встречи один на один уже проведены.
Попробуйте применить разные линзы для взгляда на команду. Если вы любите больше формализации, процессов и индикаторов попробуйте методику Health Check от Spotify.
