Роль менеджмента в ИТ
Идея этого поста зрела где-то полтора года, но обрела свою окончательную форму совсем недавно и, как обычно, под воздействием пережитого опыта.
А дело всё в том, что в компании, где я сейчас работаю, уже примерно два месяца назад сняли генерального директора, а около месяца назад компанию покинуло почти всё руководство ГД — 1 уровня.
А уже на этой неделе, 31 июля 2025 года, нас покинет ещё 68 человек из смежных блоков — маркетинг, партнёры, операционная дирекция.
На первый взгляд кажется, что тема поста и его содержание никак не связаны, но это только на первый взгляд.
Дело в том, что, несмотря на уход руководства компании и сокращение половины сотрудников, ИТ-команда продолжает работать и реализовывать 3/4 части развития продукта, запланированного на этот год.
Четвертная задача «Рефакторинг ИТ-продукта» выполняется параллельно с бизнес-задачами и, как часто бывает, имеет самый низкий приоритет. При этом завершение рефакторинга открывает бизнесу широкий спектр возможностей запуска бизнес-инициатив, которые сейчас или невозможны, или крайне затратны.
И всё это ещё как следует приправлено третьим вектором задач, срочных и горящих, которые не были изначально заложены в план, но без которых «бизнес можно закрывать».
Самое удивительное в этой ситуации то, что, оставшись без титулованного руководства, команда самоорганизуется и продолжает выполнять задачи, что часто описано в книгах по Agile, но противоречит многим известным книгам по менеджменту.
У меня давно вызывало противоречие наличие уполномоченного менеджера и самоорганизующейся команды. Если команда может самоорганизоваться, ей и не нужен менеджер, который будет её организовывать. Такой команде нужна только задача и ресурсы, а дальше она сама выдаст результат.
Подтверждение своих мыслей я вижу сейчас в реальной жизни: несмотря на уход руководства, сокращения, естественный отток и некоторые унылые настроения, команда реализует поставленные перед ней задачи.
При этом стоит сделать оговорку: команда подобралась замечательная. Её ядро — крепкие профессионалы своего дела, мотивированные на достижение результата. Такое ядро создаёт культуру достижения результата и отсеивает тех, кто ей не соответствует.
С другой стороны, менеджмент, а именно различные руководители проектов, за редким исключением, представляют собой балласт говорящих голов, приносящих больше вреда, чем пользы.
Для себя я выделил несколько типов бесполезных менеджеров, которых приведу ниже. Но сначала небольшое абстрактное обобщение уровня адекватности менеджера. Я 18 лет провёл в телекоме — индустрии, в которой постоянно двигается большой объём данных и правильная маршрутизация этих данных критически важна.
Возможности маршрутизации развивались постепенно, от менее точных к более точным. Эти же характеристики я использую для всех типов менеджеров.
Уровни маршрутизации:
- Hub — отправляет запрос всем, кого знает. Неважно, имеете вы отношение к запросу или нет, если HUB знает вас, вы получите это сообщение.
- Switch — способен вычислять интересантов по ранее проведённым коммуникациям и направляет запросы только им. Продвинутая версия HUB, которая не шлёт запрос всем подряд, а только тем, кто ранее был замечен в этом общении.
- Router — точно знает, кому переслать запрос, хранит и регулярно обновляет таблицы маршрутизации. Самая продвинутая версия маршрутизатора, которая может направлять точные запросы ответственным, используя уникальный набор меток.
Например, #архитектор #платформа_лояльности #проект_карты #диаграмма_с2.
Уровни применимы к любому типу менеджеров.
Типы менеджеров:
- Редирект — это тип менеджеров, любящих пересылать встречи, письма, сообщения и передающих вопросы/слово в ходе встреч.
- Падре — «Я собрал вас всех вместе, чтобы вы могли поговорить». Такие менеджеры любят собирать команды по всякому поводу, а порой и без повода, и таким образом тратят время огромного количества людей на самую дорогую синхронную коммуникацию.
- Эхолот — менеджеры этого типа постоянно терроризируют команду вопросами: «Ну что там? Какой статус? Давайте заполним табличку по статусам задач».
Какие-то 20 лет назад позиция РП считалась весьма престижной, ответственной и значимой. Для того чтобы стать РП, нужно было многому научиться, иметь практический опыт работы на нижестоящих должностях, разбираться в своей предметной области и владеть рядом инструментов управления.
То, что я лично наблюдаю последние годы, выглядит не просто как деградация профессии, а даже как её отмирание как ненужной функции.
Управление персоналом всё чаще передаётся лидам команд разработки, тестирования, анализа, архитектуры.
Управление планом проекта всё чаще делает команда разработки и DevOps, ввиду того, что РП не понимает, какой состав работ требуется.
Приоритизация требований, как и оценка финансовых эффектов, переходит к владельцу продукта.
А ведение протоколов и фиксация договорённостей всё чаще переходит на сторону ИИ, который делает это по итогам анализа записи встречи.
По моим наблюдениям за последние 5 лет, РП всё чаще превращаются в обузу для проектов:
- Сильным командам они не нужны и создают только нагрузку на ФОТ.
- Слабым командам они вредны, так как создают опасную иллюзию управления, которого на самом деле нет.
Но то, что я наблюдаю сейчас, ставит вопрос шире: какова роль менеджера в ИТ?
От специалистов в ИТ, от тестировщика до архитектора, всё чаще требуются:
- коммуникативные навыки;
- самоорганизованность;
- структурность;
- мотивированность;
- исполнительность;
- креативность;
- умение договариваться;
- готовность брать на себя ответственность.
С каждым годом специалисты в отрасли всё больше развивают эти навыки, чтобы соответствовать требованиям рынка и удовлетворять запросы нанимателей.
Но что же в таком случае требуется от менеджеров? Какими уникальными навыками и умениями должен обладать менеджер, чтобы быть полезным самоорганизованной, мотивированной и профессиональной команде?
У меня, к сожалению, нет ответа на этот вопрос. Все мои запросы к РП сводятся к фразе: «Не доставай меня всякими глупостями и объясни это вон тем ребятам». «Те ребята», как правило, — такие же РП других команд, которые создают мне дополнительную нагрузку. То есть я использую РП, чтобы нейтрализовать других РП, что выглядит как порочный круг.
На мой субъективный взгляд, рынок требует от менеджеров:
- разбираться в предметной области (большое заблуждение, что ИТ может управлять любой РП, например, пришедший из стройки);
- владеть правовой частью своей предметной области (юристы — это хорошо, но что делать команде реализации?);
- уметь рассчитывать финансовые модели (инженеры очень любят математику, но не любят рассчитывать экономическую эффективность);
- обладать способностью отстаивать позицию (любые проекты вызывают конфликт интересов, который часто сводится к фразе «поработайте за нас»). Менеджеры, способные отбивать такие нападки, высоко ценятся своими командами.
ИТ-отрасль — сложная система отношений и взаимосвязей, изменения в одной части системы непременно приводят к эффекту «бабочки». Когда рынок требует от исполнителей постоянно меняться и адаптироваться, менеджмент не может оставаться в старом и стабильном состоянии. Попытка найти оправдание старым подходам похожа на выстрел себе в ногу перед марафоном. Да, от забега вас освободят, но и в случае надвигающегося пожара убежать от него вы также не сможете.