Управление продуктом. Российская практика - страница 13
Пользовательская история – короткая формулировка намерения пользователя и того, что продукт должен сделать для него, поддержанная описанием функциональных требований и прототипом интерфейса. Если что-то не добавляет ценности клиенту, то это не может считаться пользовательской историей и будет оставаться задачей, подзадачей или просто требованием.
Формат пользовательской истории выглядит следующим образом: «Как [тип пользователя]; я хочу [некая цель]; так, чтобы [некая причина]». Рассмотрим все пункты подробнее.
• Как [тип пользователя]. В этом разделе указывается, кто пользователь. Это помогает лучше понять его точку зрения и потребности.
• Я хочу [некая цель]. Эта часть описывает, чего пользователь хочет достичь или какую функцию желает видеть в продукте. Она должна быть ясной и краткой, фокусироваться на желаемой функциональности, без подробностей реализации.
• Так, чтобы [некая причина]. Тут объясняется причина цели пользователя. Так мы обеспечиваем контекст и помогаем команде понять основную мотивацию, которая может иметь решающее значение для определения приоритетов и принятия решений.
Например, для сайта интернет-магазина пользовательская история может быть такой.
Как клиент, я хочу иметь возможность просматривать подробную информацию о продукте, включая изображения, описание, цену и отзывы, чтобы принимать обоснованные решения о покупке.
Критерии приемки
• На странице продукта должны быть качественные изображения высокого разрешения, демонстрирующие продукт под разными углами, обеспечивающие четкое представление о его внешнем виде и функциях.
• Описание должно включать основные характеристики и быть структурировано так, чтобы включать краткую, но подробную информацию о ключевых функциях, спецификациях, размерах, материалах и любых других важных атрибутах, которые влияют на решение о покупке.
• Информация о ценах, включая базовую, любые применимые скидки, рекламные акции или пакетные предложения, должна отображаться на видном месте рядом с описанием продукта.
• Пользователи должны иметь возможность просматривать совокупные рейтинги и читать подробные отзывы тех, кто купил продукт. Система отзывов должна поддерживать материалы, отправленные проверенными пользователями, обеспечивая достоверность и подлинность.
• Клиенты должны иметь возможность фильтровать и сортировать отзывы по релевантности, дате, рейтингу или конкретным критериям.
Пользовательская история дополняется макетом интерфейса и нефункциональными требованиями к производительности, безопасности, отказоустойчивости (если применимо). Пользовательские истории могут быть сгруппированы в эпики, которые, в свою очередь, объединены в инициативы, а инициативы в темы.
Владелец продукта (Product Owner) – это ключевая роль в Scrum, отвечающая за максимизацию ценности продукта, создаваемого командой разработки. Он определяет приоритеты в бэклоге, собирает оценки трудозатрат, взаимодействует с заинтересованными сторонами для определения и удовлетворения их требований.
Все команды помешаны на планировании. Это неудивительно, ведь точные оценки позволяют прогнозировать сроки и бюджет проекта, на которые «коммитятся» владельцы продуктов. Сколько раз я участвовала во встречах, где все спрашивали: «Когда вы реализуете эту фичу?» Коммуникация статуса и сроков крайне важна, ведь по ней оценивается работа команды в фабрике функций.
Похожие книги
