Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся темой управления командой подготовили статью, автором которой является Сергей Колосков.Также приглашаем всех желающих посмотреть открытый демо-урок «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?» За 1,5 часа на примерах реальных продуктов вы узнаете: - почему успех продакт-менеджера — это рост главной метрики продукта;- как определить метрику роста;- как построить аналитику и продукт вокруг метрики роста;- научитесь расчету unit-экономики, как это делают продакт-менеджеры;- узнаете, что может сделать продакт-менеджер для улучшения unit-экономики.   Те, кто работал с разными командами знают, что в одних командах что-то работает само, а в других — за этим надо специально следить и организовывать. В одних — все время появляются новые идеи, а в других надо организовывать мозговые штурмы или подкидывать материалы и спрашивать — нашли ли что-то полезное. Построение индивидуальных моделей для каждой конкретной команды — тяжело и требует времени. Есть системы, которые позволяют сильно облегчить системный взгляд на команду через ролевую модель командных ролей. Основа системы — ключевые проблемы и симптомы команды. Вроде бы внутри команды все готовы к работе. Но все время что-то мешает, и есть куча недоделанных вещей. Например, все спроектировали и пишут код, но при этом Continuous Integration и контроль версий не работает. То, что из коробки есть — сделали, а то, где надо докрутить — почему-то не доделывается. Диагноз: в команде нет людей на две роли: Специалист — это профессионал, который любит и знает свою работу (например, пишет бэкенд или базу данных), но за свои границы не выходит. Continuous Integration для него должен делать кто-то другой. Лид. Особенно важен. Он нацелен на результат проекта и согласен для этого делать любую работу, которую нужно. Он понимает, что что-то он будет делать непрофессионально, тратить время, но на это тоже согласен. Лечение: фокус на результате. Если такая ситуация возникает, а Работника в команде нет, нужен фокус на результате, особенно в серых зонах ответственности. Лучше всего организовать этот момент отдельно. И конечно, идеальный вариант — найти Работника компании при формировании команды, и тогда этот фокус он организует сам. Ситуация, когда типичные задачи хорошо решаются, а в случае затруднений почему-то наступает ступор. Например, есть проблемы с производительностью в базе данных, ее все время оптимизируют, но результатов это не дает. Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли – Генератор и Исследователь ресурсов, и они совсем разные: Генератор активно порождает оригинальные идеи и видит самореализацию в их воплощении. Запилить какую-нибудь сложную систему фреймворка, декларативное описание форм, еще что-то, что не очень нужно, зато прикольно и красиво — это про него. Исследователь не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить.  Лечение: Если этих ролей нет, то идеи надо находить любыми другими способами: например, мозговые штурмы и другие способы порождения идей. Но лучшим решением при формировании команды — найти Генератора. Он особенно важен на уникальных проектах или на проектах в неопределенности, где готовых решений не бывает, а мы заранее не знаем, сработает ли привлекательное снаружи решение.  Ситуация, когда существуют бесконечные споры между конкурирующими идеями. Как сделать общение фронтенда с бэкендом по разным паттернам. Или как использовать промежуточные транспортные Java-объекты: какими способами, какие нужны фреймворки и паттерны, использовать ли отдельно для каждого класса фабрику для порождения объектов или нет, и т.д. Диагноз: в команде несколько конкурирующих Генераторов или Исследователей ресурсов, конкурирующих за реализацию своих идей. Два Генератора в команде — такая же плохая идея, как и ни одного. Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть.  Бывает и так, что идеи есть, но они сложные. В этом случае команда либо не движется к результату, либо останавливается где-то на полпути. Это случается, когда есть мощный генератор, придумывающий новые сложные фреймворки и идеи, и которые сразу идут в реализацию. Но потом выясняется, например, что декларативное описание форм, которое он придумал, 100% проблем не решает, и даже 50% решает с трудом. Он его усложняет, но все кейсы и особые случаи все равно не натягиваются, и начинается ступор. Диагноз: идеи от Генератора принимаются без рефлексии. Лечение: организовать обсуждение и защиту идей до их реализации, а лучше заранее найти участника команды для оппонирования, чтобы оценивать идеи и варианты,  Следующая проблема: есть несколько идей, а договориться по поводу того, какая из них станет рабочей, не удается. Возникает паралич принятия решений. Диагноз: нет руководителей, нет таких, у которых есть роль, отвечающая за способность принимать решения. Координатор организует совместную работу, используя сильные стороны сотрудников и давая им возможность проявиться, но при этом принимает взвешенные ключевые решения. Координатор и работает на команду, и руководит. Он старается, чтобы люди проявляли свои способности. Выслушивает других, но при этом умеет принять адекватное решение: «Я вас услышал и решил, что здесь так… потому что сроки». Шейпер — это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: «Идем туда!» Лечение: внешнее руководство в точках принятия решений. Когда этот процесс налажен, неожиданностей почти не бывает.  Диагноз: у руководителя-Шейпера нет уважаемого им оппонента Координатора для обсуждения решений. Это обратная сторона Шейпера — без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий.  Лечение: создать внешние механизмы обратной связи для проверки курса движения команд, если нельзя найти оппонента в команде — чтобы у Шейпера были оппоненты для проверки курса движения. Если вы знаете, что у команды харизматичный лидер и есть опасность, что он заведет не туда, то периодически его решения нужно проверять.  Симптомы: выдающиеся члены команды с высокой самооценкой не могут работать вместе и каждый тянет в свою сторону. Очень часто команды собираются из людей, уровень которых выше среднего. Кажется, что такие команды должны быть более продуктивными: соберем наших лучших людей, и они сделают замечательный продукт. Оказывается, это не так. Диагноз: звезды в команде привыкли вести за собой и работать в роли руководителя, идеи которого без вопросов воплощаются в жизнь — у них нет навыков и опыта совместной командной работы. Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что «кто-то должен быть арбитром».  В такой команде существует парадокс: обычно руководитель команды умнее среднего участника, но не обязательно самый-самый (а вообще лучший вариант, если умнее других будет Генератор — его задача подавать классные идеи, и пусть он не отвлекается на повседневное руководство). Но для команды звезд нужно, чтобы руководитель был глупее среднего уровня. Тогда звезды объединяются и сотрудничают между собой, чтобы донести до этого глупого руководителя свои гениальные идеи. Симптомы: задачи приходят и остаются в состоянии «почти все сделано», но функционал при этом нельзя использовать. Казалось бы, всё почти готово — надо всего лишь тут и там завязать бантики. Но почему-то все они остаются не завязанными. Диагноз: потому что для этого нужна отдельная роль — в команде отсутствует педант, нацеленный на завершение задач. Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное — качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны. У Педанта есть и обратная сторона — он хочет сделать все излишне качественно. Если он стоит во главе команды, последствия ужасны, потому что для него сроки — это ничто. Но если он не руководитель, у него все время голова болит о том, что еще не внедрено и недоделано.  Лечение: чек-листы и административный контроль за реальным завершением задач не нужны, когда педант есть в команде.  Симптомы: поиск виновных в проблемах и неудачах, отсутствие взаимопомощи, люди указывают на несовершенства других. Диагноз: нет человека, который бы заботился о взаимоотношениях и сглаживал острые углы, это «слепая зона» у руководителя. Оказывается, это отдельная роль. Это не Координатор, и тем более не Шейпер, то есть роль не должна быть руководящей. Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении. Лечение: найти человека с эмпатией, который будет заботиться о взаимоотношениях. Руководителю объяснить, что важно не только производство, но и эмоциональные отношения. Необходимо показать ему на примерах, почему это важно, а не бесполезная трата времени. К тому же люди обычно оценивают коллег из своей роли — если роль несвойственна и непонятна, они искренне не видят, чем занят другой. При составлении команд имеют значение как профессиональные знания и навыки, так и приемлемость по командному профилю (роли): Пригодные и приемлемые — им работа скучна, это просто ступенька карьеры. Приемлемые и непригодные развиваются, и им интересно работать в команде. Неприемлемые, но пригодные — проблемные. Работу делают, но в команде из-за них возникают трения. Непригодных и неприемлемых надо уволить из команды — в другой команде они могут подойти по профилю и проявить свои сильные стороны. Для баланса должны быть все командные роли. Конечно, каждый может играть несколько ролей, переключаясь между ними.  При формировании команды: Нужны идеи, исполнители и организаторы. Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант. На несколько ключевых ролей (ядро команды) выбирайте профессионалов (пригодных по знаниям и навыкам) и у которых нет резких конфликтов по ролям. Они обеспечат выполнение работы. Дополняйте команду пусть и не столь выдающимися специалистами, но приемлемыми по командному профилю. Даже если они имеют формально недостаточный уровень по знаниям и навыкам, они будут расти и эффективно работать. При включении новых людей в сложившуюся команду приемлемость критичнее, чем знания и навыки. Если новый сотрудник подходит по своей роли, это снизит шторминг после его появления в команде. Командный дух не обеспечивает успеха, а конфликт между Шейперами и Генераторами не стоит решать при помощи их примирения — его надо делать конструктивным. Однородные команды слабы и часто выбирают себе подобных. Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды. Руководитель – Координатор, умеющий работать с талантливыми, но зачастую трудными участниками; Один сильный Генератор; При этом хорошим будем следующее распределение умственных способностей: умный Генератор; еще один умный не-Генератор, который ему оппонирует; умный Координатор; остальные – чуть ниже среднего уровня. Оптимальный размер команды — 5-7 человек: Ни 5, ни 7 человек не проигрывают и не выигрывают; 8 человек могут быть успешны, но возрастает нагрузка на руководителя, а также требования к нему; 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва; В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него. Смешанные сбалансированные команды, где представлены все роли. Однородные команды из стабильных экстравертов. В IT это редкость, но все же такие встречаются. Эти команды хорошо работают за счет сотрудничества, так как им нравится трудиться вместе. Роли в таких командах могут быть не выделены, но сотрудничество помогает преодолеть проблемы. Правда, они так же весело могут пойти на дно. Команды, во главе которых суперзвезда: если стратегия лидера верна, команда движется к победе, если нет — к поражению. И то, и другое будет стремительным. Команды типа «Аполлон» (команды звезд): острый ум, ресурсы и таланты, но и большие сложности в их применении. Ключ к успеху — хороший Координатор. Для сложных проектов такие команды особенно хороши, но нужно внимательно выбирать руководителя проекта. Узнать подробнее о курсе "Product Manager IT-проектов" Смотреть открытый демо-урок «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?» Редактор