△Треугольник эффективности или как понять какие метрики нужны бизнесу Недавно ко мне пришла замечательная Марьяна (автор канала Продукты, книги и любовь) с вопросом «Рома, а как лиду команды программистов Ване выбрать метрики работы команды, которые стоит отслеживать на дашборде для оценки эффективности работы команды?». Отвечаю публично. Существует куча методик, но я расскажу об одной не такой известной, которую я узнал работая с производственными процессами, она хорошо подходит для таких кейсов. Для начала давайте обсудим, что такое «эффективность»? Например, Петя, программист из команды Вани, закрывает задач на 10 стори-поинтов за спринт — эффективно ли это? Сравним со средним значением для других программистов? А как тогда определить эффективность всей команды — пойти посмотреть на рынок? Но там люди делают совершенно другие задачи и по-другому их оценивают. Отсюда первый вывод — измерить эффективность процесса чаще всего невозможно, можно только сказать насколько он стал эффективнее предыдущего периода или какого-то бенчмарка на рынке. Но бенчмарки работают крайне плохо. Окей, поняли, что можно измерить только повышение эффективности, но что же это такое? Например, программист Петя стал закрывать 15 стори-поинтов за спринт, а раньше закрывал только 10. Ваня должен дать Пете премию? Стал ли Петя работать более эффективно? Однозначно сказать невозможно, так как мы не знаем всех характеристик процесса, только его производительность. Ещё нужно понять стал ли Петя делать больше багов, сколько раз код приходилось править во время ревью, или может Петя просто стал работать на 20 часов больше и совсем не спит. Получается, что чтобы говорить про изменение эффективности надо знать ещё и другие метрики процесса, а не только производительность. Кстати, поэтому так плохо работают отраслевые бенчмарки, они не дают представление о всех метриках процесса. Описанию метрик процесса помогает фреймворк «Треугольник эффективности». Он говорит, что любой процесс должен быть описан с трёх сторон: — Delivery: Продукт/результат процесса. Чаще всего кол-во продуктов или объём услуг выпущенных за единицу времени и их продуктовый микс (выпускаем не только A, а способны делать и A, и B, и C). — Quality: Качество процесса. Кол-во ошибок в процессе. — Cost: Стоимость реализации процесса. Разберём на примере команды разработки. D - Продукт/результат — Кол-во задач сделанных за спринт — Кол-во стори-поинтов выполненных за спринт — Микс задач (60% новые фичи, 20% баги, 20% тех. долг) Q - Качество — Кол-во итераций при ревью кода — % успешных тестов — Кол-во новых багов С - Затраты — Кол-во часов работы программистов — Кол-во часов работы смежных специалистов (QA, бизнес-аналитик, продакт) — Стоимость софта/инфраструктуры Ещё в «центр треугольника» добовляют метрики рисков, чаще они качественные, но могут быть и количественными. R - Риски — Оценка рисков утечки информации пользователей — Риски замедления разработки из-за неудачной архитектуры — Риски выгорания сотрудников Смотря на этот список метрик получаем определение «повышения эффективности» — когда мы улучшаем хотя бы одну метрику процесса при этом не ухудшая остальные метрики. Стали больше деливирить фичей, но полезли баги — это не является повышением эффективности. Больше закрываем задач и нет новых багов, но 80% времени тратим на рефакторинг — не является повышением эффективности. Научились больше деливирить за счет автоматических сборок и тестов, а качество, затраты и риски не выросли — это повышение эффективности. А как же Ване это поможет для дашборда? Ему надо выбрать какая часть D, Q, C или R является ключевой для всей компании. Для стартапа — будет важным скорость релизов, а для банка — надёжность сервиса, для консалтинга — сокращение затрат и т.п. Далее делаем расчет метрик по всем категориям, но с фокусом на текущую стратегию компании и реализуем дашборд. Мне нравится, что эта методика подходит для чего угодно. Даже изменение личной эффективности можно прикинуть. Попробуйте треугольник, когда перед вами будет задача оценить эффективность бизнес-процесса. #избранное