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

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

В целом классические ассессмент-центры имеют два компонента: это упражнения, которые моделирую работу сотрудника, и критерии, по которым эксперты проводят оценку.

Наиболее распространённый критерий - это компетенции. Компетенции оцениваются в нескольких упражнениях, возможно, даже разными оценщиками. Однако проведённые исследования Пауля Сакетта и Джорджа Дрейера ещё в 1982 году поставили под сомнения точность оценок по компетенциям. Исследователи сделали вывод, что оценки по разным компетенциям внутри одного упражнения коррелируют друг с другом сильнее, чем оценки по одной компетенций в разных упражнениях. Из этого появилась альтернатива компетентностному подходу - подход, основанный на оценке управленческих ролей, который предлагает оценивать человека по его способности эффективно решать типовые задачи для каждой конкретной должности. В данной статье я не буду углубляться в теоретическое сравнение компетентностного и ролевого подхода, а предлагаю познакомиться со статьёй “Оценка по управленческим ролям. Научный обзор” от экспертов консалтинговой группы “ЭКОПСИ”, а также вебинаром “Управленческие роли: новый тренд в оценке и развитии руководителей”.

В финале конкурса “Лидеры России”, про участие в котором я писал ранее, для оценки участников использовался подход с оценкой по управленческим ролям. Участников оценивали по шести ролям. Три роли являются базовыми для руководителей любого уровня:

• Организатор. Планирует рабочий процесс, ставит задачи, следит за их выполнением и дает обратную связь.
• Лидер команды. Согласует цели команды, оценивает результаты своих подчиненных. Подбирает, мотивирует, развивает, удерживает и увольняет людей в команде.
• Проводник изменений. Организует анализ проблем и выработку решений. Занимается оценкой и продвижением идеи команды на уровень выше. Выступает проводником изменений, идущих сверху.

Ещё три роли свойственны руководителям высшего звена:

• Стратег. Анализирует внешнюю и внутреннюю среду организации, определяет цели организации в конкретной области и стратегию их достижения.
• Реформатор. Инициирует и активно поддерживает масштабные проекты развития, формирует коалиции для внедрения изменений.
• Коммуникатор. Как руководитель высшего звена решает задачи организации, связанные с внутренней и внешней коммуникацией.

Вообще модель управленческих ролей “ЭКОПСИ”, эксперты которой и проводили оценку в рамках конкурса “Лидеры России”, содержит больше ролей.

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

Организатор

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

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

Проектное управление

Начал я своё погружение в процессы управления проектами со знакомства с инструментами планирования. В компании в то время для ведения планов проектов использовался MS Project и обычно их администрирование было в ответственности руководителей проектов. Руководители групп разработки сообщали руководителям проектов результаты декомпозиции задач и оценки трудозатрат в произвольной форме (кто-то письмом, кто-то голосом), а они уже сводили эти планы в MS Project. В то время я подумал, что становление руководителем проектов может стать одним из дальнейших карьерных шагов, и мне захотелось познакомиться со спецификой и инструментарием работы руководителей проектов. Я купил самоучитель по работе с MS Project и погрузился в мир планов работ, PERT-оценок, диаграмм Ганта и критических путей. И уже через некоторое время стал планировать работы группы, используя MS Prоject, упрощая жизнь руководителям проектов.

В то же самое время в отделе руководителей проектов появились энтузиасты, которые стали развивать в компании управление проектами в соответствии со стандартом PMBoK (Project Management Body of Knowledge). Меня эта тема заинтересовала, я купил печатную версию PMBoK и погрузился в изучение. Чтение было интересным, отчасти из-за того, что изучая описываемые в стандарте процессы, я то и дело ловил себя на мыслях “ага, а вот это у нас уже используется”, “ого, а вот про это мы забываем”. Нельзя не упомянуть, что мне к тому же повезло. В то время команда разработки, которой я руководил, часто работала с опытным руководителем проектов, хорошо разбирающемся в PMBoK, имеющим сертификат PMP (Project Management Professional). Поэтому можно было увидеть как теория, описанная в стандарте, применяется на практике, как те или иные процессы используются с учётом особенностей компании.

На изучении PMBoK я не остановился и записался на курс “Управление проектами компании”, проводимый компанией PM Expert. Курс во многом пересекался с тем, что удалось почерпнуть из PMBoK, но в то же время он позволил попрактиковаться в прохождении сертификационных тестов, так как после каждого учебного блока необходимо было сдавать тест, вопросы в котором, как я узнал позже, были похожи на вопросы из сертификационного экзамена PME (Project Management Expert) - первой российской сертификации по управлению проектами. Собственно, осенью 2014 года я вместе с братом Антоном, который также прошёл обучение в PM Expert, успешно сдал сертификационный экзамен PME. Антон на этом не остановился и сразу же ещё прошёл международный экзамен на степень PMP (Project Management Professional). Что дало это обучение? Несомненно, у меня появился системный взгляд на проектное управление, набор моих инструментов руководителя пополнился, да и в целом просто изучение принятой терминологии позволило “говорить на одном языке” как с руководителями проектов внутри нашей компании, так и с руководителями проектов на стороне компаний-заказчиков.

Чтобы полученные знания не выветрились из головы слишком быстро, у меня есть лайфхак. Я стараюсь их время от времени кому-нибудь передать, рассказать, чему обучился сам. Это заставляет всё вспомнить, взглянуть через призму полученного нового опыта. Так и в случае с PMBoK у меня появились подопытные слушатели. Мне предложили провести в Череповецком государственном университете курс “Управление разработкой информационных систем” для ребят, обучающихся на специальности “Бизнес-информатика”. Так как в составлении курса я был полностью свободен, то я включил в него лекции и практические занятия по теме стандарта PMBoK. На лекциях я познакомил студентов с терминологий проектного менеджмента и всеми группами процессов, описанных в своде знаний. А на практических занятиях студенты оформляли уставы проектов, определяли заинтересованные стороны и стратегии работы с ними, составляли планы проектов и оценивали риски. Сам курс, конечно, был посвящён не только проектному менеджменту. Рассматривали в нём и гибкие методологии, RUP, практики экстремального программирования, CI/CD и многое другое. Кажется, что рассказ про него заслуживает отдельной статьи. В общем я дважды провёл этот курс в университете. Интересно то, что про него не забыли и несколько лет спустя, уже другие преподаватели вели этот курс по подготовленным мной материалам.

На этом знакомство с темой проектного управления у меня не закончилось. Узнавание чего-то нового волей-неволей продолжается и по сегодняшний день. Так интерес к этой теме во мне оживил и заставил порефлексировать об имеющемся опыте курс проектного управления, который я посетил в период учёбы в бизнес-школе. Курс хотя и был небольшим, но концентрация полезности и ориентация на особенности проектного управления в России ни могли мне дать шанса не отметить его, как одного из лучших в рамках всей программы MBA. В этот раз мне снова повезло, преподавателем курса был Павел Алферов, профессор бизнес-практики школы управления Сколково, эксперт-практик, внедрявший проектное управление в крупнейших российских компаниях и отвечавший за построение системы управления знаниями в оргкомитете олимпиады в Сочи. Учится у лучших всегда интересно, это даёт ориентиры для дальнейшего роста. Кстати, недавно у Павла в издательстве МИФ вышла книга “Проектное управление: как правильно делать правильные вещи”, где описаны все темы, которые были в учебном курсе. Книга полна инструментами, которые помогут систематизировать проектную деятельность, или понять, что проектам тут места нет. Например, мне полюбился фреймворк “Кеневин”, разработанный в стенах IBM и позволяющий выбрать наиболее удачный подход к решению проблем. Даже при зомби-апокалипсисе поможет.

Коммуникации

С появлением управленческих обязанностей у меня кратно возросло количество писем, которые я стал писать. Достаточно быстро я как-то сам выработал для себя несколько практик, которые казались мне полезными. Вот некоторые из них:

• В письмах я стараюсь описать детально контекст обсуждаемого вопроса, чтобы адресату письма не приходилось переспрашивать или чувствовать, что я часть работы, которую мог предварительно сделать сам, сваливаю на него. Это своего рода уважение к времени получателя письма.
• При описании контекста лучше использовать какую-то структуру, а не писать однородную простыню текста. Например, можно сначала написать главную мысль, а потом подкрепить её списком из нескольких аргументов. Или наоборот, сначала дать аргументы, рассказать историю, а потом сделать явно выделенный вывод. Кажется, что первый вариант больше подходит для случаев, когда надо рассказать про какое-то решение, полученный результат, какую-то идею. А второй вариант более уместен, когда надо “рассказать сказку”, повлиять на эмоции получателей письма и подготовить их к главной мысли письма. Например, когда сообщаемые новости не слишком позитивные.
• Если в поле “Кому” указано несколько получателей (это, кстати, уже не очень хорошо), то в тексте письма, надо лично обратиться к каждому из получателей, чтобы явно указать, что вы от него ожидаете. Иначе все получатели подумают, что ответ даст сосед.
• Не писать в чате “Привет!”, а дописывать дальнейший текст, только дождавшись ответного приветствия. Надеюсь, это не нуждается в пояснении :-)

Пару лет назад, читая книгу Максима Ильяхова и Людмилы Сарычевой “Новые правила деловой переписки”, заметил, что многие открытия, которые я сделал, не слишком отличаются от того, что авторы относят к хорошим практикам. Главной пользой для себя в подобных практиках я вижу в итогового уменьшения суммарного времени на общение для себя и получателей писем, что из-за большого числа переписок просто жизненно необходимо.

Можно вспомнить и титанов, например, фреймворки от консультантов McKinsey, которые структурирую подходы к решению проблем (MECE - mutually exclusive and collectively exhaustive, “взаимно исключающее, совместно исчерпывающее”) и представлению этих решений (top-down communication). Они, по сути, тоже про те же хорошие практики, которые помогают не только говорить понятно, а ещё и так, чтобы все поняли.

Делегирование и другие практики регулярного менеджмента

Если вернуться к другим обязанностям “организатора”, то нельзя не упомянуть процесс делегирования. На первых порах у меня была проблема с тем, что я сложные (как я считал) задачи оставлял на себе, а ребятам в команде отдавал те задачи, которые не должны были вызывать у них проблемы. Это приводило к тому, что я периодически становился узким местом производственной цепочки. Приходилось (по собственному желанию) существенно перерабатывать. В это время для меня начало рабочего дня в 8 утра и завершение в 9 вечера было обычным делом. С одной стороны я, несомненно, получал очень большую прокачку своих технических знаний, но с другой стороны не все ребята получали задачи, которые помогли бы им профессионально расти более быстро.

Причина этой проблемы была в том, что став руководителем, моё представление о менеджерской науке были весьма скудно и основано, в лучшем случае, на наблюдении за работой моих руководителей, а в худшем - на своих гипотезах о том, как правильно управлять людьми. То есть я был руководителем-любителем, а не руководителем-профессионалом. И у меня не было знания, что управление людьми - это деятельность, для успеха в которой, особенно на уровне линейного менеджмента, надо прокачивать “хард скиллы”. Скорее, у меня было представление, что успех руководителя в большей степени зависит от его умения межличностного общения.

Если бы у меня была возможность сейчас отравить в прошлое терминатора, то я бы передал с ним, например, книгу Павла Безручко “Практики регулярного менеджмента” и запрограммировал бы его отыскать меня и вручить её в 2012 году. На мой взгляд, знакомство начинающего руководителя с алгоритмами выполнения базовых управленческих работ - залог успешной работы и снижения вероятности разочарования в управленческой деятельности. В то же время одного чтения книг не достаточно, надо практиковаться (на коллегах, членах семьи, кошках…) и выбирать те инструменты, которые подходят и работают. За собой замечаю, что если не стараться выполнять ритуалы регулярного менеджмента, как каратисты оттачивают свои ката, то навык теряется, тонкости забываются, а в голове остаётся лишь ложное убеждение, что вот с этим у меня уж точно нет проблем. Во время написания этих строк вспомнил один случай из жизни. В школьные годы я посещал секцию плаванья, потом эти занятия были заброшены, а спустя десять лет, уже окончив институт и работая программистом, я столкнулся с миром плаванья вновь. Компания выставляла команду для участия в спартакиаде IT-компаний Череповца. Собственно, я сказал, что раньше занимался плаваньем, плавать умею. Меня в команду записали. Брата Антона тоже. И вот в день соревнований, я прыгаю в бассейн со стартовой тумбы, пытаюсь сделать первые движения и понимаю, что моё тело совершенно забыло всю технику: делаю вдох, а хлебаю воду, пара движений рук - и я уже плыву не по центру дорожки, а трусь о разделительный трос, вот впереди уже борт бассейна, а в голове мысли, что если попробую повернуться технично, то также технично повторю судьбу “Титаника”.

А что в итоге?

Хороший ли я организатор? А непонятно. Каждый раз, начиная новое дело, я как будто снова стою на краю бассейна, и не ясно, как пройдёт гонка. Иногда я чувствую, что иду на рекорд, а когда-то хлебаю воду.

Но что-то я заболтался, пора переходить к следующей роли.

Продолжение следует…