Это третья и моя любимая часть серии статей со сравнительным анализом классического PM и Agile менеджера. Напомню, что в первой части мы рассмотрели базовые определения и обязанности, которые лежат в основе работы классического PM. Во второй части речь шла об управлении объемом работ (scope management). Пришло время коснуться технологического вопроса.
Большая часть классического менеджмента со всеми практиками и подходами строится на Теории X, утрированная версия которой гласит, что люди по умолчанию не любят работать, очень неорганизованы и не стремятся делать свою работу хорошо и вовлекаться в процесс достижения конечной ценности. Отсюда берется необходимость в отчетности, координации, мотивации, контроле, командовании и прочих “ценностях” классического менеджмента. При чем тут технологии? Да при том, что на них просто не остается времени. Нужно столько всего другого “полезного” знать и уметь, что не до технологий.
В добавок к этому, я неоднократно слышал мнение от менеджеров о том, что для беспристрастного управления проектом менеджеру лучше не быть слишком техническим. Мол, техническое мышление зачастую мешает менеджеру эффективно работать над другими активностями. И это меня всегда удивляло. Ведь контекст любого управления очень и очень важен. И тут нельзя ограничиться просто пониманием наподобие “там есть у нас разработчики, они пишут код на каких-то технологиях”. Я уже молчу про лидерство, которого очень тяжело добиться, если ты “чужой на этом празднике жизни”. Но об этом будет отдельная статья.
Какие категории менеджеров меня больше всего печалят:
Agile подходы в основном построены на концепциях Теории Y, которая гласит, что люди изначально видят в работе средство для самореализации, способны быть вовлеченными и мотивированными, если будут чувствовать себя частью чего-то большего и видеть пользу от своей работы. В таких реалиях работа менеджера заключается в том, чтобы всячески помогать сотрудникам проявить свои таланты и навыки, поддержать их в этом, помочь развиваться и настраиваться на постоянный процесс улучшения.
Чтобы выполнять данные функции, нужно достаточно неплохо разбираться в том, что делает человек на рабочем месте в своей роли. В японской управленческой практике кайдзен ведется речь о гэмба, как о месте и окружении, где реально делается работа. Для любого действия менеджера нужно идти в гэмба и разбираться что там происходит. А для этого нужно достаточно глубоко понимать принципы работы гэмба в каждом конкретном проекте, что неминуемо приводит менеджера к технологиям, инженерным практикам и подходам.
Вдобавок, стоит отметить, что классические управленческие практики перекладываются на саму команду. А это значит, что она сама отвечает за принятие всех решений. Поэтому у менеджера высвобождается время от многих классических активностей. Задача менеджера тогда заключается в том, чтобы помогать команде принимать правильные решения, приносить свой многолетний опыт и знания, играть роль ментора, коуча и консультанта. А это невозможно без детального понимания технологической составляющей процесса разработки.
Поэтому Agile менеджеру просто необходимо владеть технологическими навыками, постоянно их совершенствовать, следить за современными тенденциями, пробовать на практике, участвовать в жизни команды разработки и ее решениях. Любые Agile методологии и фреймворки дают общие инструменты и практики, задача Agile менеджера уметь их адаптировать вместе с командой под конкретный бизнес домен и технологический процесс, налаживая подходы постоянного анализа и улучшения.
Японский пример улыбнул. Имею опыт работы на японских проектах. Соглашусь с тем, что нужно идти “в поле” и косить траву вместе с заказчиком. Для того чтоб понять его Value/Goals.
Но хотел бы отметить одну специфику IMHO:
Asian (чтоб не писать японский опыт) и North American ( ну вы поняли) опыт.
1. Доверие. У Asian заказчика доверие необходимо заслужить на протяжении долгого времени, показывая результат. Это делается не одним проектом. На North American проектах у вас есть большой уровень доверия заказчика в самом начале, который можно растерять по прошествии проекта своей неудовлетворительной работой.
2. Детали. Asian заказчики тратят очень много внимания и времени на детали которые не несут существенных Goals и тем самым тратят время команды. North American, напротив, не очень щепетильны в ключевых деталях – они полностью полагаются на ваш опыт и ожидают, что вы сами для них выявите контекст и проблемные сущности.