Управление продуктом для UX-специалистов (страница 4)
Перенесемся в настоящее – эта роль по-прежнему остается весьма технической. Сильный UX-специалист испытывает серьезный интерес к технологии, с помощью которой и для которой он проектирует, подобно тому как художники стараются разобраться в своих материалах. Но в то же время дизайнер в состоянии исследовать возможности, не беря в расчет очевидные ограничения существующего технического стека и кодовой базы.
Менеджеры продуктов (и не только «технические»), напротив, должны глубже вникать в суть, свойства и ограничения технологий, с которыми они работают, и никогда не позволять себе роскоши отодвигать все эти факторы на второй план. (ПМ также тратят намного больше времени на прямое взаимодействие с инженерами, нежели UX-дизайнеры, что создает еще бóльшую необходимость демонстрировать доскональное знание технических вопросов, которые всплывают при любом принятии сложного решения.)
Новая гибридная инженерно-бизнесовая модель продукта на практике по-прежнему оставляет желать лучшего, поскольку большинство компаний по-прежнему разрабатывают ПО по водопадной схеме и командуют разработчиками в стиле «начальник всегда прав», но примерно в первое десятилетие нашего века несколько влиятельных специалистов, изучавших лучшие практики Кремниевой долины, начали формулировать новую модель «бережливого», «гибкого» и «полностью уполномоченного» управления продуктами.
Менеджер продукта как исследователь-экспериментатор
Марти Каган, консультант в Silicon Valley Product Group[11] и автор книги «Вдохновленные»[12] (Inspired), убедительно обосновал расширение полномочий для команды по продукту, потому что им необходимо изучать проблемные области, управлять исследовательскими процессами, встречаться лицом к лицу с клиентами и планами на будущее, подбираться к глубокому пониманию, что необходимо людям и что им понравится, дабы вывести на рынок ценные продукты.
Рич Миронов, консультант по продуктам для компаний, работает по контракту на топ-менеджерских должностях, связанных с продуктами (он называет это «парашютист-пожарный»), пишет статьи и проводит мастер-классы. Он и ему подобные люди стремятся поднять планку и выделить наиболее эффективные методы, подходы и образ мышления, оставаясь при этом здравомыслящими и осторожными в отношении институциональных моделей и мотиваций, которые могут противодействовать таким подходам.
Например, наделенная полномочиями команда продукта должна понимать цели и результаты, к которым она движется, и участвовать в итерационном экспериментировании для достижения этих целей. Команда должна уметь донести до других, каково текущее состояние плана, в форме дорожной карты (подробнее об этом ниже), описывая то, что выполняется прямо сейчас, что будет следующим шагом и что ожидается после этого.
Многие руководители в традиционных организациях сопротивляются, когда видят обрисованную таким способом дорожную карту, особенно если они ожидали, что она будет выглядеть как последовательность четких дат выпуска конкретной функциональности.
Но обязательство предоставить функциональность к определенной дате на основании полностью подготовленной спецификации – это рецепт провала. Этот процесс слишком хрупок и ломается при появлении новой информации, данных от пользователей и заказчиков-стейкхолдеров, изменении условий рынка – я перечислил лишь некоторые из факторов.
Это та же идея сторонников «бережливости», популяризированная книгой Эрика Райса «Бережливый стартап»[13] (Teh Lean Startup), когда менеджер продукта в уполномоченной команде управляет непрерывным PDCA-циклом, который содержит следующее: изучение того, что в настоящее время «поставляется» и «по-прежнему используется»; включение найденных идей в обновленный исследовательский процесс, организованный в форме качественных исследований[14] и направленный на проверку гипотез и поиск понимания; переопределение проблемной области; выявление дальнейших возможностей или стóящих экспериментов; принятие решений о том, что создавать или исправлять дальше; и выпуск следующей версии продукта, после чего цикл начинается заново.
Этот цикл, показанный на рис. 1.1, можно смоделировать в мельчайших деталях, но чаще всего он сводится к «Созданию, измерению, изучению»[15].
Рис. 1.1. «Создание, измерение, изучение» – это простая, но мощная модель, которая лежит в основе бережливого управления продуктом, с его склонностью к действиям и акценту на изучение и эксперименты
Стоит отметить, что несмотря на заголовок и то, что это все является циклом, вы обычно не начинаете с создания продукта. Вы начинаете с изучения или измерения (первоначальной оценки) чего-то, узнаёте то, что относится к предмету вашего исследования, а затем создаете.
Этот процесс постоянного изучения, изменения выводов на основе полученных данных, переосмысления проблем и возможностей, итеративного проектирования применим на ранних стадиях при создании прототипов новых идей, а также на протяжении всей жизни продукта. У этого подхода все еще появляются новые приверженцы (например, такие люди, как Джефф Готхелф и Джош Сейден, упорно трудились, чтобы донести идеи бережливости в экспериментах до UX-сообщества).