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