Заметки на полях: что было интересного на ENTERPRISE AGILE RUSSIA 2019 (продолжение)

Продолжаю делиться тем, что запомнилось после посещения Enterprise Agile Russia. В прошлый раз я представил несколько примеров и советов из практики Agile-трансформации нашей компании. В докладе “Business Agility за счет кросс-технологичных ARTs” Марк Ричардс поделился инсайтами на предмет того, как добиться гибкости бизнеса с SAFe. Сегодня расскажу про второе выступление Марка.

Доклад “Improving Alignment, Focus and Feedback with OKRs” был про OKR (Objectives and Key Results) и о том, где его место в SAFe. На темы OKR и KPI в интернете появляется все больше информации. Если вы уже слышали о SAFe и OKR, то, возможно, у вас как и у меня возникал вопрос: “Ок, если SAFe является сборником лучших практик по внедрению и масштабированию Agile, то где же там такая крутая и “расхайпованная” вещь как OKR?” Так вот, OKR там не только есть, но и играет очень важную роль. Об этом и рассказал Марк.

Собственно, OKR в рамках SAFe может хорошо прижиться на всех уровнях для полной прозрачности и синхронизации. В SAFe есть уровень Portfolio, где можно ставить годовые цели в формате OKR. При этом Epic будут гораздо точнее, если в поле Business Outcome Hypothesis мы будем прописывать Objective, а в Leading Indicators будем писать Key Results (Рис . 1).

 

При этом, тот же Minimum Viable Product можно описывать в формате OKR. На этом я бы хотел особенно заострить внимание. Мне кажется, что в мире разработки уже все знают, что такое MVP. Но почему-то начинают использовать его в формате: “Давайте запустимся с минимальным функционалом, либо урежем все до минимума, чтобы заказчик потратил меньше бюджета и получил какое-то решение”. Основной и далеко нелегкий момент – правильное формулирование гипотезы и метрик MVP. Об этом, как будто специально, все забывают. Я не раз видел, как на решение в рамках MVP влияли не гипотеза и метрики, а нехватка бюджета или желание этот бюджет урезать. А это категорически неправильно. Впрочем, о том, как формулировать MVP и о том, как объяснять в заказной разработке это заказчику, думаю, также нужна отдельная статья.

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

Objective:

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

На данный момент на рынке прямого конкурента нет. Тем не менее, есть схожие решения: агробиржи и фермерские магазины. Эти решения обладают следующими недостатками:

 

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

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

Цели всего продукта:

 

1. Цель через 17 месяцев: Занять 4% рынка Московской области и получить выручку в 1М руб. в месяц
2. Цель через 24 месяца: Занять 1-3% рынка РФ и получить выручку от 5М руб. в месяц

Key Results на этап MVP:

 

1. Обеспечить постоянно растущий объем зарегистрированных пользователей в приложении. 
2. Нарастить объем сделок в приложении до 200 сделок в месяц.
3. Получить раунд инвестиций в размере (закрытая информация) рублей. 

Признаю, не все Key Results в данном примере поставлены конкретно и правильно, но даже эти  формулировки при сдачи MVP продукта заставили команду реализовать “линейки” того, как измерять результат. Таким образом, заказчик мог в любой момент посмотреть на достигнутые метрики Minimum Viable Product и разговаривать с инвесторами, оперируя конкретными цифрами.

Согласно тому, о чем поведал Марк, OKR, поставленные на Portfolio-уровне могут спускаться на уровень ART и влиять на продуктовую стратегию, при этом хорошо подходить под цикл DevOps (Рис. 2).

 

 Также OKR могут ставиться в PI-objectives и делать их более похожими на smart-цели (specific, measurable, achievable, relevant, time bound) (Рис. 3). Сами по себе OKR содержат в своей структуре метрики, т.е. нельзя придумать OKR без Key Result, следовательно вы получаете measurable-цели. Поскольку OKR ставятся на определенный период времени, то результаты получаются TimeBound. Конечно, в OKR есть свои правила по достижению, но в целом, на мой взгляд это хорошая практика, которая может сделать ваш беклог более понятным и конкретным.

 

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

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