Исповедь опытного PM: ошибки, которые лучше не повторять

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

Исповедь опытного PM: ошибки, которые лучше не повторять

Как отмечают на канале "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi , ключевая роль Project -менеджера - создать оптимальные условия для продуктивной работы команды. Это предполагает четкое определение зон ответственности, устранение препятствий и расстановку приоритетов, на которых следует сфокусироваться. Однако даже опытные управленцы нередко наступают на многочисленные "грабли", допуская распространенные ошибки. Об этом из личного опыта расскажет опытный PM.

Ошибка №1. Думать за пользователей и заказчика

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

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

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

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

Ошибка №2. Думать за команду

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

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

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

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

Ошибка №3. Микроменеджмент

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

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

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

Ошибка №4. Замалчивать проблемы

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

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

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

Ошибка №5. Делать работу за других

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

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

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

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

Ошибка №6. Зарываться в бумажной работе

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

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

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

Ошибка №7. Тушение пожаров вместо планирования

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

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

Истина, как часто бывает, находится посередине. Конечно, нужно быть готовым к изменениям. Но это никак не отменяет саму необходимость планирования и ревизии планов. Ведь взгляните на ситуацию с другой стороны: когда вы садитесь за руль в большом городе, пусть и знакомом, разве не проще выстроить маршрут заранее? Он будет обновляться в режиме реального времени и поможет объехать пробки, найти оптимальный путь и сэкономить массу времени. Достаточно потратить на это 30 секунд!

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

Ошибка №8. Игнорирование рисков

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

"В нашем проекте нет никаких рисков!"

"Я ничего не могу придумать!"

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

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

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

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

Ошибка №9. Многозадачность

Многозадачность я ненавижу даже сильнее, чем микроменеджмент. Это зло, которое многие почему-то считают добродетелью и проявлением выдающихся способностей. Но результаты исследований неумолимы – лишь 2% людей действительно способны эффективно совмещать множество дел одновременно. Остальные 98%, переключаясь между задачами, стремительно теряют продуктивность.

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

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

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

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

Спасибо, что вы дочитали до конца.

Подписывайтесь на наш канал Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi

Начать дискуссию