Как менеджеру справляться со страхом и неуверенностью

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM

Всем привет!

Я свитчер («Здравствуй, свитчер», как говорят в клубах анонимных алкоголиков/тунеядцев/наркоманов — нужное подчеркнуть). Перешел в IT еще когда это не было мейнстримом. В 2003 году окончил географический факультет Киевского национального университета, там же в 2008-м — аспирантуру. Пришел в IT 2004 году на позицию редактора сайта, имея за плечами три года журналистики в различных печатных и электронных изданиях. Выбирал путь или в ІТ, или в журналистику, но рекрутер в IT-компании была очень уж красивой женщиной :) За прошедшие с тех пор 15 лет прошел путь до директора департамента и руководителя проектного офиса. Сертифицированный менеджер проектов PMP и IPMA.

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

Для начала несколько постулатов от Капитана Очевидность, в некотором роде это словарь терминов для этой статьи.

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

А еще все листики на деревьях зеленые, «Динамо» — чемпион, а «Запорожец» таки по всем формальным признакам автомобиль.
Звучит как утопия, но вместе с тем результатом грамотного управления коллективом является отлаженная работа проекта.

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

Самоорганизованная команда — команда, способная предлагать и, при необходимости, принимать решения с персональной ответственностью за их результаты. В случае ошибочного решения в такой команде никто пафосно не надувает щеки: «У нас agile, поэтому мы отвечаем за выбранное решение всей командой». Это из серии позерства школьников на большой перемене, когда мячом разбили окно.

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

Проект. Определений проекта достаточно много, мы не будем отбирать работу у Гугла ;) Отметим только, что в нашей истории это не просто создание заказного ПО, а совокупность работ по комплексному решению задачи клиента.

А теперь давайте заглянем в голову менеджеру, в самые ее потаенные и темные углы.

Больше общайтесь с командой и клиентами

Сфера IT сама по себе интровертна. Такова специфика профессии. Бывает, что написать электронное письмо на три страницы проще, чем поговорить с человеком лично. Зачастую проблемы внутри команды и с заказчиком связаны с отсутствием прямой эффективной коммуникации или с непродуманной стратегией общения.

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

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

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

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

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

Планируйте работу на случай аврала

Из-за проблем с коммуникацией могут срываться дедлайны. О которых вы могли даже не знать, так как не спросили, ага. Подобная ситуация однажды произошла у меня на B2G-проекте (business-to-government).

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

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

Я однажды проявил чудеса перепланирования и подписал допсоглашение с финальной датой 24 августа. А так как это День Независимости, то есть выходной, я получил еще один день для овертаймов, если мы снова все важное пропустим.

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

Учитесь новому у коллег

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

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

Да, технические знания могут помочь (а могут и нет). Так проще говорить с заказчиком и командой на одном языке, вместе с сотрудниками реально оценивать объем предстоящих работ и ставить адекватные дедлайны.

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

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

Аргументируйте жесткие решения

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

Наш тест-менеджер, отлично понимая, что количество дефектов в релизе не просто много и продукт ляжет раньше, чем «добежит до канадской границы», не хотел ручаться за качество работы и не пропустил релиз дальше по процессу. И понеслось: заказчик пожаловался вышестоящему руководству, что какой-то менеджер не дает ему поставить релиз, он теряет деньги, мол, «за что я вам плачУ и от этого плАчу».

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

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

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

Будьте искренним с командой

Проектная команда чаще обсуждает посторонние темы, перекуры и обеды затягиваются, и коллеги все реже зовут вас с собой? Вероятно, коллектив больше не доверяет руководителю и назревает бунт. «Они заряжают пушку. Зачем? А, они будут стрелять!»

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

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

Нужен отчет? Просто дайте его

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

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

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

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

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

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

Не копите страхи — разгрузите голову

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

Но есть в этом и положительный момент. Как у оптимистов, которые даже на кладбище видят не кресты, а плюсики. Эмоциональное выгорание — это экономрежим организма. Физические проявления (головная боль, сонливость, простудные заболевания) сигнализируют, что пора отдохнуть. Сделайте перерыв и оцените работу со стороны. Возможно, какой-то из страхов вы давно преодолели. Например, страх чтения лонгридов ;)

Вместо вывода

Страхов и тревог у проджект-менеджера много. Есть обоснованные и нет, субъективные и объективные. С некоторыми можно справиться самостоятельно, иные потребуют помощи. Вместе с тем страх является и стимулом: люди боялись летать, но братья Райт преодолели этот страх, и теперь мы боимся не самолетов, а того, что попадется среднее место с храпящими соседями по обе стороны. Преодоление страха — это возможность получить новые навыки и знания. Далее обычно следует мотивирующая фраза в стиле Тони Роббинса. Вот она: выберите хотя бы один страх и начните получать удовольствие от его преодоления:

  • ищите общение с командой и клиентами;
  • готовьте план Б на случай неожиданностей;
  • не бойтесь учиться у сотрудников;
  • будьте жестким, если ситуация этого требует;
  • начните работать с командой открыто;
  • признавайте проблемы сразу: так будет проще и вам, и заказчику.

Keep calm and wash your hands ;)

LinkedIn

11 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

На практике, разраб говорит не трогай меня до завтра

Больше смолтока в нужные моменты. Больше слушать их боли. И тогда даже самые нелюдимые технари и высокомерные архитекторы начинают с тобой общаться

начинают с тобой общаться

об штом? не ну сирёзно об штом?

Как минимум — о деле. Как максимум — о чем угодно.

Весьма исчерпывающий перечень бед малоопытного или психически ослабленного внешними факторами ПМ-а. Отлично! Надо бы начать выпускать альманах анонимных факапов еще для иллюстрирования всей этой кухни)

Первый подпишусь на такой альманах)

работать не пробовал? ))

Благодарю за статью. Прекрасный слог! 👍

спасибо. но не увидел алкоголя как одного из способов )

Тогда надо будет писать что-то из серии «споживай відповідально» )

Про признание проблем (ошибок) я бы прям на первое место поставил. Оно еще граничит с поиском виноватого, вместо того, что сделать чтобы исправить. Это как продолжение.
А за статью спасибо! Познавательно)

Подписаться на комментарии