Срочную фичу попытались втиснуть в двухнедельный спринт без пересборки бэклога, и команда в итоге вернулась к повторным согласованиям и переделкам. Именно так выглядит работа ради процесса в живом IT: правила формально есть, а результата от них меньше, чем шума. Для разработчиков, тимлидов и продактов это не абстрактная управленческая боль, а прямые потери времени, фокуса и доверия к работе.
Об этом пишет Habr / Карьера в колонке Вики, руководителя продуктового направления Outlines Tech. Тезис у материала неприятно узнаваемый: если процесс перестаёт помогать команде и начинает жить своей жизнью, сотрудники редко идут в открытый конфликт, а чаще приспосабливаются. Не потому, что всех всё устраивает, а потому, что спорить с начальством дороже, чем молча закрывать бессмысленные ритуалы.
В статье разобраны несколько типовых сценариев, из которых и складывается работа ради процесса. Первый: требования меняются прямо на созвоне, но договорённости остаются только в устной форме. Задачи не обновили, ответственных не назначили, итоги встречи каждый понял по-своему. На практике это означает ещё один круг синков и неизбежные переделки. Второй сценарий знаком почти любому офисному ИТ: обязательный артефакт существует потому, что когда-то его утвердили. В примере из текста аналитик регулярно заполнял статус-отчёт, хотя руководитель узнавал то же самое на звонках и там же запрашивал уже внесённые данные. Документ продолжал жить по инерции, сотрудник тратил время, пользы никто не получал.
Третий сценарий касается перегруженных «незаменимых» людей, на которых держится весь контур принятия решений. Это может быть руководитель, старший специалист или фактический лид без новой должности и без доплаты. Автор прямо говорит о собственной рабочей ёмкости: удерживать в фокусе получается три-четыре направления, а когда сверху добавляют ещё несколько, особенно не связанных с основными, начинается типичная деградация процесса. На встречах человек уже слушает вполуха, решения не фиксирует, задачи не дотягиваются до исполнения, одни и те же вопросы всплывают снова. Для команды это выглядит как хаос, хотя формально виноватых нет: все вроде бы участвуют, просто узкое место давно перегрето.
Четвёртый сценарий особенно узнаваем на волне моды на методологии и ИИ. Руководитель приносит «готовую систему» после конференции или общения с консультантами и перестраивает работу команды, толком не проверив, какую проблему вообще собираются решать. Похожая история происходит и с нейросетями: автоматизацию внедряют не там, где она экономит время, а там, где можно красиво отчитаться о внедрении. В результате сотрудник сначала получает сырой результат модели, потом проверяет, исправляет, дописывает и тратит на это больше часов, чем ушло бы на ручную работу с нуля. Компания при этом платит и за труд человека, и за токены модели. Для рынка, который уже устал от показного AI-энтузиазма, это, пожалуй, самый точный фрагмент текста.
Почему команды терпят бессмысленные ритуалы
Самая сильная часть материала не в списке симптомов, а в разборе того, почему работа ради процесса так быстро становится нормой. По мысли автора, сотрудник редко принимает бессмысленное правило как правильное. Сначала он злится, спорит и предлагает альтернативу. Потом начинается внутренний торг: задача дурацкая, зато сама работа интересная; процесс кривой, зато команда нормальная; требование странное, зато зарплата стабильная. Финал у этого цикла не принятие, а апатия. Сопротивление требует больше энергии, чем механическое исполнение. А если рынок найма нервный, увольнение перестаёт выглядеть лёгким выходом даже для сильного специалиста.
Есть и более приземлённые причины молчания. Чтобы доказать, что процесс мешает, мало сказать «мне неудобно». Нужно собрать аргументы, показать последствия, найти человека с полномочиями и ещё предложить замену. И нередко именно того, кто поднял проблему, просят всё и починить — без времени, без ресурсов и без формального мандата. Рациональный вопрос «зачем мне это» в такой конструкции звучит не как лень, а как нормальный расчёт. Отсюда и ещё один тупик: если спорное правило ввёл непосредственный руководитель, обсуждать его приходится с ним же. Идти выше в компаниях СНГ многие по-прежнему считают почти доносом, а в крупной структуре сотрудник часто вообще не понимает, кто реально может отменить или переписать процесс.
На выходе формируется знакомый корпоративный договор: команда делает необходимый минимум, руководство видит, что всё не развалилось, значит, система как будто работает. Это плохая новость и для бизнеса, и для разработки. Для бизнеса потому, что бессмысленные ритуалы съедают дорогой рабочий ресурс в момент, когда каждая ставка и каждый час стоят заметно дороже, чем в презентациях про эффективность. Для разработки потому, что привычка «не вникать, лишь бы закрыть» быстро убивает качество обсуждений, инициативу и чувство ответственности за результат. Когда люди перестают верить, что на процесс можно повлиять, они перестают вкладываться не только в процессы, но и в сами задачи.
Что с этим делать, если полномочий нет
У рецепта из колонки нет магии, и в этом его плюс. Автор не предлагает героически ломать систему через колено. Базовый план гораздо скромнее: сначала убедиться, что руководитель вообще видит проблему, а не слышит только кухонное ворчание команды. Затем уточнить, зачем нужен спорный процесс, кто потребляет его результат и что реально изменится, если от него отказаться. Это важный разворот: разговор не про раздражение сотрудника, а про последствия для сроков, загрузки, качества решений и числа переделок. Такой язык в ИТ обычно понимают лучше, чем эмоциональные монологи о бессмысленности бытия в Jira.
Практический смысл у этого подхода тоже есть. Если процесс нельзя отменить, иногда можно хотя бы сузить его применение, заменить формат отчётности, зафиксировать договорённости письменно после созвона, убрать лишний круг согласований или развести зоны ответственности. Это не выглядит революцией, зато снижает издержки уже на текущем цикле работы. Другое дело, что сама автор оговаривает важное ограничение: такие советы работают только там, где обсуждение проблем вообще допустимо. Если любая попытка задать вопрос «зачем» воспринимается как неповиновение, речь уже не о частном сбое, а о культуре управления.
Для русскоязычного IT-рынка материал попадает в нерв точно потому, что не обещает красивого выхода. Между открытым конфликтом, увольнением и молчаливой адаптацией большинство выбирает третье. Вопрос в том, сколько ещё компании смогут позволять себе работу ради процесса, когда на фоне дорогого найма, перегруженных лидов и моды на «автоматизацию любой ценой» главным дефицитом становится не регламент, а внятный смысл каждого действия.