Agile менеджер против классического PM? Часть 3: Технологии.

Это третья и моя любимая часть серии статей со сравнительным анализом классического PM и Agile менеджера. Напомню, что в первой части мы рассмотрели базовые определения и обязанности, которые лежат в основе работы классического PM. Во второй части речь шла об управлении объемом работ (scope management). Пришло время коснуться технологического вопроса.

Большая часть классического менеджмента со всеми практиками и подходами строится на Теории X, утрированная версия которой гласит, что люди по умолчанию не любят работать, очень неорганизованы и не стремятся делать свою работу хорошо и вовлекаться в процесс достижения конечной ценности. Отсюда берется необходимость в отчетности, координации, мотивации, контроле, командовании и прочих “ценностях” классического менеджмента. При чем тут технологии? Да при том, что на них просто не остается времени. Нужно столько всего другого “полезного” знать и уметь, что не до технологий.

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

Какие категории менеджеров меня больше всего печалят:

  • Менеджер всего и вся. Это человек, который глубоко убежден, что совершенно неважно в какой области будет проект и каков его контекст как по бизнес домену, так и по технологическому стеку. В некоторых случаях даже есть уверенность, что проекты могут быть даже не из IT. Такой менеджер видит свою роль в обеспечении координации, контроля и раздачи работы сотрудникам, а детальное понимание чем они занимаются не является обязательным.
  • Менеджер от безысходности. Обычно такой менеджер раньше был разработчиком, тестировщиком, аналитиком или еще кем-то, кто делает реальную работу. Но вот он вырос до того уровня, где компания не может удовлетворять его финансовые запросы в рамках текущей рабочей “лычки”. И ему предлагают “вырасти” в менеджера. И не важно, может ли он и есть ли у него к этому талант. Хочешь расти – становись менеджером. И человек начинает деградировать в своей предыдущей области компетенции, вспоминая о ней только на собеседованиях.

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

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

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

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

Обсуждение (1)

Японский пример улыбнул. Имею опыт работы на японских проектах. Соглашусь с тем, что нужно идти “в поле” и косить траву вместе с заказчиком. Для того чтоб понять его Value/Goals.
Но хотел бы отметить одну специфику IMHO:
Asian (чтоб не писать японский опыт) и North American ( ну вы поняли) опыт.

1. Доверие. У Asian заказчика доверие необходимо заслужить на протяжении долгого времени, показывая результат. Это делается не одним проектом. На North American проектах у вас есть большой уровень доверия заказчика в самом начале, который можно растерять по прошествии проекта своей неудовлетворительной работой.

2. Детали. Asian заказчики тратят очень много внимания и времени на детали которые не несут существенных Goals и тем самым тратят время команды. North American, напротив, не очень щепетильны в ключевых деталях – они полностью полагаются на ваш опыт и ожидают, что вы сами для них выявите контекст и проблемные сущности.

Leave a Reply

Your email address will not be published. Required fields are marked *