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

Как защитить зрелую команду от деградации

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

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

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

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

1. Анализируйте свою поставку, а не только свою работу

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

Чтобы не угодить в эту ловушку обязательно обращайтесь на ваших ретроспекитивах к анализу данных. Объективные метрики потока создания ценности наилучшим образом подсвечивают проблемные зоны.

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

Посвящайте большую часть ретроспективы оценке поставки:

  • Объем поставки не сократился в последнее время?
  • Количество дефектов и доработок стремится к нулю?
  • Скорость обработки задач удовлетворяет заказчиков?

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

И только после всестороннего анализа поставки с использованием метрик, стоит переходить к обсуждению проблем рабочего процесса:

  • Требуется ли команде улучшение инструментов, технологий и стандартов работы для организации производственной среды?
  • Какие риски и блокировки возникали в предыдущий период и какой опыт команда из этого извлекла?
  • Каких правил совместной работы, внутренних или внешних, не хватает?

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

2. Предпринимайте усилия, чтобы ускорить поток

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

Потоковое управление подразумевает, что в каждую итерацию команда должна доставить как можно больше ценности. И все практики гибкого управления нацелены на то, чтобы задачи обрабатывались не только качественно, но и быстро.

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

Это нарушает базовый принцип потокового управления: заканчивайте начинать, начинайте заканчивать (Stop starting star finishing).

Гибкие практики управления вводят специальные менеджерские роли, помогающие команде сфокусироваться на внутренних проблемах и улучшении рабочего процесса. Команда, которую я упомянула в начале, работает под управлением на основе Канбан-метода. И он предусматривает роль менеджера поставки сервиса (Service Delivery Manager). Менеджер поставки должен проделать всё необходимое, чтобы поставка состоялась. Он фокусирует команду на создании ценности и отстраивает рабочий процесс таким образом, чтобы ускорить и выровнять поток создания ценности (в Scrum-командах аналогичную роль обычно выполняет Team Lead).

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

  • Следит, чтобы команда фокусировалась на доведении задач до финиша.
  • Координирует синхронизацию со смежными командами.
  • Ищет причины возникновения блокировок и рисков для задач, принятых в работу, и координирует действия по их устранению.
  • Инициирует необходимость внесения в рабочий процесс новых инструментов, стандартов или правил совместной работы.

Для реализации этих функций в команде есть событие оперативного управления – ежедневный короткий митинг.

 

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

Смотрите новый учебный курс “Трансформация ИТ в традиционных компаниях”. Кратное ускорение за счёт новой организации работы

 

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

Для этого достаточно пройтись по вашему списку задач в работе и свериться с текущим планом итерации:

  1. Эти задачи сегодня обрабатывается по плану (вместо «кто чем занят сегодня?»)? Что необходимо сделать сегодня, чтобы эта задача была завершена по плану?
  2. Кто может приложит усилия, чтобы задача была разблокирована (вместо «какие проблемы есть с задачей?»).

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

3. Ищите свежий взгляд

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

Очень хорошо в этом плане работают профессиональные сообщества и регулярные мероприятия по обмену опытом. Важно, чтобы они были неформальными и интересными, на злобу дня. Посмотрев на других, команда невольно задумывается: «А как это происходит у нас?». И выходит за рамки обыденности, понимая, что оказывается можно работать и по-другому. Или, наоборот, увидев проблемы других, может предложить своё решение, и при этом убедиться, что рабочий процесс отстроен в этой зоне действительно хорошо и может даже служить примером для других.

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

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

Итак, никогда нет предела для совершенствования. Даже зрелая команда может ощущать стагнацию или деградацию в своём рабочем процессе. Важно вовремя заметить сложившуюся ситуацию, используя объективные данные, взять под управление и найти точки роста.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM