image

РМ — человек, от которого зависит успех проекта. Он контролирует не только выполнение задач, но и следит за настроением разработчика, мирится с неадекватными заказчиками и разбирается в хаосе сорванных дедлайнов. Мы попросили экспертов — спикеров интенсива Project management in IT — рассказать о типичных ошибках project-менеджеров и о том, как их избежать.

1. Рассказывать только хорошие новости


image

Не бойтесь критиковать команду. Исправление ошибок — это нормальный рабочий процесс, который поможет проекту и его участникам быстрее идти вперед. Главное — не переругать, это демотивирует.

imageРассказывать нужно как хорошее, так и плохое. Команда должна быть в одном контексте и бежать в одном направлении.
При этом не стоит лишний раз пугать людей, если не уверен, что проблема реально есть. Это как в сказке про мальчика, который кричал «Волки!»
Если попытаться привести к универсальному правилу, рассказывайте команде о том, что точно может на нее повлиять.

                                                                                              Павел Макуха, Product manager, Skyeng

2. Менять модели управления проектом на ходу


image

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

imageИзменения несут риски и «переобуться на ходу» получается не всегда. Но если менеджер хорошо разбирается в методологиях, понимает технологию внедрения, и решение о смене модели управления принято осознанно, — то почему нет?

Но прежде чем инициировать переход, стоит убедиться, что вы не находитесь в следующих условиях:

  • У проекта минимальные временные буферы;
  • Вы управляете одним из ключевых для компании проектов и планируете провести эксперимент именно на нём;
  • Заказчик не готов к новым процессам;
  • Команда проекта не согласна и не готова к изменениям;
  • Модель оплаты не стыкуется с новой методологией управления (например, Fixed Price проекты не очень круто делать по SCRUM).
                          Михаил Косенко, Руководитель отдела управления проектами, Redmadrobot

3. Считать заказчика глупым и не слушать его


image

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

Самый простой способ договориться в таком случае — привести все к деньгам. Для этого я использую такие вопросы:

  • Какую проблему решает эта задача?
  • Что случится, когда будет готово?
  • Какие обязательные требования к результату?
  • Какой крайний срок и почему?
  • Что будет, если не сделать?
  • Сколько принесет денег? Сколько потеряем, если не сделать?

Обычно это помогает. Но всегда остается вероятность 5%, что ваш заказчик мудак. По возможности избегайте работы с мудаками.

                                                                                              Павел Макуха, Product manager, Skyeng

4. Не расставлять приоритеты и менять их без весомой причины


image

imageСтандартная матрица приоритетов предлагает такой порядок: срочное и важное, несрочное и важное, срочное и неважное и уже в конце очереди, если до нее доходит, несрочное и неважное. Это хорошо применимо на уровне текущих дел. В эту матрицу хорошо укладываются типовые приоритеты: blocker, critical, major, minor, trivial.

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

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

Мой хак для проверки в таких случаях — вопрос: «а что будет для проекта/компании/для меня, если я сейчас/вообще не сделаю эту задачу?».
                                                                       Маргарита Андрианова, Project manager, Notamedia

5. Бояться уволить сотрудника


image

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

imageПроджект не может никого уволить, но может дать обратную связь о работе каждого участника команды и указать на моменты, которые могут стать причиной для увольнения:

  • Систематический срыв сроков. К тому, что сроки в разработке плавающие, все привыкли. Но если разработчик или дизайнер из раза в раз срывает срок, который сам же обозначил — это повод для беседы.
  • Личные дела на рабочем месте: учеба, подработка, хобби, соцсети. Если сотрудник большую часть времени занят чем угодно, но не свой непосредственной работой, нужно что-то менять.
  • Замалчивание сложностей. Это справедливо и для участника команды, и для менеджера: если проблема есть, или она только намечается, о ней надо сразу говорить.
                                                                                          Ольга Дрозд, Product manager, MegaLabs

6. Не анализировать проект во время и после реализации


image

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

imagePM управляет развитием и прибыльностью проекта, а значит, должен уметь анализировать рынок, конкурентов, показатели проекта и деятельности команды. Поэтому PM должен владеть навыками аналитика как минимум на среднем уровне.

Каждый проект дает нам достаточное количество полезной информации — как минимум явно ошибочные суждения.

На одном проекте мы запустили вертикаль, которая в целом проекту давала минус, но внимательное изучение показало, что это нужно и полезно нашим клиентам. В итоге вынесли вертикаль в отдельный проект и получили успешный продукт.
                                                                              Леонид Евтушенко, Project manager, OneTwoTrip

7. Не оценивать риски


image

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

imageНевыполнимые задачи — это вызов и возможность вырасти из собственных границ. Однако нельзя хвататься за них, пообещав, что все будет безусловно исполнено.

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

В моей жизни были интересные невыполнимые задачи, с которыми я справилась. Каждая из них была невероятным скачком вверх. Были и задачи, от которых я отказалась. Ничего плохого в этом нет, так как никому не интересно отдавать работу тому, кто ее не может и не хочет делать.
                                                                    Маргарита Андрианова, Project manager, Notamedia

8. Не доверять команде и делать все самому


image

Одна из основных ошибок начинающих менеджеров. Слишком велик соблазн сделать все самому: «так будет быстрее и лучше, а у нас сроки поджимают. В следующем квартале исправлюсь и буду ставить задачи».

Так не получится. Вся суть проджекта — достигнуть результата вместе с командой.

imageОсновная проблема делегирования — доверие. При передаче задачи передается и ответственность за нее. Чтобы этот процесс прошел легче, можно придерживаться схемы:

  • Что? Понять, что именно вы планируете делегировать.
  • Кому? Исходя из первого пункта понять, кому именно в вашей команде можно передать эту задачу.
  • Как? Опишите задачу и желаемый результат. Это позволит систематизировать процесс и свои собственные ожидания.
  • Когда? Четкий срок так же важен, как правильная формулировка задачи.
                                                                                          Ольга Дрозд, Product manager, MegaLabs

9. Не учитывать интересы и навыки членов команды


image

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

imageЛучше не жестить и стараться избегать превращения рабочего процесса в бесконечную рутину. По возможности в спринт мы включаем 1–2 второстепенные задачи, которые хочется сделать разработчику: это может быть небольшая анимация, тень или какая-то пасхалка.

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

                                                                                          Ольга Дрозд, Product manager, MegaLabs

10. Отказываться от экспериментов и всего нового


image

Общайтесь, ходите на конференции, узнавайте новое — это несложно. Гораздо сложнее догонять, если вы слишком увлеклись существующими методами, а весь рынок уже работает быстрее и эффективнее.

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

В Redmadrobot используется эволюционный подход развития производства, изменения происходят постоянно и поэтапно. Серьезные обновления мы вначале проводим на одном-двух проектах и после рефлексии по результатам пилота масштабируем на остальные проекты.

                          Михаил Косенко, Руководитель отдела управления проектами, Redmadrobot

Научиться грамотно вести проекты в IT, пообщаться со спикерами из этой статьи и задать им вопросы можно на интенсиве Project management in IT. Ближайший пройдет 26 и 27 мая.

Комментарии (4)


  1. SDKiller
    23.05.2018 19:30
    +5

    С гифками перебор


    1. Daniyar94
      23.05.2018 22:00
      +1

      Закос под BuzzFeed и Medium блоги :)


  1. realbtr
    23.05.2018 20:53
    +2

    Двойственные впечатления. Цитаты неплохие, но подача материала озадачивает. То ли за ребенка считают и включили «уси-пуси», то ли обидеть хотели. Как-то неловко минусовать, но и плюс не поставить


  1. Jenyay
    23.05.2018 22:04
    +1

    Честно говоря, читать невозможно из-за мельтешения гифок.