5 ошибок руководителей проектов

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

Ошибка 1. РП — передаст

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

  • Ошибка РП — в простой передаче информации без предварительной обработки. Причины — лень и экономия времени.

  • Руководитель должен не просто получить информацию от разработчиков и разобраться в деталях, но и спрогнозировать вопросы заказчика, заранее их задать разработчику и уже потом доносить информацию до заказчика. Ошибка РП — когда он не понимает технические моменты и, не разбираясь в деталях, отправляет информацию заказчику. Хочется спросить: «Какого черта?» Заказчик, как правило, не тех. специалист. Он начнет задавать вопросы. И когда это происходит, РП просто их транслирует разработчику и передает ответы. И вот оно!!! РП становится просто ПЕРЕДАСТОМ.

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

Ошибка 2. Ответственность

Руководитель проекта — это человек, на котором лежит ответственность за успешность выполнения проекта.

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

Ошибки

  • РП передал задачу исполнителю, не контролирует её выполнение и не знает о проблемах, которые возникли у исполнителя. Причина: РП думает, что все ему должны — сделают, отчитаются, решат. Одним словом, все сделают без участия РП. Это называется передать ответственность, а ответственность нельзя передать, её можно только взять.
  • Бывают проблемные заказчики, и РП сложно получить от них обратную связь. Пока проект в процессе работы, РП особо не переживает по этому поводу, но когда случается «fuck up», то тут слова РП: «Заказчик не предоставил что-то», «Заказчик не дал конструктивную обратную связь», «Заказчик не выходит на связь». НЕТ! НЕТ! НЕТ! Заказчик тут ни при чем. РП неправильно выстроил коммуникацию. Всегда ошибка РП.
  • Отсутствие планирования. Нет планирования — нет контроля!

Решение. Решение лежит в нескольких правилах.

  • Контролировать всё, быть в курсе статусов всех задач, которые в «In progress». Руководителю проекта должно быть до всего дело.
  • Ответственность за успех и «fuck up» проекта лежит на РП — это ему необходимо выстраивать коммуникацию с заказчиком.
  • РП должен чувствовать личную ответственность, контролировать и четко планировать работу исполнителей.

Ошибка 3. Эмоциональность

Руководитель проекта — это человек, который управляет эмоциональным состоянием команды.

Давайте представим: есть человек, о котором вы все время слышите страшные истории, — в вашем представлении он ужасен. И теперь вам для него нужно делать проект. С каким настроением вы будете его делать? Будете ли вы выкладываться? НЕТ!

Заказчики — это люди, бывает так, что РП сложно с заказчиком. И эту тяжесть коммуникации он передает команде:

  • ноет, что заказчик не может дать конструктивную критику;

  • критикует решения клиента;
  • просто сплетничает о нем.

Решение

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

Ошибка 4. Страх

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

Только представьте, как тяжело хирургу сообщить о смерти пациента его родственникам.

Ошибка

РП тянет до последнего и не сообщает о проблемах, надеясь на их решение. Последствия такого поведения очень тяжелые. Заказчик думает, что все хорошо, но в день сдачи узнает о FUCK UP'е. Реакция заказчика понятна: он озвереет, кто-то даже может пострадать:)

Решение

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

Ошибка 5. Неправильная коммуникация

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

Ошибка РП. Задать вопрос и ждать ответа. Далее при получении ответа идет коммуникация по уточняющим вопросам. Это долго!

Решение. Уменьшить время на коммуникацию правильной формулировкой вопросов.

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

Когда я услышал эту фразу, не сразу понял.

Суть в следующем. Перед тем как задать вопрос, вы сами должны предположить, что может ответить заказчик. Таким образом, клиенту вы сбрасываете вопрос и варианты ответов. В ответ заказчик подтверждает определенный вариант ответа или формулирует свой.

Это значительно экономит время.

Важно! Этот способ требует тренировки, зато позволяет выстраивать эффективные коммуникации не только на работе, но и в личной жизни.

Нет плохих заказчиков — есть неправильная коммуникация

Бонус

Это уже про главное качество РП. Если этого качества нет или РП не стремится его развить, он будет совершать ошибки.

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

Как развить гибкость?

  1. Необходимо наработать опыт решения сложных и разнообразных задач. Где взять этот опыт? Элементарно, в бытовых ситуациях. Дом – это наше поле для тренировок. Научитесь правильно выстраивать коммуникации в своей личной жизни, это умение вам пригодится и в профессиональной деятельности.
  2. Общайтесь с большим количеством людей, расширяйте кругозор и варианты коммуникаций. Это вам поможет побороть скованность, вы будете легче находить подход к каждому человеку.
  3. Научитесь не отступать. Но помните: не всегда все зависит от вас. Самое главное – сделать все от вас зависящее и ждать результата. Неудачи случаются, надо быть к ним готовыми, делайте из них выводы.
  4. Читайте больше книг, разного жанра.
  5. Путешествуйте. Даже просто на речку с друзьями.
  6. Займитесь танцами. Например, сальсой. Ритм, общение с новыми людьми, отдых – лучшее развитие гибкости.
  7. Просто занимайтесь саморазвитием.

Заключение

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

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

0
13 комментариев
Написать комментарий...
Роман Гартынов

Видимо наболело) Только вот с этим не согласен "ответственность нельзя передать, её можно только взять." Если задача правильно делегирована, но с ней передается и ответственность за задачу.

Ответить
Развернуть ветку
Иван Карякин
Автор

Есть два понятия: делегирование и постановка задачи.

При постановке задачи РП исполнителю не передается ответственность.
А вот при делегировании задачи одного РП другому - в этом случае уже второй РП берет на себя ответственность. Если не возьмет, то собственно делегирование не удалось.

Ответить
Развернуть ветку
Иван Коробицин

Джим Кемп (кн. Сначала скажите «нет») пишет (выдержка из саммари):

"Беседой всегда управляет тот, кто слушает. Если вы хотите максимально контролировать ситуацию, позвольте противнику говорить. Хорошие вопросы начинаются с вопросительного слова, а не с глагола. Это открытые вопросы. Они помогают и противнику, и нам увидеть то, чего мы не увидели и не поняли раньше.»

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

Автор, что вы думаете об этом?

Ответить
Развернуть ветку
Иван Карякин
Автор

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

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

Ответить
Развернуть ветку
Maxim Bugaev

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

Ответить
Развернуть ветку
Иван Карякин
Автор

Максим.
1 - Есть реалии жизни. И многие менеджеры проектов допускают часто те ошибки, которые я описал. Думаю все с этим сталкивались. PMBOK - конечно прекрасный свод правил, но есть ещё куча реальных ситуаций, которых там нет.
2 - Человек-передаст - согласен, это аккаунт-менеджер или администратор проекта, но все-таки это не Руководитель проекта.

Ответить
Развернуть ветку
Maxim Bugaev

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

Ответить
Развернуть ветку
Иван Карякин
Автор

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

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

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

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

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

Максим, большое спасибо за вашу реакцию и комментарии. )

Ответить
Развернуть ветку
Maxim Bugaev

Вот вам ещё одна "частная" ситуация-у вас на проекте неожиданно работает бизнес-аналитик. Который по вашему мнению должен начинать общаться с заказчиком только в случае факапа. Извините, дальше просто лень спорить.

Ответить
Развернуть ветку
Иван Карякин
Автор

У бизнес-аналитика роль такая, которая предполагает общение с заказчиком. Повторюсь, здравый смысл не надо откидывать. И понимать все слова буквально и тоннельно не стоит.

Ответить
Развернуть ветку
Анастасия Бильданова

Исполнитель тоже несёт ответственность за свою работу. Невозможно контролировать все - в команде из 8ми человек голова пойдёт кругом, если погружаться во все нюансы))

Ещё один важный фактор - это постоянная работа с командой над мотивацией и развитием. В этом ещё одна функция РП.

Гибкость...)) все мы должны быть немного agile)))

Ответить
Развернуть ветку
Иван Карякин
Автор

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

Мотивация и развития - 100%.

Все мы немного agile - )))

Ответить
Развернуть ветку
Алмаз Салимзянов

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

Ответить
Развернуть ветку
10 комментариев
Раскрывать всегда