Часто встречаю мнение, что руководитель проекта должен хорошо разбираться в предмете проекта, которым он руководит. Например, если это проекты в финтехе — должен уметь разработать фин. модель продукта. Если это проект в ИТ — РП должен быть чуть ли не бывший программист.

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

Но вопрос непростой, давайте его разберем.

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

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

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

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

В результате страдает проект: выплывают риски, едут сроки, появляются недовольные стейкхолдеры.

Поэтому первый вывод такой.

Чем сложнее проект, тем меньше на менеджере должно быть исполнительских задач.

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

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

Поэтому вот второй вывод:

Классно, когда РП шарит в предмете, но обычно не критично, если он хорош в менеджменте, а проекты большие.

Одно из самых ценных моих осознаний относительно менеджмента и командной работы заключалось в том, что большинство рабочих конфликтов можно решить наилучшим образом, если вспомнить о целях (не берем сейчас борьбу за власть и прочую «политику»).

«Тянуть в разные стороны», работая в одной компании, можно только в том случае, если мы смотрим на цели близоруко. Если в разгаре спора вспомнить, какая цель нас здесь объединяет, то сразу все обсуждение можно превратить в «какой путь эффективнее», а это обычно можно как-то конкретно оценить или аргументировать. И это в любом случае уже пути, которые ведут в одну сторону.

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

Подписчики иногда задают мне вопросы, на которые я обычно отвечаю, иногда — в форме поста. Сегодня меня спросили, как быть, если твой шеф занимается «чайка-менеджментом» (прилетел, наорал, насрал и улетел) или «микроменеджментом».

Отличный вопрос.

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

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

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

После этого я бы подошел к шефу на разговор примерно такого содержания:

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

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

3. Договориться о свободе действий внутри установленных границ его комфорта.

4. В дальнейшем — постепенно расширять свои границы автономии. Скорее всего, это будет происходить даже без вашей инициативы, если вы действуете результативно и уважаете границы шефа.

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

К сожалению, это не серебряная пуля. Бывают редкие руководители, которые вас будут микроменеджерить и после такого разговора, кто-то может вас бояться за умение вести открытые и твердые разговоры, с кем-то просто не возникнет «химия».

Тем не менее, если применить эту тактику правильно (с искренней заботой и желанием услышать), в 9 случаях из 10 она приведет к существенно более комфортным отношениям с шефом.

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

Помню методолога на одном из своих проектов. Он был старше меня по возрасту и в методологии более компетентен, чем я. У него практически любая входящая мысль попадала либо в корзинку «а, ну это само собой разумеется» либо в «я не согласен». И я даже не знаю, что из этого было сложнее перешибить — он стоял на своей позиции насмерть.
Вспоминаю нашу битву, когда я просил подготовить для заказчика тезисы на полстранички, а он мне принес пространные рассуждения на трех листах, и намекал, что если мне (и заказчику) сложно в этом разобраться, это свидетельство наших скромных интеллектуальных способностей.

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

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

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

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

Именно благодаря таким вот сложным персонажам и растет твое управленческое мастерство, чувак.

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

Сегодня много говорят про «синдром самозванца» — когда в целом успешные люди сомневаются в своих способностях, и чувствуют свое несоответствие позиции, которую они занимают. Мне кажется, в какой-то умеренной степени это нормальное чувство: новые задачи всегда пугают и заставляют сомневаться. Конечно, плохо, когда это чувство парализует и мешает действовать.

Мне помогают следующие две мысли:

1. Если ты полностью, на 100% все знаешь и умеешь на своем месте работы, значит, ты работаешь на неправильной работе. В наше время (и среди читателей моего блога) довольно мало работ, на которых настолько низкая неопределенность, что можно прямо все знать. Да и те стремительно занимают роботы.

2. Знания и умения — не единственный критерий соответствия позиции.

Руководствуясь как раз вторым пунктом, я нанимаю сотрудника глядя на три вещи:

1. Соответствие знаний и умений позиции на достаточном уровне (не превосходном, экспертном и т. д.). Можно определить через интервью или, лучше, тестовое задание.

2. Мотивация. Насколько человеку интересно заниматься тем, чем он будет заниматься, как это соответствует его жизненным целям. Помню я набирал администратора проектов и выдавал участникам тестовое задание. В задании была ошибка (сначала — случайно, потом я ее оставил). И вот только одна девушка из всех кандидатов писала мне смски с уточняющими вопросами, попросила о дополнительной встрече. Ее я и взял. Отличный лайфхак для устройства на работу, кстати — будьте настойчивее.

3. Обучаемость, реакция на обратную связь. То, что в английском называется емким словечком coachability. И вот это — один из ключевых навыков. Если человек умеет не повторять своих ошибок и мотивирован, он очень быстро научится всему, что необходимо.

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

Руководитель проекта (да и другие менеджеры) часто оказывается в ситуации, когда для достижения результатов нужно оказать на кого-то воздействие, но прямое давление не применимо. Например:

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

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

Показать проблему и ее следствия на фактах

После этого решать проблему вместе, без прямой конфронтации.

Лучше всего факты иллюстрируют цифры и графики. Например:

• Показать на цифрах отклонение от плановых показателей и влияние отклонения на результаты проекта.
• Фактический процент исполнения работ, который отличается от целевого.
• Показать неполное выполнение процедур управления проектом (например, неполное оформление документов по проекту).
• Величину просрочки по невыполненной задаче или количество переносов срока.
• График, иллюстрирующий динамику выполнения работ во времени, на котором видно, как N дней/недель подряд процент выполнения не двигается с места.

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

Важно избегать разбора полетов, а сфокусироваться на конструктивной повестке: как устранить проблему и/или ее следствия.

Конечно, чтобы «батлить по фактам» необходимо:

1. Фиксировать планы
2. Фиксировать факты (документы, замечания, протоколы встреч, показатели и др.)
3. Выделять из фактов значимое, чтобы проиллюстрировать ваш основной тезис о проблеме и следствиях: количество дней просрочки, динамику показателя во времени и пр. Здесь пригодится знание о том, как составлять отчеты и работать с данными.

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

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

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

Что можно сделать?

1. Ввести простое правило: «По 99% проблем ты ко мне приходишь с проработанными вариантами решения, которые я утверждаю (или отклоняю)». 1% — это запрос в стиле «надо посоветоваться»

2. Выделить зоны ответственности с четкими контрольными событиями. Например, руководитель проекта должен а) подготовить описание проекта, первую версию плана и б) принести на утверждение руководителю. Срок на подготовку — N дней.
   Можно выдавать ответственность за значение показателя или за целое направление работ.

Конечно, при делегировании надо учитывать уровень зрелости сотрудника в данной конкретной задаче, а также понимать, как будет организован контроль. Скажем, если вы делегируете ответственность за показатель, надо быть уверенным, что сотрудник может (при разумной поддержке) нести такую ответственность, а также понимать, как вы собираете показатель и когда анализируете его динамику.

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

«Вася, ты менеджер. Твоя задача — настроить процесс»

Эти слова я запомнил. С тех пор, сталкиваясь с новой менеджерской задачей, я всегда первым делом задаю себе вопрос: «Как настроить процесс?». Я повторял эти слова десятки раз с тех пор для других менеджеров. Настроить процесс — одна из ключевых задач менеджера.

Но что это означает на практике?

1. Все знают, что им делать, и делают без пинков со стороны менеджера. Менеджер подключается только если что-то пошло не так. Например, прогнозируется недовыполнение показателя, нужно принять решение.

2. Менеджер понимает, что происходит с процессом на основе фактов (проверенные данные, отчеты). «Понимает» выражается в том, что он видит отклонение фактического исполнения от запланированного, может принимать решения на основе имеющейся у него информации.

3. Процесс приносит результат требуемого качества.

Кстати, ключевым для настройки является п.2. Как вы думаете, почему?

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

Начну с кейсов.

Кейс 1: Идет очень важное совещание по проекту, на котором должно быть утверждено ключевое решение. Вы делаете отличную презентацию... но вдруг высокоуровневый руководитель говорит: «Так, коллеги, я впервые вижу презентацию, я не могу на месте принять такое решение. Пожалуйста, проработайте сначала с моими сотрудниками». Ваш проект только что подвис на неопределенный срок, пока вы проработаете вопрос с неопределенным кругом подчиненных этого руководителя.

Кейс 2: На планерке по проекту вы спрашиваете, выполнена ли <такая-то важная задача>. Исполнитель делает круглые глаза и говорит: «Подожди, а почему эта задача на мне? Вроде Петя этим занимается, нет?» — и вы не знаете, как на это ответить, потому что вы вроде бы уверены, что проговаривали это на прошлом совещании, но не совсем.

Кейс 3: Вы внедряете новую систему. Смотрите в дашборд, из него понятно, что сотрудники системой не пользуются: не обновленные задачи, кто-то вообще не заходит. Спрашиваете у них, что за дела, вам в ответ: «Очень сложный интерфейс, у нас <очень важное дело>, нет возможности осваивать новые интерфейсы», — или вообще: «А что, уже надо работать в новой системе? Я думал, это только пилотов касается».

Во всех трех ситуациях было задействовано право на незнание:

Сотрудник имеет право не знать, что от него чего-то ждут, что-то требуется, если это четко и однозначно до него не довели.

Сколько проектов было из-за него завалено — не счесть.

Как бороться?

Список инструментов большой, вот несколько примеров.

Отправить договоренности/тудушки на почту. Может не сработать, особенно с тем, кто вам не подчиняется напрямую. Ловите классическую отмазку на «я же вам в почте отправил»: «Коллеги, у меня знаете сколько писем в день приходит? У нас сейчас <закрытие, поручение от В.И., план продаж горит — ю нэйм ит>, физически нет возможности отслеживать всю корреспонденцию».

Письмо с подтверждением о прочтении. Не пользуйтесь этим, пожалуйста. Это одна из самых бесячих штук в аутлуке, я обычно нажимаю «никогда не отправлять».

Позвонить, объяснить, подкрепить письмом. Вот это практически железобетонный метод. Вы звоните, рассказываете человеку суть, подкрепляете это письмом с фразой: «В продолжение разговора, вот мои тезисы...» Чтобы закосить от такого захода надо просто нагло врать, на это редко кто идет.

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

Согласовать правила коммуникации и следовать им. Например, если вы прописали в стратегии коммуникации, что протоколы пишете в почте и что они согласуются по умолчанию в течение 8 рабочих часов, уже нельзя будет сказать «я не прочитал». Работает, опять же, только внутри команды проекта. Правила могут быть и неформальными, главное, чтобы их все знали.

Вводное обучение. Открою секрет: лишение права на незнание — чуть ли не главная функция вводного обучения системе. Вы объясняете, что нужно делать, показываете как, затем резюмируете: от кого какие действия требуются, как будут контролироваться, куда задавать вопросы. Теперь любая попытка съехать со стороны исполнителя встретит резонный комментарий: «Так, ребята, мы же провели вводное обучение? Если у вас были вопросы, почему вы не написали нам? Все контакты у вас есть».

Кик-офф проекта. Когда проект переходит в активную стадию, необходимо провести стартовую встречу (kick off). На эту встречу зовут всех, кого касается проект и им объясняют: зачем он нужен, как их коснется и т. п. При этом руководитель просит всех оказать содействие. Обязательное мероприятие для любого проекта.

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

Как заставить сотрудников вносить все задачи в календарь, чтобы поминутно видеть, чем они занимаются, и иметь возможность онлайн переставить им ту или иную задачу?

Интересный запрос. И это не единичный случай: мне периодически поступают подобные просьбы в разных формах.

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

Достаточно того, что это просто не эффективно. Руководитель не может (и не должен) менеджерить своих сотрудников так, как будто он вдевает пальцы в перчатку. Это слишком трудоемко, не масштабируемо, лишает людей инициативы и не раскрывает их потенциал, не гибко, угрожает непрерывности бизнеса (потому что все завязано на одном человеке).

Микроменеджмент — одно из первых прибежищ начинающего руководителя.

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

Когда же стало очевидно, что результаты слабоваты, а процессы буксуют, СЕО (который был далековат от операционки) первым делом распорядился внедрить программу для контроля рабочего времени, потому что ему казалось, что люди просто недостаточно работают и скрывают это от него.

Вместо ответа на вопрос, как контролировать каждый шаг и вздох своих сотрудников, я помогаю менеджеру построить систему, в которой это становится не актуально:

1. Цели. Четкие, понятные и близкие людям, реалистичные, но амбициозные.
2. Распределение ответственности. Четко и понятно, кто за что отвечает

3. Процесс работы, который помогает людям сфокусироваться на цели и том, что нужно для их достижения: цель перед глазами (например, в ИТ системе), регулярная синхронизация усилий на планерках.

4. Оценка достижения целей. Из системы должно быть понятно, какие результаты, удалось ли достигнуть цели. 5. Вместе с закрепленной ответственностью это уже имеет волшебный эффект.
5. Поддержка со стороны руководителя.