Как объяснить совету директоров технический риск после того, как вы его нашли

Как выглядит проблема сейчас

Большая часть скрытого технического риска снаружи выглядит нормально. Продукт всё ещё работает. Клиенты по-прежнему входят в систему. Команда продолжает выпускать изменения. А потом кто-то смотрит внимательнее и находит одно слабое место, которое может отказать при обычном росте или во время рядового релиза.

Совету директоров не нужен обзор кодовой базы. Ему нужна одна простая вводная фраза, которая скажет, что вы нашли, где это находится и почему это важно. Например: «Мы обнаружили, что наш сервис биллинга зависит от устаревшего компонента, который сбо́ит под нагрузкой, и это ставит под риск создание счетов и повторные попытки оплаты».

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

Вам также нужно сказать, что произойдёт, если в этом квартале ничего не менять. Говорите об этом прямо. Если подождать, риск останется в продакшене ещё на один цикл релизов. Команда будет тратить больше времени на заплатки. Небольшие инциденты будут накапливаться. Одна плохая неделя может заставить инженеров остановить запланированную работу и снова чинить тот же участок.

Факты и предположения

Не смешивайте доказательства с прогнозами. Совет директоров лучше реагирует, когда вы отделяете то, что знаете, от того, что лишь предполагаете.

Факты можно измерить. На пике трафика вырос уровень ошибок. Два недавних инцидента пришли из одного и того же сервиса. Один из компонентов больше не поддерживается. Только один-два инженера по-настоящему понимают, как это исправить.

Предположения должны звучать как предположения. Можно сказать, что проблема, скорее всего, будет возникать чаще по мере роста использования, или что следующий крупный релиз может повысить вероятность отказа. Это нормально. Но говорить без доказательств, что «клиенты уйдут массово», — нет.

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

Начните с влияния на клиентов

Совет директоров быстрее принимает решения, когда риск выглядит реальным для клиентов, а не абстрактным для инженеров. Пропустите названия стеков, логи ошибок и внутренние ярлыки. Скажите, что ломается, кто это чувствует и как часто это происходит.

Начните с количества. Оцените, на сколько пользователей, аккаунтов, заказов или транзакций слабое место может повлиять в обычную неделю или месяц. Подойдёт и грубый диапазон, если вы скажете это прямо. «Около 12 000 клиентских аккаунтов зависят от этого процесса каждый месяц» воспринимается гораздо легче, чем «в конвейере событий есть проблема с согласованностью состояния».

Затем опишите сбой простыми словами. Новые клиенты могут застревать при регистрации в часы пик. Действующие клиенты могут видеть поздние или неверные данные по аккаунту. Заказы могут проходить дважды или не проходить вовсе. Сотрудникам поддержки может приходиться исправлять аккаунты вручную.

Это даёт совету директоров что-то конкретное. Им не нужно знать, сидит ли проблема в очереди, базе данных или старом сервисе, если только они не спросят. Им нужно понимать, что видит клиент на экране, в счёте или в сроках доставки.

Доверие обычно падает раньше, чем выручка. Если клиенты видят неверные балансы, пропавшие обновления или неудачные продления, они начинают перепроверять ваш продукт. Кто-то перестаёт пользоваться самообслуживанием и обращается в поддержку. Кто-то откладывает расширение. А некоторые уходят уже после одной плохой недели, если проблема бьёт по ключевому сценарию.

Используйте простую причинно-следственную связь. «Если это сломается на пике трафика, примерно 8% новых регистраций могут не завершиться. Это значит больше обращений в поддержку, медленнее активация и больше отказов на пробном периоде». Это звучит убедительнее, чем длинное резюме, набитое техническими терминами.

Начните с боли, которую люди могут представить. Как только совет директоров увидит влияние на доверие, отток и нагрузку на поддержку, дальше разговор станет проще.

Поставьте цифры на денежные потери

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

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

Используйте простые числа. Если в прошлом месяце команда увидела 40 неудачных платежей, а средняя месячная выручка на аккаунт составляет 500 долларов, это уже хорошая отправная точка. Если поддержка обработала 120 дополнительных обращений и на каждое уходит 20 минут, переведите это в стоимость оплаты труда. Если три инженера два дня латали старый сервис, оцените и эти часы. Совету директоров не нужен идеальный учёт. Ему нужна честная картина того, сколько проблема стоит сейчас.

Покажите два сценария, а не один. Лучший сценарий может звучать так: «Если проблема останется на текущем уровне, мы теряем около 18 000 долларов в месяц». Вероятный сценарий: «Если объём вырастет, а частота сбоев останется прежней, потери ближе к 35 000». Такой диапазон делает разговор честнее и помогает не звучать театрально.

Каждая цифра должна иметь источник в ваших заметках или комментариях к слайдам. Используйте отчёты биллинга для возвратов и кредитов. Используйте данные CRM или финансов для потерянных сделок и оттока. Используйте данные системы поддержки для объёма обращений. Используйте записи спринтов, тайм-логи или оценки менеджеров для времени инженеров. Если одна цифра — оценка, скажите об этом.

Не забывайте об упущенной выгоде. Если senior-инженеры тратят 30% недели на поддержку старой системы, они не строят следующий релиз. Эта задержка тоже сжигает деньги, даже если она никогда не попадёт в счёт.

Покажите варианты исправления

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

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

Частичная переработка подходит, когда один слой вызывает большую часть простоев, задержек или проблем безопасности. Она дороже заплатки, но намного дешевле полной замены всего. Она занимает больше времени, зато объём обычно легче удержать под контролем. И она даёт лучший долгосрочный результат, потому что вы убираете сломанный участок, а не закрываете его сверху. Ожидайте более заметную паузу в работе над roadmap, часто на один цикл релиза.

Полная замена звучит красиво, но чаще всего её сложнее всего управлять. Она имеет смысл, когда вся система блокирует рост или когда каждая починка вскрывает ещё одну скрытую проблему. Она же стоит больше всего и занимает больше всего времени. Риск здесь не только технический. Долгая замена выматывает фокус, задерживает продуктовую работу и утомляет совет директоров. На практике команде может понадобиться почти полностью заморозить работу над новыми функциями на месяцы.

Если нужен короткий итог, оставьте его простым:

• Заплатка: низкая стоимость, короткие сроки, самая высокая вероятность, что проблема вернётся.
• Частичная переработка: средняя стоимость, средние сроки, ниже долгосрочный риск.
• Полная замена: самая высокая стоимость, самые длинные сроки, самый большой риск для поставки во время проекта.

Затем сделайте рекомендацию. Не ставьте перед советом директоров три равных варианта и не ждите, что они сами выберут. Выберите один путь и объясните, почему он лучше защищает клиентов и деньги, чем остальные.

Большинству команд не стоит сразу идти в полную замену. Частичная переработка часто оказывается лучшим первым шагом, потому что она убирает самый опасный участок, не останавливая всю компанию. Скажите это прямо: «Я рекомендую частичную переработку системы биллинга. Это займёт 12 недель, сдвинет две менее приоритетные функции и снизит риск инцидентов гораздо сильнее, чем заплатка».

Соберите первый апдейт для совета директоров шаг за шагом

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

Хорошо работает простой порядок. Откройте с бизнес-проблемы простыми словами и скажите, что произойдёт, если ничего не менять: медленнее релизы, больше простоев, невыполненные обязательства перед клиентами, растущая нагрузка на поддержку или задержка продаж. Затем поставьте цифры на влияние. Оцените денежные потери, потерянное время команды, риск возвратов, недополученную выручку или дополнительные затраты на инфраструктуру. После этого объясните причину в одном коротком абзаце. Назовите систему, слабое место и почему команда заметила это именно сейчас. Затем покажите варианты исправления рядом. Закончите одним решением: утвердить бюджет, штат, сроки или объём работ.

Порядок важен. Если начать с архитектурных схем, директора либо перестанут слушать, либо сразу перейдут к вопросу стоимости. Ставьте цифры раньше, а технические детали используйте только как поддержку.

Репетиция важнее, чем внешняя полировка. Потренируйте короткие ответы на вопросы, которые вам почти наверняка зададут: Почему вы не увидели это раньше? Что будет, если мы подождём квартал? Сколько будет стоить исправление? Что сдвинется, пока команда этим занимается?

Именно такой подход Олег Сотников часто использует в работе Fractional CTO в oleg.is: свести запутанную инженерную проблему к одной записке для принятия решения с понятным компромиссом. Если после встречи совет директоров сможет повторить ваше сообщение одной фразой, значит, апдейт сработал.

Простой пример для растущей софтверной компании

Софтверная компания растёт с 300 клиентов до 6 000 за 18 месяцев. Её сервис биллинга всё ещё работает по тому же процессу закрытия месяца, который использовался в первые дни. Теперь система замедляется настолько, что задания на выставление счетов перетекают в следующее утро.

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

Внутри бизнеса люди закрывают дыру вручную. Поддержка тратит два дня на ответы на злые обращения. Финансы сверяют платежи построчно и оформляют возвраты. Инженеры каждый месяц останавливают запланированную работу, чтобы следить за биллингом и разгребать последствия. Если четыре инженера теряют по три дня в месяц, а поддержка и финансы добавляют ещё 70 часов, компания может сжигать десятки тысяч долларов каждый квартал на проблему, которая снова и снова возвращается.

Разговор с советом директоров становится гораздо яснее, когда проблему показывают в цифрах, которыми люди могут пользоваться. Около 12% счетов уходят с задержкой в конце месяца. Двойные списания затрагивают 0,4% платежей. Поступление денег сдвигается на три дня примерно по четверти ежемесячных биллингов. Поддержка, финансы и инженерия теряют около 120 часов в месяц, чиня одно и то же.

Это меняет тон встречи. Совет директоров уже не слышит: «у нас грязный код биллинга». Он слышит, что клиенты теряют доверие, деньги приходят позже, чем ожидалось, а рабочее время сотрудников снова и снова уходит на ручной ремонт.

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

Совет директоров финансирует поэтапное исправление, потому что оно снижает вред для клиентов уже сейчас, уменьшает денежные потери и не заставляет останавливать весь продукт.

Ошибки, которые ослабляют разговор

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

Используйте бизнес-язык. «Наш конвейер событий теряет заказы на пике трафика» — понятно. «У нас проблемы со связностью в ingestion layer» — нет. Первая формулировка сразу объясняет совету директоров, почему проблема важна.

Ещё одна частая ошибка — просить бюджет так, будто ответ может быть только один. Разговор слабеет, когда команда говорит: «Нам нужно 600 000 долларов, чтобы это переписать», — и на этом останавливается. Давайте варианты. Покажите маленькое исправление, более безопасный средний путь и большой перезапуск. Укажите стоимость, ожидаемый эффект и то, что каждый вариант не решает.

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

Команды также запутывают разговор, когда смешивают срочную работу и необязательную. Если растёт число сбоев платежей, не объединяйте это исправление с редизайном дашборда, обновлением инструментов и миграцией, которую команда просто предпочитает. Разделяйте работу, которая защищает выручку сейчас, и работу, которая улучшает жизнь позже.

Неопределённость — не враг. Скрытая неопределённость — враг. Совет директоров обычно лучше реагирует, когда руководители чётко обозначают границы того, чего они не знают. Можно сказать: мы знаем частоту отказов, знаем затронутую группу клиентов, пока не знаем, причина в одном сервисе или в трёх, и нам нужно две недели, чтобы это подтвердить. Такая честность сильнее, чем ложная точность.

Быстрые проверки перед встречей

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

Начните с финансов. Если вы собираетесь сказать, что риск стоит 60 000 долларов в месяц, финансы должны согласиться с расчётом и источником. Проверьте выручку под риском, возвраты, расходы на подрядчиков, сверхурочные и любую задержку запуска, которая отодвигает деньги. Одна шаткая цифра может заставить весь кейс выглядеть больше, чем он есть.

Затем поговорите с поддержкой. Спросите, что клиенты действительно сообщают своими словами. Вам нужны повторяющиеся боли, а не внутренние ярлыки. «Импорт ломается после больших загрузок» сильнее, чем «нестабильность очереди». «Наша команда вынуждена запускать отчёты заново каждый понедельник» сильнее, чем «деградация batch job».

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

Сформулируйте нужное вам решение совета директоров одной фразой. Говорите прямо. Например: утвердить шесть недель на исправление и сдвинуть дату одного запуска. Если вам нужен бюджет, скажите сколько. Если вам нужно время, скажите сколько. Если вам нужно и то и другое, скажите, что важнее.

Также приходите с запасным вариантом. Если совет директоров не согласует полный план исправления, у вас всё равно должен быть более маленький шаг, который снизит риск. Это может быть более узкий объём работ, временный контроль вокруг рискованной зоны или более медленный график релизов, пока команда не починит слабое место.

Соберите всё это на одной странице до встречи. Если финансы, поддержка и инженерия узнают в этой картине свою реальность, разговор останется на твёрдой почве.

Что делать после встречи

Хорошая встреча с советом директоров заканчивается меньшей неопределённостью, а не большей. В течение дня отправьте короткое письменное резюме, в котором будет сказано, что совет выбрал, что он не выбрал и что команда сделает первым делом.

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

Затем превратите решение в конкретных владельцев и даты. Решение совета без ясной ответственности превращается в размывание, а размывание дорого обходится, когда проблема уже касается клиентов.

Короткого списка дальнейших шагов достаточно:

• один ответственный за план исправления
• одна дата первого видимого результата
• одна еженедельная метрика по влиянию на клиентов
• одна еженедельная метрика по денежным потерям
• один триггер, когда план нужно усиливать

Отслеживайте эти цифры каждую неделю, даже если сначала они грубые. Влияние на клиентов может означать обращения в поддержку, неудачные задания, риск оттока, потерянные сделки или время, которое клиенты тратят на обходные решения. Денежные потери могут означать дополнительные часы инженеров, срочных подрядчиков, перерасход облака, возвраты или задержки по пунктам roadmap, которые приносят выручку.

Такой еженедельный обзор важнее, чем вылизанный месячный отчёт. Если число затронутых клиентов снижается, а потери денег растут, у вас может быть проблема с ресурсами. Если потери выглядят небольшими, а боль поддержки продолжает расти, значит, объём исправления слишком узкий.

Если план сдвигается, сообщайте плохие новости рано. Не ждите следующей встречи с советом директоров и не надейтесь, что команда догонит. Короткая записка «контрольная точка сорвана, причина найдена, предложена новая дата» воспринимается гораздо легче, чем сюрприз после четырёх потерянных недель.

Многие команды спотыкаются здесь, потому что путают прогресс с усилиями. «Мы много над этим работали» — не очень полезный апдейт. «Число инцидентов снизилось с 14 до 5, но работа по миграции опаздывает на две недели, потому что покрытие тестами оказалось слабее, чем ожидалось» — это уже полезно.

Если выбор всё ещё кажется запутанным, внешний CTO может помочь проверить варианты исправления, оценить, реалистичны ли стоимость и сроки, и сформулировать следующий разговор с советом директоров простыми бизнес-словами. Именно такую работу Олег Сотников делает в oleg.is, и обычно это дешевле, чем ещё один квартал идти по неверному пути.