Про коучинг, или почему менеджмент не работает

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

Коучинг — это настолько неотъемлемая часть нашего процесса, что мы постоянно забываем, что не в каждой компании или агентстве есть должность командного коуча (team coach).

Несколько лет назад мы в ustwo провели переоценку нашего процесса работы. В результате наших исследований и экспериментов с Agile и Lean мы начали переход от традиционной структуры команды, во главе которой стоит менеджер проекта (project manager), к структуре, основанной на коучинге.

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

Мы вдохновлялись идеями Agile, но это не означает, что мы полностью следуем этой методологии. Коучинг для нас — это больше, чем «управляйте людьми, а не задачами». Наша модель основана на более тонком подходе, сфокусированном на членах команды и их совместной работе.

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

Итак, если вы мало знаете про коучинг (и про то, насколько этот подход улучшает процесс разработки продукта), то вот список вопросов, которые мне часто задают новые клиенты:

Как внедрить коучинг в команду с уже устоявшимися процессами?

Внедрение коуча в команду с уже устоявшимися процессами состоит из двух этапов:

  1. Удостовериться, что все понимают пользу, которую принесёт коуч
  2. Объяснить, какие цели он перед собой ставит

Хотя подозреваю, что этот вопрос можно было бы задать немного иначе: «Как внедрить новые методы работы (в том числе коучинг) в команду с уже устоявшимися процессами?»

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

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

UstwoStudio_01

Как работать с большими командами?

Ключ к работе с большими командами — разделение их на несколько меньших команд, в каждой из которой должно быть не более девяти человек. Цель такой команды состоит в том, чтобы она могла самостоятельно разрабатывать полностью рабочие версии продукта. Её часто называют feature team, то есть команда, отвечающая за определённую задачу (фичу).

На большом проекте (например, 80 человек, разделённых на 10 команд) необходимо обеспечить обмен информацией между командами. Он должен затрагивать все возможные области — дизайн, продукт, разработка, методы работы и так далее.

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

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

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

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

Как не допустить политизации роли коуча?

Важно, чтобы в роли коуча не было никакой политики. Коучи имеют возможность оказывать сильное влияние на компанию, и они должны заботится о её интересах (что, как правило, означает интересы команды). Именно так работают хорошие коучи.

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

Именно по этой причине многие (включая меня) говорят, что коуч не должен быть постоянным сотрудником компании. В этом случае выше шанс того, что он будет постоянно оспаривать текущее положение дел.

UstwoStudio_02

Как вы помогаете членам команды работать вместе?

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

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

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

Эта проблема носит системный характер. И иногда единственный способ её решить — это обратиться к людям, находящимся достаточно высоко в иерархии компании, чтобы иметь влияние на все её подразделения. В некоторых компаниях это CEO, и он должен захотеть изменений.

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

Как вы справляетесь с противоречиями в приоритетах?

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

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

Как вы избегаете конфликтов?

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

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

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

 

Автор: Collin Lyons
Источник и фото: ustwo.com

Перевела Аля Позднякова

Не пропустите свежие статьи о e-commerce

Подпишитесь на рассылку и получайте подборку свежих статей раз в неделю. Без рекламы и спама.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *