Большая часть статей и книг о Product Owner/Product Manager посвящены умению определить правильный продукт. Но есть не менее важная часть работы — как сделать этот продукт вместе c командой.
Я задал два простых вопроса своим знакомым из разных продуктовых IT компаний:
- Что вы цените в хорошем PM’е?
- И, наоборот, что вас больше всего раздражает в манере ведения дел PM’ом?
Выборка не очень большая 20 человек: разработчики, дизайнеры и специалисты по тестированию. Вот итоговый хит-парад.
Положительные стороны.
1) Любовь к продукту. Сложно заразить окружающих идей, если она самому неинтересна. Тут недостаточно профессионализма, отныне для вас это главное увлечение.
- Вы должны знать все о пользователях, как и какие они решают проблемы с помощью вашего продукта или без него.
- Знать все об отрасли, конкурентах и смежных областях.
- Владеть статистикой и объективными количественными данными.
2) Общение и отношения с командой. Вы — главное связующее звено между совершенно разными людьми, часто слабо представляющими, чем занимается другая часть команды.
- Обсуждайте решения с командой, советуйтесь, внимательно слушайте. Не нужно быть пророком, который все знает и уже все решил.Чувствуйте, где стоит посоветоваться или доверить решение другому профессионалу.
- Доступность и открытость для команды. Не должно быть большой проблемой найти вас и обсудить сложный вопрос.
- К разным людям нужен разный подход, у каждого есть свой любимый способ общения. Для кого-то идеальный вариант — это разговор, а кто-то предпочитает выверенное письмо или комментарий в таск-трекере. Умейте сочетать разные формы и искать подход к разным людям.
3) Грамотное планирование, умение координировать различные команды. Старые и добрые навыки классического Project Manager’а.
- Дайте возможность заниматься профессионалам своим делом, оградите их от всего того, что им несвойственно, мешает или отвлекает. Взамен вы получите отдачу и очень высокую продуктивность.
- Четкое и грамотное описание продукта и задач. Хоть в agile главный способ передачи информации — разговор, это совершенно не отменяет актуальной документации. Для вас большая часть деталей кажется очевидной, но это далеко не так для остальных. Кроме того, разговоры имеют свойство забываться уже через пару дней.
- Разберитесь в основах работы различных участников команды, как они делают работу и что им для этого нужно. Снаряды нужно подвозить вовремя и правильного калибра.
А теперь главные минусы.
Неудивительно, что это зеркальное отражение положительных качеств. Но все же, на мой взгляд, стоит остановиться на них подробнее.
1) Микроменеджмент, самая страшная болезнь любого руководителя.
- Ни один менеджер не признался, что страдает этим. С другой стороны, этот диагноз всегда очевиден окружающим. Поговорите об этом с разными людьми в команде. Возможно, вы узнаете о себе много нового.
- Не нужно лезть в технические решения, даже если в прошлом вы были отличным разработчиком, или доказывать дизайнеру, что кнопка должна быть зеленой и справа. Это верный способ развалить команду или переругаться с отдельными участниками.
- Если ваши взгляды фундаментально расходятся, старайтесь не работать вместе, вы всем сэкономите кучу нервов и времени.
2) Не заставляйте команду делать ненужную работу.
- Ненужные встречи, отчеты, статус-митинги. Для команды это пустая трата времени. Всю эту информацию можно получить не отвлекая людей от работы.
- Готовьтесь к встречам. Вам кажется, что можно прийти на встречу и на ходу импровизировать. Со стороны это смотрится не так гладко. Как результат — непродуманные решения, задачи, которые потом придется переделывать. И переделывать не потому, что что-то изменилось в окружающем мире, а просто из-за того, что вам лень было это аккуратно продумать.
- Невнимание и неуважение к команде. Для вас сделали новый билд, макет или еще что-то. А вы даже не посмотрели. У команды ощущение, что результат никому не нужен. Зачем в следующий раз стараться, кто оценит?
3) Неумение сказать нет. Идей и взглядов будет всегда больше, чем вы можете сделать.
- Бесконечному потоку разных идей, хотелок и запросов. Бесконтрольные изменения планов, непонятный набор из сотни разных фич на релиз.
- Нет халтуре, должен быть высокий профессиональный уровень, ниже которого нельзя опускаться никому в команде.
- Нет внешним хотелкам, нереальным срокам и т. д. Защищайте команду от негативного внешнего влияния.
Заключение для PM’ов.
Получился довольно очевидный чеклист, но самое сложное — это следовать этим простым правилам. Проверьте себя, уделяете ли вы достаточно внимания этим вещам, что бы вы могли делать лучше?
Заключения для разработчиков.
Оставляйте в комментариях свой взгляд на работу PМ’а. Думаю, что это тот случай, когда комментарии будут намного интереснее статьи.
Автор: far4
