# Как экономия на зарплатах инженеров превращается в будущие счета

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

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

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

Я видел, как компании сокращали команду, радовались более чистому burn rate, а затем незаметно нанимали подрядчиков по высоким ставкам для релизов, эскалаций клиентов, обновлений и ремонта инфраструктуры. Это не эффективность. Так видимый ежемесячный расход превращается в нерегулярные и труднее объяснимые затраты.

## Настоящая экономия убирает работу, отложенная лишь прячет ее

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

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

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

Устойчивая экономия обычно появляется после одного или нескольких таких изменений:

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

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

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

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

## За дешевым инженерным планом скрываются четыре обязательства

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

### Обязательства по обновлениям

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

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

План, в котором написано «обновить позже», но не указаны текущая и целевая версии, владелец, срок и ожидаемая работа над тестами, не является планом. Это запись об обязательстве без суммы.

### Обязательства по безопасности

Безопасность не сводится к отчету сканера. Сюда относятся неизвестные зависимости, непроверенные сервисные учетные записи, доступ бывших сотрудников, секреты в старых системах, слабые процедуры восстановления и production-ресурсы, которые никто не может перечислить.

Рекомендации OWASP по устаревшему программному обеспечению формулируют очевидную мысль: ПО без обновлений со временем накапливает публично известные уязвимости. В рекомендациях для разработчиков также советуют вести список production-зависимостей, включая места использования, версии, источник и статус поддержки. Такой инвентарь важен: команда не может оценить масштаб уязвимости, если не знает, где работает компонент.

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

### Обязательства по поддержке

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

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

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

### Обязательства по знаниям

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

Умные люди увольняются. Они уходят в отпуск. Их могут срочно подключить к кризису с привлечением инвестиций, пока production не работает. Стартапу не нужна энциклопедическая документация. Ему нужно записать рабочие знания там, где следующий компетентный инженер сможет их найти и применить.

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

## Маленькой команде нужна меньшая операционная поверхность

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

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

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

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

Проводите простую проверку поверхности для каждой значимой системы:

| Вопрос | Какие доказательства запросить | Как звучит плохой ответ |
| --- | --- | --- |
| Кто владелец? | Названный ответственный человек | «Вся команда» |
| Как выполняется развертывание? | Повторяемая команда или конвейер | «Спросите Сэма, он знает» |
| Как система выходит из строя? | Недавние оповещения, инциденты и записи о восстановлении | «Она стабильна» |
| От чего она зависит? | Сервисы, поставщики, хранилища данных, учетные данные | «В основном от обычного стека» |
| Можно ли ее вывести из эксплуатации? | Влияние на выручку, клиентов и операции | «Когда-нибудь может понадобиться» |

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

## Ведите обслуживание в том же реестре, что и зарплаты

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

Полезный квартальный реестр может включать четыре дополнительные колонки:

| Обязательство | Наблюдаемое условие | Цена игнорирования | Запланированное действие |
| --- | --- | --- | --- |
| Обновление | Неподдерживаемая среда выполнения в production | Вынужденная миграция во время работы над функциями | Перевести один сервис на поддерживаемую версию |
| Безопасность | Критическая доступная извне зависимость без решения | Реакция на взлом или срочный патч | Исправить, удалить или документировать принятие риска |
| Поддержка | Повторяющееся ручное исправление данных | Отвлечение инженера и задержка для клиента | Исправить первопричину или включить исключение в цену |
| Знания | Только один человек может восстановить базу данных | Более долгий сбой при его отсутствии | Проверить восстановление по письменной инструкции |

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

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

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

## Во время проверки инженерных расходов факты важнее уверенности

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

Попросите материалы, которые команда может показать на одной встрече:

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

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

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

Точно так же сканер уязвимостей не является программой управления уязвимостями. Руководство OWASP Vulnerability Management Guide предупреждает о заблуждении, будто работающий сканер равен управлению уязвимостями. Сканирование создает очередь. Программа решает, что доступно извне, кто отвечает за устранение, какие находки могут подождать и как компания проверит закрытие.

Поэтому основателям стоит скептически относиться к широким заявлениям вроде «у нас все полностью автоматизировано» или «инфраструктура под контролем». Просите показать операционный путь. Кто получает оповещение? Что произойдет, если развертывание повредит данные? Где находится инвентарь учетных данных? Какой клиентский процесс все еще требует участия человека? Хорошие команды отвечают прямо. Слабые системы отвечают заверениями.

## Знакомый сценарий выглядит дешевым в течение шести месяцев

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

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

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

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

Тем временем поддержке некуда отправлять нестандартные случаи. Сотрудник customer success начинает просить инженеров исправлять записи напрямую. Каждый запрос занимает 20 минут, затем 45, потому что у команды нет безопасного административного процесса с журналированием. Инженеры начинают объединять исправления по пятницам. Запланированная работа задерживается, поэтому в этом месяце они пропускают проверку восстановления резервной копии.

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

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

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

## Документируйте систему, которая должна пережить плохую неделю

Документация не работает, когда превращается в расплывчатую просьбу «все записать». Люди либо создают красивый обзор, который не помогает управлять системой, либо бесконечно откладывают работу, потому что у задачи нет границ.

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

Запись о production-сервисе может быть такой:

```text
Service: customer-import-worker
Owner: Engineering, data operations
Repository: git.example.com/product/import-worker
Deploy: CI pipeline "import-worker-prod"
Rollback: redeploy the prior tagged release from the pipeline
Data stores: import queue, customer records database
External dependency: file storage provider
Alerts: failed imports, queue age, worker errors
Recovery check: upload a test file in staging and confirm record counts
Known manual task: malformed files require review through admin queue
```

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

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

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

## Защитите время на обслуживание, пока работа над функциями его не поглотила

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

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

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

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

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

Правило простое: используйте ИИ, чтобы сократить время на исследование и повторяющуюся реализацию, но сохраняйте за людьми ответственность за объем, тесты, выпуск и восстановление. Чем меньше команда, тем меньше у нее места для непроверенной изобретательности в production.

В oleg.is аудит Team & AI полезен основателю, которому нужно провести такую инвентаризацию и проанализировать компромиссы до того, как считать сокращение штата постоянной экономией. Ценный результат это ранжированный список операционных обязательств и возможностей для экономии, а не общее предложение купить больше инструментов.

## Пусть экономия докажет себя со временем

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

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

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

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