Как строить и мотивировать команду с нуля

Выпущено множество книг, тренингов, фреймворков по созданию команд, однако не всегда понятно, как выстроить это всё в единую систему и применить теорию на практике. Навык построения команд развивается в процессе приобретения опыта работы в разных компаниях и стартапах. О том, что такое команда, как её создавать и развивать, мы поговорили с Юрием Бранковским.

Юра, привет!

Привет!

Скажи, сколько команд ты построил?

Уф, хороший вопрос. Я не вёл точный учёт, но не менее десяти полноценных команд. Причём речь как и о продуктовых командах, так и о командах разработки, маркетинга. Разве что отдел продаж не строил — не довелось, хотя это интересно.

Ого, вот это опыт! А команда — это сколько человек?

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

А какая самая большая команда у тебя была? Кто в неё входил?

Самая большая — 10 человек. Разработчики, QA, проджект, маркетолог, дизайнер. Собственно, её я строил, будучи CPO Get Outfit.

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

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

Можешь пояснить на примере?

Конечно. Допустим, собрались два человека и решили сделать стартап.

С нуля?

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

А как нанимать людей с нуля в подобную команду?

Думаю, что в стартап важно набирать единомышленников. Сравнение команды стартапа с личностью максимально уместно, ведь успех стартапа зависит от скорости работы и согласованности действий, поэтому команда должна быть максимально синхронизирована. Когда я собирал команду как CPO, я представил её как личность, с которой мне бы хотелось работать. Я взял типологию DISC и представил, какими чертами и в какой мере должны обладать коллеги — части этой личности. При этом важно понимать, какой характер должен быть у определённой роли.

То есть?

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

А ты как CPO являешься частью этой личности?

Конечно, я её голова.

Отличное сравнение! Скажи, а почему именно DISC?

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

То есть недостаточно собрать команду, она ещё и проходит некий процесс формирования?

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

А сколько их?

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

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

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

И как их разрешать?

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

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

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

А что значит распределённая цель?

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

Раз уж мы заговорили о мотивации, расскажи, как ты мотивируешь команду.

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

А можешь привести пример?

У меня был кейс, когда заболел один из разработчиков, а необходимо было выполнить проект для крупного заказчика в срок. Основные работы были уже сделаны, но необходимо было закончить детали. Я попросил другого разработчика поработать сверхурочно. Зная, что ему важно признание, можно сделать акцент на то, что эта работа спасёт команду от срыва сроков. Обратите внимание, это не ложь и не преувеличение, это просто акцент. И разработчик с радостью согласился, мы его потом всей командой поблагодарили, подарили курс, который он хотел пройти.

А почему бы просто не заплатить?

Тут есть пара нюансов. Во-первых, не всегда есть возможность оплатить сверхурочные. У нас в стартапе это был первый крупный заказ, поэтому лишних денег не было. А во-вторых, даже если оплатить эти дополнительные часы, то это не добавит мотивации, если человека не воодушевляет материальная мотивация. Да, он испытает радость, но воодушевления не будет. Он будет просто больше работать за деньги. И всё. Любую материальную мотивацию важно привязывать к чему-то личному. Например, если сотрудник мечтает о каком-то гаджете, можно сказать, что он получает не просто бонус за работу, а приближает момент покупки этого устройства.

Какие ещё есть инструменты мотивации?

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

А что значит давать обратную связь?

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

А как часто надо давать обратную связь?

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

Но продакт же тоже руководитель?

Не совсем. Я считаю, что в продуктовой разработке нет руководителей, есть профессионалы, которые берут на себя ту или иную роль. Продакт берёт на себя ответственность за результат. Дизайнер — он ведь тоже продакт, но берёт на себя ответственность за UX. Разработчик ответственен за код и так далее.

А есть ли у тебя некоторый фреймворк, который ты используешь при построении команд?

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

Из-за количества людей?

Да, и как следствие — из-за количество взаимосвязей. Поэтому когда меня просят помочь с построением команды на экспертных консультациях или как внешнего CPO, я рекомендую использовать такую последовательность.

Определить цель, к которой должна прийти команда, и критерии достижения. Важно, чтобы конечный результат был очевиден для всех стейкхолдеров. Далее вы определяете, что мешает этой цели достичь и как решить эти проблемы. Для решения проблем нанимаете людей в команду. За счёт того, что задачи родились из общей цели, понятно, какие цели ставить лично каждому. При найме сотрудников учитываете характеры и необходимый уровень подготовки. Для этого я использую паспорт сотрудника: документ, в котором я подробно описываю задачи, характер, скиллы, KPI и так далее. На основании этого делаю систему взвешенного скоринга навыков (чтобы не принимать эмоциональных решений). Этот паспорт и скоринг отправляю рекрутеру (если нанимает кто-то со стороны). Таким образом, я нанимаю сотрудников быстрее и максимально подходящих под критерии. К тому же, рекрутер не предлагает нерелевантных кандидатов.

А что делаешь после найма?

Как раз в этом паспорте прописан чеклист адаптации, задачи на испытательный. После испытательного встречаюсь с сотрудником и определяю с ним план развития. Эти встречи один на один необходимо делать регулярными. На них мы разбираем результат и даём обратную связь друг другу. Тип мотивации, опять же, прописываю в паспорте.

Прямо целый фреймворк! Ты не думал его как-то структурно оформить?

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

Юра, благодарю за подробный рассказ! Уверен, читатели Cossa смогут применить твой богатый опыт в своей работе.

Рад был поделиться своим опытом!

Источник фото на тизере: NeONBRAND on Unsplash

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.