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

Что идет не так, когда начинаются сокращения

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

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

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

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

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

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

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

Это давление распространяется дальше. Одна пропущенная передача в продукте превращается в спешно написанный код. Спешно написанный код — в падение тестов. Падение тестов — в проблемы у поддержки. Вскоре команда целый день говорит только об усилиях и выпускает все меньше.

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

Где переделки прячутся в ежедневной работе

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

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

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

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

Тестирование — еще одна тихая утечка. Многие команды все еще прогоняют одни и те же ручные проверки перед каждым релизом, потому что никто не доверяет процессу выпуска. Люди снова и снова кликают по тем же экранам, повторяют один и тот же вход в систему и проверяют одни и те же письма неделю за неделей. Один проход может занять всего 30 минут. За месяц это превращается в часы, которые никто не планировал.

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

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

Почему сокращения кажутся дешевле, чем исправление процесса

Плата за инструменты и зарплаты стоят отдельной строкой в бюджете. Любой может открыть таблицу и сказать: «Уберите это — и мы сэкономим $8,000 в месяц». Потери из-за процесса так не видны. Они прячутся в пяти минутах ожидания ревью, в баге, исправленном дважды, в задаче, которую снова открыли после неясной передачи, или в релизе, который задержался, потому что никто не знал, кто принимает финальное решение.

Именно в этом разница. Финансы могут за один день посчитать отмененный контракт. Менеджер может пересчитать людей до и после увольнений. Переделки увидеть сложнее, потому что они размазаны по продукту, разработке, QA, поддержке и выпуску.

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

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

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

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

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

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

Простой пример из одной продуктовой команды

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

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

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

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

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

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

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

Как найти реальную стоимость за одну неделю

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

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

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

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

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

Простой пример делает это очевидным. Допустим, команда выпускает новое поле в оформлении заказа. Код занимает 10 часов. Это звучит недорого. Потом задачу открывают снова, ревью занимает еще два круга, QA повторяет тесты, а после релиза выходит один хотфикс. К пятнице команда уже потратила 24 или 30 часов, а не 10.

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

Если нужен взгляд со стороны, именно такой аудит может быстро провести fractional CTO. Полезная часть здесь не в красивом отчете. Полезный момент — когда команда видит, куда на самом деле уходят часы.

Сначала исправьте рабочий процесс, потом урезайте дальше

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

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

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

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

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

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

Это менее драматично, чем увольнения, но обычно экономит больше. Если десять человек теряют по 30 минут в день, это около 25 часов в неделю. Это реальные расходы на зарплаты, и они повторяются каждую неделю.

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

Ошибки, из-за которых экономия исчезает

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

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

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

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

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

Где менеджеры часто ошибаются в измерениях

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

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

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

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

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

Несколько ответов «да» — это нормально. Но закономерность — нет.

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

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

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

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

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

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

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

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

Время ожидания важно, потому что простаивающая работа — это все еще оплаченная работа. Повторная работа важна, потому что каждая повторно открытая задача, повторно протестированное исправление или переписанная спецификация съедает часы, которые не двигают продукт вперед.

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

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

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

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