Как применять Agile-коучинг не в IT-процессах

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

Как появился agile-подход и что это такое?

Зачастую разработчикам ПО приходится не легко, особенно если продукт не стандартный. Это означает, что требования к разработке могут меняться в течение всего процесса создания продукта. И если их не учитывать, то на выходе может получиться вовсе не тот результат, который понравится Заказчику.
Ещё несколько лет назад срок разработки программного продукта мог составлять 3 года, в то время как сейчас – 3 месяца! Задача современного бизнеса – реализовывать проекты быстро и качественно! Как же этого добиться? Командам разработчиков пришлось пересмотреть подходы, в которых они работали. Дело в том, что разработка раньше велась определёнными этапами по принципу каскадной реализации проекта. Пока не завершался один этап невозможно было перейти к следующему.
Не было возможности постоянно тестировать и улучшать продукт уже в процессе разработки проекта, т.к. всё упиралось в исходное ТЗ. Такой подход являлся совсем не гибким и был сопряжён с бюрократией и множеством разрабатываемой документации, которая зачастую становилась неактуальной к моменту окончания проекта. Именно поэтому взамен классическим были придуманы гибкие подходы в ведении проекта, не требующие длительных согласований по поводу малейших изменений в проекте.
Так появилось понятие, agile – как философия, объединившая в себе принципы всех гибких методологий по разработке программного обеспечения (ПО). К ним относится Scrum, Kanban и др.
В 2001 году, благодаря команде разработчиков, которые поняли, что жить и творить, как раньше, становится неэффективно, появился на свет Agile-манифест, содержащий в себе основные принципы работы в Agile-подходе.
Ключевыми из них стали:
1. Люди и их взаимодействие важнее, чем технологии. Причём самый эффективный метод взаимодействия и обмена информацией – это личная беседа.
2. Готовый продукт важнее, чем прописанная документация по нему. Важно поставлять Заказчику полностью рабочее программное обеспечение каждые несколько недель
3. Постоянный диалог с Заказчиком в процессе разработки продукта важнее жёстких ограничений, прописанных в контракте
4. Чуткая реакция на изменения важнее, чем следование исходному плану действий

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

Ни к этому ли стремится любая команда, работающая над проектом?
Спасибо, дорогие «айтишники», теперь мы можем смело перенимать ваш опыт!

Давайте посмотрим, как выглядит на практике такой подход? И причём здесь коучинг?

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

Пример 1.

Представьте себе утро рабочего дня, которое ежедневно начинается с 15-ти минутной Daily stand-up сессии. Это такое мини-собрание всех участников команды, на котором все стоят. Да, неудобно. Зато снижается риск затянуть мероприятие Поэтому обсуждается только самое важное, что будет двигать процесс реализации проекта вперёд.
А именно — каждый участник команды отвечает друг другу на 3 вопроса:
1. Что я делал по проекту
2. Что я планирую сделать
3. Что мне мешает продвигаться вперёд?
Такое короткое собрание помогает обнаружить запараллеливание процессов, понять стадию реализации проекта, сложности, которые нужно решить, а также повысить ответственность каждого сотрудника перед другими участниками команды.
Важно, что решение озвученных проблемных моментов будет происходить уже позже, не на самой stand-up сессии.
Цель такой встречи – удерживать фокус на текущем этапе и в то же время смотреть в перспективу. То есть увидеть, как то, что команда делает сейчас, влияет на реализацию проекта в будущем, и при необходимости вовремя скорректировать план действий.

Пример 2.

Чтобы визуализировать процесс исполняемых задач, можно использовать такой инструмент, как Kanban-доска.
Она может быть, как в виде реальной доски со стикерами, на которых написаны задачи, либо в виртуальном виде, в случае, если команда работает удалённо.
В случае, если это физическая доска задач, сотрудники пишут свои задачи на стикерах и расклеивают их в соответствующие столбцы, в зависимости от стадии выполнения задачи. Таким образом, вырисовывается общая картина работы над проектом в текущий период, а также возникает понимание, на каких этапах проекта наблюдаются «узкие места», где, к примеру, возникает наибольшее скопление задач.
В самом простом виде стадии проекта могут обозначаться как:
1. Нужно сделать
2. В процессе
3. Сделано
Можно также немного разбить процессы на составные части, тогда доска задач может выглядеть таким образом:

ЗАДАЧИ 2

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

МАТРИЦА проектаВ процессе утренней Daily stand-up сессии сотрудники, рассказывая о проделанной и предстоящей работе, переклеивают стикеры из одного этапа в другой и могут отчётливее видеть те моменты, которые затрудняют их работу. На основании такого наглядного анализа могут вырисовываться «срочные задачи», которые тормозят проект в целом. Такие задачи выносятся в отдельную графу на доске визуализации.
Эта активность позволяет понять, успевает ли данный проект быть реализованным в заданные сроки или нужны дополнительные ресурсы, в том числе временные. В этом случае, можно заранее предупредить заказчика о предстоящей корректировке сроков, а не сообщать об этом в последний момент.

Пример 3.

Матрица приоритезации требований заказчиков

Матрица преоритезации

Как говорилось ранее, для проектной команды очень важно поддерживать постоянный контакт с заказчиком. Заказчики, в свою очередь могут довольно активно предлагать множество идей для реализации, не все из которых целесообразны или могут быть тут же реализованы. Кроме того, для реализации каких-то идей могут потребоваться дополнительные расходы.
Поэтому необходимо совместно с заказчиком прояснять ценность каждой задачи для его бизнеса.
Работа с ценностями и приоритетами– это тоже коучинговый подход, который может быть легко осуществим с помощью специальной матрицы приоритетов требований заказчиков. Задачи раскидываются по всем квадрантам матрицы в зависимости от их ценности для заказчика и предполагаемых затрат. После чего происходит анализ того, какие задачи мы оставляем в работу (это задачи, попавшие в квадрант высокой ценности при минимальных затратах), а над какими — необходимо подумать относительно повышения ценности или сокращения требуемых ресурсов.

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

Что хотят наши заказчики? Качественной и своевременной реализации проекта, а также внимания к своим пожеланиям.
Что хотят руководители проектных команд? Чтобы все участники команды помимо профессионализма имели высокую степень ответственности за результат и были вовлечены в процесс реализации проекта. Это в конечном счёте, приведёт к слаженной работе и созданию продукта, способного удовлетворить пожелания заказчика, а возможно, и превзойти их.
Agile-подход позволяет нам добиться и первого, и второго.
Однако, важно понимать, что в этом случае Agile становится вашим стилем управления и коммуникации. И точно так же, как в традиционных стилях управления существуют свои положительные стороны и риски, управление в стиле agile имеет свои «узкие места».
Когда мы говорим про управление в стиле коучинг, то подразумеваем, что команда, с которой мы имеем дело, достаточно зрелая. Это творческие люди, у которых изначально есть интерес к делу, желание реализовываться, определённое чувство ответственности и вовлечённости. Мы говорим о том, что коучинг – это всегда работа с осознанностью и со 100% чувством ответственности. И если эти качества ваших сотрудников пока ещё не находятся на нужном уровне, то вам будет довольно сложно применять Agile-коучинг в чистом виде. Поэтому вы можете использовать смешанные стили управления, постепенно «выращивая» свою команду до уровня, на котором вы без риска сможете использовать Agile-подход в управлении.
И это несомненно приведёт вас и вашу команду к новым вершинам! А ваши довольные и благодарные клиенты никогда не захотят променять вас ни на кого другого!

Екатерина Кудрявцева, бизнес-тренер, коуч