Написание пользовательских историй и требований

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

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

Попросил ChatGPT помочь сформулировать эти идеи, и вот что получилось.

1. Сосредоточьтесь на потребностях пользователя, а не на решении

Объяснение:

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

Пример требования, определяющего решение (неидеальный вариант):

  • «Приложение должно использовать выпадающее меню для выбора пользователем своей страны.»

Переписанное требование без указания решения:

  • «Приложение должно позволять пользователю легко выбрать свою страну во время регистрации.»

Почему это важно:

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

2. Поощрение инноваций и экспертизы

Объяснение:

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

Пример пользовательской истории с указанием решения (неидеальный вариант):

  • «Как пользователь, я хочу получать уведомления по SMS с использованием API Twilio, чтобы быть в курсе событий.»

Переписанная пользовательская история без указания решения:

  • «Как пользователь, я хочу получать своевременные уведомления, чтобы быть в курсе событий.»

Почему это важно:

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

3. Поддержание гибкости для изменения требований

Объяснение:

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

Пример требования, определяющего решение (неидеальный вариант):

  • «Система должна хранить данные в базе данных Oracle.»

Переписанное требование без указания решения:

  • «Система должна безопасно хранить данные и обеспечивать их эффективный поиск и масштабируемость.»

Почему это важно:

  • Команда разработки сможет выбрать наиболее подходящую технологию базы данных (SQL, NoSQL, облачные решения) в зависимости от текущих потребностей и будущей масштабируемости.

4. Предотвращение избыточной инженерии и растрат ресурсов

Объяснение:

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

Пример требования, определяющего решение (неидеальный вариант):

  • «Отчет должен быть сгенерирован в формате PDF с использованием SDK Adobe Acrobat.»

Переписанное требование без указания решения:

  • «Система должна предоставлять отчеты, которые пользователи могут легко просматривать и скачивать.»

Почему это важно:

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

5. Усиление сотрудничества и ответственности

Объяснение:

  • Четкое разделение «что» и «как» улучшает сотрудничество.
  • Заинтересованные стороны определяют проблему; команда разработки предлагает решение, что способствует чувству ответственности и вовлеченности.

Пример требования, определяющего решение (неидеальный вариант):

  • «Реализовать механизм кэширования с использованием Redis для повышения производительности.»

Переписанное требование без указания решения:

  • «Система должна выполнять пользовательские запросы в течение двух секунд при нормальной нагрузке.»

Почему это важно:

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

Почему следование этому подходу важно

  1. Использование экспертных знаний команды:

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

  2. Улучшение удовлетворенности пользователей:

    • Решения адаптируются под потребности пользователей, улучшая их опыт.

  3. Увеличение гибкости проекта:

    • Легче адаптироваться к изменениям технологий или требований пользователей.

  4. Снижение недоразумений:

    • Четкие и краткие требования минимизируют недопонимания.

  5. Оптимизация ресурсов:

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

Заключение

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

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