{"id":14286,"url":"\/distributions\/14286\/click?bit=1&hash=d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","hash":"d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","title":"\u041f\u043e\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430\u0434 \u043a\u0440\u0443\u043f\u043d\u0435\u0439\u0448\u0438\u043c\u0438 \u0418\u0422-\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u044b","buttonText":"","imageUuid":""}

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

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

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

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

  • провожу встречи один на один с каждым участником команды

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

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

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

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

  • поддерживаю атмосферу в рабочих чатах

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

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

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

  • поддерживаю внутренние шутки/мемы

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

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

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

  • ввожу командные традиции

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

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

  • не обесцениваю проблемы, с которыми ко мне приходят

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

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

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

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

  • объявляю факапы на всю команду

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

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

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

  • рассказываю бизнес составляющую задач

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

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

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

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

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

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда