Колумнист Office Life, руководитель студии разработки Skywind Group Виктория Бутич рассуждает о карьерном пути менеджера в IT, но лайфхаки будут полезны всем менеджерам.
Общаясь с руководителями в сфере IT, я обратила внимание на то, что у них очень часто возникают вопросы: куда развиваться и как в целом может выглядеть карьерный путь менеджера в нашей отрасли?
Проблема в том, что названия должностей и круг обязанностей в различных компаниях могут кардинально отличаться, поэтому возникает ощущение путаницы и неуверенности в собственном видении. Например, delivery manager, как вы сможете увидеть, дочитав статью до конца, имеет как минимум три разных определения. Проблема усугубляется тем, что мода на системное обучение менеджменту пока, кажется, обходит IT стороной: компании тратят деньги на внутренние курсы и тренинги, заточенные под их нужды, а специалисты, которые проходят эти тренинги, не видят картину целиком.
Расти внутри компании, в которой вы уже находитесь и в которой вас все устраивает, не проблема. Вопрос возникает, как правило, с позиционированием себя на рынке труда, когда мы, упираясь в потолок роста, стоим перед выбором: плыть по течению или рискнуть и выйти из зоны комфорта.
Но чтобы понять, в какую сторону развивать свои навыки, которые востребованы у работодателей, важно осознавать, зачем бизнесу вообще нанимать руководителей (любого уровня) с рынка.
Во-первых, если у компании нет внутренних кандидатов или если нет денег, времени или желания учить таких кандидатов. Так уж повелось у нас, что люди сами учиться не очень хотят, ожидая, что за них все сделает работодатель: уговорит, выберет курс, заплатит да еще и предоставит выходные, для того чтобы человек мог повысить квалификацию. Часто такое обучение внутреннего кандидата выходит дороже (особенно если речь про средний и высший менеджмент), чем найм и адаптация готового руководителя. Правда, существует другая проблема: готовых образованных управленцев на рынке IT в нашей стране почти нет (и это, кстати, голубой океан возможностей).
Во-вторых, если компании нужно кардинально что-то поменять: решить внутренний конфликт; изменить культуру или ценности команды, подразделения или целого бизнеса; привнести новую экспертизу и так далее. Например, если бизнес начал активно расти и нужно построить процесс производства, поддерживающий новые объемы, или, скажем, организовать отдел тестирования, или UX, или big data.
Какие же бывают менеджеры в IT и как выбрать свой карьерный путь?
Для начала, стоит понимать, что в нашей сфере есть три основных типа организационных структур:
- плоская (в небольших компаниях, находящихся на этапе развития, который принято называть «тусовкой»), про нее я не буду говорить, потому что там, как правило, менеджмент стихийный и несистемный (считается, что у них работают самоуправляющиеся команды);
- (в основном) матричная (проектная);
- (в основном) иерархическая.
«В основном» означает, что на самом деле чистых типов я еще не встречала.
Матричная структура характерна для аутсорсинговых и сервисных моделей бизнеса. По сути, в таких компаниях существует пул специалистов, из которых создаются временные проектные команды. Проект заканчивается (или команда уменьшается), и специалисты возвращаются в пул, чтобы затем получить назначение на новый проект. При такой структуре, как правило, производственный менеджмент делится на два направления: проектный и ресурсный. Проектных менеджеров (project manager) часто называют деливери-менеджерами (delivery manager), они отвечают за все процессы на своем проекте (часто еще и за коммуникацию с заказчиком, дополнительные продажи и так далее, в зависимости от компании). Проектные менеджеры в организациях любого типа вырастают в программных менеджеров, которых (сюрприз!) тоже часто называют деливери-менеджерами.
Людьми же в матричных организациях управляют ресурсные менеджеры соответствующих пулов (часто их называют тест-менеджерами (QA manager), менеджерами разработки (development manager) и так далее), которые, как правило, вырастают в руководителей из специалистов соответствующей области знаний. Иногда ресурсные менеджеры могут консультировать проекты, участвовать в дополнительных продажах или предпродажах и пр. — это зависит от компании и ее внутренней кухни.
Иерархические модели часто применяются в продуктовых компаниях. Основная характеристика таких организаций — полный цикл производства. То есть все находятся внутри компании: те, кто придумывает продукт и отвечает за его развитие (product managers): те, кто его разрабатывает; и те, кто позиционирует и продает.
В продуктовых компаниях деление на команды обычно долгосрочное.
Одна команда может делать какую-то одну часть продукта (feature), может разрабатывать один или много целых продуктов или еще что-то для продукта. Важная особенность команды в продуктовой разработке — ее полная автономия. В продуктовых компаниях отсутствует понятие ресурсного менеджмента, а существуют несколько типов управленцев.
1. Менеджеры проектов (project managers) могут быть там, где помимо непрерывного процесса производства существуют проекты (кросс-командные или же внутри команд). Это классические PM, такие же, как и в матричных моделях. Часто их объединяют в отдельные подразделения — проектные офисы (PMO), — которые являются и центрами компетенции, и сервисами внутри компании (в матричных структурах PMO тоже иногда бывают).
2. Тим-лиды (team leads), которых иногда называют тим-менеджерами (team managers). Это линейные руководители, которые управляют отдельно разработчиками, тестироващиками или другими небольшими командами специалистов. Обычно они отвечают и за процессы в своих группах, и за людей (найм, адаптацию, обучение, мотивацию
Тим-лидов не стоит путать с техническими лидами (technical leads), которые не управляют ни процессами, ни людьми, а отвечают за выбор технических решений, как и кем эти решения будут реализовываться, а также за качество реализации (code review
3. Тим-менеджеры (team managers), которых часто опять-таки называют деливери-менеджерами (delivery managers). Они, как правило, вырастают из тим-лидов и отвечают за полный цикл разработки своей команды (всех типов специалистов), руководят и процессами, и людьми (или тим-лидами).
4. Руководители отделов (development, QA и так далее). На эти должности также приходят из тим-лидов, однако такие роли есть не везде. Руководители отдело могут понадобится там, где группу или подразделение нельзя разбить на постоянные команды полного цикла: например, компания выпускает много небольших продуктов, которые, по сути, являются типовыми проектами. Или когда внутри крупных продуктовых компаний существуют сервисные подразделения, оказывающие услуги внутренним клиентам: например, подразделение UX, архитекторы, DevOps и так далее. Выделяют их в отдельные структуры, как правило, потому, что такие специалисты не нужны в командах на постоянной основе, их привлекают на время для решения конкретных задач.
5. Руководители группы, подразделения или нескольких подразделений, студии (производства) — в зависимости от уровня руководителя (и тут тоже, вы не поверите, часто используется название delivery manager, иногда могут быть group managers, group directors). Это управленцы, которые отвечают за производство в более общем смысле — за несколько команд, отделов, продуктов или вообще за все команды или продукты. Соответственно они руководят, как правило, только менеджерами, их путь развития — CIO, COO и прочие производственные топы.
Я набросала простую схему для визуализации, которая, надеюсь, поможет упростить эту запутанную картину.
Из всего написанного можно сделать вывод, что основная проблема руководителей при попытке выйти на рынок труда — узкие знания и отсутствие опыта за пределами своей сферы деятельности. Это проблема не только кандидатов, но и работодателей, которые иногда годами не могут подобрать руководителей нужной квалификации. На это накладывается еще и вопрос с английским языком, на котором, казалось бы, теоретически говорят у нас почти все, а практически — нет. Да, объясниться с техническими специалистами на известные заранее темы могут многие. Но подчиняться англоговорящему руководителю так, чтобы иметь с ним контакт и возможность легко обмениваться мнениями, высказывать свою позицию и эффективно взаимодействовать, способны единицы.
