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

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

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

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

Можно все сделать правильно, посоветоваться с опытными специалистами, но все же самое главное — получить подтверждение от клиента, если он соответствует его ожиданиям. Если эта кнопка/текст - это то, что они хотят.

Если вы сомневаетесь, правильно ли понимаете задачу, лучше задавайте/переформулируйте вопросы, снимайте видео, рисуйте макет, присылайте скриншоты.

Пример из жизни: проект

Нам прислали psd файлы для верстки, верстальщик сделал задание на свой лад без согласования с заказчиком. В итоге смета за 80 часов превратилась в смету за 101,5 часа + 60 часов на исправление ошибок, потому что заказчик увидел результат по-другому (например, абзацы, выравнивание текста и т.д.) .)

2. Переоценка своих возможностей.

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

Но ВСЕГДА все сломано, правильное решение не приходит сразу, и Менеджер проекта должен учитывать все риски. Потому что объяснять все клиенту — это ваша обязанность, а не разработчика.

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

Проект временной шкалы

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

Это была наша ошибка: мы изначально не изучили местность, не рассмотрели сложную архитектуру проекта и способ его реализации.

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

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

4. Молчание о своих проблемах, а также непонимание проблемы.

Если вы ничего не говорите о проблеме, это не значит, что у вас ее нет. Это всегда самый дешевый и простой способ исправить что-то сразу, чем все испортить. Если вы потерпите неудачу, сделайте это быстро!

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

5. Нет проверки того, сколько времени разработчик тратит на задачу. Разработчики ответственные люди и могут сами заполнять отчеты.

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

Если это не сделать вовремя, через 2–3 недели такие детали будет сложно вспомнить.

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

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

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

https://sloboda-studio.com/blog/2054-common-project-managers-mistakes/