Наша рассылка
Заказать звонок
8 (495) 774-25-93
Главная   →   Блог
КАК ПРИМЕНЯТЬ AGILE-КОУЧИНГ НЕ В IT-ПРОЦЕССАХ
Кудрявцева Екатерина    2016-07-16

Будучи гуманитарием до мозга костей, могла ли я когда-нибудь подумать, что всерьёз заинтересуюсь изучением практических наработок из IT-области?

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

Задать вопрос


Время прочтения: 15 минут

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

И, несмотря на то, что agile-подход зародился и активно используется в IT-индустрии, его принципы могут быть отлично встроены в работу любых проектных команд, которые трудятся над решением новых, не типовых задач. Но обо всём по порядку.

 

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

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

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

Так появилось понятие, agile, – как философия, объединившая в себе принципы всех гибких методологий по разработке ПО. К ним относится  Scrum, Kanban и др.

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

Ключевыми из них стали:

  1. Люди и их взаимодействие важнее, чем технологии. Причём самый эффективный метод взаимодействия и обмена информацией – это личная беседа;
  2. Готовый продукт важнее, чем прописанная документация по нему. Важно поставлять Заказчику полностью рабочее программное обеспечение каждые несколько недель;
  3. Постоянный диалог с Заказчиком в процессе разработки продукта важнее жёстких ограничений, прописанных в контракте;
  4. Быстрая реакция на изменения важнее, чем следование исходному плану действий

 

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

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

 

Ни к этому ли стремится любая команда, работающая над проектом?

Спасибо, дорогие «айтишники», теперь мы можем смело перенимать ваш опыт!

 

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

 

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

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

 

Пример 1.

Представьте себе утро рабочего дня, которое ежедневно начинается с 15-ти минутной Dailystand-up сессии. Это такое мини-собрание всех участников команды,  имеющее ряд характерных особенностей.

Во-первых, оно построено по определённому алгоритму, который сводится к тому, что каждый участник команды отвечает  по кругу на 3 вопроса:

  1.  Что я делал по проекту?
  2.  Что я планирую сделать?
  3.  Что мне мешает продвигаться вперёд?

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

 

 Во-вторых, встречу проводит один из членов команды, который наравне с остальными сотрудниками работает над реализацией проекта и не является руководителем данного коллектива. Его задача состоит в том, чтобы помочь команде стать самоорганизующейся, принимать самостоятельные решения и выполнять их. Также он должен вовремя выявлять проблемы и способствовать их решению (в этом ему помогает ответ коллег на вопрос: «Что мне мешает продвигаться вперёд?»)

Поскольку ведущий собрания не наделён функцией руководителя, то он не имеет права раздавать задачи другим сотрудникам, а это значит, что они сами выбирают себе задачи к исполнению, отвечая на вопрос: «Что я  планирую сделать?»

 

И, наконец, ещё одной интересной особенностью данного формата собрания является то, что оно проводится стоя

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

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

Важно, что решение озвученных проблемных моментов будет происходить уже позже, не на самой stand-up сессии.

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

 

Пример 2.

Чтобы визуализировать процесс исполняемых задач, можно использовать такой инструмент, какKanban-доска.

Она может быть как в виде реальной доски со стикерами, на которых написаны задачи, так и и в виртуальном виде, в случае, если команда работает удалённо.

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

В самом простом виде стадии проекта могут обозначаться как:

  1. Нужно сделать
  2. В процессе
  3. Сделано

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

 

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

В процессе утренней Dailystand-up сессии сотрудники, рассказывая о проделанной и предстоящей работе, переклеивают стикеры из одного этапа в другой и, тем самым, могут отчётливее видеть те моменты, которые затрудняют их работу. На основании такого наглядного анализа могут вырисовываться «срочные задачи», которые тормозят проект в целом. Такие задачи выносятся в отдельную графу на доске визуализации.

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

Пример 3.

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

 

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

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

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

 

Что хотят наши заказчики? Качественной и своевременной реализации проекта, а также внимания к своим пожеланиям.

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

Agile-подход позволяет нам добиться и первого, и второго.

Однако, важно понимать, что в этом случае Agile становится вашим стилем управления и коммуникации. И точно так же, как и в традиционных стилях управления,  в нем существуют свои положительные стороны и риски, оно имеет свои «узкие места».

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

Это несомненно приведёт вас и вашу команду к новым вершинам! А ваши довольные и благодарные клиенты будут ценить вас ещё больше.



другие публикации этого автора
ПРОГРАММЫ
Продажи и сервис
Персональная эффективность
Эффективная команда
Менеджмент и лидерство
Тренерское мастерство
УСЛУГИ
Консалтинг
Обучение
Оценка
НАШ ПОДХОД
Диагностика
Разработка
Проведение
Поддержка
КОНТАКТЫ
8 (495) 774-25-93
Заказать звонок

115035, г. Москва, Садовническая ул., д.54, стр.2, 4 этаж (ст. м. Новокузнецкая)
info@pz-tr.ru
2013 - 2017, PUZZLE-Training, Москва