Портал №1 по управлению цифровыми
и информационными технологиями

Что говорят продуктовые команды и что они на самом деле имеют в виду—10 советов по диагностике проблем в команде

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

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

1 «Наши клиенты ☠️… Они не способны понять, что мы пытаемся сделать»

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

Если команда не имеет времени понять, с кем сотрудничает, может возникнуть мысленное разделение «мы и они». Надо помнить, что клиент принимает на себя большие риски как лично, так и как бизнес. Важно развивать чувствительность к клиенту. Он бывает разочарован или находится в тупике, что может привести к резкости в общении.

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

2 «Давайте отложим следующую встречу на потом, когда будет, что показать»

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

Совет: когда вы или ваша команда нервничаете перед встречей с клиентом или заинтересованным лицом, задайте себе вопрос «почему?», а затем поговорите с клиентом именно об этом.

3 «Откуда взялся этот документ?»

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

Совет: уделив время обсуждению того, как будут организованы определённые группы документов, как будут фиксироваться идеи, какая используется номенклатура, вы сэкономите время и избежите боли впоследствии.

4 «Наши собрания долгие и бессмысленные»

Слишком легко попасть в рутину плохой организации встреч. Если собрания кажутся долгими, значит, они долгие, независимо от их реальной продолжительности. Определить правильное время на встречу бывает сложно. Подход, при котором рабочий день разбивается на часы, обычно означает, что встреча заполнит весь час (как минимум), независимо от её содержания.

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

Совет: простые правила: поставьте цель, зафиксируйте описание, назначьте задачи, договоритесь о следующих шагах. И оставьте гаджеты вне зоны доступа!

5 «Они что-то замышляют!»

Если неожиданный «сюрприз» вмешивается в ход проекта, возникает склонность к конспирации, когда отдельные небольшие группы обсуждают проблему в частном порядке. Это могут быть некоторые осложнения с клиентом или проблема конкретного члена команды.

Хотя зачастую это просто рабочие моменты, маскирующиеся под проблему. Плохо то, что остальная часть команды задаётся вопросом, что происходит. Это создаёт точку напряжённости, и волны от неё разрушительны.

Совет: постарайтесь быть до абсурда прозрачным. Разъясняйте все. Расскажите команде на дейли, что происходит, а затем повторите это при случае. И не прячьтесь друг от друга.

6 «Мне не хватает рабочего времени»

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

Совет: стоит оценить необходимость собраний. Если вы руководитель, возможно встреча нужна всего лишь для вашего успокоения, и разве это важнее, чем рабочий процесс? Можно ли получить информацию, необходимую для уверенности, другим путём?

Ещё одна проблема, на которую следует обратить внимание, это двойная нагрузка, которую команда может испытывать при непосредственной работе с клиентом. Тесное сотрудничество очень ценно, и я всегда буду его продвигать. Но стоит признать, что это дорого обходится команде. Люди сохраняют активность восприятия и  остаются профессионалами, интерпретируют комментарии и фильтруют потребности. С годами вырабатывается опыт управления загрузкой мозга, и это приносит облегчение. Но людям, которые привыкли работать за любимым столом в наушниках большую часть дня, такое общение причиняет неудобство и снижает продуктивность.

Совет: есть ли возможность зарезервировать специальные рабочие дни для организации совместной работы? Раньше я доходил до системы светофоров, у меня даже был светофор на мониторе. Зелёные дни доступны для общения и совместной работы; в красные лучше не мешать глубокому погружению в работу. Если это оговорено заранее, у команды есть прочное основание для планирования рабочей недели и осознание, когда они могут погрузиться в работу с головой.

7 «У нас сегодня презентация?!»

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

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

8 «Мы загнаны, как белка в колесе»

Текущий рабочий период может быть довольно интенсивным и утомительным, потому что на горизонте маячит дедлайн, или наоборот, не видно конца работе. Ситуация может усугубиться, если команда не понимает дорожную карту развития продукта, или не оглядывалась на проделанную работу достаточно долго, чтобы оценить успех. Я часто слышу такую вещь: это «спринтерский марафон».

Совет: одна из тактик — это сделать перерыв — специальный спринт каждые X спринтов, чтобы сосредоточиться на мелких деталях, которые были отложены, например, на оргвопросах и документации. Это особенно полезно разработчикам, которым необходимо выплатить технический долг.

9 «Нас спасет «дежурный пожарный»

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

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

Совет: как узнать, что один человек берет на себя весь груз ответственности? Например, клиент говорит: «Где бы мы были без [вставить имя пожарного]. Только бы он нас не бросил!». Но что, если герой уйдёт? Можно всецело полагаться на пожарного, чтобы упорядочить рабочий процесс, но затем нужно спланировать момент, когда он отпустит проект в самостоятельное плавание. Об этом должна знать и команда, и клиент.

10 «Не трогайте команду, им нужно преодолеть барьер»

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

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

Лучше сегодня, чем завтра…

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

Как вы, наверное, догадались, у меня для вас нет серебряных пуль — если бы я их нашел, я бы прославился! 😀Удачи🙏

Роб Бойетт
Оригинал статьи можно прочитать по ссылке

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT