Записи

Что такое эффективная команда?

Работая в больших компаниях в общей сложности 15 лет, таких, как Сургутнефтегаз, Эр-Телеком, ФГУП «РЧЦ ЦФО», МТС, я постоянно встречался с командами, которых преследует ощущение малой эффективности. Взаимодействуя с лидерами команд и погружаясь в их процесс разработки продуктов, выяснялось, что команды реализовывают много задач, но не понимают, зачем и кто их явный потребитель. Команды угнетало, что, разрабатывая программный продукт в точности с техническим заданием, они получали результат, который не соответствовал ожиданиям руководства.

Погружаясь в процесс разработки, я понимал, что там просто нет команды. На каждый продукт выделялась рабочая группа с участниками. У каждого присутствует понимание, что без него продукт реализовать сложно. Но однако они работали по конвейерному принципу, да еще и над 10-15 продуктами единовременно. Соответсвенно, их подход к продукту был аналогичен принципу миниатюры Аркадия Райкина — «К пуговицам претензии есть?». И да, еще постоянно есть не хватка специалистов, а задач с каждым днем все больше и больше.

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

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

Но на деле, в большинстве случаев, проблему медленной реализации пытаются компенсировать количеством членов команды. Увеличение размера команды ради увеличения эффективности — это одна из основных ловушек процесса разработки. Что еще более удивительно, в эту ловушку попадает сама команда вместе со своим лидером. Когда лидер оказывается под давлением начальства, команда не успевает в срок выполнить задачи, лидер пытается перенести давление обратно на начальство, требует нечто, что потребует участия руководства и дополнительных расходов. Самый простой вариант — попросить нанять еще разработчиков. Звучит логично, но поможет ли это команде? Сделает ли это её более эффективной? Совершенно точно не поможет в краткосрочной перспективе: увеличение размера команды приведет к значительному снижению производительности. В долгосрочной перспективе такое изменение может быть положительным, но только если удастся держать размер в разумных пределах (6-8 человек), разделяя большие команды на маленькие (что требует соответствующего разделения продукта на компоненты).

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

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

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

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

Порекомендовать коллегам:

Что такое Scrum и как он работает

Что такое Scrum и как он работает?

Scrum — это процессный фреймворк. Это значит что он гибкий и у него очень широкая область применения.

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

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

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

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

Скрам выделяет отдельную роль, которая управляет ценностью — Product Owner, или владелец продукта. Именно он определяет, какую ценность мы создадим в текущем спринте, а какую отложим на следующий. Таким образом владелец продукта отвечает за максимизацию ценности для заказчика. “Что мы можем сделать в следующем спринте, чтобы это было максимально ценно/полезно?” Над этим вопросом владелец продукта должен думать каждый день, готовясь к следующему спринту.

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

Структура спринта

Скрам четко определяет структуру спринта. Спринт начинается с планирования спринта и заканчивается обзором спринта и ретроспективой. В середине спринта скрам регламентирует лишь ежедневные 15 минутные встречи. scrum-events

Планирование спринта

Цель встречи — определить цель спринта и составить Sprint Backlog (спринт беклог). Обязательно присутствие всей скрам команды и владельца продукта. Владелец продукта рассказывает команде о цели спринта, отвечает на вопросы команды. Команда обсуждает реализацию, выясняет важные детали у владельца продукта, составляет перечень задач, выполнив которые команда достигнет поставленной цели. В конце встречи все одинаково понимают цель спринта, и в команде сформировано общее понимание как и что нужно сделать для достижения поставленной цели. Рекомендуемая длительность встречи — не более 4 часов для 2-х недельного спринта.

Ежедневный скрам митинг

Ежедневные встречи — это способ координировать усилия членов скрам команды, оперативно выявлять проблемы, создавать прозрачность текущей ситуации. Команда собирается у доски задач, и каждый участник скрам команды по очереди отвечает на 3 вопроса: Что я сделал вчера? Что сделаю сегодня? Что меня тормозит и мешает двигаться вперёд? Время жестко ограничено — не более 15 минут, поэтому на этой встрече команда только выявляет проблемы. Поиск решения выносится за рамки этой встречи.
daily-scrum-meeting

Обзор спринта

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

Ретроспектива спринта

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

Целостность скрам

Скрам — это идеально сбалансированный инструмент. В нем нет ничего лишнего, и каждый элемент имеет свою ценность и предназначение. Именно целостное применение скрама даёт максимальный синергетический эффект. Если убрать какой либо элемент — баланс нарушится, что негативно скажется на результатах.
Однако на практике приходится встречаться с искалеченным скрамом, когда некоторые элементы не используются. Такой искалеченный скрам даже получил собственное наименование — ScrumBut, или по русски СкрамНо.
Почему же так происходит? Казалось бы, всё очень просто, бери и делай. Да, берут, делают, но потом какие то элементы отменяют, так как они не приносят пользы. Люди всегда стремятся избавляться от того, что не приносит ценности, и это проявление мудрости. Проблема не в том, что элемент плохой. Проблема в том, что он используется неправильно. И даже эта проблема предусмотрена в скрам.

Скрам-мастер

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

Обучение скрам мастеров

На основе многолетнего опыта работы со скрам командами мы разработали тренинг Advanced Scrum Master. Посещение этого тренинга — это низкий старт для начинающего скрам мастера, и прокачка навыков для практикующего.

Если вы в поисках программы обучения Agile и Scrum для более широкого круга сотрудников, то вам идеально подойдет наш основной курс — Certified Agile Professional. Типичный состав участников этого тренинга: директора, HR, менеджеры проектов, руководители подразделений.

Порекомендовать коллегам: