На позиции главного архитектора я много думал над тем, как оценивать технические решения так, чтобы бизнес понимал их ценность. В этом блоге я расскажу о своем опыте и нескольких приемах, которые я применял в работе.
Какие показатели использует бизнес? Деньги. В принципе все. Практически все метрики и составляющие бизнеса можно свести к деньгам:
P.S. В этом блоге я рассказываю про метрики в деталях.
Даже процессные задачи можно сконвертировать в деньги, например, упрощение онбординга прямо отражается на времени, через которое работник начинает выполнять задачи, т.е. через ФОТ можно получить стоимость онбординга.
Перейдем к описанию вариантов оценки.
Задачи на уменьшение времени
Общий подход здесь - это выявление конкретных задач и видов работ, которые будут уменьшены по времени. Также принимается во внимание конкретная стадия работы над задачами. В разработке распространены следующие стадии:
Возьмем для примера задачу одной из моих команд: настройка анализатора кода и проверки стиля кода. Ранее было замечено, что разработчики часто спорят по поводу переносов строк, пробелов, отступов. За двухнедельный спринт разработчики переводили в code review, в среднем, 8 задач, в каждой из которых на обсуждение стиля кода уходило около 20 минут у двух разработчиков.
Получаем следующие расчеты: 8 задач x 20 минут x 2 разработчика = 320 минут. Это каждые 2 недели. Каждый месяц получаем 640 минут или ~10.5 часов.
Если взять в среднем зарплату программиста в 250 000 руб. (после вычета налогов), то получим стоимость этого времени ~15 500 руб. каждый месяц, или 187 500 руб. в год. Для реализации анализатора и обсуждения мы потратили примерно 5 часов, которые стоили нам ~7 500 руб..
Таким образом, мы имеем задачу стоимостью 7 500 руб., которая экономит нам 187 500 руб. в год.
Дополнительно стоит:
Задача на уменьшение затрат
Здесь мы экономим не время, а именно деньги, которые используется где-то еще. Например, лицензии на ПО, инфраструктура и так далее.
Пример: у компании используется много облачных серверов. Оптимизации на уровне кода могут сократить затраты на инфраструктуру на 5-10%, что в итоге может снизить косты на тысячи долларов.
Сюда же можно отнести:
Снижение рисков
На моей практике - это самая сложная вещь для оценки. Обычно я использую следующий подход:
Обычно подсчет финансового эффекта у меня занимал несколько итераций: 5-6. Повторюсь, что это было достаточно сложно.
Удовлетворение требований регуляторов
Самый яркий пример - PCI DSS, в России это может быть 152 статья ФЗ. За его неисполнение выписывают вполне понятные штрафы. Тут я обычно смотрю на прецеденты, или штрафы, которые уже были.
Невыполнение некоторых требований регуляторных органов может повлечь за собой остановку части или всей деятельности компании.
Заключение
Оценка и продажа технических задач бизнесу требуют значительных усилий и умений.
Оценивая задачи, помните:
✅Практически все можно свести к денежному эквиваленту
✅Используйте ретроспективные данные для прогноза
✅Учитывайте влияние на различные роли и стадии работы
✅Не забывайте про риски и требования регуляторов.
Таким образом, анализируя и обосновывая технические задачи, вы сможете более эффективно донести их ценность до бизнеса и получить необходимую поддержку для их реализации.
Удачи в ваших начинаниях!
Какие показатели использует бизнес? Деньги. В принципе все. Практически все метрики и составляющие бизнеса можно свести к деньгам:
- Количество времени на реализацию задач можно вывести в деньги через ФОТ (фонд оплаты труда)
- Задачи информационной безопасности можно вывести в деньги через вероятности рисков
- Требования регуляторов можно вывести в деньги через риск получения штрафа
- Количество времени на поддержку можно вывести в деньги через ФОТ.
P.S. В этом блоге я рассказываю про метрики в деталях.
Даже процессные задачи можно сконвертировать в деньги, например, упрощение онбординга прямо отражается на времени, через которое работник начинает выполнять задачи, т.е. через ФОТ можно получить стоимость онбординга.
Перейдем к описанию вариантов оценки.
Задачи на уменьшение времени
Общий подход здесь - это выявление конкретных задач и видов работ, которые будут уменьшены по времени. Также принимается во внимание конкретная стадия работы над задачами. В разработке распространены следующие стадии:
- Проработка требований
- Проработка технического решения
- Разработка
- Code Review
- Тестирование
- Релиз.
Возьмем для примера задачу одной из моих команд: настройка анализатора кода и проверки стиля кода. Ранее было замечено, что разработчики часто спорят по поводу переносов строк, пробелов, отступов. За двухнедельный спринт разработчики переводили в code review, в среднем, 8 задач, в каждой из которых на обсуждение стиля кода уходило около 20 минут у двух разработчиков.
Получаем следующие расчеты: 8 задач x 20 минут x 2 разработчика = 320 минут. Это каждые 2 недели. Каждый месяц получаем 640 минут или ~10.5 часов.
Если взять в среднем зарплату программиста в 250 000 руб. (после вычета налогов), то получим стоимость этого времени ~15 500 руб. каждый месяц, или 187 500 руб. в год. Для реализации анализатора и обсуждения мы потратили примерно 5 часов, которые стоили нам ~7 500 руб..
Таким образом, мы имеем задачу стоимостью 7 500 руб., которая экономит нам 187 500 руб. в год.
Дополнительно стоит:
- учитывать роли, на работу которых повлияет задача. Например, упрощается работа инженеров, тестировщиков, аналитиков
- учитывать стадии работы над задачей, так будет проще. Например, код ревью, программирование, тестирование
- использовать ретроспективные данные для построение прогноза.
Задача на уменьшение затрат
Здесь мы экономим не время, а именно деньги, которые используется где-то еще. Например, лицензии на ПО, инфраструктура и так далее.
Пример: у компании используется много облачных серверов. Оптимизации на уровне кода могут сократить затраты на инфраструктуру на 5-10%, что в итоге может снизить косты на тысячи долларов.
Сюда же можно отнести:
- Снижение количества трафика
- Снижение количества генерируемого трафика
- Переход на внутреннее решение вместо платного SaaS.
Снижение рисков
На моей практике - это самая сложная вещь для оценки. Обычно я использую следующий подход:
- Оценивается вероятность реализации риска посредство либо экспертной оценки (как много связанных проблем мы видим), либо исторических данных (если раньше было много подобных инцидентов, то и сейчас их вероятность высокая).
- Оценивается вероятный финансовый эффект. Самый простой способ - посмотреть, что происходит в мире. Например, штрафы за утечки данных. Обычно их существует два вида - фиксированные (когда компания выплачивает фиксированную сумму) и более жесткие - оборотные штрафы (когда компания выплачивает процент от оборота).
- Вероятный финансовый эффект умножается на вероятность риска.
Обычно подсчет финансового эффекта у меня занимал несколько итераций: 5-6. Повторюсь, что это было достаточно сложно.
Удовлетворение требований регуляторов
Самый яркий пример - PCI DSS, в России это может быть 152 статья ФЗ. За его неисполнение выписывают вполне понятные штрафы. Тут я обычно смотрю на прецеденты, или штрафы, которые уже были.
Невыполнение некоторых требований регуляторных органов может повлечь за собой остановку части или всей деятельности компании.
Заключение
Оценка и продажа технических задач бизнесу требуют значительных усилий и умений.
Оценивая задачи, помните:
✅Практически все можно свести к денежному эквиваленту
✅Используйте ретроспективные данные для прогноза
✅Учитывайте влияние на различные роли и стадии работы
✅Не забывайте про риски и требования регуляторов.
Таким образом, анализируя и обосновывая технические задачи, вы сможете более эффективно донести их ценность до бизнеса и получить необходимую поддержку для их реализации.
Удачи в ваших начинаниях!
