Бюджет на поддержку ПО, который основатели смогут отстаивать вместе с командой

Почему на бумаге всё инженерное время выглядит одинаково

В бюджете инженерия часто выглядит как одна цифра. Это аккуратно, но скрывает очень разные задачи.

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

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

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

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

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

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

Это не решит все споры по планированию, но обычно снижает градус. Люди перестают спорить о загадочном числе и начинают обсуждать реальные выборы.

Три корзины, которые делают бюджет понятным

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

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

• Keep the lights on (поддержание работы): работа, сохраняющая текущее приложение пригодным для использования сегодня. Подумайте о тикетах поддержки, исправлениях багов, плановых обновлениях, реагировании на инциденты, сломанных интеграциях и срочных проблемах с производительностью.
• Roadmap (дорожная карта): работа, добавляющая новые возможности. Сюда входят запланированные фичи, продуктовые гипотезы и запросы клиентов, которые вы решили реализовать.
• Risk reduction (снижение риска): работа, уменьшающая вероятность будущих аварий, проблем с безопасностью или дорогостоящей переделки. Это патчи, проверки резервных копий, покрытие тестами, исправления мониторинга, ревью прав доступа и уборка в хрупких частях кода.

Тест прост: если пользователи испытывают боль сейчас — это keep-the-lights-on. Если работа добавляет что-то новое — это roadmap. Если она снижает будущий риск — это risk reduction.

Такое разделение исправляет распространённую ошибку. Команды часто прячут исправления безопасности и уборку внутри общего обслуживания, а потом удивляются, почему поставка фич кажется медленной и непредсказуемой. Risk reduction — это другая работа с другой целью. Она нуждается в собственной строке.

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

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

Что относится к keep-the-lights-on

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

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

То же самое для регулярной поддержки, которую пользователи могут и не заметить. Команды тратят время на обновления пакетов, патчи серверов, обслуживание баз данных, продление SSL, проверку расходов в облаке и изменения у вендоров из‑за обновления API или цен. Вы, возможно, никогда не будете рекламировать эту работу. Но за неё платят.

Работа поддержки тоже считается, когда она поддерживает доход. Если продажам нужна помощь с настройкой пробного доступа для важного клиента или customer success просит инженера исправить сломанный импорт для существующего аккаунта — это часть поддержания бизнеса. Основатели часто называют это «быстрой помощью» и потом удивляются, куда ушла неделя.

Не забывайте on‑call. Кто‑то следит за алертами, проверяет логи, отвечает на срочные сообщения и находится рядом после релизов на случай проблем. Даже если ничего не сломалось, это время имеет стоимость, потому что инженер не может использовать его с полной концентрацией на дорожной карте.

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

Обычно это включает:

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

Как только вы честно учтёте эти часы, планирование станет менее эмоциональным. Фича не «сдвинулась», потому что инженеры работали медленно. Часть недели ушла на работу, необходимую компании для того, чтобы вообще продолжать выпускать продукт.

Дорожная карта нуждается в строгих правилах

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

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

Если никто не может назвать цель, пункт всё ещё идея, а не часть дорожной карты. Это звучит резко, но экономит команде недели на вещах, которые пользователи не просили.

Небольшие оценки лучше крупных планов

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

Возьмём экран отчетности для SaaS. Вместо одной оценки в восемь недель, разделите на быстрый прототип для внутренней проверки, базовую версию для нескольких клиентов и второй проход только в случае реального использования.

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

Не прячьте работу по поддержке внутри оценок дорожной карты. Если команде нужны обновления зависимостей, уборка тестов или работа с базой данных, чтобы выпустить новый экран, честно пометьте это. Продуктовая работа — в roadmap. Уход за продуктом — в keep‑the‑lights‑on или risk reduction.

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

Risk reduction всё ещё нуждается в строке бюджета

Risk reduction редко выпускает фичу, поэтому основатели часто режут её первыми. Это ошибка. Если вы откладываете её «на потом», она обычно не произойдёт, пока что‑то не сломается.

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

Типичные примеры:

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

Команды часто прячут такую работу в общем обслуживании. Это портит планирование. Исправление бага после каждого релиза — не случайная поддержка, если один и тот же модуль постоянно падает. Это проблема риска, и бюджет должен отражать это.

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

Оцените цену задержки

Основатели легко отстаивают дорожную карту, потому что могут показать доход. Risk reduction нуждается в таком же простом языке.

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

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

• Что ломается достаточно часто, чтобы тратить время каждый месяц?
• Какая задача по безопасности или доступу уже просрочена?
• Сколько времени заняло бы восстановление, если бы сегодня упала главная база данных?
• Какое слабое место может заблокировать сделку или продление?

Даже компактная команда должна резервировать время на эту работу в каждом цикле. Oleg Sotnikov на oleg.is годами управляет продакшен‑системами в небольших командах, и урок прост: высокая доступность приходит от плановой профилактики, а не от геройских подвигов.

Как построить разделение

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

Затем отсортируйте каждую запись по трём корзинам. Держите правила простыми. Если работа поддерживала продукт, исправляла баги, обрабатывала поддержку, обновляла зависимости или устраняла мелкие поломки — это keep‑the‑lights‑on. Если она выпустила что‑то, что заметно пользователям — это roadmap. Если она снизила шанс будущего сбоя или пробела в безопасности — это risk reduction.

Когда люди не согласны, спросите, зачем команда делала эту работу. Причина обычно делает корзину очевидной.

Теперь просуммируйте стоимость каждой корзины. Учитывайте внутренние часы, работу подрядчиков и регулярные инструменты, которые в основном обслуживают одну корзину. Ошибки, трекинг ошибок, мониторинг, резервные копии и затраты на дежурство часто относятся к keep‑the‑lights‑on. Одноразовый аудит безопасности может относиться к risk reduction. Если инструмент служит всем, распределите его стоимость так, чтобы команда могла объяснить это одним предложением.

После этого выберите целевое соотношение на следующий квартал. Не гоняйтесь за идеальным процентом. Выберите то, что соответствует стадии компании. Небольшой SaaS с платящими пользователями может уложиться примерно в 50% дорожной карты, 30% поддержания и 20% снижения риска. Нестабильный продукт с частыми инцидентами может нуждаться в другом соотношении на пару кварталов.

Три вопроса сохраняют честность:

• Скушала ли скрытая поддержка больше времени, чем планировалось?
• Отложили ли команду уборку или задачи по безопасности, которые теперь выглядят рискованно?
• Сдвинулась ли дорожная карта, потому что поддержание мешало работе?

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

Реальный пример из небольшой SaaS‑команды

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

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

Затем появляется внешняя проблема. Вендор меняет auth‑flow и лимиты запросов в API, и продукт начинает падать у части пользователей. Никто не просил эту работу, но командe всё равно нужно её сделать. Такое время — это keep‑the‑lights‑on. Если основатель запишет это как доставку фич, дорожная карта будет выглядеть медленной по неверной причине. Если проигнорировать — бюджет окажется нереалистично маленьким.

Чистое месячное распределение может выглядеть так:

• 45% — keep‑the‑lights‑on: исправления поддержки, регрессии, уборка после релиза и изменения по вендорам
• 35% — roadmap: уже утверждённая работа
• 20% — risk reduction: тесты, патчи безопасности, мониторинг и уборка в уязвимых местах

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

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

Ошибки, которые делают бюджет трудно защищаемым

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

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

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

Изменения у вендоров создают иной разрыв между планом и реальностью. Платёжные сервисы меняют API. Облачные провайдеры снимают сервисы. Apple и Google меняют правила магазинов. Если ваш бюджет игнорирует внешние изменения, он будет выглядеть аккуратно на одной встрече и нереалистично в следующем месяце.

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

Один огромный строчный пункт тоже создаёт проблемы. Если в бюджете только «engineering support» или «platform work», никто не сможет задать полезные вопросы. Нельзя понять, идут ли деньги на uptime, уборку долга, предотвращение инцидентов или исправление продукта. Вот так начинаются плохие споры. Каждый представляет за той же цифрой свою историю.

Чистый бюджет избегает всего этого, делая несколько простых вещей правильно:

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

Когда команда делает это, ревью становятся менее эмоциональными. Разговор меняется с «почему инженерия такая дорогая?» на «какая работа поддерживает клиентов, какая растит продукт, а какая снижает риски?»

Быстрая проверка перед планёркой

Бюджет легче защищать, когда каждый может объяснить его простыми словами. Если финансы, инженерия и основатель используют разные метки для одной и той же работы, встреча превращается в спор мнений, а не обсуждение денег.

Начните с корзин. У каждой должна быть одно‑предложная дефиниция, которую нетехничный человек сможет повторить без помощи. Keep‑the‑lights‑on поддерживает текущий продукт. Roadmap выпускает что‑то новое для пользователей. Risk reduction снижает вероятность будущих аварий, проблем с безопасностью или дорогостоящих замедлений.

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

Простой тест помогает:

• Если работа исправляет или поддерживает сегодняшний продукт — считайте её keep‑the‑lights‑on.
• Если работа выпускает что‑то новое для пользователей — считайте её roadmap.
• Если работа снижает риск будущих сбоев или проблем с безопасностью — считайте её risk reduction.
• Если никто не может быстро классифицировать задачу — перепишите её перед встречей.

Оставьте место для реальности. Команды всегда тратят время на срочные исправления, доработки поддержки и уборку после релиза. Если план использует 100% инженерного времени на бумаге — он уже неверен.

Бюджетная таблица должна показывать два вида сразу: часы и деньги. Часы помогают инженерии обсуждать ёмкость. Деньги помогают основателям и финансам сопоставлять расходы с выручкой, runway и планами по найму. Нужны оба вида.

Ещё одна важная проверка: может ли инженерия показать, куда ушло время в прошлом квартале? Даже грубое распределение лучше, чем догадки. Если команда планировала 20% на поддержку, а потратила 38% — этот разрыв многое расскажет. Возможно, продукт требует уборки. Возможно, выросла нагрузка поддержки. Возможно, оценка дорожной карты была слишком оптимистичной.

Небольшой пример всё проясняет. Исправление ошибки в платёже — keep‑the‑lights‑on. Дополнительный мониторинг вокруг упавших платежей — risk reduction. Новый экран выставления счётов — roadmap. Положите все три в одну кучу — разговор быстро станет мутным. Разделите — и бюджет защищать легче.

Что делать дальше

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

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

Держите заметку короткой:

1. Напишите текущее распределение по keep‑the‑lights‑on, roadmap и risk reduction.
2. Добавьте реальные примеры за последний месяц.
3. Отметьте необычные вещи, например крупную миграцию или проблему с надёжностью.
4. Назначьте дату следующего обзора.

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

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

Это хороший момент для стороннего обзора. Fractional CTO обычно быстро видит, где работа по сопровождению прячется в оценках фич или где risk reduction постоянно откладывается до инцидента. Oleg Sotnikov на oleg.is делает такую работу с основателями и малыми командами, и даже один чёткий обзор может сильно улучшить следующую планёрку.