Что делает из набора людей команду

С самого начала работы в IT я обращала внимания как работает команда, как происходит сбор команды, как организован онбординг. И чаще всего было так, что команда формировалась спонтанно и в общем-то несистематично.

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

Делюсь фишками, которые использую для создания команды:

Я подсмотрела это прием у ресурсных руководителей.

Отличие в том, что я это делаю неформально, То есть я не ставлю встречи в календаре. Я веду сама календарь этот встреч и ненавязчиво, с каждым участником команды созваниваюсь.

Это занимаем много времени, в тоже время и эффект того стоит.

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

Если в чатике задается вопрос, то стараюсь следить, чтобы был ответ.

Если в чате разводят холивар, то пресекаю. Вплоть до бана из чата.

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

Наверно ничего так не укрепляет команду, как внутренние шутки!

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

Но их не нужно придумывать, они рождаются сами. А вот когда шутка появилась, то нужно обратить на нее внимание. И попытаться внедрить ее, когда это будет уместно. Дальше уже сама команда подхватит и она превратиться в устойчивый мем.

Тут уже можно и нужно самому придумывать традиции. Но если они не заходят, то не надо насиловать.

Если традиция зашла, то уже сама команда будет следовать ей. И через непродолжительное время уже напоминать не нужно будет.

Если ко мне обращаются, а у меня нет времени, то я даже не буду начинать слушать. Договорю о времени, когда я смогу.

Потому что выслушать в “пол уха” и ничего не понять приведет к тому, что собеседник больше не придет с проблемами.

Есть ловушка когда разговор начался. Бывает, что ситуация знакома, и я уже знаю как помочь. Но все равно я выслушаю до конца.

Какими бы типовыми проблемы не казались — в каждом случае есть что-то уникальное.

Слышала мнение, что хвалить нужно публично, на всю команду. А ругать нужно наедине. Может быть это и правильно.

Но я придерживаюсь другого мнения. Я и хвалю и ругаю всех при всех.

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

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

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

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

Понимание бизнес контекста очень помогает в решении задач.

Послесловие.

Не обязательно каждая группа людей должна стать “командой”.

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