Now Hiring: Are you a driven and motivated Mid/Senior .Net Developer?

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

Agile

Заметки на полях: что было интересного на 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). 

epic hypothesis statement
Рис. 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 на уровне Agile Release Train: влияние на продуктовую стратегию
Рис.2 – OKR на уровне Agile Release Train: влияние на продуктовую стратегию.  
Источник: coactivation.com 

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

team a pi objectives
Рис.3 – Цели команды, создающей инкремент продукта

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

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

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

Подробнее изучить вопрос про:

  • Epic (Эпик)  здесь.
  • Program Increment Objectives, PI-objectives (Цели Инкремента Программы, PI-цели)  здесь.

Комментарии

Ваш адрес email не будет опубликован. Обязательные поля помечены *