Telegram Group & Telegram Channel
Треугольник эффективности или как понять какие метрики нужны бизнесу

Недавно ко мне пришла замечательная Марьяна (автор канала Продукты, книги и любовь) с вопросом «Рома, а как лиду команды программистов Ване выбрать метрики работы команды, которые стоит отслеживать на дашборде для оценки эффективности работы команды?».

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

Для начала давайте обсудим, что такое «эффективность»? Например, Петя, программист из команды Вани, закрывает задач на 10 стори-поинтов за спринт — эффективно ли это? Сравним со средним значением для других программистов? А как тогда определить эффективность всей команды — пойти посмотреть на рынок? Но там люди делают совершенно другие задачи и по-другому их оценивают. Отсюда первый вывод — измерить эффективность процесса чаще всего невозможно, можно только сказать насколько он стал эффективнее предыдущего периода или какого-то бенчмарка на рынке. Но бенчмарки работают крайне плохо.

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

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

Описанию метрик процесса помогает фреймворк «Треугольник эффективности». Он говорит, что любой процесс должен быть описан с трёх сторон:
— Delivery: Продукт/результат процесса. Чаще всего кол-во продуктов или объём услуг выпущенных за единицу времени и их продуктовый микс (выпускаем не только A, а способны делать и A, и B, и C).
— Quality: Качество процесса. Кол-во ошибок в процессе.
— Cost: Стоимость реализации процесса.

Разберём на примере команды разработки.

D - Продукт/результат
— Кол-во задач сделанных за спринт
— Кол-во стори-поинтов выполненных за спринт
— Микс задач (60% новые фичи, 20% баги, 20% тех. долг)

Q - Качество

— Кол-во итераций при ревью кода
— % успешных тестов
— Кол-во новых багов

С - Затраты
— Кол-во часов работы программистов
— Кол-во часов работы смежных специалистов (QA, бизнес-аналитик, продакт)
— Стоимость софта/инфраструктуры

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

R - Риски
— Оценка рисков утечки информации пользователей
— Риски замедления разработки из-за неудачной архитектуры
— Риски выгорания сотрудников

Смотря на этот список метрик получаем определение «повышения эффективности» — когда мы улучшаем хотя бы одну метрику процесса при этом не ухудшая остальные метрики. Стали больше деливирить фичей, но полезли баги — это не является повышением эффективности. Больше закрываем задач и нет новых багов, но 80% времени тратим на рефакторинг — не является повышением эффективности. Научились больше деливирить за счет автоматических сборок и тестов, а качество, затраты и риски не выросли — это повышение эффективности.

А как же Ване это поможет для дашборда? Ему надо выбрать какая часть D, Q, C или R является ключевой для всей компании. Для стартапа — будет важным скорость релизов, а для банка — надёжность сервиса, для консалтинга — сокращение затрат и т.п. Далее делаем расчет метрик по всем категориям, но с фокусом на текущую стратегию компании и реализуем дашборд.

Мне нравится, что эта методика подходит для чего угодно. Даже изменение личной эффективности можно прикинуть. Попробуйте треугольник, когда перед вами будет задача оценить эффективность бизнес-процесса.
#избранное



group-telegram.com/revealthedata/1409
Create:
Last Update:

Треугольник эффективности или как понять какие метрики нужны бизнесу

Недавно ко мне пришла замечательная Марьяна (автор канала Продукты, книги и любовь) с вопросом «Рома, а как лиду команды программистов Ване выбрать метрики работы команды, которые стоит отслеживать на дашборде для оценки эффективности работы команды?».

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

Для начала давайте обсудим, что такое «эффективность»? Например, Петя, программист из команды Вани, закрывает задач на 10 стори-поинтов за спринт — эффективно ли это? Сравним со средним значением для других программистов? А как тогда определить эффективность всей команды — пойти посмотреть на рынок? Но там люди делают совершенно другие задачи и по-другому их оценивают. Отсюда первый вывод — измерить эффективность процесса чаще всего невозможно, можно только сказать насколько он стал эффективнее предыдущего периода или какого-то бенчмарка на рынке. Но бенчмарки работают крайне плохо.

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

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

Описанию метрик процесса помогает фреймворк «Треугольник эффективности». Он говорит, что любой процесс должен быть описан с трёх сторон:
— Delivery: Продукт/результат процесса. Чаще всего кол-во продуктов или объём услуг выпущенных за единицу времени и их продуктовый микс (выпускаем не только A, а способны делать и A, и B, и C).
— Quality: Качество процесса. Кол-во ошибок в процессе.
— Cost: Стоимость реализации процесса.

Разберём на примере команды разработки.

D - Продукт/результат
— Кол-во задач сделанных за спринт
— Кол-во стори-поинтов выполненных за спринт
— Микс задач (60% новые фичи, 20% баги, 20% тех. долг)

Q - Качество

— Кол-во итераций при ревью кода
— % успешных тестов
— Кол-во новых багов

С - Затраты
— Кол-во часов работы программистов
— Кол-во часов работы смежных специалистов (QA, бизнес-аналитик, продакт)
— Стоимость софта/инфраструктуры

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

R - Риски
— Оценка рисков утечки информации пользователей
— Риски замедления разработки из-за неудачной архитектуры
— Риски выгорания сотрудников

Смотря на этот список метрик получаем определение «повышения эффективности» — когда мы улучшаем хотя бы одну метрику процесса при этом не ухудшая остальные метрики. Стали больше деливирить фичей, но полезли баги — это не является повышением эффективности. Больше закрываем задач и нет новых багов, но 80% времени тратим на рефакторинг — не является повышением эффективности. Научились больше деливирить за счет автоматических сборок и тестов, а качество, затраты и риски не выросли — это повышение эффективности.

А как же Ване это поможет для дашборда? Ему надо выбрать какая часть D, Q, C или R является ключевой для всей компании. Для стартапа — будет важным скорость релизов, а для банка — надёжность сервиса, для консалтинга — сокращение затрат и т.п. Далее делаем расчет метрик по всем категориям, но с фокусом на текущую стратегию компании и реализуем дашборд.

Мне нравится, что эта методика подходит для чего угодно. Даже изменение личной эффективности можно прикинуть. Попробуйте треугольник, когда перед вами будет задача оценить эффективность бизнес-процесса.
#избранное

BY Reveal the Data




Share with your friend now:
group-telegram.com/revealthedata/1409

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

But because group chats and the channel features are not end-to-end encrypted, Galperin said user privacy is potentially under threat. Asked about its stance on disinformation, Telegram spokesperson Remi Vaughn told AFP: "As noted by our CEO, the sheer volume of information being shared on channels makes it extremely difficult to verify, so it's important that users double-check what they read." Two days after Russia invaded Ukraine, an account on the Telegram messaging platform posing as President Volodymyr Zelenskiy urged his armed forces to surrender. "And that set off kind of a battle royale for control of the platform that Durov eventually lost," said Nathalie Maréchal of the Washington advocacy group Ranking Digital Rights. And indeed, volatility has been a hallmark of the market environment so far in 2022, with the S&P 500 still down more than 10% for the year-to-date after first sliding into a correction last month. The CBOE Volatility Index, or VIX, has held at a lofty level of more than 30.
from ca


Telegram Reveal the Data
FROM American