Руководитель продукта глазами разработчиков

Большая часть статей и книг о Product Owner/Product Manager посвящены умению определить правильный продукт. Но есть не менее важная часть работы — как сделать этот продукт вместе c командой.

Я задал два простых вопроса своим знакомым из разных продуктовых IT компаний:

• Что вы цените в хорошем PM’е?
• И, наоборот, что вас больше всего раздражает в манере ведения дел PM’ом?
  

Выборка не очень большая 20 человек: разработчики, дизайнеры и специалисты по тестированию. Вот итоговый хит-парад.

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

1) Любовь к продукту. Сложно заразить окружающих идей, если она самому неинтересна. Тут недостаточно профессионализма, отныне для вас это главное увлечение.

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

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

• Обсуждайте решения с командой, советуйтесь, внимательно слушайте. Не нужно быть пророком, который все знает и уже все решил.Чувствуйте, где стоит посоветоваться или доверить решение другому профессионалу.
  
• Доступность и открытость для команды. Не должно быть большой проблемой найти вас и обсудить сложный вопрос.
  
• К разным людям нужен разный подход, у каждого есть свой любимый способ общения. Для кого-то идеальный вариант — это разговор, а кто-то предпочитает выверенное письмо или комментарий в таск-трекере. Умейте сочетать разные формы и искать подход к разным людям.

3) Грамотное планирование, умение координировать различные команды. Старые и добрые навыки классического Project Manager’а.

• Дайте возможность заниматься профессионалам своим делом, оградите их от всего того, что им несвойственно, мешает или отвлекает. Взамен вы получите отдачу и очень высокую продуктивность.
• Четкое и грамотное описание продукта и задач. Хоть в agile главный способ передачи информации — разговор, это совершенно не отменяет актуальной документации. Для вас большая часть деталей кажется очевидной, но это далеко не так для остальных. Кроме того, разговоры имеют свойство забываться уже через пару дней.
• Разберитесь в основах работы различных участников команды, как они делают работу и что им для этого нужно. Снаряды нужно подвозить вовремя и правильного калибра.

А теперь главные минусы.

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

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

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

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

• Ненужные встречи, отчеты, статус-митинги. Для команды это пустая трата времени. Всю эту информацию можно получить не отвлекая людей от работы.
• Готовьтесь к встречам. Вам кажется, что можно прийти на встречу и на ходу импровизировать. Со стороны это смотрится не так гладко. Как результат — непродуманные решения, задачи, которые потом придется переделывать. И переделывать не потому, что что-то изменилось в окружающем мире, а просто из-за того, что вам лень было это аккуратно продумать.
• Невнимание и неуважение к команде. Для вас сделали новый билд, макет или еще что-то. А вы даже не посмотрели. У команды ощущение, что результат никому не нужен. Зачем в следующий раз стараться, кто оценит?

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

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

Заключение для PM’ов.

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

Заключения для разработчиков.

Оставляйте в комментариях свой взгляд на работу PМ’а. Думаю, что это тот случай, когда комментарии будут намного интереснее статьи.