Разговор с руководством: технические ограничения как бизнес-риски и деньги

← назад к разделу

Инженер, ставший руководителем, обычно хорошо умеет объяснить, почему база на одном сервере это плохо. И почти никогда не может ответить на вопрос финансового директора: «сколько мы потеряем и с какой вероятностью». Без ответа на него любая техническая проблема для руководства выглядит как просьба о деньгах на неопределённое улучшение.

Задача этой статьи - научиться переводить: из «реплики нет» в «риск потерять около 400 тысяч рублей выручки за три часа простоя, вероятность такая-то, защита стоит столько-то».

Чем разговор с руководством отличается от разговора с продуктомспросят на собеседовании

С продакт-овнером вы обсуждаете порядок задач, сроки и объём, это разобрано в статье про стейкхолдеров и ожидания. Разговор с первыми лицами устроен иначе по четырём параметрам.

И у каждого первого лица свой вопрос, на который надо ответить ещё до того, как он прозвучал:

• CEO (генеральный): как это влияет на клиентов, выручку и обещания рынку, и что будет, если не делать.
• CFO (финансовый): сколько стоит, разовые это деньги или постоянные, когда окупится, насколько надёжна оценка.
• CTO (технический): почему именно так, какие варианты отброшены, что это делает с архитектурой и людьми.
• Безопасность и юристы: какие требования закона или договора затронуты и что будет при нарушении.

Главное отличие: продакт-овнеру вы чаще сообщаете, а руководству приносите решение на выбор. Если в конце разговора не прозвучало «да», «нет» или «вернись с другим вариантом», разговор был напрасным.

Отчёт на одну страницуспросят на собеседовании

Руководитель прочитает первые три строки. Значит, в них должно быть всё главное, а остальное - для тех, кто захочет проверить.

Тема: отказоустойчивость базы заказов            Дата: 12.10.2026
Нужно решение: да, до 25.10, от CFO и CTO

1. Суть. База заказов работает на одном сервере. При его отказе магазин
   стоит до 6 часов и теряет заказы с момента последней копии.
2. Что на кону. Один такой отказ днём: около 300 тыс. руб. прямого ущерба
   и до суток заказов, восстанавливаемых вручную. Вероятность в год: 20-30%.
3. Варианты.
   А. Ничего не делать: 0 руб., риск остаётся.
   Б. Копии журналов каждые 15 минут и учения: 0,3 млн руб., потеря данных
      до 15 минут, простой по-прежнему до 6 часов.
   В. Реплика с автопереключением: 1,5 млн руб. + 1,1 млн руб. в год,
      простой минуты, потеря данных секунды.
4. Рекомендация: Б сейчас, В вернуть к обсуждению в бюджете следующего года.
5. Что будет, если не решить до 25.10: работы не попадут в квартал.
Приложения: расчёт ущерба, протокол последних учений восстановления.

Правила: решение и срок вверху, числа с единицами и диапазонами, не больше трёх вариантов, среди них обязательно «ничего не делать» с его ценой, рекомендация своя и явная. Технические подробности - в приложение.

Реестр рисков: вероятность, ущерб, владелецспросят на собеседовании

Риск в определении стандарта ГОСТ Р ИСО 31000-2019 (идентичен ISO 31000:2018) - это «следствие влияния неопределенности на достижение поставленных целей», и примечания к нему уточняют: риск часто выражают через последствия возможного события вместе с их вероятностью. Для руководителя разработки это переводится в таблицу, которую ведут постоянно, а не к аудиту.

Что важно в каждой колонке:

• Вероятность и ущерб в баллах удобны для сортировки, но для пяти верхних рисков стоит перейти к рублям и процентам, иначе CFO не сможет их сравнить с другими расходами.
• Владелец - конкретный человек, у которого есть полномочия действовать, а не «команда».
• План реакции выбирают из вариантов, перечисленных в том же стандарте (п. 6.5.2; для угроз, без варианта «принять или увеличить риск ради благоприятной возможности»): избежать риска, отказавшись от деятельности; устранить источник; изменить вероятность; изменить последствия; разделить с другой стороной, например договором или страховкой; осознанно удержать. Последний вариант честный, если он записан и принят тем, кто отвечает за деньги.
• Триггер - признак, по которому риск превращается в инцидент и пора действовать по плану.

Реестр пересматривают раз в месяц-квартал и показывают руководству верхние пять строк, а не всю таблицу.

Стоимость простоя: считаем на примереспросят на собеседовании

Интернет-магазин, выручка 1,2 млрд руб. в год, 80% выручки приходится на дневные часы с 8 до 20. Сервис оформления заказа лёг на 3 часа днём.

Три вещи, на которых ловят:

1. Выручка не равна убытку. CFO первым делом спросит про маржу и про тех, кто вернулся позже. Если вы принесли 657 тысяч, а честная цифра 230, доверие к следующим расчётам пропадёт.
2. Час часу рознь. Ночной час стоит в разы меньше дневного, а час в распродажу - в разы больше. Считайте по профилю нагрузки, а не по среднему.
3. Трудно считаемое отдельно. Репутация, отток, жалобы в соцсетях - отдельной строкой словами, не складывая с рублями. Иначе вся таблица выглядит как подгонка.

Исходные числа берутся у финансов и аналитики: выручка по часам, маржа, доля вернувшихся. Стоимость часа инженера запросите у финансов, а не выдумывайте. Посчитанный один раз ущерб за час становится вашей валютой для всех разговоров о надёжности, SLO и бюджете ошибок.

RPO и RTO на языке денег

Техническая сторона этих двух чисел описана в статье об отказоустойчивости и восстановлении. Для руководства их надо задавать вопросами, на которые оно может ответить.

• RPO: «заказы за какой последний промежуток вы готовы потерять или восстанавливать вручную - за сутки, час, минуту?»
• RTO: «сколько магазин может не принимать заказы - шесть часов, час, пять минут?»

Каждому ответу соответствует цена. RTO в 6 часов против 15 минут - это разница в ущербе, посчитанная выше, умноженная на вероятность отказа, против стоимости тёплого резерва. Руководство выбирает числа, вы показываете, сколько стоит каждое. Важно не путать желаемое с реальным: реальный RTO - это время последних учений восстановления, а не строчка в документе.

Бизнес-кейс для технической инициативыспросят на собеседовании

Техдолг и миграции проигрывают в борьбе за бюджет не потому, что не нужны, а потому, что их приносят как просьбу. Как посчитать проценты по долгу, разобрано в статье про технический долг, здесь - как упаковать результат.

Структура на две страницы:

1. Проблема в деньгах или риске, а не в технике.
2. Варианты, включая «ничего не делать» и его стоимость за год.
3. Затраты: разовые (люди, лицензии) и постоянные (инфраструктура, поддержка).
4. Эффект: экономия, снижение ожидаемого ущерба, новые возможности, с допущениями.
5. Срок окупаемости и чувствительность: что будет, если эффект вдвое меньше.
6. Риски самого проекта и как их ограничиваем: этапы, точки остановки.
7. Что нужно от руководства: деньги, люди, решение, срок.
8. Как измерим успех через квартал.

Пример. Выкат сервиса заказов ручной, раз в неделю ночью, три инженера по четыре часа: 52 × 12 = 624 часа в год, при 2 500 руб. за час это 1,56 млн руб. Плюс из 10 инцидентов квартала 3 случились после выката. Автоматизация: два инженера на пять недель, 50 человекодней × 20 тыс. руб. = 1 млн руб. После неё на релиз уходит полчаса одного человека: 26 часов в год, 65 тыс. руб. Экономия около 1,5 млн руб. в год, окупаемость около 8 месяцев. Если эффект окажется вдвое меньше - около 16 месяцев, всё ещё в горизонте двух бюджетов. Не деньгами: исправления днём за час вместо недели ожидания.

Решение о такой инициативе стоит записать в ADR, а через квартал вернуться с фактом: было 624 часа, стало столько-то.

Как говорить о рисках без запугиванияспросят на собеседовании

Руководство привыкло, что инженеры пугают: «всё упадёт», «нас взломают». После третьего раза без последствий такие слова перестают слышать. Работает другое.

• Вероятность и ущерб вместо прилагательных. Не «критическая уязвимость», а «при эксплуатации утечёт база клиентов, по нашей оценке вероятность в год 5-10%».
• Риск вместе с вариантом защиты и ценой. Риск без предложения звучит как жалоба.
• Признавать неопределённость. Диапазон «200-400 тысяч» честнее и убедительнее, чем «312 тысяч».
• Говорить и о том, что не страшно. «Отказ зоны у облачного провайдера мы переживём за минуты, на это деньги не нужны» добавляет веса остальным словам.
• Не продавать худший случай как ожидаемый. Худший случай называйте отдельно и с вероятностью.
• Принятый риск не пересматривать без новых данных. Если руководство осознанно его удержало, не возвращайтесь с тем же раз в неделю. Возвращайтесь, когда сработал триггер.

Комитеты и эскалацииспросят на собеседовании

На крупных проектах решения принимает управляющий комитет: заказчик, финансы, ИТ, иногда безопасность. Он собирается раз в две-четыре недели, и у вас на нём пять-десять минут.

Формат выступления: статус по вехам одной строкой, отклонения от плана с причиной, верхние риски с изменениями с прошлого раза, решения, которые нужны от комитета. Материалы рассылаются заранее, на заседании их не читают вслух, а принимают решения. После - протокол: что решили, кто отвечает, срок.

Эскалация - нормальный инструмент, а не жалоба. Правила:

• Сначала на своём уровне. Прежде чем идти наверх, попробуйте договориться напрямую и предупредите коллегу, что эскалируете.
• Порог заранее. Договоритесь, что поднимается наверх: сдвиг вехи больше чем на две недели, перерасход больше 10%, риск с оценкой выше 12.
• Приходить с вариантами. «Вот проблема, вот три выхода с ценой, рекомендую второй, нужно решение до пятницы».
• Без поиска виноватых. Эскалация про решение, а не про то, кто подвёл.
• Закрывать петлю. Сообщить всем участникам, что решили, и записать в протокол.

Типичные ошибки

• Техника вместо последствий. «У нас Postgres без реплики» вместо «магазин встанет до шести часов».
• Выручка вместо убытка. Завышенный ущерб обнаруживают на первом же вопросе финансов.
• Один вариант. Руководство не выбирает, а утверждает или отклоняет, и чаще отклоняет.
• Нет варианта «ничего не делать». Без него непонятно, от чего защищаемся.
• Реестр рисков к аудиту. Таблица, которую заполнили раз и забыли, хуже, чем никакой: она создаёт ощущение контроля.
• Владелец риска - «команда». Никто конкретно - значит, никто.
• Эскалация в последний день. Сообщить о сдвиге за день до срока - это не эскалация, а уведомление о провале.
• Обещанный эффект без проверки. Бизнес-кейс без возврата с фактом закрывает дорогу следующему.

Глубже: ISO 31000 без бюрократиирасширенное

Стандарт ГОСТ Р ИСО 31000-2019 содержит, по его собственным словам, «руководящие указания по менеджменту рисков»: это не набор обязательных требований, а описание процесса. Он утверждён приказом Росстандарта от 10.12.2019 № 1379-ст, введён с 1 марта 2020 года и заменил ГОСТ Р ИСО 31000-2010.

Процесс в нём короткий. Оценка риска состоит из трёх шагов: идентификация, анализ и сравнительная оценка (п. 6.4.1). Потом обработка: выбор и реализация вариантов, проверка их эффективности и решение, приемлем ли остаточный риск (п. 6.5.1). Процесс и его результаты документируются и отражаются в отчётности, чтобы поддерживать принятие решений (п. 6.7).

Для команды это ложится на уже знакомое: идентификация - на постмортемы и ретроспективы, анализ - на расчёт ущерба, сравнительная оценка - на сортировку реестра, обработка - на задачи в плане, отчётность - на страницу для руководства. Ссылка на стандарт на собеседовании полезна, если вы показываете, как он работает в вашей команде, а не цитируете его.

Глубже: ожидаемый ущерб и редкие катастрофырасширенное

Самый удобный способ сравнить риск с затратами - ожидаемый ущерб: вероятность за год, умноженная на ущерб. Отказ сервера с вероятностью 25% и ущербом 300 тысяч рублей даёт 75 тысяч в год, и реплика за 2,6 млн в первый год по этому расчёту не окупается. Это нормальный результат: иногда честный ответ - сделать дешёвый вариант, как вариант Б в отчёте выше.

Но для редких событий с огромным ущербом умножение врёт. Потеря всей базы клиентов с вероятностью 1% и ущербом 200 млн руб. даёт «2 млн в год», хотя такое событие может закрыть бизнес. Для таких рисков руководство решает не по среднему, а по вопросу «можем ли мы это пережить». Поэтому в реестре стоит отдельно помечать риски, ущерб от которых больше, чем компания способна выдержать: для них защита покупается как страховка, даже если среднее говорит «не окупается».

Коротко

• С руководством говорят не о технике, а о решении: варианты, цена, рекомендация, срок.
• Отчёт на одну страницу: решение и срок вверху, три варианта включая «ничего не делать», детали в приложении.
• Реестр рисков: вероятность, ущерб, конкретный владелец, план реакции и триггер; пересматривать регулярно, показывать верхние пять.
• Стоимость простоя считают от маржи, а не от выручки, по профилю часов, трудно считаемое пишут отдельно.
• RPO и RTO задают вопросами о потерянных заказах и часах простоя, каждому ответу соответствует цена.
• Бизнес-кейс: проблема в деньгах, варианты, затраты, эффект, окупаемость с чувствительностью, возврат с фактом.
• О рисках говорят числами и диапазонами, вместе с защитой, без худшего случая под видом ожидаемого.
• Эскалация по заранее оговорённым порогам, с вариантами и без поиска виноватых.

Что почитать дальше

• Стейкхолдеры: как управлять ожиданиями - регулярный статус, «нет» и спор двух заказчиков.
• Технический долг - как посчитать проценты по долгу для бизнес-кейса.
• Отказоустойчивость и восстановление - техническая сторона RPO и RTO.
• SLO и алерты - как связать надёжность с бюджетом ошибок.
• Постмортемы - откуда берутся новые строки реестра рисков.
• Метрики команды - числа для возврата с фактом.
• Стоимость облака - постоянные затраты в бизнес-кейсе.