Как укрепить команду разработчиков?

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

Рассказываем, что мы делаем в Bimeister, чтобы укрепить команду и повысить ее эффективность.

Ни что так не объединяет, как общая цель, общая боль и даже общие страдания. Команда должна понимать как ее успех (или не успех) влияет на судьбу всей компании: быть в курсе плана ее развития, обещаний по доставкам и продуктовой стратегии. Члены команды должны знать, что мы делаем эту задачу, чтобы закрыть конкретный договор, иначе компания не получит денег и у всех будут проблемы.

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

Еще один важный фактор — открытость руководства. Ежемесячно у нас проходят Transparency митапы, где каждый сотрудник может задать любой вопрос любому руководителю. Вопросы бывают непростые, но тем не менее на них нужно отвечать честно и открыто. Так появляется чувство причастности к тому, что происходит в компании.

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

Необходимо включать камеры на созвонах, чтобы видеть, что ты работаешь с человеком, а не с роботом. Особенно интересно смотреть на домашний интерьер и окружение коллег — гитары, книги или картины. И, конечно, +100 к отношениям, когда команда показывает своих домашних питомцев — котиков, собачек, хомячков.

Для того, чтобы еще больше «познать» своего коллегу, мы добавили на ретроспективе игровой раздел «Кто ты в …», например, «Кто ты в мультфильме Шрек». Обычно это всем нравится, плюс в такой игровой форме можно узнать о коллегах что-то интересное (иногда информация будет интересна даже штатному психологу :))

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

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

Отдельная тема — взять на себя роль scrum-мастера. Это другой уровень — выйти в метапозицию из своей локальной роли и понять, как работает вся команда, а не только смотреть на процессы с позиции «винтика».

У команды должна быть своя история, ритуалы, легенды, правила, символы, мемы и даже свой мерч. Мы празднуем дни рождения команды, на уровне компании проводим соревнования, в которых приз получает команда, а не конкретный сотрудник. Например, есть соревнования по внутренним и внешним митапам, выступлениям на конференциях и статьям на «Хабр» — все идет в общую копилку, а в конце года команде выделяется приличный бюджет на тимбилдинг.

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