Помню свой первый серьёзный разговор с финансовым директором. Я пришёл с красивой презентацией про микросервисы, кэширование и покрытие тестами, говорил минут двадцать и был искренне собой горд. В ответ услышал короткое: «И сколько нам это сэкономит?» Ответить цифрой я не смог. Бюджет мы тогда не получили, а задачу отложили на полгода.
С тех пор я вывел для себя простое правило: бизнес не покупает технологии, бизнес покупает результат в рублях, часах или снижении рисков. Пока ты говоришь на языке стека, ты для него просто дорогой человек с ноутбуком. Как только ты переводишь задачу на язык денег, разговор мгновенно становится предметным.
И это не маркетинг и не обман, а честная арифметика. Технический долг звучит абстрактно, а «команда тратит двенадцать часов в месяц на ручные правки в биллинге, это около шестидесяти тысяч в год» — уже конкретика. Медленные релизы — не проблема инженера, а «фича лежит в очереди три недели, и мы недобираем выручку». Плохая архитектура — не эстетика, а «каждый инцидент стоит нам четыре часа простоя и ушедших клиентов».
Пример из практики. У нас была старая интеграция с платёжным провайдером, которая падала примерно раз в месяц. Инженеры три года просили её переписать и три года слышали «потом». Я собрал статистику: сколько инцидентов, сколько часов простоя, сколько обращений в поддержку, сколько клиентов ушло. Получилось около полутора миллионов потерь в год против четырёхсот тысяч на переписывание. Разговор занял пятнадцать минут, деньги выделили уже на следующий спринт.
Как считать. Первым делом иду в логи, тикеты и отчёты поддержки — там почти всегда уже лежат нужные цифры, их надо просто вытащить. Дальше считаю два числа: стоимость бездействия и стоимость решения. Потом даю три сценария — пессимистичный, реалистичный и оптимистичный, и всегда опираюсь на реалистичный, чтобы не выглядеть продавцом волшебных таблеток. И обязательно называю срок окупаемости: «вложения вернутся за семь месяцев, дальше это чистая экономия».
Есть и вторая часть — как это подать. Здесь работает одна страница текста вместо тридцати слайдов. Первая строка — проблема в деньгах, вторая — что предлагаю, третья — сколько стоит, четвёртая — что будет, если не делать. Никакого жаргона, никаких «надо переписать монолит», только «мы теряем вот столько и можем перестать терять». А если решение большое, просите не весь бюджет, а деньги на маленький пилот с измеримым результатом: после успешного пилота вам поверят в разы быстрее.
Что советую тем, кто узнаёт себя в этом тексте. Ведите учёт потерь постоянно, а не за день до защиты бюджета. Заводите привычку переводить любую техническую хотелку в деньги ещё до встречи с руководителем. Договаривайтесь с поддержкой и аналитикой, чтобы они делились цифрами. И не приходите с одной цифрой без источника — вопрос «откуда данные?» убивает лучшие инициативы. Помните, что отказ тоже результат: иногда он значит, что вы неверно посчитали, а иногда — что задача действительно не стоит своих денег.
А теперь вопрос к вам, друзья. Какой ваш самый удачный аргумент помог выбить бюджет на техническую задачу — что именно перевело разговор из плоскости «интересно» в плоскость «выделяем деньги»? Делитесь историями, вместе мы соберём отличную шпаргалку для всех, кому предстоит такой разговор.
С тех пор я вывел для себя простое правило: бизнес не покупает технологии, бизнес покупает результат в рублях, часах или снижении рисков. Пока ты говоришь на языке стека, ты для него просто дорогой человек с ноутбуком. Как только ты переводишь задачу на язык денег, разговор мгновенно становится предметным.
И это не маркетинг и не обман, а честная арифметика. Технический долг звучит абстрактно, а «команда тратит двенадцать часов в месяц на ручные правки в биллинге, это около шестидесяти тысяч в год» — уже конкретика. Медленные релизы — не проблема инженера, а «фича лежит в очереди три недели, и мы недобираем выручку». Плохая архитектура — не эстетика, а «каждый инцидент стоит нам четыре часа простоя и ушедших клиентов».
Пример из практики. У нас была старая интеграция с платёжным провайдером, которая падала примерно раз в месяц. Инженеры три года просили её переписать и три года слышали «потом». Я собрал статистику: сколько инцидентов, сколько часов простоя, сколько обращений в поддержку, сколько клиентов ушло. Получилось около полутора миллионов потерь в год против четырёхсот тысяч на переписывание. Разговор занял пятнадцать минут, деньги выделили уже на следующий спринт.
Как считать. Первым делом иду в логи, тикеты и отчёты поддержки — там почти всегда уже лежат нужные цифры, их надо просто вытащить. Дальше считаю два числа: стоимость бездействия и стоимость решения. Потом даю три сценария — пессимистичный, реалистичный и оптимистичный, и всегда опираюсь на реалистичный, чтобы не выглядеть продавцом волшебных таблеток. И обязательно называю срок окупаемости: «вложения вернутся за семь месяцев, дальше это чистая экономия».
Есть и вторая часть — как это подать. Здесь работает одна страница текста вместо тридцати слайдов. Первая строка — проблема в деньгах, вторая — что предлагаю, третья — сколько стоит, четвёртая — что будет, если не делать. Никакого жаргона, никаких «надо переписать монолит», только «мы теряем вот столько и можем перестать терять». А если решение большое, просите не весь бюджет, а деньги на маленький пилот с измеримым результатом: после успешного пилота вам поверят в разы быстрее.
Что советую тем, кто узнаёт себя в этом тексте. Ведите учёт потерь постоянно, а не за день до защиты бюджета. Заводите привычку переводить любую техническую хотелку в деньги ещё до встречи с руководителем. Договаривайтесь с поддержкой и аналитикой, чтобы они делились цифрами. И не приходите с одной цифрой без источника — вопрос «откуда данные?» убивает лучшие инициативы. Помните, что отказ тоже результат: иногда он значит, что вы неверно посчитали, а иногда — что задача действительно не стоит своих денег.
А теперь вопрос к вам, друзья. Какой ваш самый удачный аргумент помог выбить бюджет на техническую задачу — что именно перевело разговор из плоскости «интересно» в плоскость «выделяем деньги»? Делитесь историями, вместе мы соберём отличную шпаргалку для всех, кому предстоит такой разговор.