Innovation Surfing
Author

karamnova

Browsing

COVID-19: 6 важных уроков для компаний

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

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

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

  • Структура
  • Децентрализованное принятие решений
  • Цели и задачи
  • Реализация
  • Синхронизация
  • Лидерство

Структура

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

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

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

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

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

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

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

С компанией похожая ситуация. Мы можем иметь структуру как «флот» — состоять из маленьких, независимых подразделений (команд). Если внезапно появится препятствие, например, новый конкурент, изменение правил или мировая пандемия, то мы можем быстро изменить курс, распределив управление на независимые команды. 

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

Децентрализованное принятие решений

Если мы хотим создать структуру «флота», то нам необходимо изменить способ принятия решений.

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

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

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

Цели и задачи

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

«Останься дома, чтобы спасти жизни» — это четкая цель (хотя в ней отсутствуют метрики). Она была поставлена правительством Новой Зеландии в период распространения  COVID-19. Очевидно, о чем здесь идет речь, но еще важнее почему. Оказывается, «почему» очень важно для людей. Каждый хочет понимать зачем, с какой целью он что-то делает.

Цель не обязательно должна быть идеальной и содержать ответы на все непредвиденные ситуации. Но она должна быть ясной, прозрачной и объяснять «почему». Для разбиения цели на задачи нужны ощутимые метрики.

Целеполагание с помощью OKR в последнее время стало весьма популярным.

Цели — это запоминающиеся качественные описания того, чего вы хотите достичь. Цели должны быть короткими, вдохновляющими и привлекательными. Цель должна мотивировать и бросать вызов команде.

Ключевые результаты (OKR) — это набор метрик, которые измеряют ваш прогресс в достижении цели. Для каждой цели у вас должно быть от 2 до 5 ключевых метрик. Больше 5 никто и не вспомнит.

Для целей важны основания, потому что они помогают обеспечить наилучшее выполнение.

Реализация

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

Традиционная компания

Традиционная компания использует стандартные техники управления. Executive Leadership Team (ELT) разрабатывает долгосрочные стратегии и Senior Management Team (SMT) превращает их в годовые планы, бюджеты и управляет их реализацией.

Процесс принятия решений централизован на двух разных форумах: ELT для вещей, которые влияют на стратегию, и SMT для принятия решений на уровне реализации. Каждый форум (ELT, SMT) проходит раз в две недели.

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

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

Если проекту необходимо изменить направление работы, то раз в две недели можно подать заявку на форум SMT или ELT. Это довольно пугающий процесс, поэтому обычно его не используют. Иногда ELT обнаруживает проекты «арбузы» — проекты, у которых отчеты с зеленым индикатором (все хорошо), но красные внутри (с проблемами). По оценкам традиционной компании в среднем за год она тратит 72 млн долларов на проекты «арбузы» или проекты, которые требуют дополнительного финансирования.

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

Современная компания

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

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

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

В современной компании команды получают работу в рамках ежеквартальных сессий планирования. Они используют технику «Большая комната планирования» (Big Room Planning), с помощью которой составляют OKR для каждой команды. Затем они разбивают его на несколько спринтов (двухнедельные итерации) и доставляют по частям. Команды регулярно пересматривают достигнутый прогресс и обсуждают, нужно ли им менять направление. 

Такие компании меньше думают о следовании первоначальному плану. Сначала менеджеры были обеспокоены этим, но они успокоились, когда увидели результаты от фокуса на работе с клиентами.

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

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

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

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

Как вы видите, эти две компании работают по-разному, потому что они имеют разную структуру.

Синхронизация

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

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

Scrum of Scrums — это простой способ следить за прогрессом других команд и избегать накладок и зависимостей. После каждой ежедневной встречи по синхронизации 1-2 представителя от каждой команды отправляются на собрание Scrum of Scrums и делятся своими достижениями, препятствиями и проблемами.

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

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

Лидерство

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

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

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

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

Компетенции

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

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

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

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

Член командыЛидер/ коуч
Я делаюЧто ты делаешь?
Я сделалЧто ты сделал?
Я намеренЧто ты намерен сделать?
Я бы хотелЧто ты бы хотел сделать?
Я предлагаюЧто ты предлагаешь?
Я думаюЧто ты думаешь?
Я понялЧто ты понял?
Скажи мне, что делатьЯ скажу, что тебе делать

Заключение

COVID-19 изменит мир. Все из нас извлекут урок из этой ситуации и сделают бизнес более адаптивным и гибким. Это можно значительно ускорить за счет принципиально иной системы работы, основанной на распределенном интеллекте.

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

Вы не можете сделать ошибку дважды. Во второй раз это будет ваш выбор.

Оригинал: https://www.scrum.org/resources/blog/6-critical-lessons-organisational-agility-covid-19-crisis
Перевод: Карамнова Виктория
Редакция: Кочарян Эмилия

Читать далее
By

Story Points | Стори поинты. Топ-7 вопросов

Story Points (стори поинты) — одна из самых противоречивых тем в Agile сообществе. В интернете вы можете найти довольно много статей, в которых раскрывается суть этой относительной оценки. Тем не менее у команд, применяющих стори поинты, не становится меньше вопросов. Мы решили ответить на самые часто задаваемые из них. В этой статье приводим топ-7 вопросов о стори поинтах.

1. Как перевести стори поинты в часы?

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

Для начала стоит отметить, что стори поинты чаще всего используются в Скрам-командах. Для них главный временной ориентир — это Спринт. Когда Владелец Продукта и Команда разработки договариваются сделать какую-либо работу, они планируют её на ближайший спринт. В таком случае Владельцу Продукта (человеку, которому обычно чаще всего интересны сроки) не так важно, сколько времени будет делаться конкретная задача. Ему важно, чтобы Цель Спринта была достигнута. В этой системе координат оценка задач в часах перестаёт быть актуальной.

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

Если вы попробуете связать стори поинты и часы, то поймёте, что время — это неоднозначный показатель для сравнительной оценки. Такая конвертация не принесёт пользу ни Команде, ни Владельцу Продукта.

2. Зачем использовать для оценки задачи число?

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

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

3. Нужно ли переоценивать задачу, если она переходит в следующий спринт?

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

Если задача оказалась больше, чем предполагалось, но при этом вы понимаете, что сможете завершить её в новом спринте, то переоценивать её нет смысла. Вы уже провели какую-то работу по этой задаче, вам известны риски. Нет ничего страшного в ошибочной оценке — это лишь повод обсудить на ретроспективе, почему так вышло. С другой стороны переоценка даёт прозрачность понимания, сколько работы будет выполнено за спринт. При подсчёте скорости за спринт вы получаете верное значение. Однако остается открытым вопрос о том, что делать со скоростью в предыдущем спринте: засчитывать или нет стори поинты за сделанную часть работы над задачей.

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

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

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

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

4. Равны ли друг другу стори поинты двух команд?

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

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

5. Можно ли оценивать эффективность команды с помощью стори поинтов?

Давайте представим, что мы собрали команду и начали работу над новым продуктом. Со временем стало ясно, что средняя скорость команды за спринт — 20 стори поинтов.

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

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

Со временем команда начинает все быстрее приносить ценность. Но измерять эффективность команды в стори поинтах довольно неэффективно.

Почитать о том как измерять эффективность можно здесь

6. Можно ли использовать стори поинты не только в скрам командах?

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

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

7. Нужно ли учитывать при оценке задачи скиллы ее исполнителя?

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

Если мы оцениваем задачу по способностям её исполнителя, то мы невольно возвращаемся к оценке задач по времени, что не совсем продуктивно, как мы выяснили в первом вопросе.

Авторы статьи: Карамнова Виктория, Кочарян Эмилия

Читать далее
By

DA фреймворк. Манифест.

дисциплинированный Agile-манифест

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

Наши ценности

Люди и взаимодействия важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

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

Прозрачность важнее ложных прогнозов

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Принципы, лежащие в основе дисциплинированного Agile-манифеста

  1. Наивысшим приоритетом является удовлетворение потребностей заинтересованных лиц, благодаря регулярной и ранней поставке ценных решений.
  2. Новые требования приветствуются, даже на последних этапах жизненного цикла поставки решения. Agile-процессы позволяют использовать изменения для обеспечения  заказчику конкурентного преимущества.
  3. Ценные решения необходимо выпускать непрерывно, с периодичностью от нескольких раз в день до каждых пару недель, с целью увеличения частоты поставки со временем.
  4. Заинтересованные лица и разработчики должны активно сотрудничать для достижения результатов.
  5. Создавайте команды вокруг мотивированных людей. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  6. Самый эффективный и практичный способ обмена информацией как с самой командой, так и внутри команды — непосредственное общение, в идеале, вокруг доски.
  7. Непрерывная поставка ценности — основной показатель прогресса.
  8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс поставки.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  10. Простота — искусство минимизации лишней работы — крайне необходима.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд, которые используют технологическую дорожную карту (roadmap) и поддержку.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности, затем пробовать, обучаться и соотвественно корректировать стиль своей работы.
  13. Используйте и развивайте активы вашей организации, сотрудничайте с людьми, которые ответственны за эти активы.
  14. Визуализируйте работу, чтобы постоянно поставлять ценность и свести к минимуму объем незавершенной работы.
  15. Развивайте не только отдельных людей и команды, но и организацию в целом; поддерживайте не только Agile команды, но и другие.
  16. Измеряйте работу и её результаты, предпочитайте автоматизированные метрики ручным вычислениям. Это позволит принимать решения на основе конкретных данных.
  17. Обеспечивайте полную прозрачность для заинтересованных лиц во всем, что вы делаете и производите, чтобы поддерживать открытые, честные коммуникации и эффективное взаимодействие с командой.
Читать далее
By

Метрики в agile | EBM Guide

agile метрики скрам

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

Введение

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

рис.1. Примеры вопросов

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

Без измерения ценности результативность любой Agile-практики основана лишь на интуиции и предположении. В этой статье рассмотрен подход Evidence-Based Management (EBM), который позволяет измерить поставляемую ценность. Данный подход дает возможность организации принимать рациональные решения, основанные на фактах, и учитывает эмпирические данные и логику.

EBM

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

рис.2. Четыре сферы EBM

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

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

Время реализации – своевременное удовлетворение рыночного спроса.

Готовность к инновациям – способность создавать и поддерживать высокотехнологичные решения.

Нереализованная ценность – ценность, которую может принести продукт спустя время.

Current Value/Текущая ценность 

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

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

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

  1. Насколько счастливы клиенты и пользователи на данный момент? Их уровень счастья увеличивается или снижается?
  2. Насколько счастливы ваши сотрудники? Их уровень счастья увеличивается или снижается?
  3. Насколько счастливы ваши инвесторы и заинтересованные лица? Их уровень счастья увеличивается или снижается?

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

Time-to-Market/Время реализации

Определяет способность организации быстро поставлять новый функционал, сервисы или продукты.

Целью данного показателя является измерение времени, необходимого организации для поставки ценности. Время реализации позволяет понять частоту поставок. 

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

  1. Как быстро организация может получить обратную связь о новом функционале?
  2. Как быстро вы можете узнать о новой информации и адаптироваться?
  3. Как быстро вы можете поставить новую ценность пользователям?

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

Ability to Innovate/Готовность к инновациям

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

Целью определения Готовности к инновациям является максимизация возможности реализовывать новые инновационные решения. 

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

  1. Что мешает организации поставлять инновационные решения?
  2. Что мешает пользователям получать выгоду от этих инноваций?

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

Unrealized Value/Нереализованная ценность

Определяет потенциальную ценность, которую может принести продукт.

Целью определения данного показателя является максимизация нереализованной ценности. 

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

  1. Можно ли уже сейчас создать дополнительную ценность для организации на текущем или другом рынке?
  2. Стоит ли реализация дополнительной ценности потенциальных рисков и усилий?
  3. Необходимы ли дополнительные инвестиции?

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

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

*Перечень основных метрик для каждой сферы приведен в приложении.

Ведущие и запаздывающие индикаторы 

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

Меры удовлетворенности сотрудников измеряются ведущими и запаздывающими индикаторами. Например, ведущим индикатором в таком случае может быть всплывающее окно с вопросом: как твоё настроение после рабочего дня?

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

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

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

Как улучшить использование EBM

«Если вы не знаете куда идёте, то любая дорога сможет привести вас туда.» — Льюис Кэрролл

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

  1. Определите ценность

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

  1. Измерение основных метрик

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

  1. Выберите ключевые сферы для улучшения 

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

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

  1. Проведите эксперименты для улучшения выбранных ключевых сфер

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

  1. Оцените результаты 

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

Заключение

«Если не можете что-либо измерить, то не можете этим управлять.» — Питер Друкер

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

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

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

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

Приложение

Примеры основных метрик для каждой сферы.

Current Value/Текущая ценность

Метрика Описание
Revenue per Employee Данный показатель считается как соотношение выручки к количеству сотрудников. Полученное значение индекса интерпретируется в зависимости от отрасли, в которой он измеряется. Для каждой отрасли существует свое стандартное значение.
Product Cost Ratio Соотношение совокупности затрат на продукт (включая операционные расходы) к выручке.
Employee Satisfaction Измерение вовлеченности сотрудников. Например, сбор обратной связи.
Customer Satisfaction Измерение удовлетворенности пользователей. Например, NPS.
Usage Index Выявление часто используемого и менее используемого функционала. Например, соотношение используемого функционала ко всему функционалу или время, затрачиваемое на использование функционала.

Time-to-Market/Время реализации

Метрика Описание
Build and integration frequency Количество билдов-сборок (внедренных и протестированных) за определенный период.
Release Frequency Количество релизов за определенное время, например, непрерывно, ежедневно, ежеденедельно и т.д. Это помогает определить время, необходимое для поставки ценности клиенту.
Release Stabilization Period Время, затрачиваемое на исправление проблем, с момента «да, все готово для релиза» до момента «релиз».
Mean Time to Repair Среднее время с момента обнаружения ошибки до ее исправления. Это отражает насколько работа с дефектами эффективна.
Cycle time Время с момента начала работы над функционалом до момента релиза. 
Lead Time Время от идеи до реализации. Если идеи пользователя быстро реализуются, то удовлетворенность увеличивается.
Time-to-Learn Время от момента получения идеи до возможности измерить результаты реализации идеи.

Ability to Innovate/Готовность к инновациям

Метрика Описание
Usage Index Измерение функционала, который действительно используется пользователем. Фичи, которые используются редко, все равно нуждается в поддержке — на него уходят силы, это блокирует возможность использовать ресурсы на инновации.
Innovation Rate Соотношение процента усилий и затрат, потраченных на новые возможности продукта, к общей сумме усилий или затрат. Это дает представление о способности организации поставлять новый фунционал.
Defect trends Измерение изменений в дефектах с момента последнего измерения. Дефект — это, то что напрямую влияет на качество функционала и снижает ценность продукта для пользователя или организации.
On-Product Index Процент общей базы пользователей, использующих текущую версию продукта. Низкие значения — могут быть связаны с проблемами установки или низкой информированности.
Installed Version Index Количество версий продукта, которые поддерживаются. Чем больше значение — тем больше компания тратит на поддержку этих версий, и ресурсы не могут быть направлены на инновации.
Technical Debt Технический долг — количество некачественных решений, которые в дальнейшем влияют на скорость работы, обработку запросов и т.д. 
Production Incident Trends Частота случаев, когда команда прерывает запланированную работу, чтобы решить проблему или поправить возникнувший дефект «СРОЧНО». Это помогает определить стабильность продукта.
Active code branches, time spent merging code between branches Количество времени, затраченного на поддержку кода для разных версий продукта, слияние изменений и интеграцию продукта. 
Time spent context switching Частота прерываний члена команды, которые снижают его продуктивность, работая над новой возможностью. Количество встреч в день, количество раз когда необходима кому-то помощь вне команды.

Unrealized Value/Нереализованная ценность

Метрика Описание
Market Share Относительная доля рынка, контролируемая продуктом.
Customer or user satisfaction gap Разница между ожиданиями пользователя и фактическим результатом.

Статья переведена под ред. Делягиной Анастасии.

Список используемой литературы:

Оригинал текста

Читать далее
By