OKR для Agile-команд

Примечание Перевод статьи Felipe Castro OKR for Agile Teams выполнен с разрешения автора.

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

Фактически в Agile нет ни одного мероприятия для отслеживания результатов.

Многие Agile-команды застревают в мировоззрении «сделай и забудь»: реализовали фичу — можно больше о ней не вспоминать!

Даже в Agile-манифест понятия ценное ПО и работающий продукт означают одно и то же:

Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения (первый принцип).

Работающий продукт — основной показатель прогресса (седьмой принцип).

Agile-манифест разработки программного обеспечения

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

Много написано о том, что нужно фокусироваться на «создании правильного продукта», а не «создании продукта правильно», но, как сказал Марти Каган в предисловии к Radical Focus: «Сегодня команды слишком часто становятся фабриками фич, не сильно заботясь о том, решают ли поставляемые фичи исходную бизнес-задачу».

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

Пользовательские истории — это просто эксперименты и рассматривать их следует именно в этом ключе.

OKR в помощь

При правильном использовании OKR (прим. ред. — Objectives and Key Results, цели и ключевые результаты) способен дополнить Agile и способствовать его развитию. Но что значит «правильно использовать» OKR?

Использовать OKR правильно — значит отслеживать реальную ценность, а не проектные поставки. Как Кристина писала в твиттере:

Успех — это не расстановка галочек.

Успех — это реальные изменения.

Если вы сделали все задачи, но это не привело к улучшениям — это не успех.

Кристина Водтке

Цитируя Beginner’s Guide to OKR:

Существует два основных типа Ключевых Результатов:

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

Ключевые Результаты, основанные на Ценности: Измеряйте реальные результаты и поставку ценности (или ее компонентов) для организации. Ключевые Результаты, основанные на Ценности, являются мерой успешности проведенных активностей.

OKR для начинающих

Примерами Ключевых Результатов Вехи являются:

Релиз бета-версии продукта.
Запуск вкладки монетизации.
Создание новой тренинговой программы.
Разработка новой кампании по лидогенерации.

Ключевые Результаты Вехи обычно начинаются со слов: запуск, создание, разработка, поставка, сборка, внедрение, определение, релиз, тестирование, подготовка или планирование.

Ключевые Результаты (согласно приведенному выше примеру OKR из Guide) основываются на ценности:

Увеличить число еженедельных посещений активными пользователями в среднем до 3.3.
Увеличить неоплачиваемый (естественный) трафик до 80%.
Достигнуть значения NPS (Net Promoter Score, индекс потребительской лояльности) в 52%.
Снизить отток доходов до 1%.
Увеличить вовлеченность (пользователи, заполняющие полностью профиль) до 75%.

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

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

Увеличить/Снизить значение метрики ABC с X до Y

Оперируя Ключевыми Результатами Вехи, вы используете OKR в качестве инструмента управления проектами и потому не в полной мере раскрываете весь его потенциал.

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

1) Мы хотим построить культуру, ориентированную на результат, а не на задачи

2) Если вы сделали все свои задачи, но это не привело к улучшениям — это не успех

3) Ваш план действий (или бэклог продукта) — это всего лишь набор гипотез

1) Мы хотим построить культуру, ориентированную на результат, а не на задачи

2) Если вы сделали все свои задачи, но это не привело к улучшениям — это не успех

3) Ваш план действий (или бэклог продукта) — это всего лишь набор гипотез

От гибкого управления проектами к целевой гибкости

OKR способен дополнить Agile и Lean по 5 направлениям:

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

Переход от фич к ценности

Каган пишет о преодолении мышления «фабрики фич»:

При правильном использовании [OKR] помогает переосмыслить ситуацию от ориентированной на выход (фичи на дорожной карте) в ориентированную на результат (для бизнеса)

Марти Каган

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

Мне посчастливилось наблюдать такой переход в Localweb, компании, являющейся лидером на рынке услуг профессионального хостинга в Бразилии. По завершении пробного периода 9 продуктовых команд Localweb в начале 2016 года ушли от использования дорожных карт и сейчас полностью сфокусированы на поставках по методу OKR.

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

Обеспечение автономности и самоорганизации команд

Использование OKR в качестве альтернативы дорожным картам способствует тому, что команды становятся более автономными, поскольку изменяет ожидания от команд. Роль команды меняется:

От: «реализовать фичи, которые нужны стейкхолдерам»;

К: «достигнуть OKR, согласованных с заинтересованными лицами».

Одиннадцатый принцип Agile-манифеста гласит:

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

Agile-манифест разработки программного обеспечения

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

Внедрение мероприятий, опирающихся на ценности

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

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

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

Команды, работающие по Scrum, должны стремиться ставить Цели Спринта в соответствии с командными OKR. Один из возможных вариантов — использовать адаптированную модель разработки через гипотезы:

Мы полагаем, что реализация <этой возможности>
Будет способствовать достижению <этой Цели>

Мы поймём, что достигли успеха, когда увидим положительные изменения по <этим Ключевым Результатам>

Стендапы. Стендапы должны начинаться с обсуждения прогресса по OKR. Это нужно, чтобы команда осознавала достигнутые результаты. Эта ежедневная активность должна быть очень короткой, и чем чаще вы проводите такие обсуждения, тем меньше времени они будут занимать. Это особенно важно, если вы делаете поставки непрерывно и не пакетами (или группой команд), поскольку циклы измерения в этом случае должны быть короче.
Обзоры. По модели Radical Focus на демонстрацию могут быть приглашены другие команды, включая маркетологов и специалистов по продажам (“Friday wins”). И, опять же, вам нет необходимости проводить «OKR-демонстрацию» и Обзор.

Ведутся активные споры, когда проводить отслеживание прогресса по OKR: во время Планирования или Обзора («Monday Commitments» в Radical Focus). Модель все еще развивается.

Просто не забывайте, что требуется несколько дней, чтобы реализованная пользовательская история оказала влияние на OKR. Если вы будете проверять OKR во время Обзора, то вам нужно будет продемонстрировать пользовательские истории, реализованные в последней итерации, а также проверить результаты по историям, которые были реализованы ранее.

Ретроспективы. Необходимо включать в ретроспективы обсуждения, как улучшить процесс постановки и измерения OKR: Используем ли мы правильные метрики/Ключевые Результаты? Не слишком ли мы консервативны/агрессивны в наших OKR? Можем ли мы улучшить нашу инфраструктуру измерения? Чему мы научились и что мы можем улучшить в ходе следующей OKR-итерации?

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

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

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

OKR способны помочь преодолеть этот страх, заменив ощущение предсказуемости, которое дает диаграмма Гантта, на обязательство поставлять предопределенные бизнес-результаты.

Вместо обязательства реализовать фичи X к дате Y команда обязуется итеративно двигаться к оговоренным результатам.

Стимулирование бережливых подходов и поставок меньшего размера

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

Частая ошибка, которую допускают команды, только начинающие работать с OKR, заключается в том, что в течение всей OKR-итерации (обычно это квартал) они разрабатывают фичи, которые повлияют на Ключевые Результаты только в следующей итерации. Это неправильно.

Лучшим вариантом внедрения OKR является использование временного окна, основанного на ценности: вам требуется поставить ценность (то есть, улучшить Ключевой Результат) до конца текущей итерации. Это означает, что команда не сможет позволить себе тратить 2-3 месяца на подготовку нового релиза.

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

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

Заключение

Надеюсь, эта статья помогла вам лучше понять, как использовать OKR в своих Agile-командах.

Сертифицированный Практик OKR

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

Зарегистрироваться

Сергей Рогачев