Тема «разделение outcome и process metrics» поддерживает конкретное продуктовое решение. Единица «outcome/process» — наблюдаемый эффект отдельно от выполненной работы. Вопрос «outcome/process»: как не подменять изменение пользовательского или бизнес-результата количеством задач, встреч и выпусков. Методика «outcome/process» согласует определения, данные и действия. Владелец «outcome/process» отвечает за итоговую формулу.
Контекст и цель
Контур «outcome/process» начинается с будущего решения. Для «outcome/process» назовите субъект и период. Реакция на изменение «outcome/process» задаётся заранее. Единица «наблюдаемый эффект отдельно от выполненной работы» отделяет результат от активности команды. Такой порядок защищает «outcome/process» от декоративной отчётности.
Основание «outcome/process»: Google HEART преобразует целевые результаты — с учётом темы «Метрики результата и метрики процесса» — в признаки и измерения. основание
Основание «outcome/process»: GOV.UK требует понятного толкования и предварительного проектирования метрик. основание
Основание «outcome/process»: GOV.UK сочетает метрики сервиса — с учётом темы «Метрики результата и метрики процесса» — с пользовательскими исследованиями. основание
Основание «outcome/process»: W3C соединяет уровень качества данных с пригодностью использования. основание
Источники поддерживают принципы «outcome/process». Локальные фильтры выбирает команда «outcome/process». Полнота событий проверяется для «outcome/process» отдельно. Стоимость ошибки также входит в решение «outcome/process».
Рабочая модель
Формула «outcome/process»: outcome фиксирует изменение состояния пользователя или сервиса; process metric описывает способ и устойчивость достижения. Модель «outcome/process» содержит шесть самостоятельных частей. Каждая часть «outcome/process» имеет владельца и пример.
-
Целевой эффект. В «outcome/process» элемент «целевой эффект» задаёт границу. Пара «целевой эффект — единица пользователя или операции» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
-
Единица пользователя или операции. В «outcome/process» элемент «единица пользователя или операции» задаёт границу. Пара «единица пользователя или операции — горизонт результата» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
-
Горизонт результата. В «outcome/process» элемент «горизонт результата» задаёт границу. Пара «горизонт результата — процессный сигнал» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
-
Процессный сигнал. В «outcome/process» элемент «процессный сигнал» задаёт границу. Пара «процессный сигнал — ограничение качества» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
-
Ограничение качества. В «outcome/process» элемент «ограничение качества» задаёт границу. Пара «ограничение качества — контроль внешних факторов» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
-
Контроль внешних факторов. В «outcome/process» элемент «контроль внешних факторов» задаёт границу. Пара «контроль внешних факторов — целевой эффект» проверяется на эпизоде. Исключения «outcome/process» записываются до расчёта.
Конфликт вокруг «целевой эффект» блокирует модель «outcome/process». Определение «outcome/process» исправляется до публикации. Усреднение «outcome/process» не решает смысловой конфликт.
Данные и расчёт
Паспорт «outcome/process» фиксирует числитель и знаменатель. Субъект «outcome/process» указывается отдельно. Для «наблюдаемый эффект отдельно от выполненной работы» задаётся источник времени. Часовая зона «outcome/process» входит в контракт. Дедупликация «outcome/process» описывает повторные события.
Ручная сверка «outcome/process» использует реальные истории. Агрегат «outcome/process» сравнивается с транзакционным источником. Компоненты «единица пользователя или операции», «горизонт результата» и «процессный сигнал» сохраняются отдельно. Разложение «outcome/process» показывает продуктовый сдвиг или дефект сбора.
Период «outcome/process» следует естественному циклу. Календарная неделя подходит не всегда. Причина периода «outcome/process» документируется. Дата пересмотра «outcome/process» также фиксируется.
Интерпретация и решения
Правила чтения «outcome/process» записываются заранее. После результата правила «outcome/process» не переписываются.
-
Рост velocity без эффекта не считается успехом. В «outcome/process» правило связано с «целевой эффект». Владелец «outcome/process» указывает действие и срок реакции.
-
Ухудшение процесса при стабильном результате может предвещать будущий сбой. В «outcome/process» правило связано с «единица пользователя или операции». Владелец «outcome/process» указывает действие и срок реакции.
-
Разовый outcome требует проверки устойчивости. В «outcome/process» правило связано с «горизонт результата». Владелец «outcome/process» указывает действие и срок реакции.
-
Процессный показатель полезен только при понятной связи с результатом. В «outcome/process» правило связано с «процессный сигнал». Владелец «outcome/process» указывает действие и срок реакции.
-
Премирование по активности повышает риск игрового поведения. В «outcome/process» правило связано с «ограничение качества». Владелец «outcome/process» указывает действие и срок реакции.
Изменение «outcome/process» сначала проходит техническую проверку. Релиз «outcome/process» исключается первым. Затем «outcome/process» сверяется с трафиком и задержкой. Гипотезы «outcome/process» формулируются после проверки.
Практический пример
Команда поддержки внедряет самообслуживание. Число опубликованных инструкций — процессная метрика. Доля вопросов, решённых без обращения, и время до решения — outcome. Если публикаций больше, а обращения не снижаются, команда исследует поиск, понятность и покрытие тем.
В примере «outcome/process» восстанавливаются реальные истории. Поток «outcome/process» проверяется по «целевой эффект». Затем изучаются «горизонт результата» и «ограничение качества». Агрегат «outcome/process» сверяется с операционной системой.
Итог примера — правило решения «outcome/process». Правило «outcome/process» различает эксперимент и исправление данных. Дополнительное исследование назначается отдельно. Дашборд «outcome/process» остаётся каналом доставки сигнала.
Порядок внедрения
Внедрение «outcome/process» делится на короткие шаги. Каждый шаг «outcome/process» оставляет контрольный результат.
-
Переписать цель как изменение состояния. Шаг «переписать цель как изменение состояния» уточняет «целевой эффект». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
-
Отделить выход команды от эффекта продукта. Шаг «отделить выход команды от эффекта продукта» уточняет «единица пользователя или операции». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
-
Выбрать запаздывающий результат. Шаг «выбрать запаздывающий результат» уточняет «горизонт результата». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
-
Найти ранние процессные сигналы. Шаг «найти ранние процессные сигналы» уточняет «процессный сигнал». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
-
Задать допустимые границы качества. Шаг «задать допустимые границы качества» уточняет «ограничение качества». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
-
Проверять расхождения между двумя классами метрик. Шаг «проверять расхождения между двумя классами метрик» уточняет «контроль внешних факторов». В модели «outcome/process» результат проверяют три роли. Переход «outcome/process» сохраняется в журнале.
Первый расчёт «outcome/process» повторяется независимым запросом. Расхождение «outcome/process» разбирается по фильтрам. Время «outcome/process» и идентификаторы сверяются далее. Версии «outcome/process» проверяются отдельно.
Критерии качества
Определение «outcome/process» готово при следующих условиях:
-
Результат описывает изменение для пользователя или организации. Критерий «результат описывает изменение для пользователя или организации» проверяет «целевой эффект». Подтверждение «outcome/process» хранится запросом или событием.
-
Процессные показатели не выдаются за ценность. Критерий «процессные показатели не выдаются за ценность» проверяет «единица пользователя или операции». Подтверждение «outcome/process» хранится запросом или событием.
-
Периоды сравнения согласованы. Критерий «периоды сравнения согласованы» проверяет «горизонт результата». Подтверждение «outcome/process» хранится запросом или событием.
-
Существует правило реакции на расхождение. Критерий «существует правило реакции на расхождение» проверяет «процессный сигнал». Подтверждение «outcome/process» хранится запросом или событием.
-
Внешние факторы помечаются отдельно. Критерий «внешние факторы помечаются отдельно» проверяет «ограничение качества». Подтверждение «outcome/process» хранится запросом или событием.
-
Отчёт показывает обе группы без смешения шкал. Критерий «отчёт показывает обе группы без смешения шкал» проверяет «контроль внешних факторов». Подтверждение «outcome/process» хранится запросом или событием.
Критерии «outcome/process» оцениваются совместно. Формула «outcome/process» не исправляет плохие данные. Точный поток «outcome/process» бесполезен без решения.
Ограничения применимости
Перед публикацией «outcome/process» укажите ограничения:
-
Эффект может проявляться позже процесса. Ограничение «эффект может проявляться позже процесса» меняет вывод «outcome/process». В ответ добавляется «единица пользователя или операции» или качественное исследование.
-
В сложной системе outcome зависит от нескольких команд. Ограничение «в сложной системе outcome зависит от нескольких команд» меняет вывод «outcome/process». В ответ добавляется «горизонт результата» или качественное исследование.
-
Не все общественные или качественные результаты легко количественно выразить. Ограничение «не все общественные или качественные результаты легко количественно выразить» меняет вывод «outcome/process». В ответ добавляется «процессный сигнал» или качественное исследование.
-
Прокси могут потерять связь с целью. Ограничение «прокси могут потерять связь с целью» меняет вывод «outcome/process». В ответ добавляется «ограничение качества» или качественное исследование.
-
Слишком редкое измерение затрудняет оперативное управление. Ограничение «слишком редкое измерение затрудняет оперативное управление» меняет вывод «outcome/process». В ответ добавляется «контроль внешних факторов» или качественное исследование.
Крупное ограничение отменяет общий итог «outcome/process». Несколько представлений «outcome/process» честнее одного числа. Ложная определённость «outcome/process» опаснее сложности.
Вывод
Практика «outcome/process» начинается с единицы «наблюдаемый эффект отдельно от выполненной работы». Затем «outcome/process» связывает формулу, события и проверки. Реакция «outcome/process» назначается владельцу. Ручная сверка предшествует автоматизации.
Минимум «outcome/process»: ответить на вопрос «как не подменять изменение пользовательского или бизнес-результата количеством задач, встреч и выпусков». Далее проверяется формула «outcome фиксирует изменение состояния пользователя или сервиса; process metric описывает способ и устойчивость достижения». Ограничения «outcome/process» записываются до регулярного review.
