ИТ-команде бывает непросто получиться бюджет на свои задачи: рефакторинг, минимизацию технического долга, оптимизацию архитектуры. Лучший способ для этого — наглядно продемонстрировать бизнес-подразделению, что это принесет экономическую выгоду. Как переводить технические метрики в понятные бизнесу показатели рассказывает ведущий инженер-программист IT_ONE Дмитрий Владимиров.
Часто программисты видят свою задачу только в создании работоспособного кода и не задумываются о том, какую бизнес-ценность этот код будет нести и как этот компонент будет интегрирован в общую архитектуру системы. Бизнес же далеко не всегда понимает все технические нюансы, о которых говорит CIO. Поэтому, чтобы согласовать проект рефакторинга необходимо доказать, что он так или иначе принесет компании деньги.
Есть сценарии, по которым ИТ и бизнес могут вести продуктивный диалог. Он строится на основе двух ключевых метрик.
Первая метрика: время доставки новой функциональности
Время доставки — это период от начала разработки до появления целевой функциональности у конечных пользователей.
Эта метрика требует введения формулы: Стоимость задержки = Ожидаемая прибыль от фичи в месяц * Время задержки (в месяцах)
Допустим, продакт-менеджер или аналитик подсчитал, что новая функциональность core-системы (например, дополнительная актуальная опция для клиентов) должна приносить компании 6 млн руб в месяц.
При этом система имеет монолитную архитектуру с тесно связанным кодом. Это означает, что, модифицируя один ее компонент, необходимо тщательно отслеживать, как это отразится на остальных компонентах. Для реализации доработки требуется переписывать тесты, проходить череду согласований и т. д. На всё это, как показывает опыт, уходит не менее месяца: примерно 3 недели на реализацию, и 1 неделя на развертывание. Значит, бизнес потеряет как минимум 6 млн рублей, не запустив новую фичу за месяц.
Если же перевести систему на микросервисы, то для доработки отдельного компонента потребуется гораздо меньше кодирования и стандартные тесты (регрессионное, ручное тестирование). Всё это можно сделать за 4 дня: 3 дня тратится на реализацию, 1 день на развертывание. То есть в первый же месяц новая функциональность начнет приносить прибыль.
Далее рассматриваем окупаемость. Для перевода системы на микросервисную архитектуру потребуется ФОТ в 1 млн рублей и срок 3 месяца — то есть общие затраты составят 3 млн рублей. Благодаря микросервисам бизнес сможет реализовать функциональность за считаные дни вместо месяца и заработать 6 млн рублей. Таким образом, окупаемость проекта составит всего две недели, после чего новые возможности будут гарантированно приносить компании постоянный профит.
Важно отметить, что монолит далеко не всегда заведомо проигрывает микросервисам в эффективности.
Вторая метрика: стоимость доработок
Стоимость будущих доработок базово рассчитывается по следующей формуле: Стоимость доработок = Дневная ставка команды * Дни на изменения * Частота изменений в год
При планировании деятельности ИТ-команды стоит учитывать несколько факторов, влияющих на особенности доработок. Во-первых, уже упомянутую связность компонентов — она может быть как сильная, так и слабая. Бывает, что исправление в одном компоненте провоцирует изменения по всему проекту.
Во-вторых, потребности бизнеса, который традиционно хочет, чтобы доработки были сделаны «уже вчера». В случае не оптимизированного приложения это приводит к накоплению технического долга и, как следствие, — к увеличению времени на реализацию новой функциональности. Например, сегодня по настоянию руководства ИТ-подразделение решило проблему за 3 дня, но с помощью грубых «костылей». Через полгода эта проблема может повториться, и тогда для ее решения может потребоваться уже 10 дней.
Допустим, такие доработки обходятся компании в 50 тыс рублей и проводятся регулярно — 20 раз в год. Тогда их стоимость будет 50 тыс * 20 раз * 10 дней = 10 млн руб.
Это хороший повод для CIO сказать бизнесу: можно оптимизировать приложение, вынести логику, интерфейсы в отдельные модули, смоделировать слабое связывание. На это потребуется две недели и 3 млн рублей, но тогда мы сможем выпускать любые обновления не за 10 дней, а за 3.
Каждый проект будет стоить 50 тыс * 20 раз * 4 дня = 4 млн рублей. То есть, по сравнению с предыдущими расчетами, в год компания сэкономит 6 млн рублей.
Реальность сложнее. Чек-лист
На практике приведенные формулы чаще всего обрастают дополнительными параметрами и сопровождаются различными нюансами. Например:
- при рисках высокой инфляции в долгосрочный проект закладывается стоимость денег;
- новая функциональность может быть направлена не на рост прибыли, а на обеспечение соответствия ПО законодательным требованиям — в этом случае деньги можно искать в минимизации рисков штрафных санкций;
- если жизненный цикл проекта исчисляется месяцами, а не годами, апеллировать к росту годовой выручки как к основанию для проведения рефакторинга не получится — нужно искать другие аргументы.
Поэтому, чтобы оценить позицию ИТ в диалоге с бизнесом в той или иной ситуации, мы рекомендуем каждый раз честно ответить себе на 4 вопроса:
- Как решение о рефакторинге повлияет на время доставки следующих 10 фич?
- Какова через год будет стоимость сопровождения компонента, который сейчас поддерживается с помощью «костылей»?
- Что мы теряем, если не сделаем правильно сейчас? В ответе можно учитывать слабые места как для ИТ (много ручной работы, излишние трудозатраты), так и для бизнеса (увеличивается срок поддержки, теряются деньги).
- Есть ли способ благодаря рефакторингу достичь 80% желаемого результата за 50% времени? Зачастую это выгодная сделка с точки зрения бизнеса: компания получит только 80% выручки, но зато намного быстрее.
Успешное взаимодействие ИТ с бизнесом требует:
- перевода технических метрик в экономические показатели;
- четкого понимания влияния архитектурных решений на бизнес-процессы;
- способности обосновывать необходимость технических изменений с точки зрения экономической эффективности;
- поиска компромиссов между скоростью разработки и качеством решений.
Рефакторинг и оптимизация архитектуры должны преподноситься бизнесу как инвестиции, приносящие конкретную экономическую выгоду в среднесрочной перспективе.
Источник: Дмитрий Владимиров, ведущий инженер-программист IT_ONE
