По сути, это анатомия работы распределенной команды с требованиями. Главное здесь то, что данный процесс работает у нас в текущей конфигурации и эффективен.

Отказ от ответственности: каждая организация отличается от других — от внутреннего устройства до способов общения с внешним миром. Поэтому ни один рабочий процесс не является серебряной пулей.

*Отказ от ответственности 2: SkuVault — постоянно совершенствующаяся команда примерно из 50 человек, распределенная по 10 часовым поясам, 2 различным версиям и круглосуточно обслуживающая лояльных клиентов по всему миру. Узнайте больше о Коммуникации в распределенных командах: Messenger и правила, или *Почему мы отказались от Scrum в пользу Kanban в JIRA

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

- Поддержка по требованиям — к кому обратиться
- Описание и декомпозиция задачи
- Отсутствие прерываний

Мы приблизились к пункту об отсутствии прерываний, создав дежурные команды, которые реагируют на любые возникающие срочные вопросы. (Привет Scrum from the Trenches Книберга, 2-е издание — наш собственный вариант «пожарных команд»!).

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

Чтобы объединить все подразделения, связанные со сбором и утверждением требований, мы создали поток Product Management, который должен был стать шоссе в ад к более качественным требованиям.

Поток Product Management

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

- Легко понимаемая последовательность шагов
- У каждого шага есть ответственный человек, видимый всем участникам
- Процесс поощряет аргументацию и обсуждение -> никаких неверно истолкованных предложений, а детали совместно прорабатываются
- Каждый шаг обеспечивает более высокое качество требований, задавая критерии, которым должен соответствовать результат

Рабочий процесс состоит из последовательных этапов: Новая задача -> Исследование -> Утверждение -> Анализ

обратите внимание на типичную плохую оценку пространства слева :P

Новая задача

Тикет создается по сигналу из разных источников (маркетинг, сервисы, технологии, форумы клиентской поддержки,..). На этом этапе тикет относительно пуст и содержит лишь запрос и его источник.

Переход: Чтобы перевести задачу на следующий этап, Product Owner рассматривает, будем ли мы вообще реализовывать эту функцию. Если нет — закрывает ее. Если да, когда-нибудь — переносит тикет в Backlog. Если да, в ближайшем будущем — переносит его в Preliminary Analysis.

Предварительный анализ (исследование)

Цель этапа: Product Owner должен сформулировать цель функции (чего необходимо достичь, выгоды для нашей компании и клиентов); описать основной бизнес-процесс (общими 1–2 предложениями, как это работает на складе, поскольку мы занимаемся складскими решениями); и добавить это на wiki-страницу этой функции.

**Пример: **

Краткое описание функции

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

Чего мы хотим достичь Позволить людям, использующим службы доставки, не интегрирующиеся с маркетплейсами вроде SkuVault Как это работает на складе

Цель: позволить клиентам маркировать товары номером отслеживания и видеть отгрузки в связи с продажей, к которой они прикреплены

- Комплектовщик подходит к столу контроля качества
- Сотрудник, выполняющий контроль качества, берет товар, проверяет его и маркирует товар транспортной этикеткой и номером отслеживания
- Номер отслеживания добавляется в систему и виден в связи с продажей
- Пользователь отслеживает товар по номеру отслеживания

Утверждение стейкхолдерами

Поскольку поток тикетов довольно велик, мы позволяем стейкхолдерам утверждать сразу пачку тикетов. Кто-то может сказать: «Эй, разве утверждение не входит в обязанности Product Owner?» Что ж, прежде всего наш продукт большой и включает разные области и домены: сервисы, маркетинг, технологии, операции — у каждого свои интересы, хотя мы и движемся к общей цели.

Цель этапа: утвердить идею, общий процесс и сроки разработки функции.

Следующим шагом будет собрать заинтересованные стороны и начать..

Анализ

Анализ — самая крупная, совместная и сложная часть рабочего процесса. Она включает:

[Бизнес-аналитики (создание User Stories)] => [совместная работа BA / UX / разработчиков (создание вайрфреймов)] <=> [BA / разработчики (корректировка требований, мозговые штурмы, декомпозиция и уточнение)].

Результат: ясные и атомарные User Stories с оцененными подзадачами Backend, которые позволяют охватить и запланировать разработку функции. Под «вам» я имею в виду нас, Project Managers :)

Пример: User Story — формализованное и легко воспринимаемое описание, представляющее активность пользователя и возможность взаимодействовать с ней.

Предусловие: пользователь находится на странице Sale Info

- До того как пользователь нажмет вкладку Shipment на странице Sale Info, подсказка сверху гласит "Нажмите Shipment для подробной информации"
- Когда пользователь нажимает строку Shipment, он видит полные сведения об этой Shipment сверху.
  1. список полей для Shipments можно увидеть в Shipments - Plans / Technical Requirements
    2. - Они могут нажать кнопку Shipped Items или Total Cost, чтобы увидеть сведения по товарам. - Если для отгрузки существует Tracking URL, пользователь может нажать его, чтобы открыть URL в новой вкладке.
    <li>После открытия новой вкладки пользователь переходит на сайт перевозчика с информацией по URL отслеживания
- Если URL отслеживания отсутствует, пользователь просто видит "Неизвестно" вместо URL.
    - Если имеется Label (то есть PDF), пользователь может просмотреть его в новой вкладке или скачать, нажав кнопку "Download"
Постусловие: пользователь может видеть информацию о связанных Shipments У нас есть строгие правила создания user stories, технических задач, запросов в поддержку и отчетов об ошибках. Это обеспечивает единые стандарты для разных типов задач во всей нашей системе отслеживания задач (Jira и правильно используемая магия Kanban) и позволяет интерпретировать требования единственным возможным способом (что чрезвычайно полезно :).

В двух словах

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

*еще кое-что: «о, автор, твой процесс избыточен для небольших функций!». Вы правы: просто уберите этап утверждения и упростите анализ, чтобы он соответствовал простому описанию истории для этой функции / улучшения ;). *