С ростом компании увеличиваются масштабы проектов и бюджеты. Часто новые клиенты приходят, а менеджеров не хватает. Нужно расширять штат и нанимать новых сотрудников — либо специалистов с опытом ведения проектов, либо стажёров в помощь менеджерам-старичкам.

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

Руководителям легче вырастить менеджеров «под себя», если изначально закладывать время на их погружение. Развитие стажёров подходит компаниям, у которых есть отточенные процессы для похожих проектов. На них опытные специалисты могут скучать, а начинающие — быстро расти под присмотром наставника. Когда процессы не настроены, удобнее взять специалиста высокого уровня, чтобы он стандартизировал управление.

Как мы погружаем менеджеров в проекты

Менеджеры в KTS отвечают за большой поток задач: ведение проектов, управление разработкой, контроль документов и платежей. При этом они — лицо компании, которое выстраивает коммуникацию между клиентом и командой разработчиков.

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

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

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

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

Продакшн-менеджер ведёт как минимум один полноценный проект, контролирует постановку и распределение задач. На этом этапе наставники учат менеджеров описывать задачу разработчикам, объяснять, какие дополнительные материалы прикреплять для выполнения. Например, минимум информации, которую должен собрать менеджер для работы frontend-разработчика — это ссылка на макет, описание поведения системы, используемые методы API и обработка ошибок. Если менеджер не опишет это всё в задаче, её нельзя будет выполнить.

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

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

Аккаунт первый присоединяется к проекту: на этапе продажи и заключения договора. Он развивает компанию благодаря наращиванию клиентской базы: отвечает за контакт и доверительные отношения с клиентами. Также он не ведет проекты самостоятельно — в основном контролирует общие темпы развития и работу продакшн-менеджеров.

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

Какими знаниями должен обладать менеджер

Существует две модели знаний управленца: советская и американская. Георгий Щедровицкий подробно объясняет их разницу в книге «Оргуправленческое мышление».

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

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

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

Что в итоге

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

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