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: |

Multiple pro-Kremlin media figures circulated the post's false claims, including prominent Russian journalist Vladimir Soloviev and the state-controlled Russian outlet RT, according to the DFR Lab's report. On Feb. 27, however, he admitted from his Russian-language account that "Telegram channels are increasingly becoming a source of unverified information related to Ukrainian events." Meanwhile, a completely redesigned attachment menu appears when sending multiple photos or vides. Users can tap "X selected" (X being the number of items) at the top of the panel to preview how the album will look in the chat when it's sent, as well as rearrange or remove selected media. Telegram users are able to send files of any type up to 2GB each and access them from any device, with no limit on cloud storage, which has made downloading files more popular on the platform. The picture was mixed overseas. Hong Kong’s Hang Seng Index fell 1.6%, under pressure from U.S. regulatory scrutiny on New York-listed Chinese companies. Stocks were more buoyant in Europe, where Frankfurt’s DAX surged 1.4%.
from us


Telegram Reveal the Data
FROM American