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

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