Как надо и не надо делать. Ярким примером является то, что в жизни продукта и команды бывают критические ситуации, например что-то перестает работать в продакшене и начинается сильный негатив от клиентов, а это еще вдобавок нерабочее время или выходные. Твое непосредственное включение в проблему на уровне члена команды, а не руководителя значительно снижает факторы негатива в команде, а вовлеченность поддерживает моральную составляющую и повышает скорость решения проблемы.
У нас была ситуация, когда после релиза очередной версии продукта, который был в субботу в шесть утра, спустя несколько часов начались проблемы. К нам прилетели первые ласточки от клиентов и нужно было включиться в решение проблемы. Первым делом мы самостоятельно пытались локализовать проблему и начали подключать к решению соответствующих людей от разных подразделений, включая инфраструктуру. Организовали созвон, на котором сами присутствовали и разбирались с проблемой и вытаскивали ребят по мере их возможности и необходимости. Мы не переложили проблему на тестирование или поддержку, а сами принимали активное участие в тестировании и локализации проблемы, что сильно помогало команде и снижало уровень стресса.
Вывод: старайся управлять командой не через указания и административное влияние, а через свой личный пример, рвение к целям и результатам, которые должны быть доступны через тебя каждому сотруднику в твоей команде.
– — – — – — – — – — – — – — – — – — – —
Итак, мы разобрались, что владелец продукта должен быть другом в команде и никак не жестким руководителем, который навязывает команде совершенно непонятные для нее цели и способы достижения мифических результатов. Владельцы продукта в большинстве случаев относятся к продуктовым вертикалям, департаментам, отделам, все зависит от организационной структуры, принятой в компании. Как правило, есть вторая вертикаль – техническая, куда