5 ошибок менеджера проектов, которые мешают эффективной работе
Советы, как исправить грубейшие недочёты в работе, от Андрея Головина, куратора и преподавателя онлайн-курса об управлении проектами образовательного портала GeekBrains.
Чтобы стать хорошим менеджером проектов, недостаточно жонглировать словами Agile, Scrum и Kanban и распределять задачи между членами команды. Профессионал разбирается во всех этапах жизненного цикла проекта, знает об эффективных инструментах и понимает, когда и какой нужно применить.
А ещё хорошего менеджера проектов отличает то, что он не допускает простейших и вместе с тем фундаментальных ошибок, которые могут поставить под угрозу всю работу.
1. У встречи с заказчиком нет конкретных итогов
Вы встретились с представителями заказчика и несколько часов обсуждали проект. Все много говорили, соглашались друг с другом и довольные разошлись. Вот только никаких конкретных выводов, с которыми бы согласились обе стороны, сделано не было.
Подобные встречи напоминают детскую игру «Испорченный телефончик». Заказчик думает, что предельно доступно объяснил, что хочет получить на выходе. Вам кажется, что вы с заказчиком на одной волне и буквально угадываете его желания. Правда, в итоге может оказаться, что ваше понимание финального результата работы не просто не совпадает, а полярно различается.
Как избежать
К концу встречи у вас должны быть записаны тезисы по её результатам. Для верности пробегитесь по ним вместе с заказчиком и ещё раз убедитесь в том, что всё поняли верно. Не жалейте нескольких минут на это даже в условиях цейтнота. На переделку уйдёт гораздо больше времени.
2. Нет промежуточных встреч с заказчиком
Вы встречаетесь с заказчиком дважды — когда принимаете заявку и когда представляете результат. Но в процессе работы многое может измениться. Например, у заказчика появятся дополнительные вводные или новые предпочтения. Нюансы могут появиться и с вашей стороны. В конце концов, даже необходимость скорректировать сроки лучше обсудить до того, как срыв дедлайнов стал неизбежным.
Если бы промежуточные встречи были, исправления в проект можно было бы вносить в режиме реального времени. В противном случае править придётся уже готовый продукт, что обычно сложнее и неприятнее психологически.
Как исправить
Определите ключевые для разработки точки и запланируйте встречи по каждой из них. Так обе стороны смогут удостовериться, что всё идёт по плану, и внести коррективы.
3. Плохо прописаны требования для разработки
Всё очевидно: чем меньше конкретных требований, тем больше остаётся пространства для того, чтобы сделать что-то не так. Это ничего не говорит о квалификации исполнителей — если среди разработчиков нет ясновидящих, они не могут залезть в чужую голову и понять, что от них хотят. В итоге результат может очень отличаться от ожиданий.
Как исправить
Максимальная точность ещё никому не вредила. В случаях, когда требования могут быть истолкованы двояко, лучше уточнить, что имеется в виду. Внятное, подробное техзадание — гарантия хорошего результата.
4. Нет плана работ и понимания сроков по каждому этапу
Даже для одного человека выполнить задачу без понимания, что, когда и к какому времени нужно сделать, очень сложно. Команду в этом случае спасёт только чудо. Без плана работ риск не уложиться в срок слишком велик. Действия членов команды раскоординированы, и слишком тяжело отслеживать, в штатном ли режиме ведётся работа. В итоге именно вам придётся объяснять заказчику, почему день Х наступил, а ничего не готово.
Как исправить
В качестве мотивации для решения объёмных задач часто используют метафору «съесть слона». В соответствии с ней задача выглядит невыполнимой до тех пор, пока вы не поделите её на этапы — не решите съесть слона по кусочкам.
Метафора работает и при работе над проектами. Необходимо не просто разбить слона на этапы-кусочки. Нужно чётко определить сроки и последовательность действий. Например, уши надо дожевать ко вторнику, чтобы перейти к хоботу.
Благодаря чёткому плану с промежуточными дедлайнами все члены команды знают, что и когда делать, и вы можете отслеживать соблюдение сроков и корректировать их, чтобы в итоге сдать проект в срок.
5. Не определены зоны ответственности среди заказчиков и исполнителей
Если зоны ответственности не поделены внутри команды, может получиться так, что обязанности дублируются, кто-то работает за себя и за того парня, а некоторые задачи просто повисли в воздухе, потому что никто не хочет брать их на себя.
Это же приводит к неразберихе и при работе с заказчиками. Как правило, при отсутствии зон ответственности вся коммуникация замыкается на одном человеке. В итоге это негативно влияет на качество и скорость взаимодействия.
Как исправить
Важно ещё на старте договориться, кто за что отвечает, когда и кем должны быть предоставлены вводные, макеты, дополнительные материалы и всё, что может понадобиться. Когда такая подготовка проделана, все процессы протекают более гладко.
скучно и очевидно ?
Гикбрейнс же...
Aye aye, captain
Я не буду платить 7400 в месяц за курс человеку дающему такие советы )))))))))))))00000
Капитан Очевидность даже покраснел от стыда
Пошел встану в очередь за онлайн курсом. (На самом деле нет)