Эффективная команда – самоорганизованная команда

Продолжаем публикацию докладов с онлайн-конференции «Продуктивная команда без кнута и седативных». Сегодня представляем расшифровку выступления Антона Костерина «Эффективная команда — самоорганизованная команда».

На команду можно смотреть как на аналог вещества, у которого есть агрегатное состояние. Немного экскурса обратно в школьную программу.

Какое отношение агрегатное состояние имеет к работе команды?

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

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

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

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

Другой крайностью является состояние твёрдого тела или кристаллической решётки.

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

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

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

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

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

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

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

Есть такое состояние — аморфное тело.

Самым известным примером является стекло. Оно, с одной стороны, твёрдое: если мы возьмём кусок стекла и бросим его, то все его составляющие полетят в одну сторону, оно не разбрызгается. Если мы оставим стекло без какого-либо перемещения на достаточно долгое время, то через 20−30 лет мы увидим, что стеклянная фигура поплыла, как жидкость, только с очень медленной скоростью движения.

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

А пока вернёмся к химическому составу команды. Из кого обычно состоит команда ИТ-проекта?

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

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

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

И, естественно, менеджер: продуктовый, проектный или какой-то другой, в зависимости от используемой методологии.

Также могут быть дополнительные участники. Например, аналитик или скрам-мастер.

Многие сталкивались с ситуацией, когда при запуске небольшого стартапа, экономя на всём, команда может состоять всего из нескольких человек (или даже из одного). И возникает вопрос, нужен ли в такой ситуации менеджер.

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

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

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

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

В реальности эти два подхода часто смешиваются. В больших командах выделяются дополнительные роли, появляются подкоманды (команды разработки, тестирования). Если выстраивать абсолютно одноранговую систему, в которой менеджер управляет всеми коммуникациями, то он сойдёт с ума, так как для группы из 16 человек получается 120 связей. В такой системе менеджер должен находиться на встречах с 8 утра до 12 ночи.

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

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

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

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

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

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

И у нас есть конечная цель — создать такую команду.

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

Рассмотрим эти шаги повнимательнее.


Цель

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

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

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

Цель должна приносить ценность потребителю. Например, «создать самое удобное мобильное приложение для платежей и переводов для физических лиц в РФ».

Роли

Роли должны быть определены (например, в перечне ролей).

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

Можно также разбить роли на уровни и грейды: junior, middle, senior. Так, для части проектов недостаточно будет скиллов начинающего или среднего разработчика, а для части процессов скиллы опытного разработчика будут избыточными.

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

Процессы

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

Необходимо определить критичность процессов и найти те самые 20% процессов, которые составляют 80% пользы для проекта.

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

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

Принципы

Все ситуации рассмотреть нельзя, необходимо делегировать принятие решений (особенно если команда разрослась до 30−50 человек). Поэтому нужно вырабатывать правила для принятия решений, когда нет инструкций. Таким образом, вы даёте право своей команде принимать правильные решения без вашего участия.

Принципы должны постоянно обновляться. Достаточно хорошо про принципы в своей книге рассказал Рэй Далио.

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

Метрики

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

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

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

Безопасность

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

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

Автор: Антон Костерин, руководитель отдела веб-технологий

Расшифровку подготовила: Мария Родина, Консультант проектов в М. Видео-Эльдорадо