Вы наверняка встречали «плохих менеджеров»: тех, кто берёт всё подряд, срывает сроки, снимает с себя ответственность и удивляется, почему команда выгорает.
В этой статье я собрал топ-7 паттернов слабого управления. Кратко и по делу объясняю, почему они возникают и что с этим можно сделать.
Чтобы картина была объективной, я опирался не только на свой опыт. Поговорил с коллегой — топ-менеджером крупного банка, у которого в подчинении десятки проджектов и много лет наблюдений, как хорошие менеджеры растят продукт, а плохие — топят его.
Оглавление:
1. Не умеют планировать ресурсы
«Плохой» менеджер не продумывает, какие ресурсы понадобятся через месяц, полгода или в следующем году. Он реагирует на все входящие запросы одинаково: задача прилетела — «Окей», ещё одна — «Берём». И не сопоставляет это с текущей загрузкой команды.
Через пару недель выясняется, что объём работ разросся до состояния, где его физически невозможно выполнить. Тогда начинается пани��а и поиск людей на рынке в последний момент — а это очень сложно и дорого.
Как научиться планировать:
1. Запросить у клиента или бизнеса конкретные требования: что нужно, зачем и к какому результату это должно привести.
2. Разобрать требования вместе с командой. Не приходить с готовым списком задач, а пройтись по целям и разобраться:
какие шаги нужны,
что должно быть готово раньше,
какие этапы завязаны друг на друге.
Так появится структура проекта — база для будущего roadmap.
3. Построить полноценный роадмап, или дорожную карту проекта.
Идите «задом наперёд» — от конечного результата к шагам, которые для этого нужны. Например, на прод нужно выкатить продукт к такой-то дате. Значит, за полторы недели до релиза его нужно протестировать. До тестов нужно закончить разработку — хотя бы за неделю до нового этапа. До разработки закончить прототип, и так далее.
4. Перенести работу в таск-трекер. Планирование ресурсов невозможно без прозрачной картины текущей нагрузки. Чтобы понимать, что команда тянет сейчас, всё должно лежать в одном месте: задачи, сроки, статусы, обсуждения.
Если вы до сих пор не используете трекер — это задача №1.
Выберите простой инструмент, который не превратит внедрение в отдельный проект. Например, в системе управления проектами YouGile можно за 15 минут собрать доску, завести команду, настроить роли и начать работу. Интерфейс интуитивный, поэтому обучения не потребуется.
Дальше — опирайтесь на встроенные отчёты и аналитику, которые показывают загрузку людей, просрочки, узкие места в процессах и общую динамику по проекту.
5. Последовательно спланировать рост штата. Если сейчас хватает двух человек, а в следующем году бизнес хочет масштабироваться в семь раз, значит нужно планировать нагрузку под большее количество сотрудников.
Тут полезно подключать лидов аналитики, разработки, дизайна и других отделов — каждый оценивает свой блок, зависимости и риски.
2. Перекладывают ответственность
Есть менеджеры, которые формально «руководят проектом», но по факту занимают позицию наблюдателя.
Обычно им свойственны такие фразы:
«Это не я обещал»;
«Мне никто не сообщил»;
«Вы сами виноваты, что не сделали» и т.д.
Всё это — разные формы одной и той же установки: «я здесь ни при чём».
Такой человек не защищает команду перед заказчиком, не держит границы между «мы» и «они» и первым ищет, кто виноват, а не что пошло не так.
Ещё один тревожный сигнал — моментальное дистанцирование от результата. Если всё получилось: «Мы сделали», если нет — «Команда не справилась».
Это считывается мгновенно: люди перестают доверять проджекту, не делятся рисками, не признаются в ошибках. Команда уходит в режим подстраховки: каждый закрывается в своих задачах, лишь бы не попасть под раздачу.
Далеко не всегда это лень или нежелания работать. Вот возможные причины:
Менеджер искренне считает, что отвечает «за свою часть», а не за весь контур проекта.
Он боится нагрузки. Если менеджер признает ошибку, ему придётся разбираться, где именно произошёл сбой и почему. Это неприятный, энергозатратный процесс, поэтому многие от него уходят.
Нет опоры в процессах. Когда задачи болтаются в личках и разных чатах, проще сказать «я не знал», чем навести порядок.
Как выйти из позиции наблюдателя:
1. Знать свою роль и держать её в фокусе.
Менеджер должен понимать, зачем он вообще нужен: что дает бизнесу и команде. Когда вы осознаёте свою роль, исчезает соблазн из неё выйти.
2. Перестать оправдываться и сразу переходить к разбору ситуации.
Каждый раз, когда хочется сказать «это не я» или «мне не сказали», меняйте фокус на другое:
«Что именно произошло и что нужно сделать дальше?»
Оправдание оставляет вас в стороне, разбор фактов — возвращает в управление.
3. Перестать молчать об ограничениях.
Менеджер, который не говорит бизнесу или заказчику об ограничениях, не может полноценно управлять.
Нормальная рабочая формулировка звучит так:
«В этот срок помещается вот этот объём. Выбираем, что делаем сейчас, а что переносим».
4. Создать систему, которая держит ответственность на поверхности.
У неё может быть несколько уровней:
общие принципы и договорённости, которые понятны всей команде;
прозрачные цели и ожидаемые результаты, закреплённые за направлением и конкретными людьми;
операционное управление задачами, где видно, кто что делает и к каким срокам.
Самый простой способ собрать всё это в одном месте — перенести процессы в таск-трекер, например, в YouGile. Это дает прозрачность и возможность влиять на работу команды как на коротком, так и на длинном горизонте.
Один из полезных инструментов трекера — диаграмма Ганта, которая показывает, какие задачи идут параллельно, где они пересекаются и не накладываются ли этапы друг на друга.
3. Не умеют делегировать
Это свойство часто маскируется под «повышенную ответственность». Со стороны кажется, менеджер хочет держать всё под контролем. Команда может даже говорить про него — «Ну, он такой… основательный». При этом он становится узким горлышком, через которое всё проходит.
Иногда дело в тревожности — менеджеру кажется, что если он что-то отпустит, команда сделает «не так», и отвечать придётся ему. Иногда — в нехватке опыта, когда менеджер выходит из специалиста и пытается решать новые вызовы по-старому. Иногда — в неосознанном желании чувствовать себя незаменимым.
Получается замкнутый круг: менеджер всё делает сам → команда привыкает к этому → люди перестают брать инициативу → менеджер убеждается, что «по-другому не работает».
Как научиться делегировать:
1. Определить зоны ответственности. Менеджер отвечает за верхнеуровневые цели: финансовый результат и качество продукта, но всё, что нужно для достижения этих целей, можно и нужно отдавать.
2. Проверить, понятно ли людям, что им поручено. Задача должна быть чётко сформулирована: что нужно сделать, к какому сроку и какой результат считается готовым. Обязательно фиксировать это в таск-трекере.
3. Договориться о формате контроля. Здесь многое зависит от команды. Например, на производстве, а иногда и в разработке нужно идти строго по этапам. Их можно закрепить с помощью функции «Строгие процессы», или Workflow, они есть во многих таск-трекерах.
А вот креативным командам нужно больше воздуха, тут можно выстраивать процессы посвободнее. Например, разрешать сотрудникам работать так, как они считают нужным — главное, чтобы задачи были готовы в срок.
Здесь для контроля не обязательно звать всех на планёрки или ретро, подойдёт мягкое наблюдение. Например, в YouGile можно создать специальную доску для ежедневного мониторинга. Её можно сделать со сводками — отдельными колонками на доске, которые автоматически показывают задачи по нужным фильтрам. Например, можно вывести чувствительные карточки: те, где скоро дедлайн, где давно нет движения или которые могут заблокировать релиз.
Так вам не придётся прыгать между досками или вручную собирать статусы. И главное: вы сможете спокойно сосредоточиться на своих задачах.
Показываю, как создать сводку:
4. Не перехватывать работу обратно. Классическая ловушка: сотрудник замешкался — менеджер делает за него. В этот момент делегирование обнуляется. Важно остановиться и помочь человеку пройти шаг, а не выполнить его своими руками.
4. Не умеют в коммуникацию
Есть менеджеры, которые работают изолированно: не уточняют планы у соседних команд и не объясняют своей, зачем вообще делается задача.
Кратко разберу каждую проблему.
Не синхронизируются с другими командами
Если не сверять планы, зависимые задачи начинают расходиться по срокам, а ваши отношения с коллегами неизбежно портятся.
Причина обычно банальная: менеджер просто не думает об этом. Ему кажется, что «всем и так всё понятно».
Как исправить:
1. Уточнять планы заранее.
Не нужно созваниваться на час. Обычно хватает одного короткого сообщения вроде:
— «Мы делаем такую-то доработку, вы готовы?»
— «Да, у нас тоже ручка готова».
2. Регулярно стыковать бэклоги.
Это минимальный объём работы, который предотвращает ситуации, когда одна команда бежит в релиз, а вторая о нём даже не слышала.
Не могут донести бизнес-цели до команды
«Плохой» проджект — это тот, кто не умеет объяснить бизнес-цели задач тем языком, который понятен команде. Он просто вкидывает задачу и уходит.
У разработчиков и у бизнеса — разные «точки интереса».
Команда смотрит на задачу технически. Им важно, как это реализовать, какой стек использовать, насколько решение изящное, быстрое, устойчивое. Это их профессиональная мотивация.
Бизнесу важно, какой результат даст эта фича: ускорит ли она процесс, закроет ли риски, принесёт ли деньги, уменьшит ли издержки, повысит ли конверсию.
И если менеджер этого не доносит, команда может сделать технически красивую, но по сути ненужную доработку.
Как исправить:
Очевидно: связывать эти миры. Объяснять, зачем бизнес просит именно это, что будет на выходе и как результат повлияет на продукт.
5. Не считают метрики
По сути продолжение прошлого пункта. Если менеджер не сформулировал ожидаемый результат, он потом и не проверяет, достигнут ли он. Отсюда типичное поведение: «Предложили сделать — давайте сделаем».
Что должен делать проджект:
смотреть продовые показатели — скорость разработки, конверсию, MAU/DAU, загрузку сервисов, ошибки;
проверять гипотезы на данных;
проводить хотя бы простые A/B-тесты, если решение влияет на клиентский опыт;
валидировать идеи после запуска: сравнивать, что ожидали получить и что получилось;
изучать влияние фич на пользователей — кто стал пользоваться, как часто, что изменилось в поведении.
Суть простая: если у задачи есть цель, у неё должны быть и признаки того, что она достигнута. Без этого команда просто пилит код.
6. Не ведут документацию
Это, пожалуй, один из самых опасных признаков плохого менеджера.
Проджект — человек, который отвечает за порядок в знаниях: что решили, когда поменяли, зачем добавили и как это должно работать.
Типичная ситуация: нужно интегрироваться с другой командой или сервисом. В нормальном процессе проджект открывает актуальную документацию, добавляет недостающие детали — и всем понятно, что делать.
В реальности же документацию «переносят на потом». Кажется, что есть дела поважнее: баги, демо, правки, новые задачи.
И вот к чему это приводит:
непонятно, когда менялась функция;
непонятно, что именно вносили;
непонятно, зачем это добавили;
непонятно, кто это сделал.
В результате: решение вроде работает, но его невозможно поддерживать. Возникает bus-factor — история работы держится на сотрудниках, которые «помнят, как это делалось и чинится». Если они увольняются — решение приходится фактически делать заново.
Как вернуть порядок:
1. Фиксировать решения сразу, пока они свежие. Не нужно писать трактаты, просто: что решили, почему и что делаем дальше.
2. Обеспечить доступ к документации для всей команды. Гуглдок, база знаний, доска в таск-трекере — подойдёт любой удобный формат.
7. Перегружают команду ритуалами
Ретро, планирования, стендапы ради стендапов. Формально — всё правильно: процессы есть, команды «синхронизируются». Но когда встречи не дают пользы, это превращается в имитацию активности.
У менеджеров это обычно случается по трём простым причинам:
Ритуалы подменяют реальную работу, потому что привычные «синки» проще, чем разбираться в задачах;
Встречи позволяют снять с себя часть ответственности — обсудили «всем кругом» и вроде бы уже что-то сделали;
Ну и инерция — когда «мы всегда так делали» и никто не задумывается, что половину этих созвонов давно заменяет два сообщения в таск-трекере.
Как исправить:
1. Перенести обсуждения в трекер, а не в Zoom. Например, в YouGile у каждой задачи есть свой чат, похожий по функциям и интерфейсу на Telegram — туда и складываем вопросы, файлы, уточнения.
2. Записывать короткие скринкасты вместо созвонов. Если нужно пояснить макет или логику задачи — записали видео прямо из карточки задачи, команда посмотрит в удобное время:
3. Собирать статусы автоматически. Включили сводки — и видите просрочки, зависшие задачи, движение по спринту. Про сводки писал выше.
4. Обязательно делиться повесткой и постмитом. Каждая встреча должна начинаться с формулировки: «Что нужно решить?» И заканчиваться ответами на такие вопросы:
Кто за что отвечает?
Какие сроки на работу?
К какому результату идём?
Без этого созвон становится просто болтовнёй.
Если в каких-то пунктах узнали себя — без паники. Главное, что теперь вы знаете, где можно подтянуть процессы и облегчить жизнь себе и команде.
Поделитесь в комментах, какие паттерны встречали у себя, коллег или бывших руководителей. Может, чего-то не хватает в списке?
wannaslp
То чувство, когда в начале карьеры я бы набрала 7/7………