В разработке сложного программного обеспечения и систем одной из постоянных проблем является формулировка требований, ориентированных на пользователя, которые одновременно должны быть технически реализуемыми. Пользовательские истории — популярная методика в рамках гибкой разработки — могут давать сбои в крупных или сложных проектах из‑за неточностей формулировок, нехватки контекста и слабой прослеживаемости требований. В то же время методология Jobs‑to‑Be‑Done (JTBD) фокусируется на основной задаче, которую должен выполнить пользователь, подчеркивая, зачем вообще требуется решение. Несмотря на значительный потенциал для стабилизации требований и стимулирования инноваций, JTBD сама по себе остается достаточно абстрактной и слабо интегрированной в гибкие практики.
В этой статье представлена новая методология, сочетающая пользовательские истории с JTBD в контексте сложных проектов. Проводится тщательный обзор литературы, подробно раскрывающий сильные стороны, ограничения и ключевые преимущества каждого подхода. Затем вводится интегрированная структура, включающая диаграммы, примеры и сравнительную таблицу. Небольшой практический пример демонстрирует применение предложенного подхода. В заключение рассматриваются последствия, ограничения и направления будущих исследований с целью повышения ясности, согласованности и устойчивости требований в разработке сложного программного обеспечения.
Современная разработка программного обеспечения часто использует пользовательские истории для краткого и наглядного описания функциональных требований в формате «Как [пользователь], я хочу [возможность], чтобы [польза]». Хотя этот метод эффективен для описания небольших фрагментов функциональности, пользовательские истории могут сталкиваться с трудностями в сложных системах, что приводит к накоплению задач, теряющих общий контекст и логическую связность, а также прослеживаемость. Исследования показывают, что они часто оказываются малоэффективными для крупных и��и сложных программных проектов.
С другой стороны, методология Jobs‑to‑Be‑Done фокусируется на более глубоких мотивациях пользователей, подчеркивая «задачу», для выполнения которой человек «нанимает» продукт, как в известном примере: «Люди не хотят сверло на четверть дюйма; им нужно отверстие на четверть дюйма». JTBD помогает прояснить, почему необходим продукт, однако этот подход не всегда напрямую соотносится с практическими задачами разработки программного обеспечения.
Признавая сильные стороны обоих подходов, эксперты предлагают интегрированный подход для решения задач крупных проектов, где важно учитывать как роли пользователей, так и их мотивации. В этой статье предлагается структурированная методология, которая сочетает пользовательские истории с JTBD, предлагая гибридную модель, сохраняющую гибкость и одновременно усиливающую контекст, прослеживаемость и ориентацию на конечную ценность для пользователей. Размещая отдельные истории в рамках более общих формулировок пользовательских задач, команды могут масштабировать требования, создавая устойчивые, ориентированные на пользователя решения, способные адаптироваться к изменяющимся бизнес‑ и пользовательским потребностям.
1 Обзор литературы
1.1 Пользовательские истории в инженерии требований
Пользовательские истории появились в рамках гибких методик, таких как Extreme Programming и Scrum, в качестве альтернативы объемным и формализованным документам с требованиями, предлагая краткие, ориентированные на пользователя формулировки. Обычно они имеют формат «Как [роль пользователя], я хочу [возможность], чтобы [польза]», при этом пользовательские истории ставят на первое место общение и сотрудничество, часто обобщаемые в виде «трёх тезисов»: Карта, Обсуждение, Подтверждение. Их краткость способствует постоянному взаимодействию между разработчиками, тестировщиками и бизнес‑стейкхолдерами, позволяя деталям проясняться в нужный момент. Этот подход соответствует быстрой итерационной разработке, гарантируя, что каждая история несет явную ценность для конечного пользователя.
На практике пользовательские истории хранятся в бэклоге продукта, приоритезируются владельцем продукта и выбираются для реализации в рамках спринтов. Их можно объединять в эпопеи или темы для управления сложными проектами, хотя поддержание четкой связи с более широкими целями системы может быть сложной задачей. Несмотря на то что простота пользовательских историй способствует пониманию как со стороны технических, так и нетехнических участников команды, неопределенность может возникать при отсутствии достаточного обсуждения и уточняющего контекста. Более того, проблема масштабируемости становится особенно актуальной, поскольку пользовательские истории фокусируются на отдельных взаимодействиях, не отражая системную целостность и взаимосвязь компонентов.
Прослеживаемость также остается проблемной: из‑за своей неформальности и изменчивости пользовательские истории могут быть сложными для долгосрочного проектирова��ия и реализации, что затрудняет соблюдение требований на протяжении всего жизненного цикла проекта. Кроме того, они часто акцентируют внимание на функциональных возможностях, оставляя в стороне нефункциональные требования, что дополнительно ограничивает их эффективность.
1.2 Методология Jobs-to-Be-Done
Методология JTBD возникла в рамках исследований инноваций и маркетинга и стала популярной благодаря работам Клейтона Кристенсена и Тони Уликса. Она предполагает, что пользователи «нанимают» продукты для достижения конкретных целей, перенося акцент с характеристик решений на выявление глубинных потребностей и проблем пользователей. Обычно анализ проводится в формате «Когда [ситуация], я хочу [действие], чтобы [желаемый результат]».
JTBD подчеркивает более глубокие мотивации, выявляя скрытые и часто неосознаваемые потребности, которые остаются незамеченными при использовании традиционных методов. Методология способствует анализу причин пользовательских действий, стимулируя инновации, при этом оставаясь нейтральной по отношению к конкретным решениям, что открывает пространство для креативного поиска подходов, ориентированных на реальные потребности пользователей. Примечательно, что формулируемые задачи остаются относительно стабильными во времени, несмотря на изменения в продуктах или технологиях.
Однако внедрение JTBD может носить абстрактный и труднореализуемый характер, поскольку отсутствуют стандартизированные способы перевода полученных инсайтов в конкретные программные требования. Выявление задач часто требует глубоких и ресурсоемких исследований, включая интервью и наблюдения, что может быть затруднительно в условиях многообразия ролей и пересекающихся пользовательских потребностей. Кроме того, JTBD может недостаточно учитывать нефункциональные требования, нормативные ограничения и ролевые различия между сегментами пользователей.
В целом, пользовательские истории и JTBD обладают взаимодополняющими преимуществами. Пользовательские истории эффективны для конкретной, гибкой реализации требований, но могут не охватывать глубокий контекст, тогда как JTBD раскрывает мотивации и желаемые результаты, однако сложен в практическом применении. Гибридный подход, объединяющий JTBD и пользовательские истории, может обеспечить более целостное и устойчивое формирование требований, вводя компонент «почему» в гибкие практики. В связи с этим эксперты рекомендуют использовать оба подхода совместно, рассматривая их как взаимодополняющие, а не взаимоисключающие.
2 Предлагаемая методология. Фреймворк пользовательских историй с усилением JTBD
Интегрированная методология, названная структурой пользовательских историй с усилением JTBD (JTBD‑Enhanced User Story Framework, JUSF), сочетает подход пользовательских историй с принципами Jobs‑to‑Be‑Done для управления требованиями в рамках сложной разработки программного обеспечения. Она использует методологию Jobs‑to‑Be‑Done в качестве основы для структурирования требований, в то время как пользовательские истории служат конкретными единицами проектирования и реализации. Структура фреймворка включает двухуровневую модель: верхний уровень состоит из определений задач, описывающих высокоуровневые цели пользователей, а второй уровень содержит связанные с ними пользовательские истории, что обеспечивает прослеживаемость от задач разработки до реальных потребностей пользователей. Процесс соответствует фазам гибкой разработки и включает выявление задач, формирование историй задач и итеративную реализацию (Рисунок 1).
Основные этапы методологии описаны ниже.
Выявление ключевых задач по методу Jobs‑to‑Be‑Done.
Процесс начинается с этапа исследования, направленного на глубокое понимание целей и мотиваций пользователей посредством интервью, наблюдений и фасилитируемых семинаров. Основное внимание уделяется выявлению проблем, контекста и желаемых результатов, а не конкретных решений. На этом этапе формируется набор задач, которые должны выполнить пользователи или заинтересованные стороны, классифицированных от основных задач (например, «эффективно управлять личными финансами») до подзадач (например, «отслеживать расходы»). Для каждой задачи устанавливаются критерии успеха (например, «быстрее, чем текущий процесс»). Задачи должны быть сформулированы в терминах пользовательского опыта, избегая технических деталей. Этому могут способствовать специализированные инструменты JTBD, такие как лестница вопросов «Почему?» и контекстное картирование. В контексте B2B целесообразно включать организационные цели в качестве задач верхнего уровня, что помогает точнее определить стратегические приоритеты.
Формулирование историй задач.
Для эффективного описания ключевых задач рекомендуется формулировать их в виде историй задач, используя формат Job‑Threading‑Based Destination. История задачи отражает контекст, мотивацию и ожидаемый результат в повествовательной форме: «Когда [ситуация], я хочу [мотивация/цель], чтобы [ожидаемый результат]». Альтернативно может использоваться формат с указанием портрета пользователя: «Когда [ситуация], [портрет пользователя] хочет [цель], чтобы [результат]». В обоих случаях акцент делается на потребностях и контексте пользователя, а не на возможных решениях.
Например: «Когда сотрудник подает заявку на отпуск, руководители хотят иметь простой способ ее рассмотрения и утверждения, чтобы сотрудник получил своевременное решение».
Каждая история задачи является родительским требованием, которое может охватывать несколько функциональностей и взаимодействий, задавая критерии успеха и формируя основу общей модели задач.
Перевод историй задач в пользовательские истории.
После определения историй задач каждая из них декомпозируется в одну или несколько пользовательских историй, которые непосредственно направляют процесс разработки. Этот этап связывает проблемное пространство с пространством решений, превращая абстрактные цели в конкретные действия. Команда анализирует каждую историю задачи, чтобы определить необходимые функции, помогающие пользователю достичь желаемого результата. Основной вопрос при этом формулируется так: «Что должна уметь система, чтобы поддержать выполнение этой истории задачи?»
Пользовательские истории следуют формату: «Как [пользователь], я хочу [функциональность], чтобы [польза]», что обеспечивает четкость в определении роли, действия и ценности. Например, для истории задачи, связанной с запросами на отпуск, пользовательские истории могут включать:
Как сотрудник, я хочу подать запрос на отпуск онлайн с всеми необходимыми данными, чтобы процесс утверждения начался быстро.
Как менеджер, я хочу получать уведомления о новых запросах на отпуск, чтобы я мог быстро их рассматривать.
Как сотрудник HR, я хочу, чтобы утвержденный отпуск фиксировался в системе, чтобы зарплата обновлялась корректно.
Эти истории охватывают различные роли, участвующие в процессе, обеспечивая согласованный и непрерывный рабочий поток. Дополнительно учитываются нефункциональные требования, такие как производительность (например, загрузка данных в течение 2 секунд) и безопасность (например, ограничение доступа только для менеджеров и сотрудников HR). Карта пользовательских историй визуально структурирует все элементы, подчеркивая их полноту, взаимосвязь и логическую последовательность.
Рисунок 2. Концептуальная иллюстрация взаимосвязи между задачей, которую необходимо выполнить, и производными от нее пользовательскими историями Организация бэклога.
Организация и приоритизация бэклога по задачам формируют двухуровневую структуру, включающую бэклог задач и бэклог пользовательских историй.
Бэклог пользовательских историй содержит элементы, готовые к оценке, детализации и планированию, в то время как бэклог задач поддерживает стратегическое планирование релизов и приоритизацию. Группировка пользовательских историй по задачам дает такие преимущества, как отслеживание прогресса, выявление функциональных пробелов и согласование ожиданий заинтересованных сторон, что позволяет расставлять приоритеты на уровне задач в соответствии с целями MVP. Такая структура улучшает межкомандную координацию и повышает качество интеграционного тестирования.
Кроме того, явное связывание задач и пользовательских историй в инструментах гибкой разраб��тки повышает прослеживаемость, упрощая анализ изменений, выявление устаревших требований и оценку их влияния. Каждая пользовательская история должна содержать ссылку на соответствующую задачу, чтобы обеспечить ясность контекста при планировании спринтов и принятии проектных решений.
Разработка и валидация.
Стандартный процесс гибкой разработки включает проектирование, реализацию и тестирование пользовательских историй с акцентом на проверку инкрементов относительно ожидаемых результатов выполнения задач, а не только формальных критериев приемки. Во время обзоров спринтов внимание сосредотачивается на том, насколько эффективно пользователи могут достигать своих целей с помощью созданного функционала. После завершения всех пользовательских историй, связанных с конкретной задачей, — возможно, в рамках нескольких спринтов — продукт должен пройти сквозную оценку соответствующего сценария, включая пользовательское приемочное тестирование или моделирование реальных рабочих процессов, например обработку запроса на отпуск.
Такая проверка позволяет выявить проблемы интеграции и продемонстрировать, в какой степени система поддерживает достижение пользовательских целей. Если валидация показывает, что задача была выполнена не полностью или неэффективно, полученная обратная связь может привести к созданию новых либо уточненных пользовательских историй. Например, если выясняется, что менеджерам необходимо делегировать утверждение заявок в период своего отсутствия, это приведет к формированию соответствующих пользовательских историй. Этот процесс итеративного уточнения обеспечивает согласованность между желаемыми результатами и средствами их достижения, позволяя более точно отвечать на реальные потребности пользователей в сложных проектах.
Непрерывное уточнение задач
Задачи могут эволюционировать со временем, что требует регулярной переоценки историй задач. На ранних этапах жизненного цикла продукта, перед каждым релизом или через несколько спринтов, команда должна анализировать актуальность выявленных задач, учитывая появление новых потребностей и изменение приоритетов. Явная визуализация задач облегчает эти обсуждения. Например, данные об использовании продукта могут выявить неожиданные цели пользователей, что приведет к добавлению новых задач в бэклог, а изменения в нормативных требованиях — к появлению задач, связанных с обеспечением соответствия регуляторным стандартам.
Кросс‑функциональное сотрудничество играет ключевую роль в этом процессе. Вовлечение менеджеров продуктов, дизайнеров, разработчиков и тестировщиков в формирование историй задач и создание пользовательских историй гарантирует учет как технической осуществимости, так и качества пользовательского опыта. Такое взаимодействие способствует формированию общего понимания мотиваций, лежащих в основе разрабатываемого функционала, снижая барьеры между командами. Создание сбалансированной кросс‑функциональной команды является решающим фактором достижения высоких результатов.
Сравнение с традиционными методами
Для того чтобы прояснить, чем предложенная структура пользовательских историй, усиленная JTBD, отличается от традиционных подходов и в чем заключаются ее преимущества, в таблице представлено сравнение по ключевым аспектам. Мы сопоставляем три подхода: использование только пользовательских историй, использование только JTBD и фреймворк JUSF, описанный в данной работе. Это позволяет наглядно показать, как интегрированная методология сочетает сильные стороны обоих подходов и минимизирует их ограничения.
Аспект | Традиционные пользовательские истории | Чистый JTBD | Предложенный фреймворк |
|---|---|---|---|
Основной фокус | Конкретная роль пользователя и функциональность (что нужно реализовать) | Основная задача (цель/мотивация и результат) с контекстом | Как роль, так и контекст/цель. Сохраняет внимание на «кто» для эмпатии и «почему» для актуальности в одной связной структуре |
Учет «Почему» | Частично через фразу «чтобы...», но часто поверхностно. Истинная мотивация может быть упущена | Центральный элемент — вся история задачи о том, почему пользователю что‑то нужно. Мотивация и результат явно указаны | Явно зафиксировано на двух уровнях. Истории задач документируют «почему» и желаемый результат; связанные пользовательские истории унаследуют этот контекст, что гарантирует, что каждая функция связана с реальной ценностью для пользователя |
Контекст использования | Обычно опускается или минимален (например, не упоминаются когда или условия). Может приводить к неясности в контексте реализации | Явно указан «Когда [ситуация]…», что дает контекст ситуации | Явно определено на уровне задачи (когда/где возникает потребность) и передается в истории. Снижает неясность — разработчики знают условия, при которых будет использоваться каждая функция |
Уровень детализации | Очень детализировано и удобно для реализации. Легко оценить и разработать каждую историю, но можно упустить общую картину | Высокий уровень, нейтрален к решениям. Отлично подходит для видения, но не напрямую применимо без дальнейшего разбиения | Многоуровневая структура: истории задач для видения большой картины; подробные истории пользователей для реализации. Гарантирует, что как большая, так и маленькая картина охвачены и связаны |
Учет нескольких ролей | Требует отдельных историй для каждой роли, возможна дуб��икация, если роли разделяют цель (множество «Как пользователь…») | Обычно нейтральны к роли; фокусируется на универсальной потребности пользователя. Может игнорировать особенности, связанные с ролями | Учитывает сценарии с несколькими актерами в рамках одной задачи. Разные пользовательские истории для каждой роли могут быть привязаны к одной задаче, сохраняя общую цель и задачи, специфичные для роли |
Нефункциональные требования | Часто игнорируются или записываются как отдельные технические истории; формат не поддерживает их напрямую | Не охватываются явно; задачи обычно формулируются как функциональные результаты | Учитываются через критерии успеха задачи и дополнительные истории для каждой задачи (например, производительность, безопасность для выполнения задачи). Нефункциональные требования могут быть связаны с соответствующими задачами для контекста (например, «быстрая проверка» привязана к задаче «покупка продукта») |
Прослеживаемость и согласованность | Низкая прослеживаемость (истории — это независимые карточки). Согласованность зависит от связывания карт историй, что может быть неформальным | Согласованность на уровне видения (все функции концептуально привязаны к задачам), но нет формальной связи с кодом | Высокая прослеживаемость с иерархическими ссылками (задача‑история). Каждую историю пользователя можно отследить до задачи (и наоборот), гарантируя, что ни одна история не останется без привязки, а ни одна задача не будет забыта. Согласованность встроена: истории, сгруппированные по задачам, образуют завершенные рабочие процессы |
Адаптация к изменениям | Легко изменить приоритет отдельных историй; сложно оценить влияние на общие цели, если изменяется объем | Большие изменения в задачах могут перенаправить продукт, но без промежуточного плана сложно подстроить разработку | Поддерживает изменения на нескольких уровнях. Можно добавить/изменить задачу (затем настроить её истории) или заменить истории, сохраняя цели задачи стабильными. Если приоритет задачи снижается, все связанные истории могут быть отложены вместе. Это обеспечивает структурированную адаптируемость |
Кривая обучения | Знакомо большинству гибких команд; понятный формат. Возможность неправильного использования, если команда забывает об обсуждениях | Требуется обучение методологии JTBD; не широко распространено среди команд разработчиков. Риск неправильной формулировки задач | Умеренная — использует знакомую практику историй с дополнениями по JTBD. Первоначальные усилия по обучению фо��мулировке задач, но она хорошо вписывается в существующие процессы гибкой разработки (бэклог, спринты), поэтому освоение идет постепенно |
Интегрированный подход JUSF направлен на сбалансированное объединение ясности, конкретности и реализуемости пользовательских историй с контекстной глубиной и стратегической ориентацией, присущими JTBD. Традиционные пользовательские истории фокусируются на тактическом уровне реализации, однако со временем могут превращаться в набор разрозненных задач, оторванных от реальных целей пользователей. В то же время JTBD предоставляет ценные стратегические инсайты, но не предлагает достаточно конкретных механизмов для повседневной практики разработки.
Предлагаемая структура стремится постоянно согласовывать стратегический уровень с практической реализацией, устраняя характерные для пользовательских историй проблемы, выявленные Хайландом, — актуальность, неявные предположения и потерю контекста. Это достигается за счет гарантированной связи каждого требования с соответствующей пользовательской целью, стимулирования осмысленных обсуждений мотиваций и явного включения контекста использования.
3 Пример из практики. Гипотетическое применение в корпоративной системе
Для иллюстрации предложенной методологии рассмотрим гипотетический проект по разработке комплексной системы управления ресурсами предприятия, включающей модули для HR, финансов и закупок и обслуживающей различные категории пользователей. Традиционно для каждого модуля может быть собрано сотни пользовательских историй, что затрудняет управление требованиями. Однако предложенный фреймворк предлагает начать с выявления ключевых задач, которые должно поддерживать программное обеспечение.
Одна из ключевых задач, выявленных на старте, — «Эффективная обработка возмещения командировочных расходов сотрудников». Эта задача имеет критическое значение для финансового модуля и включает в себя процесс подачи сотрудниками отчетов о расходах для последующего возмещения. Интервью выявляют несколько болевых точек в существующем процессе: сотрудники хотят простой и быстрый способ подачи квитанций, менеджеры требуют прозрачности и контроля расходов, а бухгалтеры нуждаются в соблюдении нормативных требований, чтобы избежать задержек в возмещении. Это приводит к формированию следующей истории задачи:
«Когда сотрудник несет командировочные расходы, он хочет быстро и корректно получить возмещение, чтобы не покрывать затраты за счет личных средств, а компания могла поддерживать точные и актуальные финансовые записи».
Из этой истории задачи создаются пользовательские истории, охватывающие различные компоненты системы, такие как:
Сотрудники хотят подавать отчеты о расходах через веб‑портал.
Сотрудники хотят отслеживать статус поданных отчетов.
Менеджеры хотят утверждать отчеты о расходах онлайн.
Бухгалтеры хотят, чтобы система автоматически проверяла отчеты на соответствие корпоративной политике.
Финансовые директора хотят иметь доступ к аналитике и мониторингу командировочных расходов.
Нефункциональные требования включают ведение журнала аудита, а также мобильный доступ для подачи отчетов о расходах.
Используя картирование пользовательских историй, эти элементы упорядочиваются по хронологии, выявляя зависимости и обеспечивая полноту охвата сценария. Такой структурированный подход позволяет наглядно демонстрировать весь процесс возмещения расходов в рамках спринтов, помогая заинтересованным сторонам четко видеть создаваемую ценность для пользователей.
Если происходят изменения в нормативных требованиях, команда может гибко адаптироваться, пересмотрев историю задачи, обновив ее формулировку и создав новые пользовательские истории по мере необходимости, сохраняя согласованность и устойчивость процесса разработки.
В этой статье представлена методология интеграции пользовательских историй с фреймворком Jobs‑to‑Be‑Done с целью повышения качества инженерии требований в сложных проектах разработки программного обеспечения. Структура пользовательских историй, усиленная JTBD, устраняет ограничения обоих подходов, связывая высокоуровневые задачи пользователей с детализированными и реализуемыми пользовательскими историями. Истории задач вводятся как промежуточный аналитический артефакт, сохраняющий обоснованность требований и гарантирующий, что они приводят к значимым и измеримым результатам для пользователей. Эта иерархическая структура улучшает согласованность разработки и снижает риск накопления функциональности, не имеющей практической ценности.
Методология была проиллюстрирована на примере корпоративной системы, демонстрируя практическое применение подхода и согласование различных пользовательских ролей вокруг единой задачи, такой как возмещение командировочных расходов. К числу преимуществ относятся улучшение приоритизации требований, повышение качества коммуникации с заинтересованными сторонами и рост общей ценности продукта. Практики могут адаптировать предложенную методологию для реорганизации бэклогов, проведения семинаров по выявлению требований и стратегического планирования, способствуя более глубокому пониманию пользовательских задач.
Хотя методология обладает прочным концептуальным обоснованием, ее широкое промышленное внедрение требует дальнейшей эмпирической проверки. Среди потенциальных проблем — сопротивление организаций внедрению дополнительного уровня абстракции в требованиях, а также необходимость обучения команд формулированию качественных историй задач. Кроме того, некоторые технические или нормативные требования могут не полностью вписываться в структуру историй задач, что требует дополнительной адаптации подхода.
Если вы хотите перестать «тушить» разрозненные истории и начать управлять требованиями как продуктом, обратите внимание на курс «Бизнес-аналитик в IT». На нем разбираем выявление и оценку процессов, связь метрик с целями, BPMN и оформление ТЗ — чтобы «почему» и «что» сходились в одном бэклоге. Пройдите вступительный тест, чтобы узнать, подойдет ли вам программа курса.
Для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:
5 февраля в 20:00. «Как бизнес-аналитик может улучшить систему через нефункциональные требования». Записаться
16 февраля в 20:00. «Роль бизнес-аналитика в процессах тестирования и контроля качества». Записаться
