[Управление проектами, Управление продуктом, Управление персоналом] Основные проблемы в командах разработки и их решения

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
12-Апр-2021 21:30

Цитировать

Для будущих студентов курса "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-экономику?»

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_produktom (Управление продуктом), #_upravlenie_personalom (Управление персоналом), #_product_management, #_komanda_razrabotki (команда разработки), #_metriki (метрики), #_unitekonomika (unit-экономика), #_blog_kompanii_otus (
Блог компании OTUS
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_personalom (
Управление персоналом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:54
Часовой пояс: UTC + 5