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

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

Статья написана на основе моего одноименного доклада, который я читала на конференции Analyst Days 14. Видео также приложила в конце статьи.

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

Думаю, большинство из вас понимают, в чем основные преимущества. Это:

• повышение производительности каждого участника проекта и команды в целом,

• повышение качества проекта в случае достаточной грамотности выполняющего, 

• увеличение мотивации за счет переключения на новые задачи,

• рост в профессиональной сфере,

• укрепление авторитета каждого члена команды, 

• рост компетенции всех сторон,

• подготовка преемников, для них открываются большие карьерные перспективы.

У каждой медали есть оборотная сторона, у этой тоже. Давайте теперь посмотрим возможные минусы:

• производительность падает, когда на объяснение задачи уходит больше времени, чем ожидалось;

• качество снижается, если у выполняющего недостаточно знаний, опыта, компетентности в целом;

• происходит ослабление авторитета и мотивации всех участников проекта, если делегируемая задача воспринимается как неправомерное перекладывание работы.

Поэтому, учитывая этот далеко не полный список рисков, мы с вами поговорим о том, как делегировать, чтобы ловить только плюсы.

Для начала давайте договоримся, что мы понимаем под делегированием. Первое определение, которое гуглится, говорит нам о том, что 

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

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

Ответственность также может передаваться по-разному. Об этом давайте и поговорим на примере RACI-матрицы.

Приоритизацию требований разделим на приоритизацию бизнес-требований и приоритизацию требований реализации. 

Если формально за приоритизацию бизнес-требований отвечает ведущий аналитик, а требований реализации - младший, то здесь никакого делегирования не будет вообще, это просто распределение обязанностей (первая строка с R/A пиктограммами в картинке ниже). Но если формально за приоритизацию всех требований отвечает ведущий аналитик, то выполнение части работы младшим уже будет делегированием.

Для того, чтобы провести эту границу между делегированием и распределением обязанностей, вам нужно знать свою должностную инструкцию и понимать, должны вы выполнять эту задачу или нет. Также важно учитывать, что в делегировании можно передать часть ответственности за исполнение: т.е. младший выполнит, но старший проверит и будет отвечать за результат (втора строка с R/A пиктограммами в картинке ниже). А можно передать ответственность за результат: т.е. младший сам и выполнит, и проверит, и ответит (последняя строка).

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

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

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

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

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

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

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

Например, что вам предложили продумать систему SLA. Разберем ситуацию по матрице Эйзенхауэра:

• Срочное и важное: продумать систему SLA для заключения договора ASAP. Это можно делегировать аналитику, работавшему в поддержке.

• Срочное и неважное: продумать упрощенное представление системы SLA для обсуждения текущих показателей завтра с клиентом. Это можно делегировать аналитику, у которого есть время.

• Важное, но несрочное: продумать систему SLA на поддержку (старт через 3 месяца). Это можно делегировать аналитику, которые еще не делал этого. 

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

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

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

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

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

• персональное лидерство,

• лидерство команды,

• лидерство задачи.

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

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

В случае же лидерства по проекту или по задаче главная ценность – это выполнение задачи в срок и с должным качеством. Здесь не учитываются персональные интересы выполняющего и делегирующего, только команды. Соответственно лидерство по задаче по факту вырождается в менеджмент.

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

Давайте чуть подробнее остановимся на разнице между лидером и менеджером.

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

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

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

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

Соответственно нужно четко понимать, кто вам делегирует задачу: менеджер или лидер, – и из этого понимать критерии успешности и выполненности задачи. 

Что важно! Менеджер формально имеет право распределять вам задачи, а у лидера этого права может не быть, он делегирует по другим причинам.  Особенно опасна ловушка, когда ваш лидер вдруг становится менеджером на проекте, и критерии неожиданно меняются.

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

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

• определить ожидаемые критерии выполненности и успешности по задаче, дать некоторые инструкции, 

• договориться, как будем коммуницировать в процессе выполнения задачи,

• предусмотреть какие-то возможные сложности, проблемы, ловушки,

• предложить оказать поддержку при необходимости,

• обязательный шаг – проверить понимание того, что ожидается;  

• мотивировать и помочь поверить в себя.

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

Таких ключевых пререквизитов два: 

• авторитет лидера,

• автономность выполняющего. 

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

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

Делегирование является одним из самых эффективных стилей менеджмента (находится в правом верхнем квадранте). И нам нужно в зависимости от автономности выполняющего и от авторитета лидера постепенно пробираться и выстраивать путь в правый верхний квадрант. Сделать это сложно, но еще сложнее в этом квадранте оставаться, и мы с вами позднее посмотрим, как это делать.

Как говорил Генри Форд:

"Собраться вместе – это начало, оставаться вместе – это прогресс, а вот работать вместе – это успех”.

Поэтому, как только добрались до квадранта, нужно думать, как остаться и работать вместе.

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

Автономность складывается из двух компонентов:

1. Компетенции выполняющего,

2. Ответственности, или "коммитмента" – того, насколько выполняющий привержен делу и готов ответственно выполнять данную  задачу.

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

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

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

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

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

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

• обсуждение в группе;

• практика;

• обучение других. 

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

Живой пример: в моем списке желаемых задач было разобрать подходы к проведению дискавери, разложить это по полочкам и собрать в некую модель. Задача по матрице Эйзенхауэра важная для меня, но несрочная. Соответственно она была у меня в ToDo-листе, ждала своего часа. Тут приходит ко мне моя коллега и говорит, что хочет выступить с темой – проведение дискавери на Analyst Days. Я в этом вижу прекрасную возможность делегировать свою задачу. Соответственно коллега проделала огромное количество рутинной работы, рассмотрела, какие различные бывают типы дискавери, на что влияют, она реально проверила на разных кейсах, рассмотрела модель. Мы с ней вместе обсудили, поделились опытом. В итоге мы использовали все три самых эффективных типа обучения, и обе чему-то научились.

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

Ицхак Адизес выделяет 4 ключевые характеристики у каждого лидера, которые в нас с вами присутствуют в разном соотношении:

• Предприниматель,

• Производитель,

• Администратор,

• Интегратор.

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

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

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

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

Соответственно, если вы понимаете свой стиль как лидера, то вы прекрасно понимаете, какие задачи у вас будут получаться хорошо, где ваши слабые стороны. Делегируете слабые – скорее всего, результат будет гораздо лучше, чем если бы это вы делали бы сами. 

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

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

Давайте попробуем подвести итог и вспомнить все те модели, о которых мы сегодня говорили, чтобы, когда вы будете делегировать, не забыть о них подумать. Мы с вами будем двигаться по V-модели сверху вниз слева направо.

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

2. Далее пытаемся понять, говорим мы про лидершип или про менеджмент, т.е. мы будем делегировать задачи или распределять. 

3. Потом смотрим на задачи через объекты лидерства, т.е. это персональное лидерство, лидерство команды или менеджмент. 

4. Следующим шагом мы смотрим непосредственно наши человеческие характеристики. Т.е. насколько высокий авторитет у делегирующего, и насколько высока автономность у выполняющего.

5. Также по модели Адизеса пытаемся понять, кто есть Предприниматель, Производитель, Администратор или Координатор, чтобы понять, какие задачи в этих взаимоотношения стоит друг другу делегировать.

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

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

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

А говорили мы с вами сегодня об этом почему? Потому что большинство из нас уже переходит в мир Agile-разработок, и внутри наших Agile-команд мы можем делегировать от каждого члена команды каждому члену команды.  Это позволяет нам постоянно обучаться внутри команды,  делая ее более взаимозаменяемой и универсальной, повышая таким образом ее стабильность. И если мы с вами владеем инструментами делегирования, мы реально можем достаточно долго и мотивироваться и обучаться внутри той среды, где мы с вами находимся.