Менеджер По Продукту Глазами Разработчиков

Большинство статей и книг о владельце продукта/менеджере продукта сосредоточены на выборе правильного продукта.

Но есть не менее важная часть работы — как сделать этот продукт вместе с командой.

Я задал два простых вопроса своим друзьям из разных компаний, производящих ИТ-продукты:

  • Что вы цените в хорошем ПМ?
  • И наоборот, что вас больше всего раздражает в том, как премьер-министр ведет дела?
Выборка не очень большая: 20 человек: разработчики, дизайнеры и специалисты по тестированию.

Вот и завершился хит-парад.

Положительные стороны.

1) Любовь к товару.

Трудно заразить идеей других, если самому она не интересна.

Здесь не хватает профессионализма, отныне это ваше главное хобби.

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

  • Знайте все об отрасли, конкурентах и смежных областях.

  • Обладать статистикой и объективными количественными данными.

2) Коммуникация и отношения с коллективом.

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

  • Обсуждайте решения с командой, советуйтесь, внимательно слушайте.

    Не нужно быть пророком, который все знает и уже все решил.

    Почувствуйте, где вам следует проконсультироваться или доверить решение другому профессионалу.

  • Доступность и открытость к команде.

    Найти вас и обсудить сложный вопрос не должно составить большой проблемы.

  • Разным людям нужны разные подходы, у каждого свой любимый способ общения.

    Для кого-то идеальный вариант — разговор, а кто-то предпочитает проверенное письмо или комментарий в трекере задач.

    Умейте сочетать разные формы и находить подход к разным людям.

3) Грамотное планирование, умение координировать действия различных команд. Старые добрые навыки классического менеджера проектов.

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

  • Четкое и грамотное описание продукта и задач.

    Хотя в agile основным способом передачи информации является разговор, это совершенно не заменяет актуальную документацию.

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

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

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

    Снаряды должны быть доставлены вовремя и нужного калибра.



А теперь основные минусы.

Неудивительно, что это зеркальное отражение положительных качеств.

Но все же, на мой взгляд, стоит остановиться на них подробнее.

1) Микроменеджмент, самая страшная болезнь любого лидера.

  • Ни один менеджер не признался, что страдает от этого.

    С другой стороны, этот диагноз всегда очевиден для окружающих.

    Поговорите об этом с разными людьми в команде.

    Вы можете узнать о себе много нового.

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

    Это верный способ расколоть коллектив или поссорить отдельных участников.

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

2) Не заставляйте команду делать ненужную работу.

  • Ненужные встречи, отчеты, статусные встречи.

    Это пустая трата времени для команды.

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

  • Готовьтесь к встречам.

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

    Внешне все выглядит не так гладко.

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

    И переделывать не потому, что что-то изменилось в окружающем мире, а просто потому, что вам лень тщательно это продумать.

  • Невнимательность и неуважение к коллективу.

    Сделали для вас новую сборку, планировку или что-то еще.

    А ты даже не посмотрел.

    Команда чувствует, что результат никому не нужен.

    Зачем пробовать в следующий раз, кто оценит?

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

  • Бесконечный поток разных идей, желаний и запросов.

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

  • Никакой халтуры, должен быть высокий профессиональный уровень, ниже которого никто в команде не может опуститься.

  • Никаких внешних пожеланий, нереальных сроков и т. д. Защитите команду от негативного внешнего воздействия.



Вывод для ПМ.

Это довольно очевидный контрольный список, но самое сложное — следовать этим простым правилам.

Проверьте себя, достаточно ли вы внимания уделяете этим вещам, что вы могли бы сделать лучше?

Выводы для разработчиков.

Свои мнения о работе ПМ оставляйте в комментариях.

Думаю, это тот случай, когда комментарии будут гораздо интереснее статьи.

Теги: #менеджер по продукту #отношения в команде #Веб-аналитика

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.