Какие человеческие проверки нужны вашему ПО, прежде чем сокращать штат

Почему команды сокращают слишком рано

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

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

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

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

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

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

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

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

Три вида человеческих проверок

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

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

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

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

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

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

Как по шагам разложить работу

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

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

Для каждого шага в процессе используйте одну строку:

• что запускает работу
• что софт делает сам
• где человек смотрит, решает или исправляет
• что получает клиент в конце

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

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

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

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

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

Мониторинг, который нужно посчитать

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

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

Простое правило помогает: если человеку нужно посмотреть, оценить или решить, это нужно считать.

В течение двух недель фиксируйте по каждому такому случаю четыре вещи:

• что его запустило
• сколько времени человек потратил
• был ли алерт реальным или это был шум
• произошла ли проверка в рабочее время или после него

Последний пункт важнее, чем многим кажется. Проверка на 10 минут в 14:00 — это не то же самое, что проверка на 10 минут в 23:30. Мониторинг вне рабочего времени стоит дороже из-за усталости, внимания и дежурных смен. Если один инженер всё ещё просматривает алерты перед сном или проверяет очередь по выходным, это всё равно нагрузка на штат, даже если в планёрках о ней никто не говорит.

Нужно также отделять реальное время на проверку от шума алертов. Если система присылает 50 уведомлений, а действия требуют только 3, команда всё равно потратила время на открытие остальных 47. Это не работа по согласованию и не восстановление. Это нагрузка на мониторинг, вызванная шумными правилами, слабыми порогами или плохими дашбордами.

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

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

Согласование, которое нужно посчитать

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

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

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

Для каждой точки согласования фиксируйте четыре вещи:

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

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

Решения, которым нужен контекст

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

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

Работа по восстановлению, которую нужно посчитать

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

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

Считайте восстановление как полноценную задачу, а не как один тикет. Для каждого типичного сбоя запишите:

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

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

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

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

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

Простой пример небольшой софтверной команды

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

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

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

Такая проверка — не пустая трата времени. Если руководитель поддержки пропустит реальную проблему в 7:30 утра, команда разработки начнёт день вслепую, а клиенты почувствуют это первыми.

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

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

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

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

Ошибки, которые искажают планы найма под ИИ

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

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

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

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

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

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

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

Короткий чек-лист перед сокращением

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

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

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

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

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

Что делать дальше, чтобы план был безопаснее

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

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

Запишите простыми словами четыре вещи:

• что делает ИИ
• что человек всё ещё проверяет
• что по-прежнему требует согласования
• кто занимается восстановлением, если что-то ломается

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

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

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

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

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