Если вы пишете заметки, которые любой поймет без отсылок к каким-либо предварительным знаниям, то вы провóдите отличный четкий стендап. Или презентацию, или рабочую встречу. А когда вы не на встречах, то тратите несколько часов в день либо на изучение электронных таблиц, либо на данные из MySQL, либо на анализ стопки графиков и диаграмм. Если вы не погружаетесь глубоко в данные, то читаете отчеты, материал для изучения, исследования, статьи и всё, что попало вам в руки, удовлетворяя свою ненасытную потребность внести следующий раунд изменений и улучшений в ваш продукт, чтобы он продолжал расти и развиваться.
Ключевые идеи
• UX-дизайнерам позволительно сказать «Всё зависит от обстоятельств», а менеджеры продукта должны принимать решения.
• Менеджеры продукта уделяют внимание пользовательскому опыту и даже в некоторых случаях могут направлять его в нужное русло, но сами они не выполняют работу по дизайну.
• У UX и менеджера продукта многие навыки пересекаются, и это может стать хорошей основой для смены карьеры. Проанализируйте свои сильные стороны по всему спектру и найдите способы дополнить или развить слабые навыки.
• Информационная архитектура – это сверхспособность менеджера продукта, которая крайне полезна для формулирования и визуализации смысла и взаимосвязей, а также для достижения консенсуса в отношении общих забот команды.
• Исследователи пользователей – это естественные союзники менеджеров продукта, а опыт UX-специалистов в исследованиях может стать хорошим фундаментом для продуктовой работы.
• Использование дизайна для разработки экспериментов и проверки гипотез, измерение влияния дизайна по данным пользователей и ключевых метрик производительности переходят от сложных практик UX-дизайна в главную повседневную увлеченность менеджера продукта.
• Менеджеры продукта тратят намного больше времени на колонки цифр и маркированные списки, чем на визуальный дизайн интерфейса.
Глава 4Инженеры спорят
Бóльшая часть работы менеджера продукта заключается в том, чтобы обеспечить инженеров всем необходимым для продуктивной работы.
Иногда менеджеры продукта считают, что им достаточно давать указания инженерам, но затем они быстро понимают, что это все равно что пасти котов[26]. Это не работает, даже если ваши намерения – самые лучшие.
Ваша задача, наоборот, состоит в том, чтобы задать фокус, направление и смыслы, убедиться, что цели ясны, запросы четко сформулированы, а инженеры являются ключевыми участниками обсуждений и предлагают идеи, необходимые для воплощения всего этого в реальность.
Конечно, вы хотите, чтобы люди что-то делали. Вы задаете направление, поэтому вы должны всегда быть готовы и способны выразить сильную точку зрения, даже если вам придется выдумывать ее уже на месте. Но вы не диктатор. Инженеры не подчиняются вам в 99 % случаев, да и не должны.
Но они являются частью вашей команды, той, которую вам нужно воспитывать и лелеять, делать максимально продуктивной. Поэтому исследование проблем, определение требований и уточнение нюансов – все это помогает вашим инженерам фокусироваться на том, что у них получается лучше всего. (Мотивация, убеждение и сплочение становятся также неотъемлемой частью работы.)
Кроме того, помните, что инженеры – это творческие люди. Если только они сами не являются менеджерами (в этом случае инженеры выступают как ваши ближайшие коллеги по многим областям), то они работают как создатели, которым полезно иметь большие промежутки времени, когда их никто не отвлекает от создания сложных мыслительных моделей текущей проблемы, решения, алгоритма или логической задачи.
По этой причине старайтесь не мучить инженеров краткими вмешательствами, а лучше сосредоточьте свое общение, обратную связь и указания в асинхронных письменных сообщениях, которые разработчики могут просмотреть в подходящее время, и на регулярных периодичных ритуалах гибких методологий.
Поддерживать согласованность в команде инженеров
На данном этапе вашей UX-карьеры вы, возможно, хотя бы вскользь познакомились с такими понятиями, как стендапы и спринты, но вы могли не всегда в них участвовать ежедневно или еженедельно. Менеджеры продукта устанавливают свои часы по этим «ритуалам», которые формально являются структурированными встречами, обычно посвященными синхронизации или сверке часов, но могут быть ретроспективными или касаться будущего в зависимости от того, где вы находитесь в производственном цикле.
Эти циклы (ежедневные стендапы, недельные спринты или ежемесячные обновления дорожной карты, квартальное планирование) в совокупности называются каденциями. Они составляют ваш основной канал для сотрудничества с инженерами и определения направления их работы.
Представьте себе эти повторяющиеся встречи в виде фракталов. На каждом уровне вы снова и снова делаете какие-то вещи, и по каждой более продолжительной каденции ставки становятся на порядок выше.
Почти для каждой команды, практикующей гибкую разработку, наименьшей каденцией является ежедневный стендап (рис. 4.1). Традиционно человек отчитывается стоя, чтобы все помнили, что это короткая встреча, а не детальное рабочее совещание. Каждый человек отчитывается о том, что сделал за прошедшее время, что планирует выполнить на следующий день, и, возможно, отмечает то, что препятствует работе.
Рис. 4.1. Как и положено, команды, практикующие гибкую разработку, отчитываются раз в день (рабочий), чтобы проанализировать прогресс, следующие шаги и препятствия
Ежедневный стендап – это лишь один из ритуалов[27] (от регулярной обработки списка задач до планирования спринтов, демонстраций, приемки продукта и ретроспективы), который проводится во время спринта, обычно длящегося от двух до четырех недель (рис. 4.2).
Рис. 4.2. На протяжении всего спринта будут проводиться и другие ритуалы (в начале, середине или конце)
Раз в месяц рекомендуется просматривать дорожную карту, чтобы убедиться, что все пункты «Сейчас» выполняются в соответствии с планом, список «Следующий шаг» все еще актуален и точен, ведется подготовка к тому, когда эти пункты перейдут в «Сейчас», и все другие идеи за горизонтом отражены в разделе «Позже» (рис. 4.3).
Рис. 4.3. Поскольку дорожные карты формально не могут обновляться чаще, чем раз в квартал, будет полезно просматривать их раз в месяц, чтобы оценить, идет ли все по плану или дрейфует куда-то в сторону
В некоторых компаниях, например в Intercom, в дополнение к ежемесячным сверкам с дорожными картами каждый квартал разбивается на отрезки по шесть недель и одну «неделю колебаний» посередине. Раз в квартал команда по управлению продуктом совместно с другими заинтересованными сторонами анализирует прогресс в достижении целей с самого начала, определяет цели для предстоящего квартала и оценивает прогресс в соответствии с годовым планом (рис. 4.4).
Рис. 4.4. Ежеквартальное планирование обеспечивает структуру для четырех-шести спринтов вперед
Раз в год вы можете критически оценить результаты прошедшего года и сравнить их с планами, составленными в конце предыдущего такого же периода, поразиться тому, как много произошло неожиданного, извлечь уроки и пересмотреть ви́дение, миссию и цели на 5, 10 или даже 20 лет, а затем составить рабочий план на предстоящий год (рис. 4.5).
На каждом уровне заложены несколько простых принципов работы, которые помогают удерживать их совмещение и корректировать ваше управление в любом масштабе. Как концепция «бережного производства» основывается на фундаментальном цикле «создавай, измеряй и изучай», так и практики гибких методологий следуют очень схожему принципу, который сводится к «итерируй, проверь и перенастройся» (повторить), в сочетании с идеей, что на каждом уровне ваша цель должна быть выражена в том, что вы можете проверить, протестировать и либо отправить обратно для доработки, либо принять.
Рис. 4.5. Пришло время для ежегодного корпоративного ретрита!
Принципы и практики гибких методологий пронизывает подход рутинной коррекции курса «с предпочтением более коротких временны́х промежутков» (Принципы, лежащие в основе Agile-манифеста[28]).
Если мы говорим о систематическом итеративном улучшении командных процессов с течением времени, то только один из первоначальных 12 принципов Agile (последний) прямо излагает этот принцип:
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
SAFe® – это палка о двух концах
Вы обнаружили, что работаете в организации, которая внедрила SAFe® (Scaled Agile Framework® для предприятия). Мне жаль, но SAFe® – это дьявол. Это корпоративный набор формальных процессов в стиле Agile, которые создают так называемый agilefall – переизобретенный водопад, то есть каскадный план проекта (именно то, против чего восстал Agile-манифест) с ловушками жесткой интерпретации ритуалов Agile. Тем не менее организации, использующие SAFe®, часто получают пользу от этого подхода, если сравнивать с тем, что они на него заменили. И в этом смысле его можно рассматривать как шаг в правильном направлении в решении сложной задачи, которая заключается в том, чтобы предложить большой корпорации полностью принять самые сложные аспекты гибкости.
Если вы остановитесь на мгновение и задумаетесь, то поймете, что этот принцип охватывает уровень выше – это «метапринцип». В основном он берет силу из этой обманчиво простой идеи (рутинных проверок и коррекции курса) и советует вам применить ее к тому, как в целом работает команда, а не только к написанию кода и его тестированию. Очень мощная штука!