Прикладной тактический повседневный мир менеджера продукта вращается вокруг спринтов разработки (а также на разнесенных по времени спринтах по исследованиям/UX/дизайну, если мы говорим о системах двухпоточного производства[29]). Как правило, у вас очень хорошее представление о том, где вы находитесь в спринте в любой момент времени, и ваши ежедневные стендапы должны держать вас в курсе прогресса, а также существенных препятствий на пути (то есть таких, которые мешают разработчикам или другим сотрудникам закончить свои задачи) и неблокирующих проблем.
Планирование спринта – это процесс и часто встреча для определения, какие пользовательские сценарии, исправления ошибок и другие инженерные задачи будут запланированы для того, чтобы работать с ними в начинающемся спринте. Это переговоры между всеми заинтересованными сторонами, но в основном между специалистами по продукту и инженерами.
Потенциальные вопросы для обсуждения вы берете из списка задач. Не приведенный в порядок список задач – это просто длинный список предложенных идей, задач, пожеланий и так далее. Перед спринтом их необходимо достаточно четко сформулировать. Процесс расположения задач в приоритетном порядке и проверка того, что верхние пункты готовы быть переданы разработчикам, называется приведением в порядок списка задач (рис. 4.6).
Существует множество методов оценки трудозатрат и сроков на решение задач, присвоения им баллов, а затем сравнения полученных значений по желаемым задачам с имеющимся количеством времени и ресурсов. Первые попытки планирования спринта часто недооценивают издержки, встречи, управленческие трудозатраты и время на выполнение работ (не говоря уже о задержках и времени на обучение), но после нескольких циклов[30] большинство команд получают коллективное понимание о своих приблизительных способностях.
Рис. 4.6. Скриншот из инструмента Jira. С помощью подобных программ многие команды управляют своим списком задач по проекту
Во время спринта вам может понадобиться добавить новые пункты или перенести вниз некоторые из них в списке. Быть гибким (англ. agile) отчасти означает уметь адаптироваться к изменяющимся условиям, но это иногда может осложнить сопоставление фактических результатов с планами при построении, например, диаграммы сгорания работ. Команда учится быстрее, если каждый может четко видеть разрыв между оценками и планами на одной стороне диаграммы и фактическими результатами и итогами на другой (рис. 4.7).
Рис. 4.7. Пример диаграммы сгорания работ в Jira компании Atlassian, показывающий, что в конце спринт отклонился от плана
Многие команды во время спринтов используют канбан в качестве метода отслеживания управления проектом. Это модель, в которой реальные или виртуальные стикеры с кратко изложенными пользовательскими сценариями или задачами перемещаются из одной колонки в другую по мере их выполнения в процессе разработки.
Если команда работает в одном физическом месте, то она может использовать настоящую канбан-доску со стикерами, где каждый будет видеть задачи, перемещающиеся в ходе работы (рис. 4.9).
Рис. 4.8. Прототип канбан-доски
Рис. 4.9. Если команда работает в общем пространстве, то реальная канбан-доска поможет сделать прогресс мгновенно прозрачным
В наши дни многие команды, и не только рассредоточенные или удаленные, любят использовать программы для ведения канбан-досок. Например, Trello – это чрезвычайно популярная программа для канбан, на которую буквально молятся многие команды продукта, и сейчас большинство инструментов для планирования спринта и поддержки других процессов управления проектом по гибким методологиям предлагают формат канбан-доски (рис. 4.10).
Рис. 4.10. Канбан-доска помогает визуализировать прогресс по нескольким параллельным приоритетам
Из опыта работы в UX вам должен быть знаком еще один аспект управления продуктом – реагирование на проблемы, которые возникают во время спринта. Они могут касаться уточнений спецификации, закрытия непредвиденного сценария (любого, от ошибок до конфликта требований, которые могут быть решены несколькими способами), работы дизайнеров по решению сложных задач, связанных с воплощением дизайна, а могут возникнуть, когда вы садитесь перед доской с разработчиком и другими сотрудниками, чтобы проработать вопросы системного уровня.
Что для вас означает понятие «готово»?
Камнем преткновения для многих команд, создающих ПО и пытающихся быть гибкими, является критерий того, что задача уже сделана. Чем дальше в лес, тем больше мерещится того, что вроде бы вам еще нужно доработать. Почти всегда появляются ошибки, которые находятся на грани в том смысле, что не влияют на людей по многим сценариям и не вызывают серьезных неудобств (особенно потому, что существуют достаточно простые обходные пути). Всегда есть крайние случаи, с которыми код пока не справляется идеально. Могут также быть нишевые мобильные устройства с «длинным хвостом» по продажам, которые проходят не все тесты. Чем пристальнее вы смотрите, тем больше видите.
Но существенная часть работы менеджера продукта заключается в принятии сложных решений, которые могут пойти в любую сторону. И если неправильных решений будет слишком много, то это приведет либо к неприемлемой задержке вашего проекта, либо, что хуже, к сдаче системы с ошибками и ужасным интерфейсом в интересах соблюдения графика.
Но, опять же, менеджер продукта не диктатор. Наоборот, на менеджера возлагается обязанность дать определение понятию «готово», с которым согласятся все члены команды.
Это определение обычно отсылает нас назад к документам с требованиями, в которых описывалось исходное проблемное место и указывалось, к какому решению необходимо прийти для его устранения. Если все согласятся с определением «готово», то позже, когда менеджер скажет: «Мы не можем опубликовать это, потому что пользователи потеряют свои данные» или «…потому что это не запускается на устройствах с Android» и так далее, – его слова не должны вызывать споров.
Определение «готово» также означает, что код написан, протестирован и принят. Без четкого определения того, что задача не готова, если не прошла через весь рабочий процесс, существует риск постоянного ее проскальзывания от спринта к спринту в виде фрагментов «готового» кода, потому что они были созданы перед окончанием срока спринта, но их все еще необходимо протестировать в следующем спринте и, возможно, доработать в зависимости от результатов тестирования.
Наконец, четкое определение «готовности» может помочь избежать «паралича» из-за перфекционизма. Управление продуктом – это работа не для перфекциониста! Помните слова Рида Хоффмана: «Если вас ни капельки не смущает продукт, который вы выпустили, значит, вы слишком долго ждали, чтобы выпустить его»?
Менеджеры продукта говорят: «Достаточно хорошо – уже хорошо». Это отличное напоминание о том, что ваша задача – выпустить продукт для вашего клиента, решить его проблемы, создать для него достаточно ценности, чтобы он принял ваше решение. Суть не в том, чтобы получить награду или создать «код без ошибок».
Многие команды по продукту считают полезным планировать демонстрационные дни в конце спринта. Обычно это встреча, на которой инженеры показывают работу кода, написанного за всё время спринта, и на нее могут прийти все заинтересованные лица.
Демонстрационный день может быть частью официального ритуала принятия продукта, во время которого менеджер продукта объявляет, что созданный код принят, или выявляет пробелы, где требования не выполнены. На таких встречах у других заинтересованных сторон появляется возможность предварительно увидеть то, что скоро будет выпущено и какой сделан прогресс; у разработчиков – шанс побыть на солнышке после долгих часов кодирования перед экраном, часто в почти полной изоляции от остальной части компании.
Итеративный процесс совершенствования с помощью ретроспективы
В конце спринта менеджер продукта отвечает за то, чтобы был организован заключительный ключевой ритуал гибкой разработки – ретроспективное совещание. Эту встречу непосредственно может вести и организовывать менеджер продукта, но даже в тех случаях, когда собранием руководит владелец продукта или скрам-мастер, менеджер по продукту все равно участвует и уделяет встрече пристальное внимание.
Движущая идея для этого ритуала исходит из 12-го принципа Agile про проверку командных процессов и постоянное их улучшение. Перед этим команду просят подготовиться и подумать над двумя вопросами: «Что прошло хорошо?» и «Что мы можем улучшить?», – а также предложить конкретные действия для членов команды, которые они, возможно, захотят предпринять, учитывая выводы только что закончившегося спринта.
Используя такой инструмент, как EasyRetro, команда может записать в таблице свои вопросы, комментарии или проголосовать за записи других людей (рис. 4.11). К вашему сведению, не называйте их «вскрытием», так как это немного нездорово.
Рис. 4.11. Ретроспектива позволяет команде отметить и закрепить эффективные модели поведения, а также конструктивно осмыслить разочарования и неудачи
Менеджеру следует организовать и вести дискуссию, свободную от обвинений, при этом подталкивать участников к размышлениям о том, что было сделано хорошо, и давать пространство для исследования неудач и поиска того, как с ними можно справляться в будущем. Если участники команды предлагают конструктивные меры, основываясь на полученных выводах, то за них можно проголосовать или расставить их в приоритетном порядке.
Если проводить такие встречи в открытой, здоровой и поддерживающей атмосфере, то ретроспективы могут значительно усилить сплоченность команды, ее координацию и эффективность.