5 ошибок менеджера проектов, которые мешают эффективной работе

Советы, как исправить грубейшие недочёты в работе, от Андрея Головина, куратора и преподавателя онлайн-курса об управлении проектами образовательного портала GeekBrains.

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

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

1. У встречи с заказчиком нет конкретных итогов

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

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

Как избежать

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

2. Нет промежуточных встреч с заказчиком

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

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

Как исправить

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

3. Плохо прописаны требования для разработки

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

Как исправить

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

4. Нет плана работ и понимания сроков по каждому этапу

Даже для одного человека выполнить задачу без понимания, что, когда и к какому времени нужно сделать, очень сложно. Команду в этом случае спасёт только чудо. Без плана работ риск не уложиться в срок слишком велик. Действия членов команды раскоординированы, и слишком тяжело отслеживать, в штатном ли режиме ведётся работа. В итоге именно вам придётся объяснять заказчику, почему день Х наступил, а ничего не готово.

Как исправить

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

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

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

5. Не определены зоны ответственности среди заказчиков и исполнителей

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

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

Как исправить

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

0
6 комментариев
Написать комментарий...
Аркадий Алексеевич

скучно и очевидно ?

Ответить
Развернуть ветку
Valentin Dombrovsky

Гикбрейнс же...

Ответить
Развернуть ветку
Pavel Dubrovskiy

Aye aye, captain

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

Я не буду платить 7400 в месяц за курс человеку дающему такие советы )))))))))))))00000

Ответить
Развернуть ветку
Al Po

Капитан Очевидность даже покраснел от стыда

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

Пошел встану в очередь за онлайн курсом. (На самом деле нет)

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