Экономический эффект продуктовых и бизнесовых задач многие считать уже научились. А вот как считать эффект для технических задач, как оказалось, умеют далеко не многие.
Зачем вообще считать эффект от технических задач?
Обычно это нужно, если тех. специалисты понимают, что команда недостаточно уделяет внимания техническому совершенству, но при этом бизнес/продакт не понимает, почему он должен тратить время команды на это.
Вообще далеко не всегда команды считают этот эффект.
В первую очередь потому, что время на подсчёт этого эффекта может быть соизмерим со временем на реализацию самой задачи.
Часто в команде просто есть договорённость, что она какой-то % времени тратит на выплату Техдолга, т.к. «технический налог». Чаще всего это 20-30%.
Но нередко с бизнесом/продактом договориться на такой налог не удаётся, либо бизнес просит посчитать какой точно % времени нужно выделять.
Вот тогда хорошим решением может быть подсчёт экономического эффекта от технических задач
Почему эффект считать нужно именно в деньгах?
Техническим специалистам и архитекторам часто сложно понять, как посчитать деньги.
В лучшем случае архитектор может сказать, насколько улучшается Uptime, снижение времени восстановления, снижается число инцидентов, но как это отражается на деньгах.
Но продакту/бизнесу чтобы понимать, насколько важна та или иная задача нужно иметь единую шкалу с бизнесовыми задачами. И единственная единая шкала, которую можно придумать – это деньги
Как считать в деньгах эффект от технических задач?
Алгоритм такой:
- Отвечаем на вопрос, зачем мы хотим сделать данную техническую задачу
- Отвечаем на вопрос, почему это важно для продукта
- Исходя из ответов на вопросы понимаем, как посчитать эффект
Из моей практики существуют следующие виды эффекта от технических задач:
- Снижаем время простоя приложения
- Снижаем затраты и/или сроки на реализацию бизнесовых задач
- Снижения багов на тестировании
- Отказ от проприетарных решений
- Выполнение требований PCI DSS, ГОСТ и др. ИТ-стандартов
Подробнее для каждого кейса
Не буду прямо в формулы, погружаться. Кому будет интересно, пишите в личку.
Расскажу принципы
1. Снижаем время простоя приложения
- Считаем, время недоступности продукта за год на текущий момент
- Прогнозируем насколько снизим это время после выполнения технической задачи
- Дальше самое интересное: считаем сколько стоит 1 минута недоступности системы
a. Для зарабатывающих приложений достаточно просто берем доходы за неделю/месяц (в зависимости от того, как часто вы считаете) и делите на число минут
b. Для внутренних продуктов нужно понять какой бизнес-процесс остановится или замедлится и понять к каким убыткам или упущенному заработку приведёт остановка этого процесса.
Тут может быть и простой зарабатывающего процесса или просто зарплата специалистов, которые не могут двигаться по процессу.
2. Снижаем затраты и/или сроки на реализацию бизнесовых задач
Здесь попроще:
- Прогнозируем насколько в среднем снизим трудозатраты на новые бизнесовые задачи
- Считаем сколько бизнесовых задач делаем за единицу времени
- Берем среднюю зарплату специалистов, реализующих задачи
- Всё перемножаем
3. Снижения багов на тестировании
Тут аналогично:
- Считаем сколько тратим времени на обнаружение и исправление багов
- Прогнозируем насколько снизим эти трудозатраты
- Берем среднюю зарплату специалистов, можно даже специфицировать QA и разработку отдельно
- Всё перемножаем
4. Отказ от проприетарных решений
Здесь, кажется, очевидно:
- считаем сколько тратим сейчас на решение в год/месяц
- Прогнозируем сколько будем тратить на поддержку собственного решения
- Вычитаем из первого второе – это и будет экономический эффект
5. Выполнение требований PCI DSS, ГОСТ и др. ИТ-стандартов
Тут тоже вполне понятно:
- Определяем какой грозит штраф за невыполнение требований.
Либо это может быть закрытие бизнеса, тогда считаем, сколько бизнес зарабатывает в единицу времени просто
Это и будет экономический эффект
Вместо заключения
Вероятно, есть, и другие кейсы, пишите, тоже их разберу.