Техническое лидерство начинается с удаления работы в первую очередь

Почему команды выглядят занятыми, но двигаются медленнее

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

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

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

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

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

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

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

Как выглядит удаление работы

Большинству команд сначала нужно не больше мощности, а меньше шума.

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

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

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

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

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

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

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

Проведите недельный аудит работы

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

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

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

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

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

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

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

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

Оценивайте задачи, прежде чем оставлять их

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

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

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

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

Простая оценочная таблица помогает:

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

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

Владение задачей — последний фильтр. Оставляйте только то, у чего есть понятный владелец и понятная причина. «Мы так всегда делали» — это не причина. «Финансам это нужно, чтобы закрыть месяц» — это причина. «Платящий клиент уйдет без этого» — это причина.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки, которые сохраняют старую работу

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

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

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

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

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

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

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

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

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

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

Что проверить перед открытием роли

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

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

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

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

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

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

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

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

Что делать со временем, которое вы вернули

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

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

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

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

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

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

Если команда все еще перегружена, не торопитесь с наймом. Внешний разбор может помочь увидеть работу, которую свои уже считают нормой. Oleg Sotnikov делает такой разбор в рамках своей работы fractional CTO и startup advisory, а oleg.is хорошо показывает, как он подходит к lean-операциям, архитектуре продукта и разработке с опорой на ИИ. Для небольшой или средней команды такой внешний взгляд часто быстрее и дешевле, чем добавлять людей раньше, чем команда снова вернет фокус.