Привет, меня зовут Ксения, я менеджер проектов в ЮMoney. В этой статье расскажу про непростой жизненный цикл развития своей команды и как в итоге мы превратились в сплочённых, поддерживающих друг друга коллег. Спойлер: было очень непросто и понадобилось много терпения, веры в себя и людей. Делюсь, какие ошибки я допускала, как их исправляла и к чему это нас привело.

Существует модель развития команды по Брюсу Такману. Она состоит из пяти стадий:

• Формирующая. Когда команда только собирается, а люди знакомятся. Это самый короткий период, состоящий из нескольких встреч.

• Конфликтная (шторминг). На этой стадии люди друг друга не знают: кто как работает, какие у кого процессы. Коллеги проходят через конфликтные ситуации, борются за лидерство и разные роли в команде. Происходит так называемая притирка.

• Нормализующая. На этом этапе люди уже понимают, как взаимодействовать друг с другом и как работают процессы в команде. Здесь все вместе стремятся к общей эффективности.

• Перформинг. Стадия, на которой команда работает практически самостоятельно и роль менеджера отходит на второй план. Он арбитр в сложных ситуациях.

• Расставание. Эта стадия актуальна только для тех команд, которые собираются под конкретный проект. Когда проект завершён, команда отмечает успех, подводит итоги и расходится.

К штормингу можно вернуться на любой из стадий.

С чем мы столкнулись в ЮMoney

• Команду, в которую я пришла, сформировали из двух других (они работали в разных продуктовых направлениях).

• За несколько месяцев до меня здесь сменился продакт-менеджер.

• В сопровождении у команды было много продуктов, и их количество продолжает расти.

• Команда была разбросана по разным городам: Нижний Новгород, Санкт-Петербург. К тому же у всех ребят был разный опыт.

• При этом в команде были устоявшиеся процессы.

Команда дала обратную связь:

• Все взаимодействовали друг с другом исключительно как рабочие единицы, им не хватало человеческого общения.

• Из-за того, что две разные команды объединили в одну, было мало экспертизы по некоторым продуктам и процессам.

• Не все коллеги могли открыто высказываться и говорить о проблемах. Как выяснилось потом, у каждого копилось внутреннее недовольство, но на вопросы об этом команда отвечала, что всё нормально ?‍♀️

Я провела первоначальное ревью, познакомилась со всеми. Расспросила ребят, что им нравится, а что нет, что хотелось бы изменить и есть ли какие-то пожелания.

Передо мной встал выбор:

• Оставить всё как есть и привыкнуть к уже сложившимся в команде процессам.

• Внести изменения.

Команда разделилась:

• Кто-то поддерживал изменения.

• Кто-то относился к ним нейтрально.

• Остальные считали, что не нужно ничего менять, если всё и так работает.

Шторминг — довольно стрессовый период для команды. Вот с чем нам пришлось столкнуться:

• Люди не видели смысла в изменениях.

• Часть сотрудников вообще не проявляли инициативу, отмалчиваясь на встречах.

• Сопротивлялись новому формату встреч, вплоть до того, что мы не могли договориться о времени.

• Коллеги не принимали обратную связь.

• Не видели общую цель.

• Не доверяли друг другу: не могли открыто поговорить о том, что происходит и что они собираются делать.

Как мы внедряли изменения

Разделим весь процесс на две части:

• Налаживание взаимодействия и повышение доверия в команде.

• Внедрение изменений в процессы.

Если в команде нет доверия между людьми, ни одно из изменений не будет эффективным.

Как мы налаживали взаимодействие между людьми

Нам нужно было повысить уровень доверия в команде. Для этого потребовалось:

• Сформировать общий фокус.

• Внедрить регулярную обратную связь.

• Проводить мероприятия на сплочение.

• Проявлять друг к другу больше эмпатии.

Проблема с фокусом

У ребят не было понимания командной ответственности, отсутствовала общая цель, а результат работы был непрозрачным: брали один проект, выполняли его и шли за следующим. Такой себе конвейер.

Мы запланировали продуктовые новости: это серия встреч, на которых продакт-менеджер делится планами на предстоящий квартал и год, рассказывает, чем важны наши проекты и для кого они, какую ценность они несут для нас и для пользователей. Также продакт объясняет, какую прибыль приносят проекты, чтобы все понимали, как их работа влияет на компанию.

Нам приходил фидбек от пользователей ЮMoney — были и положительные отзывы, и критика. Это помогало понимать, что мы делаем верно, а что можно улучшить при реализации следующих проектов.

Параллельно мы провели ретроспективу по командной и личной ответственности. В рамках этой встречи разобрали:

• Как каждый человек влияет на результат команды и как мы друг от друга зависим.

• Как решаем возникающие вопросы, как подсвечиваем проблемы и распределяем роли при реализации проектов.

• Как помогаем друг другу — и в рамках проектов, и по работе в целом.

Обратная связь: почему она нужна на регулярной основе

• Это повышает уровень доверия в команде.

• Позволяет лучше понимать, что происходит с сотрудниками, и вовремя на это влиять.

• Даёт возможность решать спорные ситуации своевременно.

• Помогает выявить рабочие моменты, которые можно улучшить.

Обратная связь бывает развивающая, корректирующая и поддерживающая. Очень важно не только давать её коллегам, но и запрашивать по себе.

Какие инструменты для обратной связи есть в ЮMoney

Помимо того, что можно просто напрямую поговорить с коллегой, есть и другие способы.

• Фидбэчница в Универе. Здесь можно оставить положительный или развивающий комментарий по любому сотруднику в компании. Его увидит и сам сотрудник, и его руководитель.

• Комментарии к Опросу 360. Комментарии разбиты по компетенциям — хардовым и софтовым. Любую из них можно подсветить, а сотрудник возьмёт это в работу.

• Ачивки в личном кабинете сотрудника. Это специальные символические награды за достижения, например за запуск важного проекта, выступление на конференции, статью для Хабра. Ачивки отображаются на странице человека, которому они выданы, и видны всем сотрудникам.

Командообразование: какие были задачи

• Сплотить команду.

• Найти общие интересы.

• Создать доверительную атмосферу.

Можно ли сплотить команду, просто сходив вместе в бар? Да, но далеко не всем ребятам подходит такой формат. Выход — тимбилдинг, который:

• создаёт непринуждённую атмосферу;

• формирует условия, в которых все будут взаимодействовать друг с другом;

• вызывает интерес у каждого члена команды.

Поскольку участники команды разбросаны по разным городам, было непросто согласовать дату, время и место тимбилдинга. Мы провели опрос о том, что интересно ребятам, и в итоге выбрали кулинарный мастер-класс. Тут было всё, что нам нужно: непринуждённая обстановка, работа в команде, распределение обязанностей, а ещё вкусная еда, приготовленная своими руками. В результате лёд в команде начал таять.

Традиция тимбилдингов сохранилась: я на регулярной основе приезжаю из Нижнего Новгорода к ребятам в Питер и мы посещаем квизы, катаемся на арендованном катере по Неве или рисуем картины — вариантов много.

Делитесь в комментариях, какие тимбилдинги проводите вы. Нам нужны новые идеи ?

Появилась ещё одна необычная традиция: на дейлики по пятницам все приходят в головных уборах. И включенных камер в этот день сильно больше, чем в четыре предыдущих ?

Проявление эмпатии

В нашей команде минимум 12 человек. Все мы работаем по 40 часов в неделю, и за это время встречаемся в среднем шесть раз. С таким графиком невозможно общаться только по рабочим вопросам, а личная жизнь влияет на работу. Поэтому очень важно интересоваться жизнью сотрудников.

Можно задавать такие вопросы:

• Как прошли твои выходные?

• Как здоровье ребёнка?

• Как отпуск?

• Как прошла конференция, какие от неё впечатления?

• Какие планы на праздники?

• И так далее — в зависимости от ситуации.

Как проектному менеджеру, мне важно следить за состоянием сотрудников. Например, если человек был весёлым, идейным и разговорчивым, но вдруг перестал включать камеру и начал отмалчиваться на встречах, скорее всего, у него что-то случилось. С ним обязательно надо поговорить — вдруг ему нужен дополнительный выходной, чтобы он разрулил какие-то свои проблемы и смог вернуться в хорошем настроении? Важно, чтобы сотрудник понимал: к нему относятся не только как к исполнителю рабочих функций, а как к человеку, и нам важно, как он себя чувствует.

Как мы меняли процессы в ретро

Когда я только пришла в команду, ситуация с ретро (ретроспектива — взгляд в прошлое) была далеко не радужная: встречи проводили нерегулярно, в основном раз в квартал, вопросы решали в индивидуальном порядке. Сотрудники не могли высказываться на всю команду, у них не было понимания, как эта встреча может помочь и зачем тратить на неё час своей жизни.

Тогда я подумала: ха! Да у вас просто не было классного ретро! ? С моим-то приходом всё точно изменится к лучшему! Но нет.

Что пошло не так на нашей первой ретро-встрече

• Все отвыкли от формата ретро, и было некомфортно.

• Мы слишком долго обсуждали задания и зачем они нам нужны. Например, я попросила ребят написать впечатления от предыдущего спринта только прилагательными на конкретную букву — все зависли ?

• Мы успели обсудить не все задачи, которые хотели, и пришлось сместить фокус с основной повестки.

• А по тем задачам, которые обсудили, мы не назначили ни сроков, ни ответственных. Финал встречи получился скомканным: нам просто не хватило времени.

Из-за этого мнение команды о том, что ретроспектива вообще не нужна, только укрепилось?

Поэтому мы назначили новую встречу: ретро по ретро

Было две цели:

• Сформировать у команды понимание, зачем нужны ретро и какие вопросы мы можем на них решить.

• Договориться об удобном формате проведения встреч.

Запланировали, встретились, обсудили:

• Плюсы и минусы встречи для каждого и для команды. Сотрудники поделились своим видением того, для чего она нужна.

• Сформировали определение, что такое ретро для нас, и договорились о формате. Все проголосовали за стандартный формат, но ближе к Новому году попробовали формат адвент-календаря.

• Договорились, что заведём страницу с задачами и ответственными по ним. Теперь у нас есть отдельное место, где мы фиксируем вопросы к ретро, определяем их приоритетность и подводим итоги.

К чему мы пришли

• У всех сложилось единое понимание, зачем нужна встреча, что мы на ней делаем, как и для чего.

• Появилось пространство, где каждый может открыто высказаться и прокомментировать предложенные идеи.

• Получилось подсветить моменты, которые стоило пересмотреть.

• Сформировали пул задач, которые нужно выполнить, и назначили ответственных.

В ретро важно не то, что мы встретились и пожаловались друг другу, как всё плохо работает, а потом разошлись. Важнее понять проблему и то, как её решить. В этом были заинтересованы все члены команды.

Оценка задач: что было не так

Когда я пришла в команду, я заметила, что сотрудники, выполняющие задачи, склонны их переоценивать. Все задачи проходили процедуру оценки до распределения по коллегам, и эта оценка всегда была ниже итоговой ?‍♀️

Вместе мы разобрали эту проблему и поняли, что начальная оценка не всегда соответствует действительности и отражает суть задачи. А ещё выяснили, что процесс обсуждения задач неэффективен и негативно влияет на распределение нагрузки. Например, мы запланировали 20 стори-поинтов на спринт, а с увеличением оценки эта цифра могла вырасти до 25 или 30. Мы понимали, что просто не сможем выполнить такой объём работ за планируемые сроки.

Обсудили эти моменты с командой на ретро и вот к чему пришли:

• Важно, чтобы задачи оценивали все члены команды, чтобы каждый был вовлечён в этот процесс.

• Оценка должна быть прозрачной и понятной каждому.

• Нам нужно место, где можно обсуждать нюансы и вопросы, чтобы оценка была более объективной.

Как оценивали задачи раньше и как стало сейчас

• Было: каждый сотрудник получал список задач, оценивал его и после этого задачи попадали в работу к любому коллеге — менеджеры проектов распределяли их в рамках спринта или квартала. Сотрудник видел оценку задачи после того, как её получил, и недоумевал, почему она (оценка) именно такая.

• Стало: мы решили, что каждый раз будем создавать асинхронную сессию в программе, где перед встречей все коллеги могут просмотреть и оценить задачи, оставить свои комментарии, а потом на общей встрече обсудить возникшие вопросы и поставить оценку.

Сначала на подобные сессии уходило много времени, но, когда мы обкатали процесс и привыкли к формату, это изменилось. Теперь мы не тратим время на задачи, которые оценили одинаково, и фокусируемся только на тех, где оценки различаются.

Как мы внедряли шеринг знаний

Для команды это был новый процесс. Мы решили его наладить, потому что сотрудников из двух разных команд объединили в одну и не было понимания, кто в чём эксперт. Коллеги боялись не разобраться в процессах и что-то упустить в реализации, из-за этого сопротивлялись незнакомым задачам.

При этом ребята тратили довольно много времени, чтобы погрузиться в задачи. Даже если задачу брал в работу эксперт, нужно было пройти этап ревью кода от сокомандников, прежде чем она попадёт на прод. Ведь баги в финтех-продуктах недопустимы ☝️

Поэтому мы:

• Договорились с продактом организовать ряд встреч по специфике продуктов. На встречах менеджер рассказал, как работают продукты и зачем они нужны, какие есть пользовательские сценарии, какую пользу получают клиенты.

• Организовали технические встречи, на которых эксперт делился знаниями с командой. Мы разбирали техрешения, смотрели код. Нужно было понимать, как всё работает «под капотом».

• Применяли полученные знания на практике. Важно было не просто присутствовать на встречах, а обязательно внедрять в процессы то, что узнал.

К чему пришли в итоге

• Команда стала лучше разбираться в продуктах, которые были у неё на сопровождении.

• У ребят пропал страх, что не к кому будет обратиться, если эксперт заболеет или уйдёт в отпуск.

• Начала расти экспертиза: теперь коллеги могли разобраться не только в своих, но и в чужих процессах. Это положительно влияло на развитие каждого сотрудника и команды в целом.

• Повысился Time to Market, потому что сопротивление задачам пропало, а базовые задачи по всем продуктам мог подхватить любой в команде.

Где мы находимся сейчас

Мы пришли на стадию Norming:

• Теперь открыто обсуждаем вопросы.

• Исчезло разделение на два направления: знания распределяются равномерно по всем сотрудникам.

• В команде нет постоянных изменений. А если что-то меняется, это уже не вызывает такого стресса, как раньше.

• Появился чёткий формат взаимодействия: мы понимаем, кто за что отвечает и как работает.

• Теперь мы оцениваем эффективность процессов.

• И проводим регулярные нерабочие активности — тимбилдинги.

Выводы

• Шторминг — неотъемлемая часть развития. Да, это стрессово, но через это проходит любой менеджер и любая команда, которая хочет развития. Избежать стадию шторминга невозможно.

• Не нужно бояться конфликтов. Придётся очень много говорить и обсуждать, но главное — не сам конфликт, а как мы из него выйдем.

• Важно понимать, как решать нестандартные ситуации и к чему это приведёт. В этом помогает чёткая цель. И эту цель надо уметь продать команде, чтобы люди перестали сопротивляться и поняли, что от них требуется.

• Надо прислушиваться ко всем членам команды. Обычно у ребят есть опыт взаимодействия с другими командами и менеджерами проектов, поэтому они точно смогут поделиться знаниями и подсветить важные моменты, чтобы в дальнейшем всем было комфортно работать.

Если вы тоже сталкивались со стадией шторминга в команде, пишите в комментариях, как справлялись. Получилось ли выйти в Norming и какие цели на будущее? Будем рады пообщаться ?

Это один из докладов, который звучал на ежегодной конференции ЮMoneyDay. В этом году мы готовимся провести её снова. Наши разработчики, аналитики, тестировщики, продакты и другие специалисты поделятся своим опытом работы над финансовыми продуктами. Даты проведения объявим в телеграм-канале. Подписывайтесь чтобы не пропустить.