— Если оценивать подходы банков к измерению эффективности ИТ — насколько эта тема хорошо проработана в отрасли, какие ошибки чаще всего допускаются, в чём новизна вашего подхода?
А. Саломатин: Тема эта в отрасли проработана не слишком хорошо, поскольку многие банки предпочитают идти по пути наименьшего сопротивления. Наибольшей популярностью пользуются следующие подходы к оценке:
1. «Если организация или направление получает прибыль, а мы все одна команда, значит, ИТ тоже работает достаточно эффективно». В таком фундаменталистском agile-подходе, на мой взгляд, есть доля лукавства: рост общей прибыли совершенно не означает, что в этом есть заслуга конкретных разработчиков, — возможно, на рынке просто сложилась благоприятная ситуация. И не исключено, что эффективность ИТ-команды вполне можно было бы значительно повысить либо оптимизировать ресурсы на поддержание её деятельности.
2. Использование стандартных agile-метрик — стори-пойнтов. Проблема в том, что стори-пойнты являются уникальными для каждой команды, и если компания хочет управлять общей эффективностью на основе общей статистики, она должна найти способ их универсализации.
Данный подход популярен среди ИТ-компаний, банки к нему относятся осторожно.
3. «Количественный» подход, когда компания пытается измерять эффективность разработчиков исходя из количества решённых ими задач. Однако количественная оценка довольно часто будет некорректной, особенно если компания перестроила процессы, например на выпуск MVP и постепенную доводку решений до целевых, либо сменила крупную технологическую платформу. Это может привести к «измельчению» задач, но не факт, что как-то повлияет на реальную эффективность разработки.
4. Лучше всего зарекомендовавший себя сценарий — выстраивание метрик эффективности на базе общепризнанных единиц измерения. Такой подход был использован Ренессанс Банком при внедрении методологии оценки объёма полезной работы разработчиков в функциональных точках (fast function points).
— Как вы формулируете само понятие эффективности ИТ в данном контексте, какие здесь приоритеты?
А. Саломатин: Есть объём полезной работы, который мы можем научиться измерять, внедрив соответствующую методологию, и есть задействованные ИТ-ресурсы, т. е. человеко-часы аналитиков, разработчиков, тестировщиков, DevOps-инженеров и пр., затраченные ими на разработку новой полезной функциональности, которую можно измерить, например, в функциональных точках или любых других единицах (главное — сохранять при этом объективность).
Делим первый показатель на второй — и получаем текущую эффективность, уровень производительности команд разработки.
Разобравшись с метриками эффективности, можно приступать к поиску сценариев управления ею, например путём выставления KPI, реорганизации процессов разработки и отслеживания динамики в производственных параметрах. И обязательно научиться контролировать влияние произведённых улучшений на объективный показатель.
— Какие метрики/группы метрик представляют наибольшую ценность для бизнеса и почему? Как повысить эффективность самих показателей?..
Продолжение читайте на https://futurebanking.ru/post/4057
