Pull to refresh

PAEI-стили менеджмента Адизеса и роли Scrum

Reading time4 min
Views34K
По мнению экспертов, успешность проекта во многом зависит от личных качеств лидеров и «укомплектованности» менеджмента этими качествами. К сожалению, не всегда эти качества учитываются при формировании менеджмента. Это создает риски и часто приводит к провалу. В данной статье рассматривается типология менеджеров по Адизесу и соответствие этих типов различным ролям в Scrum.

Классификация Адизеса


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

  • Producing results (P) — производство результатов, собственно, ради которых организация и существует (короткосрочная перспектива);

  • Administering (A) — администрирование, необходимое для обеспечения эффективности (короткосрочная перспектива);

  • Entrepreneuring (E) — предпринимательство, служащее для управления изменениями (долгосрочная перспектива);

  • Integrating (I) — интеграция, необходимая для обеспечения жизнеспособности организации в долгосрочной перспективе за счет объединения ее элементов (долгосрочная перспектива).

По мнению эксперта, нет руководителей, у которых все эти функции одновременно были очень сильно развиты (PAEI). Обычно у успешных руководителей часть функций развиты хорошо, а часть отлично (PaEi, Paei, paEi и тд). При этом, для успешного существования организации необходимо, чтобы в совокупности в менеджменте были представлены все эти функции на отличном уровне. Более того, надо чтобы имеющиеся у каждого руководителя характеристики соответствовали его деятельности. Так, главе производственного отдела необходимо быть как минимум Paei, а HR-у отвечающему за корпоративную культуру и атмосферу — paeI.

Бывает такое, что у руководителя напрочь отсутствуют 3 (P---, -A--, --E-, ---I) или все 4 (----) функции. По мнению Адизеса, это очень опасно для проекта и предприятия. Так, ---I обычно означает интриги и разложение коллектива, вместо интеграции в случае paeI. Разумеется, такой коллектив не может нормально работать, образуется текучка и обычно из самых квалифицированных кадров. С другой стороны, P--- — это менеджер, который делает всю работу сам, не доверяя ее членам команды. Это приводит к завалам и простоям в короткой перспективе и создает большие риски для будущего проекта.

Классификация Адизеса и роли в Scrum


Scrum не подразумевает менеджера в классическом его понимании. Его роли размыты между Product Owner (PO), Scrum Master (SM) и командой (DT от Development Team). Тем не менее, это не означает что менеджмента нет и не должны учитываться PAEI в назначении на роль. Поэтому, попробуем разложить по этим функциям.

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

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

Задача SM следить за соблюдением Scrum процессов. Даже их эволюция должна идти в соответствии с этими процессами. Так же ему необходимо обеспечивать команду всем необходимым, решать или эскалировать возникающие проблемы. Поэтому ему необходимо быть A. Более того, он должен поддерживать атмосферу в команде, способствовать взаимопониманию между членами команды, а также с внешними для команды людьми, способствовать росту командного духа, сплоченности. Это все I. Таким образом, pAeI.

Обычно команда ориентирована на краткосрочную перспективу длиной в спринт или 2-3. Их цель — произвести за спринт все, что обещали. Т.е. Paei. Это в принципе минимальное требование для команды. Однако, если они не будут думать об архитектуре, производить рефакторинг, внедрять какие-либо лучшие практики, то в какой-то момент система станет просто невозможной для поддержки и расширения. Поэтому, команде необходимы долгосрочное видение, анализ и внедрение лучших практик и тд, что соответствует E.

Также, команда занимается планированием и контролем, соблюдением каких-либо принятых норм, процессов и практик (code style, coverage при code review и тд), что является административной функцией — А. Таким образом, команде хорошо бы быть PAEi. Благо, что она команда и в ней могут найтись люди способствующие продуктивности, долгосрочному взгляду и администрированию.

Хотелось бы обратить внимание на тот факт, что Адизес рекомендует, чтобы в управлении командой/предприятием было два человека с PaEi и pAeI и лучше, если PaEi «выше» pAeI. Это как раз соответствует функциям Product Owner-а и Scrum Master-а, лишь только в Scrum PO не является руководителем SM и команды, а лишь исполняет свои функции.

Пример


Автору знаком случай, когда Product Owner был ---I, а Scrum Master — PaEi. Т.е. у них были сильно/слабо развиты эти функции как у личностей, хотя роли требовали иного набора. Это привело к интригам со сторон PO, конфликтам, падению результативности и увольнениям членов команды.

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

Заключение


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

Литература


  1. Идеальный руководитель. Почему им нельзя стать и что из этого следует, Адизес Ицхак Калдерон, 2013.
  2. Scrum Guide, Кен Швабер и Джефф Сазерленд, 2013.
  3. Scrum Body of Knowledge, Scrum Institute, 2016.
Only registered users can participate in poll. Log in, please.
О чем нужна следующая статья?
50% Опыт пострения архитектуры в условиях Scrum7
7.14% Опыт формирование нефункциональных требований в условиях Scrum1
0% Stakeholder Management0
42.86% Риск Менеджмент в условиях Scrum6
14 users voted. 6 users abstained.
Tags:
Hubs:
Total votes 22: ↑19 and ↓3+16
Comments2

Articles