Как PM взаимодействует с дизайнерами, разработчиками и бизнесом?
Как говорилось выше, менеджер продукта не является руководителем для членов команды. Он такой же участник, как и все остальные, без каких-либо дополнительных рычагов и привилегий — отдельный и самостоятельный специалист в своей области. Как тогда взаимодействовать друг с другом? Кто кого слушает, за кем последнее слово и почему?
При работе над продуктом команда придерживается процессов. Процессы — это договорённости участников команды о взаимодействии друг с другом. Своеобразный свод правил и набор соглашений. Существуют даже манифесты для таких правил. Самый популярный — Agile. Команда может использовать какой-то фреймворк для организации процессов, например Scrum, но в деталях у каждой команды будут свои процессы и привычки, даже в рамках одной компании.
PM для команды является заказчиком (или стейкхолдером). Он ставит задачи и принимает результат. Исходя из этого строится взаимодействие. Например, при работе с дизайнерами продакт ставит задачу, в которой описан ожидаемый результат. В задаче не указывается, какие использовать цвета, где должны быть объекты и какого они должны быть размера — это решит дизайнер самостоятельно. Максимум — допустимо перечислить список желаемых элементов, но некоторых специалистов даже это может раздражать. Дизайнер берёт задачу в работу и разрабатывает решение, ориентируясь на ожидаемый результат. Он имеет полное право реализовать на макетах любое решение, соответствующее задаче. Дизайнер — это профессионал, и он лучше понимает, как нужно строить интерфейсы, чем продакт.
После того как макеты готовы, дизайнер и продакт вместе обсуждают решение. Это важный этап, к которому нужно серьёзно отнестись. Необходимо внимательно изучить результат, оценить, насколько хорошо он решает задачу пользователя, и задать дизайнеру уточняющие вопросы. На этом этапе не нужно искать компромиссы между ожиданиями продуктового менеджера и предложением дизайнера. Нужно либо принять решение, либо, если оно не решает проблему пользователя, искать другое. Несмотря на то, что автором решения является дизайнер, ответственность за его принятие (и за выполнение задачи) лежит на PM. Он даёт зелёный свет.
Примерно так же строится работа и с разработчиками. Единственное отличие в том, что соответствие техническим и бизнес-требованиям будет проверять не продакт, а QA (инженер по качеству или тестировщик). Проверка результата работы разработчика — настолько специфичный процесс, что менеджер продукта просто не сможет выполнить его самостоятельно, как минимум из-за нехватки технических компетенций.
С представителями бизнеса процессы строятся наоборот. Теперь уже PM выступает исполнителем, а «бизнес» (топ-менеджеры, CPO, инвесторы и т. д.) — заказчиком. И в компаниях со здоровыми процессами бизнес тоже описывает ожидаемый результат — например, в виде ключевых результатов или KPI по метрикам (показателям), — а product-менеджер самостоятельно ищет решение.