5 ошибок руководителей проектов
Сразу скажу: я не претендую на объективность. Это мой топ-5 ошибок руководителей проектов, в результате которых хочется совершить греховные деяния по отношению к этим самым руководителям.
Ошибка 1. РП — передаст
Не подумайте ничего пошлого, ПЕРЕДАСТ — это человек, который передает информацию от одного другому. Руководитель проекта — это связующее звено между заказчиком и разработчиками. Разумеется, он должен получать информацию от заказчика и доносить до команды, но он также должен её обрабатывать.
Ошибка РП — в простой передаче информации без предварительной обработки. Причины — лень и экономия времени.
- Руководитель должен не просто получить информацию от разработчиков и разобраться в деталях, но и спрогнозировать вопросы заказчика, заранее их задать разработчику и уже потом доносить информацию до заказчика. Ошибка РП — когда он не понимает технические моменты и, не разбираясь в деталях, отправляет информацию заказчику. Хочется спросить: «Какого черта?» Заказчик, как правило, не тех. специалист. Он начнет задавать вопросы. И когда это происходит, РП просто их транслирует разработчику и передает ответы. И вот оно!!! РП становится просто ПЕРЕДАСТОМ.
Решение. РП должен всю получаемую информацию обрабатывать, предвидеть вопросы и заранее быть готовым на них отвечать! У нас, например, есть 2 проектных чата: внутренний и внешний (с заказчиком). Одним из наших принципиальных решений было запретить делать пересылку сообщений от заказчика во внутренний чат.
Ошибка 2. Ответственность
Руководитель проекта — это человек, на котором лежит ответственность за успешность выполнения проекта.
Руководитель проекта — это пионер (да, имеется ввиду тот, кто с красным галстуком): в советское время была фраза «Пионер, ты отвечаешь за все».
Ошибки
- РП передал задачу исполнителю, не контролирует её выполнение и не знает о проблемах, которые возникли у исполнителя. Причина: РП думает, что все ему должны — сделают, отчитаются, решат. Одним словом, все сделают без участия РП. Это называется передать ответственность, а ответственность нельзя передать, её можно только взять.
- Бывают проблемные заказчики, и РП сложно получить от них обратную связь. Пока проект в процессе работы, РП особо не переживает по этому поводу, но когда случается «fuck up», то тут слова РП: «Заказчик не предоставил что-то», «Заказчик не дал конструктивную обратную связь», «Заказчик не выходит на связь». НЕТ! НЕТ! НЕТ! Заказчик тут ни при чем. РП неправильно выстроил коммуникацию. Всегда ошибка РП.
- Отсутствие планирования. Нет планирования — нет контроля!
Решение. Решение лежит в нескольких правилах.
- Контролировать всё, быть в курсе статусов всех задач, которые в «In progress». Руководителю проекта должно быть до всего дело.
- Ответственность за успех и «fuck up» проекта лежит на РП — это ему необходимо выстраивать коммуникацию с заказчиком.
- РП должен чувствовать личную ответственность, контролировать и четко планировать работу исполнителей.
Ошибка 3. Эмоциональность
Руководитель проекта — это человек, который управляет эмоциональным состоянием команды.
Давайте представим: есть человек, о котором вы все время слышите страшные истории, — в вашем представлении он ужасен. И теперь вам для него нужно делать проект. С каким настроением вы будете его делать? Будете ли вы выкладываться? НЕТ!
Заказчики — это люди, бывает так, что РП сложно с заказчиком. И эту тяжесть коммуникации он передает команде:
ноет, что заказчик не может дать конструктивную критику;
- критикует решения клиента;
- просто сплетничает о нем.
Решение
- Исполнитель не должен участвовать в коммуникации с заказчиком.
- РП не должен передавать критику заказчика по отношению к команде разработчикам. Лучше просто в общении с клиентом защитить свою команду, но ей желательно об этой ситуации не знать.
- Какой бы сложный заказчик ни был, РП не должен показывать этого команде — исполнителям нужно транслировать только положительные эмоции.
- Важно не забывать: требовательность заказчика — это хорошо, а не плохо. Многие это воспринимают в штыки!
Ошибка 4. Страх
Интересный факт: когда мы переживаем за проект, нам психологически тяжело сообщать плохие новости.
Только представьте, как тяжело хирургу сообщить о смерти пациента его родственникам.
Ошибка
РП тянет до последнего и не сообщает о проблемах, надеясь на их решение. Последствия такого поведения очень тяжелые. Заказчик думает, что все хорошо, но в день сдачи узнает о FUCK UP'е. Реакция заказчика понятна: он озвереет, кто-то даже может пострадать:)
Решение
- Ребят, ну серьезно. Заказчик — это человек, он переживает за проект и понимает, что могут возникнуть сложности. Очень важно о них сообщить и предложить пути решения.
- Не надо тянуть до последнего. Попробуйте разрешить проблемы, а если не получится, сразу сообщайте заказчику. Вы сможете сказать, какие попытки предприняли, а дальше совместно с клиентом найдете решение.
Ошибка 5. Неправильная коммуникация
Тут можно говорить много. Сегодня остановимся на том, как правильно задавать вопросы.
Ошибка РП. Задать вопрос и ждать ответа. Далее при получении ответа идет коммуникация по уточняющим вопросам. Это долго!
Решение. Уменьшить время на коммуникацию правильной формулировкой вопросов.
В нашей компании я написал отдельную инструкцию о том, как правильно задавать вопросы. Во главе стоит тезис — «Задавая вопрос, ты должен знать на него ответ».
Когда я услышал эту фразу, не сразу понял.
Суть в следующем. Перед тем как задать вопрос, вы сами должны предположить, что может ответить заказчик. Таким образом, клиенту вы сбрасываете вопрос и варианты ответов. В ответ заказчик подтверждает определенный вариант ответа или формулирует свой.
Это значительно экономит время.
Важно! Этот способ требует тренировки, зато позволяет выстраивать эффективные коммуникации не только на работе, но и в личной жизни.
Нет плохих заказчиков — есть неправильная коммуникация
Бонус
Это уже про главное качество РП. Если этого качества нет или РП не стремится его развить, он будет совершать ошибки.
Это качество — гибкость. Оно позволяет РП мыслить нестандартно, не прямолинейно, не в лоб. Можно назвать это той самой предпринимательской жилкой, которая позволяет находить выход из любой ситуации.
Как развить гибкость?
- Необходимо наработать опыт решения сложных и разнообразных задач. Где взять этот опыт? Элементарно, в бытовых ситуациях. Дом – это наше поле для тренировок. Научитесь правильно выстраивать коммуникации в своей личной жизни, это умение вам пригодится и в профессиональной деятельности.
- Общайтесь с большим количеством людей, расширяйте кругозор и варианты коммуникаций. Это вам поможет побороть скованность, вы будете легче находить подход к каждому человеку.
- Научитесь не отступать. Но помните: не всегда все зависит от вас. Самое главное – сделать все от вас зависящее и ждать результата. Неудачи случаются, надо быть к ним готовыми, делайте из них выводы.
- Читайте больше книг, разного жанра.
- Путешествуйте. Даже просто на речку с друзьями.
- Займитесь танцами. Например, сальсой. Ритм, общение с новыми людьми, отдых – лучшее развитие гибкости.
- Просто занимайтесь саморазвитием.
Заключение
Надеюсь, статья была полезной. Если да, поделитесь ею, чтобы больше людей получили полезную информацию.
Буду благодарен комментариям, пополнению списка ошибок и дополнительным вариантам решений.
Видимо наболело) Только вот с этим не согласен "ответственность нельзя передать, её можно только взять." Если задача правильно делегирована, но с ней передается и ответственность за задачу.
Есть два понятия: делегирование и постановка задачи.
При постановке задачи РП исполнителю не передается ответственность.
А вот при делегировании задачи одного РП другому - в этом случае уже второй РП берет на себя ответственность. Если не возьмет, то собственно делегирование не удалось.
Джим Кемп (кн. Сначала скажите «нет») пишет (выдержка из саммари):
"Беседой всегда управляет тот, кто слушает. Если вы хотите максимально контролировать ситуацию, позвольте противнику говорить. Хорошие вопросы начинаются с вопросительного слова, а не с глагола. Это открытые вопросы. Они помогают и противнику, и нам увидеть то, чего мы не увидели и не поняли раньше.»
Ваш тезис «Задавая вопрос, ты должен знать на него ответ» противоречит вышеизложенному. Предположу, что это зависит от специфики вопроса.
Автор, что вы думаете об этом?
Иван, здесь я рассматриваю взаимодействие РП с Заказчиком. Как правило коммуникация сводится к выявлению требований. Заказчик чаще всего не знает что хочет и ему сложно формулировать свои мысли и отвечать на открытые вопросы.
Поэтому для эффективной коммуникации предлагаю схему, когда РП задает вопрос и далее предполагает возможные варианты ответов и предлагает их Заказчику. Заказчик выбирает тот вариант, который к нему ближе. Или генерирует свое решение.
Формулируя варианты решения на возникший вопрос, РП глубже погружается в предметную область, что тоже положительно влияет на ведение проекта.
хрень какая-то для детей. что должен и чего не должен РП написано в основе основ управления проектами - PMBOK. То что вы после долгих размышлений выяснили, что РП должен быть ответственным - это конечно ноу хау.
Человек-передаст на проекте кстати очень даже может быть. Роль называется "администратор проекта".
Максим.
1 - Есть реалии жизни. И многие менеджеры проектов допускают часто те ошибки, которые я описал. Думаю все с этим сталкивались. PMBOK - конечно прекрасный свод правил, но есть ещё куча реальных ситуаций, которых там нет.
2 - Человек-передаст - согласен, это аккаунт-менеджер или администратор проекта, но все-таки это не Руководитель проекта.
Повторюсь, полная пурга. Взять хотя бы "Исполнитель не должен участвовать в коммуникации с заказчиком" - это вы откуда взяли?
Если например проблемы на проекте, участвует несколько подрядчиков, включая вас, плюс it отдел заказчика. Заказчик собирает на разбор полётов, все приходят с программистами и только с вашей стороны один рп будет, как он будет отдуваться?