Текст книги "Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании"

Если вам все-таки важно реализовать свое решение, попробуйте понять, сможет ли команда совершить запуск сейчас и активно поработать на погашение технического долга после. Используйте этот подход, только если вы действительно сможете найти для него время.

• Партнерство имеет решающее значение: самый важный технический навык – это выстраивание прочных партнерских отношений с инженерами. Если вы не боитесь задавать вопросы и привлекаете разработчиков на ранних этапах жизненного цикла продукта, вы почти всегда получите технические данные, нужные для работы.

• Для понимания технологии, на которой основан ваш продукт, техническое образование не требуется: изучите техническую инфраструктуру своего продукта настолько, чтобы понимать, как она может влиять на решения, касающиеся пользователей. Не позволяйте неуверенности или смущению помешать вам узнать, какие есть ограничения. Задавайте вопросы.

• Разберитесь, что стоит за фразой «Это слишком сложно»: когда разработчик говорит, что выполнить какую-то задачу слишком сложно, это может означать разные вещи. Узнайте, что конкретно имеется в виду, и примите соответствующие меры.

• Оценка затрат – это навык, который вы приобретаете со временем: вырабатывайте собственное мнение о том, сколько усилий занимает создание той или иной функции, что может сократить или увеличить время реализации проекта. Используйте это суждение для оценки решений и подбора альтернативных вариантов, но обязательно консультируйтесь с разработчиками, чтобы ничего не упустить.

Глава 9
Документация по продукту

Наконец, мы переходим к разговору о документации по продукту! Это единственный осязаемый результат, за который действительно отвечает PM.

Но будьте осторожны.

Часто PM ожидают слишком многого от готовой документации и слишком мало вкладывают в обдумывание и совместную работу, которые стоят за ее написанием.

Неважно, каким документом вы пользуетесь: спецификацией (spec), техническим заданием (Product Requirements Doc, PRD), одностраничным шаблоном (lean product canvas) или продуктовым брифом (product brief) – у них всех одно назначение, и в них нет никакой магии. Любой из этих документов – всего лишь инструмент, который помогает прорабатывать важные моменты, обмениваться идеями, получать обратную связь и улучшать план работы. И, как и любые другие инструменты, их иногда неправильно используют.

Именно поэтому так важно сосредоточиться не на конечном результате, а на процессе создания документа и его совершенствовании. Все действия, которые выполняются с продуктом в течение его жизненного цикла, сводятся воедино в документации. Оформление информации в письменном виде дает вам шанс заметить, если вы что-то упустили или сделали неверные предположения, до того, как это вызовет проблемы. Главная задача документации по продукту – не ознакомить команду со своим идеальным планом, а сделать этот план лучше!

Не стоит относиться к документации как к чему-то предназначенному только для других людей. Воспользуйтесь процессом ее написания, чтобы упорядочить свои идеи, составить план дальнейших действий, учесть возможные риски и в целом прояснить мысли.

Чтобы вспомнить, какие стороны процесса следует продумать, обратитесь к шаблонам спецификаций, – там есть вся эта информация. Однако, используя шаблоны, не забудьте удалить из них неактуальные разделы и формулировки, иначе готовую спецификацию будет сложно прочесть. Составляя шаблон спецификации, думайте о том, сколько времени и сил потребуется, чтобы его заполнить. Если он будет слишком сложным и длинным, то люди просто перестанут им пользоваться.

Самое важное, чтобы вашу спецификацию читали и понимали. Этого нелегко добиться, потому что люди не любят читать спецификации.

Дадим несколько советов:

• Используйте диаграммы и рисунки для иллюстрации концепций.

• Оформляйте маркированные списки для выделения важной информации, чтобы она не потерялась в сплошном тексте.

• Будьте кратки – переместите как можно больше сведений в приложение к документу.

• Упомяните о рассмотренных альтернативах и предоставьте свои аргументы.

• Выделите спорные моменты и места, по которым вам больше всего нужна обратная связь и согласование.

• Узнайте у своих ключевых партнеров, устраивает ли их формат спецификации и не хотели бы они в ней что-то изменить.

Если ни один из этих пунктов не сработает, вы можете обсудить самые важные моменты со своей командой вживую. Не стоит ожидать, что люди прочитают документ.

Прежде чем закончить работу над спецификацией, получите обратную связь от всех важных стейкхолдеров. Если какая-то проблема существует, то лучше узнать о ней именно сейчас.

В первую очередь покажите спецификацию своим ближайшим коллегам – дизайнеру и инженеру. Если вы еще в самом начале карьеры, то еще лучше перед этим показать документ своему ментору или руководителю. Как только они скажут свое слово, можно показывать спецификацию дальше.

В зависимости от корпоративных традиций и личных предпочтений вы можете попросить коллег дать обратную связь в удобное для них время в письменном виде или попросить высказать свое мнение в ходе живой встречи.

Если у вас есть выбор, то лучше выбрать асинхронный сбор отзывов – так вы сможете собрать их все до того, как начнете на них отвечать. Может оказаться, что какие-то мнения противоречат друг другу, или обнаружатся спорные моменты, требующие дальнейшего обсуждения. Когда вы можете в спокойном режиме прочесть отзывы, это позволяет лучше подготовиться к последующим шагам.

Некоторое время спецификация будет источником истины. И в этот период в случае любых изменений она должна соответствующим образом обновляться.

В какой-то момент имеет смысл сместить источник истины на что-то другое, например дизайнерские мокапы, тикеты (запросы на разработку) или рабочий код. И здесь очень важно четко озвучить, что ваша спецификация больше не обновляется, и убедиться, что все заинтересованные стороны это понимают.

Для поддержания источника истины не требуется каких-то невероятных усилий. Часто бывает, что какие-то части документа берутся из старых спецификаций, или одну спецификацию приходится разбивать на несколько более мелких. Это та еще работа, но она стоит затраченных усилий, так как позволяет избежать ситуаций, когда кто-то начинает следовать устаревшим инструкциям.

Документация по продукту – одна из немногих вещей, за конечный результат которой фактически отвечает PM. Но на деле разработка спецификации – это не его работа. Случается, что PM тратит слишком много времени на то, чтобы довести спецификацию до идеала, так как по сути это единственное, что полностью находится под его контролем. Поэтому важно следить за тем, что вы ориентированы на долгосрочный результат, а не физическое создание документа. Например, спросите: «Удалось ли нам выявить и устранить риски? Все ли действовали в соответствии с планом? Успешно ли прошел запуск?»

Книга – это продукт, и с нашей книгой вы, читатели, уже знакомы. Давайте посмотрим, как может выглядеть спецификация для этого продукта.

Следование шаблону, подобному тому, что указан ниже, поможет выявить важные детали и гарантировать, что вы будете решать именно те проблемы, которые действительно волнуют людей.

Обратите внимание на частое использование заголовков и маркированных списков, которые облегчают поиск ключевой информации. В разделе «Варианты использования» перечислены важные сценарии и случаи применения, которые должны быть реализованы в продукте. Раздел «Основные дилеммы и решения» описывает, для каких мест в книге PM рассматривал различные альтернативы, чтобы в дальнейшем читатели могли лучше понять аргументацию автора.

ПРОБЛЕМЫ

• Компании часто создают ужасные продукты, которые могли бы быть намного лучше при более эффективном продакт-менеджменте.

• PM не всегда знают, что от них требуется.

• Даже самым лучшим PM не всегда удается эффективно управлять своей собственной карьерой, поэтому они не всегда имеют столько влияния, сколько должны.

• Менторы зачастую действуют не так эффективно, как могли бы, потому что тратят слишком много времени, отвечая на элементарные вопросы.

ЦЕЛИ

• Больше качественных продуктов

◊ Как должен выглядеть успех: люди говорят, что книга помогла им создать более качественные продукты.

• Больше эффективных PM

◊ Как должен выглядеть успех: книга хорошо продается и получает хорошие оценки от PM и их руководителей.

• PM получают признание и продвижение по службе, которых заслуживают

◊ Как должен выглядеть успех: в отзывах на платформе Amazon читатели пишут, что книга помогла им получить повышение.

• У менторов больше времени для индивидуальной работы с учениками

◊ Как должен выглядеть успех: менторы PM рекомендуют книгу.

• Международное признание

◊ Как должен выглядеть успех: читатели не говорят, что книга слишком ориентирована на США.

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

Формат «Работа, которую нужно сделать (JTBD)» (из одноименного раздела).

• Если я только в начале карьеры, я хочу:

◊ Получить навыки PM, узнать секретные приемы и хитрости, чтобы

« быть лучшим в своем деле;

« не оказаться в неловком положении, совершив ошибку.

◊ Понять структуру карьерной лестницы PM, чтобы

« сосредоточиться на наиболее важных навыках;

« быстро продвигаться вверх.

◊ Научиться ставить карьерные цели, чтобы

« быть уверенным, что я получаю правильный опыт;

« понять, хочу ли я руководить людьми;

« избежать участия в крысиных бегах.

• Если я не могу получить продвижение, я хочу:

◊ Четко понять ожидания, предъявляемые PM на каждом конкретном уровне, чтобы

« выявить ошибки;

« сосредоточиться на важных действиях.

• Если я занимаю руководящую должность в продакт-менеджменте, я хочу:

◊ Научиться лучшим методам управления командой, чтобы

« настроить свою команду на успех;

« помочь росту PM в своей команде.

◊ Получить документ с описанием того, каким должен быть лучший PM, чтобы

« показать PM из своей команды, на чем им нужно сфокусироваться, чтобы получить продвижение;

« получить ориентир для проведения индивидуальных менторских сессий.

ГРАФИК

1. Содержание (1 день).

2. Первый черновой вариант (4 месяца).

3. Углубленные интервью (2 месяца).

4. Доработка проекта (3 месяца).

5. Отзывы бета-ридеров и редактирование рукописи (2 месяца).

6. Публикация (1 месяц).

ПОДРОБНОЕ ПРЕДЛОЖЕНИЕ

Навыки PM

• 80 % книги.

• Расписать, что означает каждый из навыков PM и на чем следует сосредоточиться, находясь внизу, в середине или на вершине карьерной лестницы.

• Распределить по группам: продуктовые, стратегические, лидерские, управленческие навыки и навыки реализации.

• Добавить реальные цитаты везде, где это возможно.

Управление карьерой

• 20 % книги.

• Обо всем, что нужно для успеха, помимо того чтобы просто хорошо делать свою работу.

• Добавить интервью с успешными PM, которые разными способами помогли другим людям определить карьерные цели и показали, что такое успех.

ОСНОВНЫЕ ДИЛЕММЫ И РЕШЕНИЯ

Как сгруппировать навыки PM

Каждая компания это делает по-своему. Я решила пойти по пути, который кажется мне наиболее разумным, и проследить за тем, чтобы ключевые слова, которые люди будут искать в тексте, были указаны в оглавлении книги, тем самым снизить возможные риски. Посмотрим, что скажут в отзывах о таком подходе после бета-чтения.

Как выделить информацию, которая касается PM-сеньоров и руководителей

Мы хотели, чтобы наша книга была полезна в том числе и для PM-сеньоров, поэтому решили вынести предназначенные для них подсказки в отдельную главу, вместо того чтобы добавлять их в описание каждого отдельно взятого навыка. Я думаю, что так PM-джуниоры смогут узнать, что им еще предстоит развивать, а PM на более высоких позициях смогут освежить в памяти полезные навыки, которые они приобрели на заре своей карьеры и могли бы использовать и дальше. Проверим, какие будут отзывы бета-ридеров по этому поводу.

ОСНОВНЫЕ ВЫВОДЫ

• Путешествие важнее пункта назначения: документация по продукту – это всего лишь инструмент, на который можно опираться, пытаясь выработать свою точку зрения по каким-то важным вопросам, поделиться ключевыми решениями, получить обратную связь и усовершенствовать план действий. Конечный результат не так важен, как процесс, который стоит за написанием документации.

• Не подменяйте свои суждения шаблонами: шаблоны помогают вспомнить, на что следует обратить особое внимание, но они не могут заменить ваши личные выводы. Не зацикливайтесь на выборе правильного шаблона; вместо этого сосредоточьтесь на том, для чего предназначен каждый его раздел и каким образом он может способствовать получению желаемого результата.

Часть 4
Навыки реализации

Чтобы быстро, четко и эффективно реализовывать проекты, необходимо обладать определенными навыками. В этой части мы поговорим о том, какие из них нужны для управления командой разработки и запуска продукта и как их развить.

• «Управление проектами» (с. 131) – в этой главе вы научитесь составлять план ведения проекта и придерживаться его без отклонений. Мы расскажем вам о методологии Agile и других наиболее эффективных практиках, которые помогут вам ускорить работу вашей команды.

• Глава «Определение объемов и пошаговая разработка» (с. 146) научит вас разбивать процесс запуска на несколько этапов, чтобы ускорить его и сделать более успешным. Вы узнаете о минимально жизнеспособных продуктах (MVP) и о том, насколько важно представлять продукт реальным пользователям.

• В главе «Запуск продукта» (с. 157) речь пойдет о подготовке запуска. Как выбрать дату, что включить в лист проверки запуска, какие стратегии запуска существуют – обо всем этом написано здесь.

• «Как довести дело до конца» (с. 172) – это глава о том, как управлять своим временем и преодолевать препятствия. В ней мы познакомим вас c концепцией 4D и научим, как эффективно работать с командами в удаленном режиме.

Больше всего навыки реализации могут пригодиться в середине и в конце жизненного цикла продукта.

Глава 10
Управление проектами

Многих PM трясет при одной мысли об управлении проектами. После долгих лет безуспешных попыток объяснить друзьям и родственникам, что ты занимаешься продуктами, а не проектами, такая реакция неудивительна. К счастью, существуют современные подходы к управлению проектами – более легкие и менее утомительные по сравнению с традиционными. Но независимо от того, какой из них выберете вы, важно все сделать правильно.

Без эффективного управления проектами срок создания продукта серьезно увеличивается. Это происходит из-за дублирования работы, отсутствия самостоятельности, неграмотного распределения времени, простоя кого-то из команды, отвлекающих факторов и недопониманий.

Сфера ответственности PM по управлению проектами варьируется в разных командах. В одних случаях он берет инициативу на себя, в других – этим занимается инженер или специально назначенный менеджер по управлению проектами (проджект-менеджер).

Agile, Lean, Kanban и Scrum – это современные концепции и методологии, применяемые к разработке программного обеспечения в большинстве технологических компаний. Если вы слышали о спринтах (sprints), бэклоге продукта (product backlog) или ежедневных стендапах (daily standups), значит, с некоторыми концепциями вы уже знакомы. Большинство современных команд используют некоторые из этих элементов[57]57
  В других главах раздел «Концепции и фреймворки» идет третьим по очереди, после «Обязанностей» и «Практик роста». Но здесь нам показалось важным сначала описать суть фреймворков, чтобы вы смогли узнать терминологию, необходимую для лучшего понимания двух других разделов. Это не очень хорошо с точки зрения последовательности изложения, но зато прекрасно для усвоения материала.


[Закрыть].

Предлагаем ознакомиться с основными понятиями, которые используются для описания данной темы. Имейте в виду, что многие применяют их в широком смысле или как синонимы.

МЕТОДОЛОГИИ

Lean

Lean, или бережливое производство, – это философия, в основе которой лежит принцип максимизации потребительской ценности при минимизации отходов. Она произошла от практик, разработанных в компании Toyota, и стала фундаментом для методологии Agile. Сегодня Lean и Agile, как правило, используются в качестве взаимозаменяемых концепций, а также в виде ссылок на новые подходы (например, Lean MVP, направленный на то, чтобы проверять отношение клиентов к продукту, прежде чем вкладывать большие средства в его создание).

Agile

Agile – это философия и высокоуровневая методология, построенная на гибкости и итеративности действий. Agile является противоположностью более раннего подхода Waterfall (водопадный стиль разработки), где решения и результаты, полученные на каждом этапе процесса, фиксируются и «перетекают водопадом» на следующий этап.

В случае с Waterfall PM сначала вынужден прописать и рассмотреть горы рабочей документации, в которой подробно описана каждая стадия работы над продуктом. Затем эти бумаги проходят долгий процесс жесткой проверки и согласования. После этого документация попадает к дизайнерам, и они разрабатывают идею буквально по пикселю, не отступая ни на шаг от исходных требований. Получив готовые проекты от дизайнеров, инженеры пишут код, который так же в точности соответствует условиям. И, наконец, спустя месяцы или годы клиенты получают продукт. Этот подход подразумевает большое количество подготовительной работы и почти полностью исключает возможность вносить изменения в первоначальную идею.

Agile включает в себя те же этапы, что и Waterfall, но в ней используются более короткие циклы и границы между ними размыты. PM не приходится тщательно прописывать принципы работы продукта. Вместо этого проводится беседа или создается бриф с требованиями. Допускается, чтобы дизайнер создавал простые мокапы для тестирования продукта на реальных пользователях. Такие тесты могут показать, что какие-то требования нуждаются в пересмотре. Инженеры могут начинать писать код до того, как будет закончен дизайн, и работать в связке с дизайнерами, чтобы опробовать разные идеи. Запуск продукта разбивается на несколько мелких частей, каждая из которых презентуется пользователям как можно раньше, чтобы на основании отзывов можно было внести изменения в следующий этап работы.

Agile можно представить в виде спектра. Большинство команд склоняется к этому подходу. Для этого достаточно уменьшить размер цикла (то есть разбить работу на несколько мелких этапов и запусков) и заменить объемную официальную документацию ситуативной совместной работой.

Scrum

Scrum – это популярная концепция гибкого ведения проектов с четко выраженными ролями, инструментами и процессами. Благодаря ей в нашу жизнь прочно вошли такие понятия, как бэклог, спринт, ежедневные стендапы и ретроспективы. Часто команды используют некоторые из этих элементов (или сразу все), не обязательно называя это Scrum.

В Scrum команды работают спринтами продолжительностью от одной до четырех недель. В начале каждого спринта команда проводит планирование, при котором работа из бэклога продукта переносится в бэклог спринта и оценивается объем, который можно выполнить в следующем спринте.

Затем члены команды выбирают задачу из списка и ежедневно встречаются на 15-минутном стендапе, где делятся информацией о ходе работы и помогают друг другу преодолеть какие-то сдерживающие факторы. В конце каждого спринта команда проводит обзор спринта с точки зрения сделанного и ретроспективу спринта, чтобы понять, как все прошло и что можно было бы улучшить.

Главными фигурами в Scrum являются владелец продукта и скрам-мастер. В большинстве компаний роль владельца продукта выполняет PM. Если же эти роли разделены, тогда PM больше сосредоточен на стратегии, в то время как владелец продукта занимается ежедневной тактикой. Роль скрам-мастера часто играет техлид.

Владелец продукта отвечает за управление бэклогом, координацию участников и приемку работы по ее окончании. Скрам-мастер следит за тем, чтобы Scrum проводился правильно, организует и ведет встречи, помогает людям преодолевать препятствия в работе, взаимодействует с владельцем продукта в ходе подготовки каждого следующего спринта.

Часто команды выбирают только несколько элементов Scrum или по-своему адаптируют эту концепцию к своей работе. Почти невозможно найти команду, которая бы неукоснительно следовала принципам, описанным в «Руководстве по Scrum™». К счастью, адаптивность – это именно то, чего хотели создатели Scrum![58]58
  Подробнее читайте на сайте https://www.scrumguides.org/.


[Закрыть]

Kanban

Kanban – еще один метод гибкого управления, известный благодаря так называемой kanban-доске.

Kanban-доска – это инструмент визуального представления структуры работы и ее процессов. Работает она так. Карточки с задачами размещают в первом столбце таблицы и по мере выполнения перемещают в следующие. Каждый столбец означает этап рабочего процесса и имеет соответствующее название, например: «Не начато», «В процессе», «Ревью» и «Готово».

На kanban-доске хорошо видно, сколько задач находится в каждой колонке, и легко следить за тем, чтобы работа не зависала на каком-то этапе. В строгих версиях метода Kanban число карточек для каждого этапа ограничено – если оно достигло предела, нужно сосредоточиться на их перемещении в следующий столбец, прежде чем браться за новые задачи.

БЭКЛОГ ПРОДУКТА

Бэклог продукта представляет собой список задач для команды разработки в порядке их выполнения. В него входят запланированные функции, подробное описание требований, исправление багов, работа с инфраструктурой и исследования, которые необходимо провести.

Они могут быть описаны в виде простых заданий или в формате так называемых пользовательских историй. Типичный шаблон таких историй имеет следующий вид: «Как <кто>, я хочу <что>, чтобы <зачем>». Например, «Как администратор, я хочу получить двухфакторную аутентификацию, чтобы повысить безопасность». Такой формат предполагает, что PM будет описывать проблемы и требования с учетом контекста, а не только исходя из возможного решения.

Пользовательские истории могут быть сгруппированы в более крупные эпики, которые можно объединить в инициативы, а их, в свою очередь, в темы. Например, рассказанная выше история может стать частью эпика «Запуск улучшенных инструментов администратора», которая является частью инициативы «Переход на корпоративный уровень», которая входит в тему «Каждая компания из списка Fortune 500 использует наши продукты».

Для задач или историй обычно составляется смета затрат, например в виде стори поинтов (Story Points), или единиц истории. Стори поинты – это абстрактная единица оценки сложности работы. Один поинт означает самую простую задачу, два поинта присваивается задаче, на выполнение которой уйдет в два раза больше времени, чем на задачу с одним поинтом, и т. д. Составлением смет занимаются инженеры (не PM).

Отношение поинтов к дням может варьироваться, подобно курсу доллара к евро. В конце каждого спринта команда суммирует количество набранных поинтов для определения скорости работы (velocity) и может использовать полученную цифру для оценки того, сколько поинтов можно набрать в следующем спринте. Если вам известно, что половина вашей команды уйдет в отпуск во время следующего спринта, то заранее можно предположить, что вы сможете получить только половину поинтов. Если команда набрала поинтов меньше, чем ожидалось, то вам есть что обсудить на ретроспективной встрече.

ЧТО ТАКОЕ «ПОИНТ»?

Поначалу команде бывает сложно разобраться, чем по сути является эта новая «валюта». Действительно, непонятно, что на самом деле означает один поинт, два поинта, три. Чтобы глубже вникнуть в этот вопрос, пригодится забавная техника под названием покер планирования. Она заключается в том, что каждый инженер оценивает пользовательскую историю отдельно, а затем все одновременно «вскрываются», то есть предъявляют друг другу свои оценки (например, показывают соответствующее количество пальцев). Затем проводится обсуждение того, что повлияло на разницу предположений, пока вся команда не придет к единому решению.

Следить за тем, чтобы задачи были небольшими, вы должны вместе с инженерами. Иногда PM слишком много думают о ситуации в целом, и определяемые ими задания становятся слишком объемными. Если задача стоит более восьми поинтов (или занимает больше двух недель), оценки инженера могут оказаться крайне неточными. Но есть простое решение: разбить задачу на несколько более мелких.

Ответственность за создание и поддержание бэклога лежит на PM. Груминг (или уточнение) бэклога – это поддержание его в актуальном состоянии, приоритизация задач и отслеживание их реализуемости. Например, он проводится, когда PM нужно убедиться, что для позиций в верхней части бэклога дизайн уже выполнен и имеются все сведения для начала следующего этапа.

КАК ИССЛЕДОВАНИЕ ПРОДУКТА И ДИЗАЙН ВПИСЫВАЮТСЯ В РАБОТУ

Agile прекрасен во всех отношениях с точки зрения планирования. Однако кое-что все-таки непонятно: когда дизайнеры выполняют свою работу? Дизайн почти наверняка должен готовиться до того, как начнется разработка. Но насколько раньше?

Все зависит от команды, но в целом существуют два главных подхода, и у каждого из них есть свои плюсы и минусы.

Дизайнеры идут на один спринт впереди инженеров

Такой подход работает, если дизайн занимает меньше времени, чем написание кода. Благодаря ему дизайнеры и инженеры тесно сотрудничают друг с другом, а команде проще менять направление практически без потери результата трудов дизайнера. Его недостаток состоит в том, что разработка дизайна ограничивается одним спринтом, что не всегда желательно или осуществимо.

Стадии исследования и дизайна продукта стартуют задолго до начала разработки

Этот подход полезен, если для исследования продукта и создания дизайна требуется дополнительное время. Однако если дизайн готов с опережением графика, команда может не суметь сразу подхватить работу. Дизайнеры принимают больше решений, исходя из имеющихся инструментов, без глубокого понимания затрат на проектирование, а могли бы поиграться с рабочим кодом и итерациями. При этом еще хорошо бы знать, чем заняты инженеры, пока ждут своей очереди.

Если вы собрали команду с нуля, инженеры могут оставаться в своей прежней команде, пока для них не найдется задача в вашей. Также они могут заняться исследованиями, например созданием прототипов по новым технологиям, или начать разрабатывать бэкенд, поскольку он не зависит от дизайна.

Если же команда у вас уже есть, PM и дизайнеру придется работать «на два фронта». То есть они должны проводить этап исследования продукта для следующего проекта и одновременно оказывать поддержку инженерам, занятым текущими задачами. PM должен скоординировать графики всех участников и проследить, чтобы у каждого была важная, выполнимая работа. Например, можно поручить инженерам создание дополнительной версии продукта с менее приоритетными функциями или занять их отработкой технического долга.