Как посчитать time to market

Метрики в Scrum и Kanban

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

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

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

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

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?

Источник

Time to market: почему показатель важен в кризис и при чем тут облако

Что такое Time to market?

TTM — это время от начала разработки идеи до конечного запуска решения и его выхода на рынок. Например, для мобильного или корпоративного приложения Time to market начинается с момента, когда компания только решила его создать. И заканчивается, когда приложение публикуется в сторе или внедряется в компании.

Time to market — один из ключевых показателей для стартапов. Но он также важен для любых компаний, которые выпускают или внедряют новые решения.

Чем меньше значение TTM, тем лучше. Ведь если создание и запуск продукта затягиваются, компания может отстать от конкурентов и упустить выгоду. А инновационное решение — потерять свою инновационность. По данным Gartner, примерно 20% продуктов, выпущенных с задержкой, не достигают своих целей.

Почему этот показатель так важен в кризис?

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

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

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

Бизнес, прошедший через периоды экономической нестабильности, хорошо это понимает. После мирового кризиса 2008 года компания Amdocs отмечала рост внимания к TTM. Если в 2008-м его называли одним из важнейших бизнес-показателей только 58% поставщиков услуг и сервисов, то три года спустя цифра выросла до 70%. А сегодня сокращение TTM — одна из самых обсуждаемых тем в компаниях, которые выводят новые продукты на рынки.

Какие этапы включает в себя Time to market?

ТТМ включает несколько основных стадий, которые проходит команда при создании нового продукта или функции:

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

Какие еще факторы влияют на Time to market?

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

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

По подсчетам Gartner, только 55% продуктов запускается вовремя, а оставшиеся 45% релизов откладываются как минимум на месяц. «Продукт может не запускаться в запланированные сроки из-за нескольких факторов, включая отсутствие формализованных процессов запуска, задержки в разработке продукта (баги, ошибки, нестабильность функций), невыполнение требований клиентов, качество продукта или даже проблемы с поставками», — отмечают аналитики.

Как можно сократить Time to market?

Чтобы быстрее вывести продукт на рынок, компании часто готовят MVP (Minimum Viable Product — минимально жизнеспособный продукт, позволяющий получить обратную связь) с ограниченным функционалом и тестируют его на потребителях. Это позволяет выявить ошибки в продукте и оценить его востребованность.

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

Однако после запуска MVP решение все равно приходится докручивать. Если делать это «по старинке», потребуется время.

Среди самых эффективных способов уменьшить TTM — использование облачных ИТ-ресурсов вместо физических серверов, отказ от архаичных подходов к разработке в пользу готовых решений на облачных платформах.

Каким образом облака помогают ускорить выход на рынок?

Облачные сервисы ускоряют процессы по двум основным направлениям.

Их предоставляют поставщики облачных услуг (облачные провайдеры) в рамках услуг PaaS — Platform as a Service. Эти сервисы специально спроектированы, чтобы ускорить и упростить процесс создания решений. Разработчики продукта получают готовую программную среду для написания, тестирования и размещения приложений вместе с набором дополнительных инструментов.

Так, на облачной платформе SberCloud.Advanced компании SberCloud интегрированы и инфраструктурные облачные услуги (IaaS), и платформенные PaaS-решения. Например, услуга развертывания приложений в облаке, бессерверные вычисления, облачные базы данных реального времени и другие продукты.

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

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

Как заявил президент, председатель правления Сбербанка Герман Греф, на встрече с инвесторами и акционерами (Investor Day 2020) переход на новую облачную цифровую платформу сократил Time-to-market новых продуктов «Сбера» в семь раз.

Каким компаниям и в каких проектах стоит использовать облако для сокращения TTM?

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

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

Наращивать использование облаков собирается большинство компаний, показало исследование Flexera: 59% предприятий ожидают, что облачные сервисы будут применяться шире, чем планировалось в доковидный период.

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

Как это работает с ИТ-стартапом?

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

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

Единственный вариант успешно запустить такой стартап, это использовать готовые инфраструктурные (IaaS) и платформенные облачные сервисы (PaaS). Идеально, если они будут еще интегрированы между собой.

Поставщики облачных услуг уже предлагают такие варианты. Например, на платформе SberCloud.Advanced можно получить сразу и IaaS сервисы, такие как Elastic Cloud Server — легко конфигурируемый и масштабируемый виртуальный сервер с возможностью автомасшатбирования, а также все необходимые для быстрой реализации идеи платформенные сервисы (PaaS).

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

Мы уже используем облачные сервисы. Как еще можно сократить TTM?

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

Источник

Agile-метрики команд. Часть 2. Хорошие метрики

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

Agile-метрики команд. Часть 1. Сомнительные метрики

Оранжевые организация — большие любители все “мерять”. Лично мое мнение такое: мерять можно что угодно, однако в…

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

Burn-up Chart

Что это: показывает как вы съедаете скоуп (объем) к дате или же наоборот, к какой даде будет сделан этот объем скоупа.

Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?

Или, что будет сделано к Рождеству?

В Agile мире, мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет, потому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.

End-to-end time to market (Lead time)

Что это: это метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.

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

Однако, на много интереснее, сколько времени прошло в целом от идеи до реализации. И вот почему:

Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу

А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика 🙂

Эффективность потока (Flow Efficiency)

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

Например, возьмем упрощенный процесс разработки с точки зрения задачи:

Проработка деталей — Разработка — Тестирование — Выпуск

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

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

Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%

Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.

Количество элементов в беклоге

Что меряет: меряет количество элементов в бэклоге 🙂

Зачем мерять? Что бы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.

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

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

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

Нет цифры, которая бы идентифицировала предел 🙂 это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂

Срок жизни элемента беклога

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

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

Чем меньше срок жизнь, тем понятнее контент беклога, проще с ним работать и повышается его актуальность.

Эволюция Definition of Done

Как померять работу Scrum Master? Очень просто — на сколько растет Definition of Done его команды. Этим же можно померять “взросление команды”.

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

Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали более Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.

Источник

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Приложение

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

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

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

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

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

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

Источник