Анализ данных • 25 апреля 2023 • 5 мин чтения
User Story помогает описать функции продукта, которые нужны пользователю. Рассказываем, как освоить инструмент самостоятельно и начать применять его в работе.
- Понятие User Story
- Для чего применяются User Stories
- Плюсы и минусы пользовательских историй
- Как формулировать User Story
- Примеры пользовательских историй
- Советы эксперта по написанию пользовательской истории
Понятие User Story
User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей. Главное — сделать фокус на целях и потребностях людей.
В основной части User Story обычно указывают:
● категорию, к которой относится пользователь;
● действие, которое он или она хотели бы совершить;
● результат, который ожидает получить пользователь после действия.
В историю обязательно включают критерии приёмки — условия, которые должны быть выполнены, чтобы история считалась завершённой.
Например, сотрудники компании «Лапки Солюшнз» разрабатывают приложение для хозяев домашних животных. Пользовательская история для будущего приложения может выглядеть так: «Из-за работы я постоянно в разъездах. Как хозяин кота, я хочу иметь приложение, которое позволит видеть моего питомца, чтобы я мог убедиться, что он выглядит счастливым и здоровым».
Для чего применяются User Stories
Пользовательские истории помогают увидеть ценность функций продукта и решить несколько задач:
1. Разложить требования на понятные и выполнимые элементы
Пользовательские истории обычно описывают не продукт целиком, а отдельные его функции. Так проще подойти к решению большой задачи. Например, разработка приложения для людей с питомцами может состоять из нескольких задач:
● Разработать безопасные и удобные регистрацию и вход в приложение.
● Спроектировать опцию создания профиля, в котором можно указать породу питомца, кличку, возраст и прививки.
● Придумать, как отслеживать активность домашнего животного.
Так работает декомпозиция: сложное задание легче выполнить, если разделить его на задачи попроще. Каждую из них потом можно описать в формате User Story.
2. Упростить оценку ресурсов для разработки
Когда требования в виде критериев приёмки описаны по одной структуре, задачи легче сравнивать между собой. Так можно оценить, насколько они сложные и сколько времени могут занять.
3. Добавить ясности всей команде
С помощью пользовательских историй коллеги могут обсудить, как будет выглядеть продукт, для кого его разрабатывают и зачем. Основную часть User Story пишут простым языком, поэтому её поймут и разработчики, и менее технически подкованные участники команды.
Научиться использовать User Story для формализации требований к продукту можно на курсе «Бизнес-аналитик». За восемь месяцев студенты научатся исследовать потребности пользователей, описывать процессы и просчитывать эффект от изменений в продукте. Чтобы начать учиться, необязательно иметь опыт в IT и уметь программировать.
Попробуйте себя в роли бизнес‑аналитика
Научитесь проводить интервью и описывать бизнес‑процессы. Пройдите бесплатную вводную часть курса.
Плюсы и минусы пользовательских историй
✅ User Story сфокусирована на пользователях
Сбор требований и оформление пользовательских историй начинают с интервью и опросов. Это помогает сразу получить обратную связь от пользователей: узнать их точки зрения, боли и потребности.
✅ User Story можно обсуждать в команде
Основную часть пользовательской истории формулируют так, чтобы любой участник команды смог предлагать идеи, думая как пользователь.
✅ User Story помогает поэтапно разрабатывать продукт
В историях описывают функции, которые можно разработать и протестировать за одну итерацию, или этап. Поэтому инструмент подходит для итеративной разработки и Agile.
❌ User Story не заменит требований
Если компании нужен документ с требованиями, то пользовательских историй недостаточно. User Stories могут не затрагивать важных нефункциональных требований: производительности, масштабируемости и безопасности.
❌ Если в User Story недостаточно деталей, её можно по-разному интерпретировать
Разночтения возникают, если забыть важные детали или описать их поверхностно. Это может привести к ошибкам в продукте.
Как формулировать User Story
Пользовательская история состоит из нескольких частей. Разберём, как писать каждую часть User Story.
Основная часть User Story
Основную, самую лаконичную часть пишут по шаблону.
Так выглядит классический шаблон User Story. Иногда в компаниях меняют его или придумывают собственный
При работе с классическим шаблоном важно придерживаться двух правил:
1. Определить, кто будет использовать продукт и с какой целью. Целью может быть конкретная проблема или задача, которую пользователи хотят решить, или информация, к которой хотят получить доступ. Например, сотрудники «Лапки Солюшнз» провели исследование и выяснили, что хозяевам питомцев важно знать, что их любимцы каждый день съедают необходимое количество корма и пьют достаточно воды.
2. Описывая действие, которое хотел бы совершить пользователь, важно не переборщить с подробностями. Не стоит писать: «Я, как владелец животного, хотел бы получать регулярные пуш-уведомления, в которых будет информация о том, когда я последний раз кормил питомца, и напоминание, что скоро нужно покормить его снова». Обилие деталей мешает увидеть альтернативное решение. Лучше вообще избегать названий элементов интерфейса в истории.
Критерии INVEST для User Story
Написанную User Story можно оценить по шести критериям INVEST, которые сформулировал консультант и директор по развитию продукта Билл Уэйк.
Критерии INVEST помогают убедиться, что история получилась качественной и полезной. Их знание часто проверяют на собеседованиях бизнес-аналитиков
● Independent (с англ. «независимый»). В пользовательской истории лучше описывать одну или несколько независимых функций. Они должны решить проблему пользователя без помощи других инструментов. Например: «Как хозяин домашнего животного, я хочу иметь возможность записывать визиты к ветеринару, чтобы следить за здоровьем питомца и не пропускать приёмы». В этой истории описан минимум функций, которые нужны пользователю: приложение должно уметь создавать встречи с ветеринаром и напоминать о них. Эти функции не зависят от других опций и свойств приложения, поэтому их можно разработать и протестировать самостоятельно.
● Negotiable (с англ. «подлежащий обсуждению»). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется. Без обсуждения есть риск, что команда разработки получит неполное представление о задаче.
● Valuable (с англ. «ценный»). В функции, которую описывает User Story, должна быть реальная ценность для пользователя. Например, возможность следить за здоровьем питомца и планировать посещение ветеринара.
● Estimable (с англ. «поддающийся оценке»). Хорошую User Story можно оценить — понять, сколько времени, ресурсов и денег займёт разработка функции.
● Small (с англ. «маленький»). История должна быть краткой и ёмкой. Объёмные истории сложнее оценить, и они могут потребовать больше ресурсов на разработку.
● Testable (с англ. «поддающийся тестированию»). С критериями приёмки команде разработки будет проще создать нужную функцию. Тестировать историю лучше за один раз — это ещё одна причина, почему в истории не должно быть много деталей.
Критерии приёмки и ограничения
Критерии приёмки добавляют независимо от формата User Story — это условия, которые должны быть выполнены, чтобы история считалась завершённой. Критерии приёмки в User Story — это требования к системе, которые помогают разработчикам создавать нужные функции.
Сотрудники «Лапки Солюшнз» поняли, что пользователи хотят следить за питанием своих животных. Для этой пользовательской истории возможно несколько критериев приёмки:
● Пользователь может добавлять информацию о питании своего питомца, включая тип корма, его количество и время суток.
● Приложение показывает, сколько корма питомец съел за день.
● Приложение позволяет устанавливать и отслеживать цели по питанию, включая ежедневные и еженедельные показатели.
Так выглядит общая формулировка критериев приёмки для User Story. Существуют разные способы их описания — глубина и подробность зависят от потребностей команды.
Ограничения показывают, как и в чём ограничены возможности продукта или функции. Они определяют, что невозможно, не разрешено или не может быть сделано в рамках конкретной истории.
Например, у функции для управления питанием животных могут быть такие ограничения:
● Приложение не позволяет загружать фото корма.
● Приложение не может автоматически корректировать рекомендации по приёму пищи на основе изменений веса или уровня активности питомца.
Примеры пользовательских историй
Использовать User Story можно не только в разработке приложений для хозяев домашних животных. Инструмент подойдёт разным продуктам: от программного обеспечения для космических спутников до сервисов доставки еды.
Сравним несколько примеров написания User Story из разных сфер.
Советы эксперта по написанию пользовательской истории
1. Фокусироваться на преимуществах для пользователя. Бывает, что в User Story описывают только функциональность системы, а о том, зачем это пользователю, забывают. Нужно обязательно добавить результат или ценность для пользователя — обычно это часть с союзом «чтобы». Например, «как пользовательница соцсетей, я хочу планировать публикации на будущие даты, чтобы я могла создавать контент в соцсетях в удобное время». Так каждый член команды поймёт, зачем разрабатывают ту или иную функцию.
2. Создавать небольшие и выполнимые User Story. Не стоит писать объёмные истории, которые потребуют много времени для разработки. Допустим, сервису нужен личный кабинет. Для такой большой задачи пишут несколько небольших историй. В них можно описать, что пользователь хотел бы иметь возможность войти в свой личный кабинет или написать в службу поддержки, если войти не получилось.
3. Добавлять детали в критерии приёмки. В пользовательской истории описание будущих функций продукта должно быть общим, без деталей дизайна и разработки, например: «Как пользователь, я хочу быстро найти кнопку на главной странице, которая позволит мне зарегистрироваться на сайте». Все уточнения вносят в критерии приёмки во время обсуждения User Story в команде.
Если не получится сразу следовать всем советам, не страшно. Опыт и насмотренность позволят делать User Story понятнее и эффективнее для продукта. Первое время лучше держать в голове критерии INVEST: кратко формулировать истории, выражать ценность для пользователя, создавать истории, которые можно оценить и протестировать.
Яндекс Практикум
Автор курса «Бизнес-аналитик», Head of Business Analysis Samokat.tech
Яндекс Практикум
Редактор
Яндекс Практикум
Иллюстратор
Варианты на все случаи жизни: как написать полезный use case
Одной ногой в бизнесе, другой — в IT: кто такой бизнес-аналитик и чем он занимается
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
Что такое User Stories
Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.
Дать емкое определение этому приёму сложно. Его внешняя простота заставляет сводить его описание к внешним характеристикам. Поэтому я, как автор, хотел бы дать читателю несколько определений.
В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:
User Story — это короткая запись сути задачи в формате «As a … I want to … so that I can …».
Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!
Пройдя круг обсуждений с ментором, прочитав и посмотрев много статей и видео, я понял, что главное в пользовательской истории — это ценность, которую пользователь получит от функции. Поэтому я попытался сгенерировать определение:
User Story — это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.
Чтобы понять, чем является сама нужда, давайте рассмотрим следующий пример. Человек хочет есть. Так, мы можем накормить человека рыбой. И тогда он будет сыт целый день. Но в этом ли настоящая нужда этого человека? Вряд ли, ведь завтра человек проголодается. Внимательный читатель уже догадался, что главная нужда человека — инструмент, которым можно добыть еду (например, удочка).
Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код…), Product Owner или представителей бизнеса.
Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Как Х,
Я хочу Y,
Чтобы Z.
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
«Тело» JS делится на три части:
-
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.
-
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.
-
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
-
В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z. -
В три строки:
When X
I want to Y
So I can Z.
Пример:
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Вопросы, которые следует задавать во время написания стори
Во время написания истории для аналитика важен не только её текст, но и то содержание — ценность, проблема — которая описывается этим текстом. Чтобы написать историю, которая сможет решить проблему пользователя, аналитику надо лучше понять пользователя и задать себе следующие вопросы.
-
Решает ли это настоящую проблему юзера?
-
Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?
-
Какие последствия от такого решения?
Вопросы можно задать и стейкхолдерам. Например, первый вопрос имеет смысл адресовать Product Owner в команде которого вы работае. А второй и третий — самой команде разработки, они наверняка смогут указать на какие-то подводные камни.
А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».
-
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
-
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
-
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
User Personas
Этот метод представляет собой детализированное описание пользователя продукта. Описание пользователя должно быть конкретным и детальным, ведь по его описанию члены команды должны понять, что это целевая аудитория приложения, которое они делают.
Создавая четкого и детального персонажа, аналитик требований или Product Owner уменьшает вероятность того, что нужды пользователя будут забыты или заменены на нужды тех членов проектной команды, которые ставят себя на место пользователей.
Карточка персонажа не обязана быть полностью правильной, но она обязана содержать максимальное количество деталей.
Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:
Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.
Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?
В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Не стоит забывать и об еще одной важной детали. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания.
Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.
Что же в сухой практике использования User Personas?
На практике автор статьи убедился, что команде не важны многие вещи из описания Persona: бренды, биография, боязни… Я думаю, что наиболее актуальная информация, которую следовало бы поместить в описание Persona — это роль в системе, цели от ее использования, а также основные кейсы.
Отрицательный персонаж
Не все персонажи должны создаваться, чтобы показать пользователей системы. Задача некоторых указать, кому в приложении нет места.
Например.
Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.
Ключевой персонаж
Ключевыми персонажами являются те, для кого и будет проводиться проектирование решения. Такой персонаж олицетворяет группу пользователей, которая будет либо чаще всего пользоваться приложением, либо имеет какие-то особенности, из-за которых им следует пользоваться приложением иначе. Такие персонажи заслуживают отдельных интерфейсов в системе.
Например.
Давайте вернемся к приложению для саппорта. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми. Так, тому, кто будет устранять жалобы, нужен интерфейс, который показывает жалобы и помогает выстроить маршрут. В тоже время клиенту, скорее всего, нужно посмотреть все его жалобы и оставить новую.
INVEST
По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.
I — Independent — Независимый
Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).
На практике это стремление не всегда достижимо. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Пример.
Мы хотим добавить в наш продукт поддержку банковских карт MasterCard, Visa и третьей системы. Тогда проще всего разделить эту стори на три. В первой, самой большой, разработчик должен добавить поддержку банковских карт в целом и какую-то из списка. А остальные две могут пойти в другую стори, которая зависит от первой.
N — Negotiable — Обсуждаемый
После написания черновика истории следует обсудить ее со стейкхолдерами и, возможно, внести изменения, исправить ошибки. В ходе обсуждения команда ещё не говорит о том, как данная история будет реализована, а обсуждается лишь то, как будет удовлетворяться нужда пользователя.
V — Valuable — Ценный
Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Но и истории, в рамках которой команда избавляется от легаси-кода, делает рефакторинг или переносит старый функционал на новую инфраструктуру (например, в новую базу данных) несут ценность для как для продукта, так и для пользователя. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Это следует отразить в описании такой задачи.
E — Estimable — Оцениваемый
История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:
-
история слишком большая;
-
в описании недостаточно данных;
-
разработчику нужно больше опыта.
Однако подробнее об оценках поговорим в отделе “Оценка историй”.
S — Small — Компактный
Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию. На многих проектах команды устанавливают рамки, в которые должна уместиться история. Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика.
T — Testable — Тестируемый
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить.
Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.
Как добавить деталей к истории?
Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
Acceptance Criteria
Что такое АС
Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.
АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.
Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.
Для чего нужны
-
Показывают фичу с точки зрения конечного юзера.
-
Для понимания задач бизнеса.
-
Достижения консенсуса с бизнесом относительно какой-то стори.
-
Служат базой для тестов.
-
Помогают эстимировать стори.
Правила написания
-
Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).
-
Должны быть проверяемы. -> pass/fail result прописан четко.
-
Должны быть измеримы.
-
Пишутся ДО работы над задачей.
-
Включают функциональные и нефункциональные критерии.
-
Содержат примеры.
-
Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.
-
-
Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).
-
Не содержат технического арго.
Что делать, когда надо выбрать одно из нескольких решений?
Тогда на помощь приходит Evaluation Criteria. Используются, чтобы оценить ценность нескольких решений и выбрать нужное.
Пример.
Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:
1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.
Gherkin
Gherkin — это способ описания сценариев использования систем, который понятен разработчикам, тестировщикам, бизнесу. Он строится по строгому синтаксису и потому позволяет «обходить» многие вольности естественного языка.
Эти сценарии используются чаще всего для описания критериев приёмки и могут стать отличным помощником для автоматизации тестирования. Их большим минусом является нечитабельность, ведь сценарии представляют из себя длинные тексты, в то время как АС — это чаще всего 1-2 строчки текста.
Пример:
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see "Your article was published"
Базовый синтаксис Gherkin
-
Given — это тоже самое, что Precondition в Use Case. То, что должно быть выполнено перед началом сценария.
-
When — то, что приводит в действие систему; главная суть этого юзкейса.
-
Then — то, что должно произойти в конце юзкейса.
-
And — для усложнения сценария вместе с given, when, then. Считается плохим тоном перегружать сценарий большим количеством and-конструкций, показывает, что в нем слишком много деталей.
-
But — используется с Then и указывает на то, что не должно случиться как итог юзкейса.
-
Feature — объединение множества сценариев в одну функцию. Включает сторю, АС и сценарии этой стори.
-
Background — устанавливает precondition сразу для всех сценариев, чтобы не переписывать.
-
Scenario Outline / Examples — используются вместе, чтобы скомбинировать несколько сценариев, где попадаются разные сообщения.
Пример:
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published <number of blogs>
When I try to post a new blog
Then I should see <message>
2) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:
Number of blogs |
Message |
>5 |
Your article was published. |
5 or <5 |
Please, pay for posting. |
-
Tags — средство для группировки сценариев (в тегах можно указывать тикеты, особенности системы, группы пользователей и пр.)
-
Steps — это Given, When, Then в виде нумерованных шагов.
Короткий отзыв об использовании Gherkin
Сложно сделать однозначный вывод относительно полезности Gherkin. Я много раз пытался начать постоянно использовать его на проекте. Gherkin отлично подходит для описания сложных сценариев с ветвлением, вариантами. Тем не менее, этот способ не вызвал положительные отзывы со стороны (вообще не вызвал) команды разработки или тестирования. Получается так, что балом в «деталях» к историям правят критерии приёмки — именно на них команда смотрит чаще всего во время оценки и изучения задач.
Болезни плохих пользовательских историй
Как не все фломастеры красные, так и не все пользовательские истории хорошие. Существует несколько типичных черт, которые характерны плохим историям. Давайте рассмотрим наиболее распространенные из них.
Слишком много информации про функционал в “So that …”
“So that” — это часть про ценность истории, а не функции, которые будут в её рамках реализованы.
Антипример.
Как посетитель кафе, я хочу, чтобы мой заказ сохранялся где-то, чтобы я мог смотреть историю заказов, распечатать чеки, отправить чеки по email.
Потенциальная проблема из этой истории в том, что команда видит “заказ сохранялся где-то”, то на этом и заканчивает рассмотрение истории, эстимацию, так как думает, что задача-то и не очень сложная, а ведь тут так много функционала!
Пример возможного решения.
Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог изменять чеки, сравнивать их, отправлять новые заказы в ресторан.
Мы расширили часть “I want…”, чтобы каждая “хотелка” из третьей части истории была соотнесена с функцией из второй части. Так команда точно увидит, что задача не такая простая и там есть над чем подумать.Но даже такая история не становится хорошей, ведь кто угодно замучается читать такой длинный “исторический роман”.
“Исторический” роман
Истории должны быть короткими. В идеале они должны помещаться на канцелярский стикер, который должен клеиться на реальную доску.
Антипример.
Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог пересматривать их, сравнивать их, отправлять такие же заказы в ресторан.
Как поступить с такой большой историей? Её следует разделить на несколько!
Пример.
Как посетитель кафе, я хочу смотреть историю заказов, чтобы я мог сделать такой же заказ в будущем.
Как посетитель кафе, я хочу видеть чеки, чтобы я сравнивать их.
Слишком конкретные
История — не место для деталей. Переполненность истории негативно скажется на нескольких аспектах. Во-первых, она не оставляет места для творчества разработчику — он становится просто руками, которые делают, что сказали; во-вторых, детали превращают историю в исторический роман.
Антипример.
Как посетитель ресторана, я хочу, чтобы разные виды продуктов были обозначены разными цветами (мясо — #FF0000, крупы — #A52AFA, овощи — #808000), чтобы я мог легко различать их.
Лучший способ улучшить такую историю — убрать конкретные примеры. Если в самих цветах есть какая-то важность, их можно поместить в критерии приемки.
Пример.
Как посетитель ресторана, я хочу, чтобы разные виды продуктов были обозначены разными цветами, чтобы я мог легко различать их.
1. Для мяса используется цвет #FF0000.
2. Для круп используется цвет #A52AFA.
3. Для овощей используется цвет #808000.
“Хочу делать, чтобы делать”
Одной из распространенных хворей историй является главной болезнью плохой пользовательской истории автор считает истории “хочу Х чтобы Х”.
Антипример:
Как человек, гуляющий в жару, я хочу мороженое, чтобы съесть мороженое.
История из примера не отражает ценность, только средство ее достижения. Предполагаю, что человек хочет мороженое, чтобы палящее июльское солнце не довело его солнечного удара.
Вывод
Пользовательские истории — это очень полезный формат описания требований. Он позволяет команде разработки придумать именно то решение, которое удовлетворит потребность конечного пользователя.
Но не стоит забывать, что сами истории — это верхушка задачи. Очень важно аккуратно дополнить историю примерами и деталями, которые будут направлять команду во время имплементации решения.
Источники
-
When Is a Story Done? Three Criteria to Decide, — Atomic Object. URL: https://medium.com/@atomicobject/when-is-a-story-done-three-criteria-to-decide-1979c7edd1fe
-
What is Acceptance and Evaluation Criteria in the context of Business Analysis?, — Business Analysis Excellence. URL: https://business-analysis-excellence.com/acceptance-evaluation-criteria-context-business-analysis/#:~:text=In%20the%20case%20of%20a,’%20or%20’a%20fail
-
Gherkin for Business Analysts, — Hewitt, Ryan. URL: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3810/Gherkin-for-Business-Analysts.aspx
-
Agile Extension to BABOK, — IIBA.
-
Business Analysis Body Of Knowledge, — IIBA.
-
10.1 Acceptance and Evaluation Criteria. URL: https://www.slideshare.net/maddyiscrazy/101-acceptance-and-evaluation-criteria
-
7 Tips for Writing Acceptance Criteria with Examples, — Prasad, Durga. URL: https://agileforgrowth.com/blog/acceptance-criteria-checklist/
-
Identifying and Improving Bad User Stories, — Suscheck, Charles; Fuqua, Andrew. URL: https://www.agileconnection.com/article/identifying-and-improving-bad-user-stories
-
Разработка требований к программному обеспечению, — Вигерс, Карл.
-
Пользовательские истории гибкая разработка программного обеспечения, — Кон, М.
-
Пользовательские истории. Искусство гибкой разработки ПО, — Паттон, Дж.
-
Психбольница в руках пациентов, — Купер, А.
Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.
Пользовательская история – это легковесный инструмент для документации пользовательских требований к разработке продукта. История описывает функциональность системы с точки зрения пользователя с определенной ролью и целью этой системы.
Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.
Часто команды задаются вопросом: зачем работать над документацией вообще, если можно просто создать задачи в трекере и сразу начать внедрять новый функционал?
Но основная задача любой документации — выявить и описать потребности пользователя, для которого разрабатывается продукт. Она создана не столько, чтобы описать всё, что должен делать продукт, сколько чтобы убедиться, что команда знает, зачем пользователю продукт и как именно он будет им пользоваться. Невнимание к этой разнице в целях очень часто приводит к тому, что продукт работает «как написано», но не приносит никакой пользовательской ценности.
И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как <роль/персона пользователь> я <что-то хочу получить> <с такой-то целью>», позволяет команде задуматься над этой ценностью на самом раннем этапе.
История — это не продукт размышлений одного бизнес-аналитика или менеджера, который, как мог, попытался зафиксировать всё множество особенностей продукта или функционала, который нужно спроектировать.
История — это результат обсуждения команды разработки и бизнес-пользователей, который фиксируется в максимально ненагруженной форме.
Обсуждения позволяют избавиться от ложного представления о том, зачем разрабатывается новый функционал и кто им будет пользоваться. Вдобавок к этому истории позволяют продумать тестирование и ограничения системы на ранней стадии разработки.
Пользовательская история включает в себя следующие элементы:
- Текст истории.
- Критерии приемки: как мы поймем, что история завершена.
- Тестирование. В идеальном случае пользовательские истории служат еще и легковесной тестовой документацией, в которой фиксируются тест кейсы.
- Технические заметки. Сюда часто попадает информация об ограничениях системы, к примеру, о необходимости поддерживать определенный формат данных.
Как писать пользовательские истории
В идеальном случае черновая пользовательская история должна быть написана внутренним или внешним бизнес-пользователем, который заказывает разработку нового продукта или функционала у команды, а после коллаборативно разбирается вместе с командой разработки.
Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.
Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.
Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:
- Разработка этой истории относительно независима. Чем больше программных зависимостей и ограничений, тем сложнее будет спланировать разработку такой истории.
- Ценность. Финальная часть конструкции «я хочу что-то получить с такой-то целью» должна содержать цель, которую вся команда признает важной и осмысленной.
- История должна быть легко оцениваема. Если она слишком большая или слишком размытая, чтобы оценить, то ее стоит разбить на меньшие части.
- Разработка не должна занимать больше недели. Иначе ее придется дробить на составляющие.
- Критерии приемки должны быть довольно четкими, чтобы по ним можно было протестировать продукт.
Распространенные ошибки в пользовательских историях
История для пользователя
Пример: «Как пользователь я хочу управлять отображением спецпредложений, чтобы удалять неактуальные и устаревшие».
Что не так с этой историей? Все важные части, кажется, на месте, но присмотревшись ближе, мы не знаем, для кого мы проектируем эту историю. Возможно, наш пользователь — администратор системы, которому нужно премодерировать показ спецпредложений от рекламодателей? Или, возможно, он рекламодатель, которому нужно управлять показом спецпредложений в списке?
У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.
История для разработчика
Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»
Часто такие истории пишутся, чтобы объяснить, что нужно сделать в рамках технического долга и рефакторинга, и здесь уже команда выступает непосредственным заказчиком. Однако, убедить бизнес в необходимости такой истории будет очень сложно, ведь на словах она не создает никакой ценности для пользователя. Как же с ней быть, если задача действительно нужная и полезная?
Необходимо посмотреть на то, что делает библиотека Х для конечного пользователя продукта. К примеру, она позволяет быстрее создавать спецпредложения и убирает задержку после их создания. Тогда история может звучать так:
«Как рекламодатель я хочу, чтобы в системе не было задержек после создания спецпредложений, чтобы я мог быстрее работать с большим объемом спецпредложений».
Перепишите ее с пользовательской точки зрения: «Как рекламодатель я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»
Технические заметки к этой истории могут выглядеть следующим образом:
- «Отрефакторить механизм добавления спецпредложений».
- «Обновить версию библиотеки, отвечающей за анимации добавления спецпредложений».
При этом к такой истории гораздо проще написать критерии приемки:
- «Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».
Никакой бизнес-ценности для пользователя
Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».
Вроде бы все на месте, кроме ценности для пользователя. Зачем администратору сортировать спецпредложения? Не понимая какая цель у сортировки, нельзя сформулировать и дальнейшие требования к ней, а история теряет смысл.
Практические советы по написанию пользовательских историй
- Выбирайте в пользу разбивки истории на мелкие составляющие вместо одной громоздкой.
- По возможности избегайте технического жаргона в историях — особенно если впоследствии вашим бизнес-пользователям нужно будет приоритезировать истории.
- Избегайте обсуждения конкретных UI элементов. История должна оставаться актуальной, даже если визуальная реализация меняется.
- Обязательно оценивайте усилия по разработке истории.
- История должна приводить к понятному и ценному результату.
Порочные практики
- Формализм
Иногда бизнес-пользователи из лучших побуждений пишут огромные подробные истории. В этом случае команда часто сдается и пропускает обсуждения, видя, что все нюансы «кажутся» освещенными. Как результат, часть требований теряется, ведь один человек редко может охватить абсолютно все детали.
- Отсутствие обсуждений
Без обсуждения истории с командой очень легко пропустить мелкие детали или создать неправильное представление о задаче. Лучше потратить время на старте, когда не написано ни строчки кода, чем спохватиться в середине проектирования.
-
Перевес в пользу технических историй
Если при планировании вы видите, что у вас готовы только истории технического плана, то в итоге может получиться, что истории реализованы, а продуктовой ценности совсем мало. Желательно соблюдать баланс между техническими историям, которые часто делаются для внутренних пользователей системы и теми, которые создаются для конечных пользователей продукта.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
Читать еще
- 21 совет по созданию хорошего интерфейса
- И ещё 26 советов по созданию хорошего интерфейса
- Учебник по юзабилити: ключевая правда о UX
Обучение
- Бесплатный курс «Adobe Photoshop: основы для веб-дизайнера»
- Программа обучения «Проектирование интерфейсов: UX-дизайн от стратегии до тестирования»
- Программа обучения «Веб-дизайнер: эффективный сайт от идеи до реализации»
Краткое описание: пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя. Она пишется с целью разъяснить, как именно функциональная возможность принесет пользу клиенту.
Есть тенденция считать, что пользовательские истории — это, говоря проще, функциональные требования к программному обеспечению. Но это не так.
Уникальная черта agile-разработки ПО — ставить во главу угла человека, и пользовательские истории как раз служат для того, чтобы в центре обсуждения всегда были фактические пользователи. Истории пишутся простым языком, без технической специфики, и служат контекстом для команды разработчиков и их деятельности. Прочитав пользовательскую историю, команда знает, почему она создает то, что создает, и какую ценность это формирует.
Пользовательские истории — одна из базовых составляющих agile-программы. Они позволяют организовать повседневную работу в систему, ориентированную на пользователей, что способствует укреплению сотрудничества, поиску нестандартных идей и повышению качества продукта в целом.
Что такое пользовательские истории в agile?
Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО.
Пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя или клиента.
Пользовательская история пишется с целью разъяснить, как именно выполнение рабочей задачи приведет к созданию конкретной ценности для клиента. «Клиентами» необязательно должны быть сторонние конечные пользователи в привычном смысле слова. Эту роль могут на себя примерять внутренние клиенты или коллеги из организации, которые рассчитывают на вашу команду.
Пользовательские истории состоят из нескольких предложений, описывающих требуемый результат простым языком и в общих чертах. Они не содержат мелочей. Требования появятся позже, когда команда обсудит их и придет к согласию.
Пользовательские истории изящно вписываются в методики Agile, такие как Scrum и Kanban. В Scrum пользовательские истории добавляют в спринты и отслеживают на диаграммах Burndown в течение спринта. Команды, работающие по методике Kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут в дальнейшем совершенствовать рабочие процессы.
Пользовательские истории также составляют значительные элементы методик Agile, такие как эпики и инициативы. Эпики — это большие рабочие задачи, которые делятся на несколько историй. Группа эпиков образует инициативу. Благодаря этим крупным структурам каждодневные усилия команды разработчиков (в работе над историями) ведут к достижению целей организации, выраженных в эпиках и инициативах.
Подробнее об эпиках и инициативах
Зачем нужны пользовательские истории?
Для команд разработчиков, которым agile в новинку, пользовательские истории кажутся лишним шагом. Почему бы просто не разбить большой проект (эпик) на несколько шагов, а потом разбираться с ними? Но с историями команда получает необходимый контекст и связь между задачами и ценностью, которая возникает в результате выполнения этих задач.
Пользовательские истории обладают несколькими важными преимуществами.
- Истории удерживают акцент на пользователе. Список дел поможет команде сосредоточиться на актуальных задачах, в то время как с набором историй участники смогут направить усилия на решение проблем реальных пользователей.
- Истории создают условия для совместной работы. Когда определена конечная цель, команда может совместными усилиями найти лучшее решение для клиента и лучший способ достижения этой цели.
- Истории подталкивают к поиску нестандартных решений. Истории заставляют команду подходить критически и творчески к выбору наилучшего пути достижения конечной цели.
- Истории задают динамику. Выполнив очередную историю, команда разработчиков справляется с небольшой задачей и радуется промежуточному успеху, который помогает двигаться дальше.
Работа с пользовательскими историями
Когда история написана, самое время встроить ее в рабочий процесс. Как правило, историю пишет владелец продукта, менеджер по продукту или руководитель группы проектов, после чего она отправляется на проверку.
В ходе собрания по планированию спринта или итерации команда решает, какие истории она выполнит в ходе этого спринта. На этом этапе команды обсуждают требования каждой пользовательской истории и связанные функциональные возможности. Это шанс проявить свои навыки и творческий потенциал и внести вклад в воплощение истории в жизнь вашей командой. По завершении согласования требования добавляются в историю.
Еще на собраниях оценивают истории на основании их сложности или времени, которое нужно потратить на выполнение. Команды высчитывают оценки в размерах футболок, баллах из последовательности Фибоначчи или с помощью покера планирования. Размер истории должен позволять выполнить ее за один спринт, поэтому в ходе оценки каждой истории команда следит, чтобы слишком трудоемкие или затратные по времени истории разбивались на меньшие части.
Как написать пользовательскую историю
При написании пользовательских историй держите в уме следующее.
- Критерии готовности работы. Как правило, история считается «выполненной», когда пользователь может сделать то, что было запрошено. Тем не менее, четко сформулируйте цель.
- Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.
- Типы клиентов. Для кого? При наличии нескольких типов конечных пользователей желательно написать несколько историй.
- Этапы как часть цепи. Напишите историю для каждого этапа, составляющего более масштабный процесс.
- Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?
- Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, поэтому истории, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше. Как вариант, считайте их самостоятельными эпиками.
Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.
Шаблон и примеры пользовательских историй
Пользовательские истории часто представлены в виде простого предложения следующего вида:
«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».
Давайте разберем эту формулировку.
- «Как [тип клиента]»: для кого мы выполняем эту работу? Нам не так важна должность, сколько личность, что стоит за типом клиента. Вот Макс, например. Нашей команде нужно иметь единое представление о том, что Макс за человек. К счастью, мы опросили множество Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. Мы испытываем к Максу эмпатию.
- «Хочу то-то»: в этой части заключается намерение пользователя — не возможностей, которыми он пользуется. Чего пользователь хочет добиться? В этом утверждении не должно быть ни слова о способах реализации. Если вы описываете какую-либо деталь пользовательского интерфейса, игнорируя цель пользователя, вы упускаете суть.
- «Чтобы делать что-то»: какое место отведено этому сиюминутному желанию клиента в более широком масштабе? Какую пользу в целом хочет извлечь клиент? Какую крупную проблему нужно решить?
Пользовательские истории могут выглядеть, например, следующим образом.
- Как Макс, я хочу пригласить друзей, чтобы мы вместе могли пользоваться этим замечательным сервисом.
- Как Саша, я хочу организовать свою работу, чтобы лучше контролировать ситуацию.
- Как менеджер, я хочу видеть, как продвигается работа у моих коллег, чтобы можно было составлять более точные отчеты о наших успехах и неудачах.
Придерживаться такой структуры необязательно, но она помогает определить критерии готовности работы. История выполнена, когда упомянутый тип клиента получает требуемую ценность. В идеале, команды формулируют свою собственную структуру и придерживаются ее.
Начало работы с пользовательскими историями в agile
В пользовательских историях раскрываются суть и цели повседневной работы участников команды разработчиков. Зачастую они написаны в форме «тип клиента + потребность + цель». Чтобы процесс работал как часы, важно понимать роль историй: именно в них объясняется, что должна сделать команда и почему она должна это сделать.
Начните с оценки следующего или самого срочного крупного проекта (например, эпика). Разбейте его на небольшие пользовательские истории и вместе с командой разработчиков доведите до ума. Когда истории будут готовы и представлены на суд всей команды, можно приступать к работе.
Max Rehkopf
Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian.
Как правильно формулировать пользовательские истории? Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT
User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него.
Для чего применяется User Story?
- Для описания элементов бэклога
- Для лучшего понимания пользователей
- Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
- Для вовлечения в процесс разработки пользователей и заинтересованных лиц
- Для построения User Story Mapping
Как формулировать User Story?
User Story — это ответы на 3 вопроса, связанные в одно предложение:
- Что это за пользователь?
- Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
- Зачем это ему?
Как <роль или тип пользователя>,
я хочу/могу <выполнить действие или получить результат>,
чтобы <получить ценность>
Еще 50 инструментов для владельца продуктаОписания продуктовых практик и подходов, сгруппированные по 7 темам, от Дмитрия Кустова
Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.
Примеры пользовательских историй
И ещё немного примеров:
Как <пользователь соцсети>, хочу <видеть в ленте только позитивные посты>, чтобы <не портить себе настроение>
Как <гипертоник>, я хочу <нормализовать давление на весь день>, чтобы <не измерять его в течение дня>
Как видно из примеров, ценность User Story как инструмента в том, что он очень универсален — вы можете использовать для лучшего понимания пользователей в абсолютно любой сфере.
Хорошая пользовательская история
INVEST — критерий хорошей истории:
Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки
Эти критерии не всегда достижимы, но чем больше историй будут им удовлетворять, тем более гибким будет ваш процесс разработки продукта.
Мы учим формулировать User Story на тренинге «Владелец продукта: краткий курс выживания».
P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.
Подключайтесь к Telegram-каналу, где Дмитрий делится практиками и опытом.
Авторы
Agile Coach и LeanStartUp-практик с опытом работы в ИТ и в производственной сфере.
Вырастил более сотни Владельцев Продуктов в производственной, банковской, ИТ и пищевой отраслях.
Подробнее о Дмитрии
Роман Баранов
Партнер ScrumTrek. Руководитель программ корпоративной акселерации. В качестве ментора обучает резидентов стартап-акселераторов подходам Customer Development, Agile и Lean StartUp.
Подробнее о Романе
Другие статьи
Менеджер продукта vs владелец продукта: навыки и полномочия
Заключительная часть цикла из 4-х статей про менеджера продукта и владельца продукта, которая поможет вам понять ландшафт продуктового менеджмента.
Lean Canvas: инструкция по применению
Lean Canvas на примере: как построить и как использовать для формирования продуктового видения. Пятая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
Как найти владельца продукта внутри компании
Чем грозит неправильное определение владельца продукта, как найти людей, между которыми распределены его функции сейчас, и понять, кто из сотрудников сможет взять все обязанности на себя.