В быстром темпе разработки продуктов легко попасть в ловушку измерения прогресса по количеству выпущенных функций. Команды часто празднуют, когда список требований отмечен как выполненный. Однако выпуск функций не гарантирует успех. Продукт может быть насыщен инструментами и функциями, но при этом не удовлетворять потребности пользователей или не способствовать росту бизнеса. Переход от вывода к результату требует фундаментального изменения подхода к определению и написанию нашей работы. Нам нужно отказаться от списков функций и начать писать пользовательские истории, которые ставят во главу угла ценность.
В этом руководстве рассматривается, как создавать истории, которые фокусируются на почемуза работой, обеспечивая, чтобы каждый фрагмент кода имел свою цель. Мы рассмотрим практические рамки, распространённые ошибки и стратегии для согласования вашего бэклога с настоящей ценностью для пользователя.
Понимание основной проблемы: ловушка функций 📋
Многие команды разработки действуют, исходя из предположения, что больше функций — это лучше продукт. Такой подход приводит к «разрастанию функций», когда продукт становится громоздким и трудным в использовании. Когда заинтересованные стороны просят конкретную кнопку, панель мониторинга или интеграцию, очень соблазнительно принять это как требование.
Однако функция — это всего лишь механизм. Это инструмент, используемый для достижения чего-либо. Пользовательская история, описывающая функцию, часто не содержит контекста относительно пользы, которую она приносит.
Почему списки функций не работают
- Отсутствие контекста:Разработчики реализуют функцию, но упускают из виду её цель.
- Сложности с приоритизацией:Как сравнить кнопку входа с изменением цвета? Оба являются функциями, но приносят разную ценность.
- Бесполезные усилия:Разработка функции, которую никто не использует, — это прямые издержки для бизнеса.
- Путаница у пользователей:Слишком много функций может перегрузить пользователей, снижая их вовлечённость.
Чтобы решить эту проблему, нам нужно переформулировать разговор. Вместо вопроса «Что мы должны создать?» мы задаём вопрос: «Какую проблему мы решаем?» и «Какую ценность это приносит?».
Определение ценности в пользовательских историях 💡
Ценность — это не только выручка. В контексте пользовательских историй ценность — это выгода, которую получает пользователь или бизнес, когда история завершена. Эта выгода может быть:
- Экономия времени:Сокращение количества шагов для выполнения задачи.
- Снижение затрат:Снижение эксплуатационных расходов или затрат на обслуживание.
- Снижение рисков:Улучшение безопасности или соответствия требованиям.
- Рост выручки:Повышение коэффициента конверсии или среднего чека.
- Вовлечённость:Повышение удержания пользователей или удовлетворённости.
История, ориентированная на ценность, связывает потребность пользователя с бизнес-результатом. Она отвечает на вопрос: «Если мы это сделаем, что произойдет?»
Истории, ориентированные на функцию, противоречат историям, ориентированным на ценность
Визуализация различий имеет решающее значение для вашей команды. В таблице ниже подчеркиваются структурные и стратегические различия между двумя подходами.
| Аспект | История, ориентированная на функцию | История, ориентированная на ценность |
|---|---|---|
| Фокус | Результат или функциональность | Результат или выгода |
| Вопрос | «Что он делает?» | «Почему нам это нужно?» |
| Критерии приемки | Технические спецификации (например, «Кнопка красная») | Результаты пользовательского опыта (например, «Пользователь чувствует уверенность при нажатии») |
| Приоритизация | На основе срочности или запроса | На основе соотношения влияния и затрат |
| Ценность | Низкая (часто предполагается) | Явная и измеримая |
Анатомия истории, ориентированной на ценность 🛠️
Стандартная история пользователя следует формату: Как [пользователь], я хочу [действие], чтобы [выгода]. Чтобы приоритизировать ценность, разделвыгодадолжен быть самым подробным и важным разделом карточки. Он не может быть расплывчатым.
1. Актор (Как…)
Будьте конкретны в описании пользователя. «Пользователь» — слишком общее понятие. «Возвращающийся клиент» или «Администратор, управляющий учетными записями» дают лучший контекст.
2. Действие (Я хочу…)
Сделайте это кратко. Это механизм, а не цель. Избегайте чрезмерного уточнения решения здесь. Пусть команда дизайна и разработки найдет лучший способ достижения действия.
3. Выгода (чтобы…)
Здесь и находится ценность. Не останавливайтесь на «чтобы сэкономить время». Будьте точны. «Чтобы обрабатывать возвраты менее чем за две минуты» или «чтобы снизить процент ошибок на 10%».
Пошаговое руководство по написанию историй ценности
Преобразование вашего бэклога требует дисциплинированного процесса. Вот практический рабочий процесс, чтобы убедиться, что ваши истории соответствуют ценности.
Шаг 1: Обнаружение и подтверждение 🔍
Прежде чем писать одну историю, подтвердите наличие проблемы. Не предполагайте, что проблема существует. Поговорите с пользователями, проанализируйте тикеты поддержки и изучите аналитику. Если вы не можете найти доказательства существования проблемы, предложение ценности слабое.
- Проверьте данные: Есть ли точка отказа в воронке?
- Опросите пользователей: Спросите их напрямую о точках боли.
- Просмотрите метрики: Показывают ли текущие KPI потребность в изменении?
Шаг 2: Написание с намерением 📝
При составлении истории заставьте себя сформулировать ценность в разделе чтобыфразе. Если вы не можете сформулировать ценность, история, возможно, не должна находиться в бэклоге.
Плохой пример:
- Как пользователь, я хочу темную тему, чтобы я мог изменить внешний вид.
Хороший пример:
- Как разработчик, работающий в ночную смену, я хочу темную тему, чтобы снизить усталость глаз и сохранить концентрацию в вечерние часы.
Шаг 3: Определение критериев приемки, основанных на ценности ✅
Критерии приемки часто смещаются в сторону технических деталей. Сместите акцент на результаты. Как мы узнаем, что ценность была реализована?
- Функциональные: Функция работает, как задумано.
- Основанные на ценности: Пользователь выполняет задачу быстрее. Пользователь сразу понимает действие. Снижается процент ошибок.
Шаг 4: Уточнение и сотрудничество 🤝
Используйте сессии уточнения, чтобы проверить ценность. Задавайте вопросы, например:
- «Это лучший способ решения проблемы?»
- «Можем ли мы получить эту ценность с меньшими усилиями?»
- «Что произойдет, если мы не будем это строить?»
Эта совместная среда гарантирует, что команда понимает почему, а не просто что.
Стоимость функций: финансовый взгляд 💰
У каждой функции есть стоимость. Это не только время разработки. Включает:
- Стоимость разработки: Время, затраченное на проектирование и кодирование.
- Стоимость сопровождения: Будущая поддержка, исправление ошибок и обновления.
- Когнитивная нагрузка: Дополнительная сложность для пользователя.
- Альтернативная стоимость: Время, которое не было потрачено на работу с более высокой ценностью.
Когда вы ставите ценность на первое место, вы фактически рассчитываете доходность инвестиций (ROI) для каждого сюжета. Сюжет с высокой ценностью и низкой стоимостью — приоритет. Сюжет с низкой ценностью и высокой стоимостью следует убрать или пересмотреть.
Распространённые ошибки, которых следует избегать ❌
Даже при лучших намерениях команды часто возвращаются к мышлению, ориентированному на функции. Будьте бдительны перед этими распространенными ловушками.
1. Ловушка «Хорошо бы»
Функции, которые удобны, но не являются необходимыми, часто загромождают бэклог. Если функция — просто роскошь, она должна быть снята с приоритета в пользу основных факторов ценности.
2. Неопределённые утверждения о выгоде
Фразы вроде «улучшить пользовательский опыт» или «повысить эффективность» слишком расплывчаты. Они не дают четкого сигнала для приоритизации. Используйте цифры и конкретные сценарии.
3. Пренебрежение техническим долгом
Ценность не всегда ориентирована на пользователя. Иногда ценность внутренняя. Рефакторинг кода или улучшение инфраструктуры снижает риски и ускоряет будущую доставку. Это ценность, даже если пользователь не видит её напрямую.
4. Избыточная детализация решений
Если сюжет точно определяет, каким образом должно быть построено решение, это ограничивает способность команды найти наиболее эффективный путь доставки ценности. Сосредоточьтесь на проблеме, а не на решении.
Оценка влияния 📊
Как вы узнаете, что ваш подход, ориентированный на ценность, работает? Вам нужно отслеживать метрики, соответствующие ценности, указанной в ваших сюжетах.
Уровень принятия
Пользователи действительно используют новую функциональность? Высокий уровень принятия свидетельствует о том, что предложение по ценности было воспринято.
Время выполнения задачи
История достигла цели по экономии времени? Измерьте время, затраченное на выполнение задачи до и после.
Удовлетворенность пользователей (CSAT/NPS)
Пользователи чувствуют себя лучше относительно продукта? Опросы могут предоставить качественные данные о том, были ли устранены болевые точки.
Метрики удержания
Помогает ли функция удерживать пользователей дольше? Снижение оттока — это сильный показатель доставленной ценности.
Работа с запросами заинтересованных сторон
Заинтересованные стороны часто приходят с запросами на функции. «Нам нужен чат-бот». «Нам нужное мобильное приложение». Ваша задача — перевести эти запросы в истории ценности, не отвергая их.
Техника перевода
Когда заинтересованная сторона просит функцию, копните глубже.
- Слушайте: Принимайте запрос без осуждения.
- Вопрос: «Какую проблему это решает для клиента?»
- Переформулируйте: «Значит, вы хотите снизить объем заявок в службу поддержки? Давайте рассмотрим истории, которые достигают этой цели, а не просто создание чат-бота».
Этот подход держит разговор нацеленным на результаты. Возможно, чат-бот не является правильным решением, но обновление базы знаний — да. Цель остается той же: доставка ценности.
Роль эпиков и тем
Истории ценности часто группируются в крупные инициативы. Эпики и темы помогают организовать эти истории, не теряя фокус на ценности.
Темы
Темы — это широкие категории, основанные на ценности, а не на функциональности. Вместо «Работа с фронтендом» или «Работа с бэкендом» используйте темы, такие как «Оптимизация оформления заказа» или «Ознакомление пользователей».
Эпики
Эпик — это крупный объем работы, который обеспечивает значительное предложение по ценности. Он должен быть разбит на истории, каждая из которых вносит вклад в ценность эпика. Если эпик нельзя разбить на истории ценности, он, возможно, слишком расплывчат.
Практический пример: процесс оформления заказа
Рассмотрим реальный сценарий, связанный с процессом оформления заказа в корзине покупок.
Сценарий А: Список функций
- Добавить возможность оформления заказа без регистрации.
- Разрешить хранение данных кредитной карты.
- Добавьте калькулятор доставки на страницу корзины.
- Покажите значки доверия рядом с кнопкой.
Анализ: Это список функций. Он не объясняет, почему. Уменьшает ли возможность оплаты без регистрации напряжение? Увеличивают ли значки доверия конверсию? Мы не знаем.
Сценарий B: Истории, ориентированные на ценность
- Как первый раз покупатель, я хочу совершить покупку, не создавая аккаунт, чтобы быстро завершить заказ, не испытывая тревоги из-за обязательств.
- Как повторный покупатель, я хочу видеть сохранённые способы оплаты, чтобы совершить покупку менее чем за 30 секунд.
- Как покупатель, чувствительный к цене, я хочу видеть стоимость доставки до ввода информации об оплате, чтобы избежать отказа от корзины из-за неожиданных сборов.
Анализ: Каждая история здесь имеет чёткого пользователя, чёткое действие и чёткую ценность. Команда теперь может приоритизировать на основе того, какая ценность наиболее сильно снижает отказы.
Интеграция ценности в ваш рабочий процесс
Чтобы сделать это привычкой, вы должны внедрить проверки ценности в свой существующий рабочий процесс.
1. Очистка бэклога
Во время очистки проверьтеТак чтобы условие. Если оно отсутствует или слабое, верните историю на доработку.
2. Планирование спринта
При выборе историй для спринта спросите команду: «Какая из этих историй сейчас приносит наибольшую ценность нашим пользователям?»
3. Ретроспективы
Обсудите, действительно ли доставленные истории принесли ожидаемую ценность. Соответствовали ли данные гипотезе?
Психология ценности
Понимание человеческой психологии — ключ к написанию качественных историй ценности. Пользователи не покупают функции; они покупают решения проблем. Они покупают чувство безопасности, облегчение от раздражения или радость достижения.
Когда вы пишете историю, представьте себя на месте пользователя. Представьте их раздражение. Представьте их облегчение, когда проблема решена. Эта эмпатия — основа ценности.
Картирование эмпатии
Используйте техники картирования эмпатии при создании истории.
- Говорит: Что пользователь говорит о своей проблеме?
- Думает: О чём они беспокоятся?
- Делает: Какие действия они в настоящее время предпринимают для смягчения?
- Чувствует: Каково их эмоциональное состояние?
Это упражнение раскрывает эмоциональную ценность вашего продукта, которая часто оказывается более значимой, чем функциональная ценность.
Заключение по приоритизации ценности
Написание пользовательских историй, в которых приоритет отдается ценности, а не спискам функций, — это смена мышления. Это требует дисциплины, любопытства и приверженности потребностям пользователей. Это переводит команду с позиции исполнителей заказов на позицию решателей проблем.
Фокусируясь на почему, вы гарантируете, что каждый спринт приближает вас к продукту, который люди действительно хотят использовать. Вы сокращаете потери, повышаете удовлетворенность и согласовываете вашу техническую работу с бизнес-целями.
Начните сегодня. Просмотрите текущий бэклог. Найдите истории, в которых отсутствует четкое обоснование ценности. Задавайте сложные вопросы. Уточняйте истории. И наблюдайте, как ваш процесс разработки продукта становится более сфокусированным и эффективным.
Часто задаваемые вопросы
В: Могут ли технические задачи быть историями ценности?
О: Да. Если техническая задача снижает риски или улучшает скорость будущей разработки, она приносит ценность. Формулируйте ее так: «Как разработчик, я хочу рефакторить X, чтобы мы могли развертывать обновления в два раза быстрее в следующем месяце».
В: Что делать, если я не знаю ценность заранее?
О: Если вы не знаете ценность, история является гипотезой. Создайте небольшой эксперимент или спайк, чтобы узнать больше. Не приступайте к полной разработке, пока ценность не будет подтверждена.
В: Как мне справляться с противоречивыми ценностями?
О: Некоторые истории могут обеспечивать скорость, а другие — безопасность. Используйте данные, чтобы определить, какая ценность более важна для ваших текущих пользователей. Иногда необходимо явно балансировать между компромиссами.
В: Это замедляет разработку?
О: Вначале может потребоваться больше времени на написание и уточнение. Однако это предотвращает создание неправильных вещей. Со временем это ускоряет доставку, сокращая повторную работу и обеспечивая, что сначала создаются правильные функции.
