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

Кто такие агенты изменений в продуктовой команде?

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

Люди и процессы

Гибкие методологии призывают: управляете работой, а не людьми. Эта декларация зачастую вызывает недоумение. Ведь работу делают люди, причём сама по себе работа ИТ-специалиста – штука нематериальная. Как ей управлять?

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

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

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

Команда не может создать ценность (попасть в ожидание заказчика), если не выстроены коммуникации между бизнесом и разработчиками. Создание ценности процесс двусторонний. Этот процесс опирается на правила совместной работы, общие понимание предназначения команды, общее стремление к качеству продукта.

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

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

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

Вот почему любому мировому пролетариату (и не только) нужны вожди. Те, кто покажут путь к светлому будущему, вдохновят двигаться по нему, превозмогать и побеждать.

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

Агенты изменений

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

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

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

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

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

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

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

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

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

Дорожная карта развития команды

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

Пример дорожной карты развития продуктовой команды

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

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

Ещё немаловажный факт, что агент изменений сопровождает команду лишь в начале маршрута, когда сопротивление к изменениям велико. Когда отсутствие понимания, компетенций и опорных примеров легко может сбить команду с маршрута. И очень важно чтобы в этом сопровождении он оставался не нянькой, а наставником. Готовил зрелую команду, способную самостоятельно продвигаться по выбранному маршруту уже через 3-4 месяца.

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

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

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

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

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

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

  • Рубрики

  •  
  • Авторы

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

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT