Команда будет работать сама: как создать самоорганизующуюся команду разработки

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

Что такое настоящая самоорганизующаяся команда

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

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

- архитектурные и технические стандарты;

- обязательные правила по ревью кода;

- правила по тестированию, включая нагрузочное тестирование;

- правила работы с ошибками и обращениями пользователей и т.д.

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

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

Что команда может делать в рамках самоорганизации

В рамках самоорганизации команда может:

Что команда не должна делать в рамках самоорганизации

Самоорганизующаяся команда не должна:

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

Обеспечить команду четкими описаниями задач с критериями приемки

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

Позитивный сценарий работы с описанием задачи

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

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

Критерии приемки:

- пользователь должен видеть свой город на всех страницах сайта

- пользователь должен иметь возможность выбрать свой город

- пользователь должен иметь возможность поменять свой город

- все товары должны выводится только с доступностью в выбранном городе"

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

Негативный сценарий работы с описанием задачи

Владелец продукта создает задачу со следующим описанием:

"Сделать, чтобы пользователи могли выбирать свой город."

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

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

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

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

Команда рассматривает на встрече User Story, созданную в прошлом пункте и возникает вопрос “Должен ли сохраняться город для пользователя и автоматически выбираться на всех его устройствах?”. Они обсуждают этот вопрос с владельцем продукта и приходят к заключению, что адрес должен сохранятся в профиле пользователя и быть одинаковым везде. После этого они дописывают в задачу новый критерий приемки:

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

Негативный сценарий отсутсвия владельца продукта на встрече

Команда рассматривает на встрече User Story, созданную в прошлом пункте и возникает вопрос “Должен ли сохраняться город для пользователя и автоматически выбираться на всех его устройствах?”. Но владельца продукта в этот раз нет, поэтому команда не может выяснить свой вопрос и дополнить критерии приемки задачи. Поэтому задача остается в бэклоге продукта до выяснения деталей и не может попасть в ближайший спринт.

Четко расставлять приоритеты задач

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

Позитивный сценарий расстановки приоритетов

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

Негативный сценарий расстановки приоритетов

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

Быть доступным в экстренных ситуациях

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

Позитивный сценарий доступности владельца продукта для команды

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

Негативный сценарий доступности владельца продукта для команды

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

Своевременно находить бюджет на блокирующие ресурсы

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

Позитивный сценарий работы владельца продукта с ресурсами для команды

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

Негативный сценарий работы владельца продукта с ресурсами для команды

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

Доверять команде

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

Позитивный сценарий доверия к команде

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

Негативный сценарий недоверия к команде

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

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

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

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

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