Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не буду говорить о том, почему это так. На эту тему можно найти массу отличных публикаций, в том числе на нашем портале. Сегодня я хочу обсудить вопрос, как происходит перестройка работающей команды в сторону нового подхода.
Люди и процессы
Гибкие методологии призывают: управляете работой, а не людьми. Эта декларация зачастую вызывает недоумение. Ведь работу делают люди, причём сама по себе работа ИТ-специалиста – штука нематериальная. Как ей управлять?
На самом деле высококвалифицированные специалисты, которые и составляют команду ИТ-разработки прекрасно знают, как им делать свою работу. И именно из-за её нематериальной специфики, из-за неоднородности задач, сложности рабочей среды и исследовательского подхода к поиску решений, предпочитают самостоятельно регулировать этот процесс.
Но зачастую сосредотачиваясь не реализации задач, разработчики просто не успевают подумать о том, как организован их собственный рабочий процесс. Достаточно ли он удобный и эффективный. И если это не так, то есть большой риск свалиться снова в ручное управление, директивную раздачу задач каким-нибудь менеджером и размытие понимания того, что от команды ожидает получить бизнес.
При этом, говоря об изменениях в команде, есть риск угодить в когнитивную ловушку, поскольку возникает ощущение, что это касается только команды разработки. На самом деле, это ни в коем случае не односторонний подход. Инициировать перемены, как только лишь изменение внутренних процессов команды бессмысленно.
Команда не может создать ценность (попасть в ожидание заказчика), если не выстроены коммуникации между бизнесом и разработчиками. Создание ценности процесс двусторонний. Этот процесс опирается на правила совместной работы, общие понимание предназначения команды, общее стремление к качеству продукта.
Беда в том, что прекрасные люди в команде разработки далеко не всегда обладают соответствующими компетенциями. Они крутые специалисты в ИТ, но могут очень плохо уметь общаться и ещё хуже управлять организационными процессами. Могут вообще не подозревать, что работу надо не только работать, но и организовывать. И действительно испытывать ужас от необходимости в этом разбираться.
Страх перед изменениями, по сути своей есть неуверенность в собственной компетентности. Люди не боятся трудиться, люди боятся ошибаться. И очень неохотно включаются в процессы, которые для них сложны и не понятны.
А в случае, когда надо перестроить работу конкретной команды, даже подсмотреть негде. Очень хочется видеть перед глазами какой-то успешный пример и основывать на нем свои действия. Но так не бывает, поскольку условия, в которых находится каждая команда уникальны. И чужой пример выстраивания организационных изменений, может оказаться не только не полезным, но и разрушительным для сложившейся системы.
Вот почему любому мировому пролетариату (и не только) нужны вожди. Те, кто покажут путь к светлому будущему, вдохновят двигаться по нему, превозмогать и побеждать.
Шутки, шутками, но доля правды в этом есть и изрядная. Команде нужен некто, кто поможет разобраться, что происходит с организацией процессов сейчас, и какие шаги необходимо предпринять, для быстрого и безболезненного перехода к гибкому управлению разработкой. Таких специалистов чаще всего именуют агентами изменений или методологами.
Агенты изменений
Агент изменений должен обладать сочетанием компетенций, которое не так часто встречаются. И чаще всего такое сочетание возникает из непростого жизненного пути, через собственный опыт и последовательное саморазвитие.
Агент изменений должен понимать, как устроено ИТ, какие есть внутренние взаимосвязи и операционные процессы на всех этапах разработки и эксплуатации, как движется информация между заказчиками, разработчиками, поддержкой и так далее. То есть действительно на собственном опыте знать, как это работает.
Кроме того, методолог должен свободно ориентироваться в моделях и методологиях управления ИТ-разработкой, понимать их суть и границы применимости. Ему требуется не просто разбираться в каком-нибудь отдельно взятом DevOps, а осознавать эволюцию подходов и почему она происходила. Понимать как конкретная методология управления ложится на реальный ИТ-ландшафт, в котором ему необходимо работать.
А ещё он должен отлично ориентироваться в современном стеке технологий, актуальных для команды разработки. И не в отдельно взятой функциональной области, а на всех этапах жизненного цикла продукта.
А помимо этого, он должен обладать компетенциями модератора, уметь работать с людьми, настраивать их на принятие изменений, делать сложное простым, а непонятное доступным. Уметь фокусироваться на конкретной пользе изменений и доносить её до людей. Никакая методология не будет принята и не приведёт к ожидаемым результатам, если на практике не примерить, как это работает. В чем выгода для конкретного человека, высококвалифицированного специалиста, уверенного, что он знает, как ему надо делать свое дело. Такое донесение, примерка на реальность и демонстрация конкретной пользы, сложный и тонкий процесс. Поэтому агенту изменений приходится быть ещё немножко психологом и эмпатом.
А сверх того, методолог должен обладать развитыми навыками преподавания, потому что команду и бизнес придётся обучать и методологии, и многим новым для них концепциям. Обучать взрослых состоявшихся людей, находящихся в напряжённом рабочем процессе, и не имеющих возможности от него отрываться. Готовить для них материалы в том объёме и с той фокусировкой, которые позволят развиваться без перегрузки, но с быстрыми результатами.
И это, конечно же, не весь список необходимых компетенций. Но уже понятно, что найти такой редкий вид на рынке труда в эпоху цифровой трансформации очень не просто. И стоить он будет дорого. При этом его все ещё придётся глубоко погружать в контекст конкретной организации, принятых стандартов разработки и качества, сложившиеся особенности корпоративной культуры и т.д.
Поэтому многие крупные компании, особенно имеющие сложный, исторически сложившийся ИТ-ландшафт, предпочитают самостоятельно подготавливать агентов изменений.
В такой подготовке важно иметь определённое понимание, по какому маршруту агент изменений будет вести команду и какие целевые состояния должны быть достигнуты. Это необходимо для единого видения целей развития на системном уровне. Иначе есть риск получить деятельность ради деятельности, без измеримого результата.
Дорожная карта развития команды
Есть несколько направлений развития, по которым должна двигаться команда при переходе к продуктовому подходу: самоорганизация, выстраивание рабочего процесса, управление продуктом, развитие технической зрелости и работа с качеством. Все эти дорожки складываются в дорожную карту.
Пример дорожной карты развития продуктовой команды
Важно, чтобы движение по дорожной карте поддерживалось со стратегическими целями развитием компании. Т.е. дорожная карта на каждом этапе прохождения должна приводить команду к новому состоянию, соответствующему заявленным стандартам организации. В конечном итоге все команды в рамках ИТ-ландшафта должны быть синхронизированы в своём развитии. Иначе различия в их стандартах разработки и организационных процессах будут препятствовать поддержанию целостной бизнес-модели.
Задача агента изменений выстроить маршрут по дорожной карте для конкретной команды таким образом, чтобы с одной стороны темп был комфортным, а с другой – соответствовал целевому видению компании. При этом балансировать прохождение по каждому направлению развития, чтобы в целом получить гармоничный результат.
Ещё немаловажный факт, что агент изменений сопровождает команду лишь в начале маршрута, когда сопротивление к изменениям велико. Когда отсутствие понимания, компетенций и опорных примеров легко может сбить команду с маршрута. И очень важно чтобы в этом сопровождении он оставался не нянькой, а наставником. Готовил зрелую команду, способную самостоятельно продвигаться по выбранному маршруту уже через 3-4 месяца.
Иначе, если такой уникальный специалист будет жёстко привязан к процессам сопровождения длительный период, выйдет слишком дорого и мало эффективно.
Подготовка и дорожной карты развития команд, и агентов изменений связанный и сложный процесс. Он должен основываться на чётком понимании стратегии развития компании в целом, выстраивании экосистемы в рамках ИТ-департамента и сквозном целостном процессе взаимодействия.
И конечно, все это люди, которые важнее процессов и инструментов! Самый ценный и незаменимый ресурс компании, требующий бережного и вдумчивого отношения, больших вложений и постоянного развития.
