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

Диагностика продуктовых команд как поток

Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что с этой командой мы какое-то время поработали: разобрались в её рабочем процессе, особенностях, составе, области ответственности... Реализовали набор практик, помогающих работу/результаты структурировать, визуализировать, организовывать, измерять и улучшать. Всё на основе важных принципов и исходя из определённого, нового продуктово-гибкого mindset'а (это слово я на русский перевести затрудняюсь). Итого: первоначальные инвестиции сделаны, далее ожидается более самостоятельное движение этой команды вперёд. Возникают важные управленческие вопросы:

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

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

Предположим, что у нас не одна продуктовая команда, а много. Что такое много? В среднего размера компании, имеющей собственную разработку ПО, ИТ-департамент состоит из 500-1500 сотрудников. Что даёт нам оценку в десятки продуктов и, соответственно, десятки продуктовых команд. Мы не сможем уделять равное внимание каждой из них, и нам крайне важно понимать, какие из команд нуждаются, к примеру, в методологической поддержке, насколько сильно, насколько срочно. Диагностика может дать ответы и на эти вопросы, но как провести (а точнее — регулярно проводить) диагностику десятков команд?

Консалтинговый опыт Cleverics позволяет утверждать, что диагностику продуктовых команд вполне реально организовать как поток, и в такой организации есть существенные преимущества. Вход (очередь на диагностику) может быть организован и приоритизирован, действия — расписаны поэтапно, работы — визуализированы, выходные результаты — получаемы в разумный срок и с достаточным качеством. Такая организация работ требует хорошо проработанной методической базы и поднимает новые управленческие вопросы. Некоторые из них я приведу далее, равно как и ответы на них, данные исходя из опыта Cleverics (помните, your mileage may vary).

Как часто проводить диагностику каждой команды?

Не чаще раза в полгода, не реже раза в год.

Сколько занимает диагностика одной продуктовой команды?

Хорошо бы укладываться в одну календарную неделю.

Можно ли ограничить количество одновременно проводимых диагностик? (см. WIP limit)

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

Сколько человек проводят диагностику одной команды?

По-разному. От трёх до пяти, и это зависит от выбранной вами модели управления и организационной структуры.

Диагностику проводят специально выделенные для этой работы сотрудники? (см. аудиторы)

Ни в коем случае. Аудиторы, как правило, так быстро отрываются от земли, что поймать их в свободном полёте не представляется возможным. А заключения аудиторов вроде «Ну вам бы все процессы подтянуть хотя бы до третьего уровня зрелости» не имеют никакой ценности (кстати, приведена реальная цитата из жизни одного горе-аудитора).

Могут ли к проведению диагностики привлекаться сторонние консультанты?

Да, и это хорошая практика. Консультанты приносят с собой не только воспроизводимые методики, но и свежий взгляд. Это помогает и обогащает и тех, кого диагностируют, и тех, кто диагностирует.

Нужно ли поручать диагностику полностью выполнять сторонним консультантам?

Никак нет. Во-первых, это довольно дорого, если у вас десятки команд. Во-вторых, хорошо бы накапливать собственную экспертизу.

Как быть, если в продуктовой команде есть работники подрядчика?

О, это шикарный практический кейс. И он имеет разные ответы, в зависимости от вашей стратегии работы с этим подрядчиком.

Не будет ли диагностика требовать много внутреннего ресурса?

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


Закончу на философской ноте. Поток диагностик — это поток чего? Уж не поток ли создания ценности? Не знаю, да и не важно. Я воспринимаю его как управленческий инструмент, позволяющий ускорить трансформацию и обеспечить направленное движение вперёд. Из опыта знаю, как сильно оказанная вовремя продуктовой команде помощь может повлиять на динамику и направление её развития. И из того же опыта знаю, как сложно обеспечить развитие десятков продуктовых команд одновременно.

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

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

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

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

  • Рубрики

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

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT