Lex Humanitas показывает, где форма скрывает власть и подменяет смысл.

Google Play Веб-версия

Модуль 6. Работа с требованиями и стейкхолдерами

Введение

Лид должен уметь выяснять, какая задача стоит за входящим запросом. Формулировка «добавьте кнопку» уже содержит предложение решения, но сама по себе ещё не объясняет, кому оно нужно и что должно изменить. Команда может точно выполнить такой запрос и не устранить проблему, ради которой началась работа.

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

В модуле «Delivery: как доводить работу до результата» рассмотрен весь путь изменения до работающей поставки. Здесь подробнее разбирается работа с содержанием требования: от выяснения его основания до пересмотра договорённостей и проверки эффекта. Этот разбор продолжается и во время разработки, когда появляются новые сведения.

1. Требования и варианты решения

Требование — это представление о потребности, с которым участники могут работать: обсуждать, уточнять, выбирать решение и проверять результат. (IIBA BABOK Glossary)

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

Бизнес-цель: зачем организации это изменение

Какой результат организация хочет получить.

Пример: снизить долю незавершённых заказов после неуспешной оплаты.

Потребность: что нужно участнику ситуации

Какую задачу человек пытается решить и что мешает ему сейчас. Здесь важно описать его ситуацию и желаемый результат.

Пример: после отказа банка покупателю нужно завершить покупку без повторного выбора товаров и ввода уже указанных данных.

Требование к поведению системы: что должно быть обеспечено

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

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

Потребность и такое требование тесно связаны. Первая формулировка объясняет задачу покупателя, вторая задаёт обязательное поведение системы. Для простой задачи они могут быть выражены одной фразой; отдельные записи нужны, когда помогают уточнить содержание.

Вариант решения: каким способом обеспечить это поведение

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

Пример: на странице заказа размещается кнопка повторной оплаты, которая открывает выбор способа платежа.

Другой вариант — после отказа сразу показать выбор способа оплаты на текущем экране. Оба варианта нужно оценить относительно потребности и условий использования. Требование о возможности повторить оплату позволяет сравнивать эти варианты по общему основанию: сможет ли покупатель продолжить оплату сохранённого заказа.

Реализация: как устроить выбранный способ в системе

Какие компоненты и технические механизмы будут обеспечивать выбранное поведение.

Пример: кнопка вызывает endpoint создания платёжной попытки; повторный запрос с тем же ключом идемпотентности возвращает уже созданную попытку.

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

Допустим, к лиду приходит Product Owner с запросом: «Добавьте кнопку повторной оплаты на странице заказа». В нём предложен вариант решения, но ещё предстоит выяснить, какое затруднение испытывает покупатель и какого результата ожидает организация.

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

2. Кого лид должен вовлечь в работу с требованием

В примере с повторной оплатой запрос принёс Product Owner. Чтобы разобраться в нём, могут понадобиться покупатель, поддержка, команда платежей и владелец правил резервирования. У каждого есть часть информации, без которой можно выбрать неверное решение.

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

Найти участников по ситуации

Лид должен выяснить, кто пользуется результатом, кто обеспечивает текущий процесс, кто зависит от данных и контрактов системы и кто несёт последствия ошибки. При этом нужно учитывать участников, которые сами не пришли с запросом.

Для повторной оплаты начальная карта может выглядеть так:

Участник Что необходимо выяснить у него Как изменение его затронет
Product Owner Зачем начата работа, для каких пользователей важен результат Отвечает за продуктовый выбор и приоритет
Покупатель Как он действует после отказа и где теряет возможность завершить заказ Получает новый способ продолжить покупку
Поддержка Какие обращения повторяются и какие обходные действия используются Должна объяснять новое поведение и разбирать отказы
Команда платежей Какие состояния и события поддерживает интеграция Реализует и сопровождает изменение
Владелец резервирования Когда заказ теряет резерв и можно ли его восстановить Отвечает за правила обращения с остатками
Финансы Как учитываются попытки, списания и возвраты Сверяет платёжные операции

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

Сведения участников нужно связать с конкретным сценарием: разобрать обращение, пройти путь вместе с пользователем, сопоставить его действия с событиями в системе. В нашем учебном примере так выяснилось, что после отказа банка покупатель возвращается на страницу заказа. Заказ и введённые данные сохранены, но начать новую попытку со страницы нельзя. Покупателю нужно завершить покупку без повторного сбора заказа; Product Owner ожидает снижения доли заказов, оставшихся неоплаченными после отказа.

Определить, какое участие нужно

Сам по себе список имён ещё не помогает работать. Нужно определить, у кого получить сведения, с кем проверить сценарий, кто должен принять решение и кого достаточно уведомить. Не всем участникам требуется присутствовать на каждой встрече.

IIBA связывает планирование взаимодействия со стейкхолдерами с их характеристиками, ролями, потребностями в коммуникации и способом совместной работы. (IIBA: Plan Stakeholder Engagement)

Например, лид может отдельно разобрать обращения с поддержкой, проверить платёжные состояния с командой и вынести на Product Owner уже подготовленный выбор. Перед поставкой поддержке потребуется объяснение нового сценария, хотя она не принимала все технические решения.

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

Проверить понимание вместе с участниками

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

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

3. Как распределить ответственность за решения

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

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

Ниже используется разделение на Product Owner, Engineering Lead и команду. В конкретной организации должности могут называться иначе, а один человек может выполнять несколько ролей. Для работы важно установить реальные полномочия и договориться о них.

Продуктовые решения

Product Owner или другой владелец продуктового результата определяет цель, приоритет, целевой пользовательский сегмент и приемлемый объём первой поставки. Он выбирает между продуктовыми вариантами с учётом их технических последствий.

Лид должен объяснить эти последствия: например, почему поддержка всех способов оплаты требует другого объёма работы, чем поддержка одного. Такое участие даёт владельцу продукта основание для выбора.

Инженерные решения

Engineering Lead вместе с командой отвечает за оценку реализуемости, технические варианты, зависимости, архитектурные и эксплуатационные последствия. Команда выбирает способ реализации в своей области ответственности и обеспечивает её качество.

Лид должен сделать инженерную оценку понятной другим участникам и привлечь разработчиков к её получению. Если все варианты заранее выбраны им самим, участие команды становится формальностью и теряется знание тех, кто будет реализовывать изменение.

Специализированные решения

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

Например, владелец правил резервирования определяет, можно ли сохранить заказ после истечения резерва. Команда показывает последствия такого правила для данных и поведения системы. Product Owner не может обещать сохранение заказа, пока эти условия не выяснены.

Где возникает подмена ответственности

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

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

4. Какие условия нужно учесть в требованиях

Согласие с фразой «пользователь может повторить оплату» ещё не означает, что участники одинаково понимают требуемое поведение. Нужно выяснить, когда оно допустимо, какие свойства обязано сохранять и как будет работать в существующей системе.

Лид проводит этот разбор с владельцами предметных правил, командой, QA и теми, кто будет сопровождать решение. Глубина разбора зависит от последствий ошибки: изменение текста на экране и новая платёжная операция требуют разного внимания.

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

Предметные правила

Предметное правило определяет допустимое поведение независимо от устройства интерфейса. В рассматриваемом примере резерв действует 30 минут с момента создания заказа. Владельцы правил согласовали: повторная оплата разрешена только при активном резерве и окончательно отклонённой предыдущей попытке. Новая попытка не продлевает исходный срок резерва.

Из этого сразу следуют вопросы: что считается окончательным отказом, как определяется срок резерва, что происходит при неизвестном статусе платежа? Ответы нужно получить у владельцев правил и сверить с возможностями платёжной системы.

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

Ограничения решения

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

Лид должен проверить основание каждого существенного ограничения:

Область Что выяснить
Срок Почему нужна эта дата; что должно быть доступно к ней и кому
Данные Какие данные используются, кто имеет доступ, как исправляются ошибки
Масштаб Каковы обычные и предельные объёмы, есть ли пики
Совместимость Какие клиенты и соседние системы зависят от текущего поведения
Полномочия Кто вправе выполнять действие и подтверждать исключение
Внешнее обязательство Где оно зафиксировано и кто компетентен его интерпретировать

Фразу «обязательно нужна кнопка» тоже следует проверить. В ней может быть выражено требование к доступности действия, предпочтение конкретного интерфейса или действительное обязательство перед клиентом.

Для обсуждения удобно различать подтверждённое обязательное условие (hard constraint), обсуждаемое предпочтение (soft constraint) и условие, основание которого пока не проверено (assumed constraint). При записи требования важно сохранить основание и владельца условия, чтобы участники понимали, что допускает пересмотр.

Свойства качества

Для каждого существенного сценария нужно определить требуемые свойства: время ответа, доступность, надёжность, защищённость, доступность интерфейса для разных пользователей. Лид выясняет, какие свойства важны именно для этого изменения и какие действующие требования системы продолжают применяться.

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

Переход в новое состояние

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

Лид должен выяснить, что произойдёт с заказами, созданными до выпуска изменения. Если новое поведение работает только с новой моделью платёжных попыток, нужно определить судьбу уже открытых заказов. Требования к переходу позволяют связать новую функцию с существующим состоянием системы.

Эксплуатация

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

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

5. Как сделать требования проверяемыми

После выяснения правил и ограничений участники должны договориться, по каким признакам будет установлено, что система ведёт себя требуемым образом. Лид организует эту проверку с Product Owner, командой и QA до того, как реализация закрепит неоднозначное толкование.

Описать поведение на конкретных примерах

Формулировки «работает корректно» и «обработаны все ошибки» не позволяют сторонам одинаково оценить результат. Для каждого существенного сценария нужно назвать исходное состояние, действие или событие, ожидаемое наблюдаемое поведение и сохраняемые инварианты.

Например, после согласования правил повторной оплаты можно записать такие критерии приёмки — acceptance criteria:

Feature: Повторная оплата существующего заказа

  Rule: Новая попытка доступна при активном резерве после окончательного отказа

    Scenario: Пользователь повторяет оплату
      Given предыдущая попытка окончательно отклонена и резерв заказа активен
      When пользователь подтверждает оплату другим доступным способом
      Then для существующего заказа начинается новая платёжная попытка
      And пользователь видит её текущий статус
      And новый заказ не создаётся
      And сумма и состав заказа сохраняются
      And срок резерва не продлевается

    Scenario: Резерв истёк
      Given предыдущая попытка окончательно отклонена и резерв заказа истёк
      When пользователь открывает страницу заказа
      Then повторная оплата недоступна
      And пользователь видит объяснение и способ оформить новый заказ

    Scenario: Результат предыдущей попытки ещё неизвестен
      Given платёжный провайдер ещё не сообщил окончательный результат
      When пользователь открывает страницу заказа
      Then он видит статус ожидания
      And новая попытка оплаты недоступна

Gherkin здесь служит формой записи примеров: Given задаёт исходный контекст, When — событие, Then — ожидаемый результат. Можно использовать и обычный текст, если участники одинаково его понимают. (Cucumber Gherkin Reference)

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

Задать условия проверки качества

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

Например, для получения статуса заказа можно задать такое условие: при нагрузке 100 запросов в секунду и истории до 20 платёжных попыток у заказа 95% ответов API должны формироваться не дольше 500 мс. Время измеряется от получения запроса сервисом до отправки ответа. Числа в этом примере условные; в реальной задаче их выбирают исходя из потребности пользователя, обязательств продукта и возможностей системы.

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

Для других свойств проверка может выглядеть иначе:

  • Доступность: какой пользовательский сценарий, в какой период и в каких границах должен оставаться доступным; как учитывается его недоступность.
  • Надёжность: какие потери и дублирование недопустимы; как восстанавливается состояние после сбоя.
  • Безопасность: кто вправе выполнить действие; что получает пользователь без такого права; какие события должны оставаться в аудите.
  • Масштаб: на каких обычных и предельных объёмах должны выполняться согласованные требования.

Часть таких условий уже может действовать для всего продукта. Тогда на них нужно сослаться и проверить применимость к изменению. Новые условия требуют явного согласования.

Проверить достаточность договорённости

Лид должен проверить вместе с участниками две вещи: можно ли однозначно установить выполнение требования и помогает ли описанное поведение удовлетворить потребность. Формально точный критерий способен закрепить неверно выбранное решение.

Критерии приёмки описывают конкретное изменение. Общая Definition of Done задаёт требования к завершённости работы команды: например, необходимые проверки, документацию и готовность к сопровождению. План тестирования определяет, как исследовать и проверить реализацию. Достижение продуктовой цели оценивается по использованию решения после поставки. Эти договорённости должны быть согласованы между собой.

6. Как работать с открытыми вопросами и предположениями

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

Выбрать действие по типу неизвестности

Одинаковая пометка «нужно уточнить» может скрывать разные задачи:

Чего не хватает Что поможет получить ответ
Неясно, где пользователь испытывает затруднение Наблюдение сценария, разбор обращений, разговор с пользователем
Не определено предметное правило Решение владельца правила на конкретных примерах
Неизвестно поведение внешней системы Проверка документации и контракта, эксперимент в тестовой среде
Неясно, сможет ли пользователь выполнить действие Прототип и проверка сценария с пользователем
Неизвестен технический способ Ограниченное исследование или spike с конкретным вопросом
Не выбран приоритет Решение владельца продуктового результата с учётом последствий вариантов

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

Сделать неизвестность управляемой

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

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

Формат записи может быть коротким: «Какой ответ провайдера означает окончательный отказ? Ответственный — инженер интеграции; проверка — документация и тестовые события; ответ нужен до выбора модели повторной попытки».

В нашем примере инженер проверил контракт провайдера A и обработку тестовых событий: состояния окончательного отказа определены, порядок обработки повторных и задержанных событий понятен. Для остальных провайдеров проверка ещё не закончена. Это позволяет обсуждать ограниченный выпуск, сохранив открытые вопросы перед расширением.

Определить, достаточно ли известно для следующего шага

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

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

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

7. Как выбрать вариант решения и объём первой поставки

Когда понятны потребность и существенные условия, лид вместе с командой должен предложить технически достижимые способы получить результат. Одновременно Product Owner уточняет, какая часть результата нужна первой и чем можно поступиться. Выбор развивается в обе стороны: продуктовый приоритет влияет на техническое решение, а технические последствия — на допустимый объём.

Соединить продуктовый и инженерный контекст

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

В нашем примере провайдер A поддерживает два способа оплаты: банковскую карту и электронный кошелёк. Поэтому покупатель может сменить способ оплаты, оставаясь в пределах одного провайдера. Проблема подтверждена в обращениях его пользователей, а контракт уже проверен командой.

Поддержка повторной оплаты у всех провайдеров требует дополнительной проверки их контрактов. Лид предлагает начать с провайдера A в веб-интерфейсе. Для этой части команда выбирает кнопку на странице заказа: именно туда покупатель возвращается после отказа и видит сохранённый заказ. Product Owner должен оценить, достаточен ли такой охват для первой поставки.

Найти содержательные альтернативы

Лид должен проверять, какие части предложенного решения допускают изменение при сохранении требуемого результата. IIBA рассматривает разработку вариантов решения как поиск способов удовлетворить потребность и достичь требуемого будущего состояния. (IIBA: Define Design Options)

Возможные направления поиска:

Что можно изменить Пример Что нужно проверить
Пользовательский сегмент Сначала пользователи одного способа оплаты Получит ли выбранная группа полезный результат
Набор сценариев Сначала повтор после подтверждённого отказа Как система ведёт себя в исключённых состояниях
Канал Сначала web, затем мобильное приложение Приемлем ли этот путь для целевых пользователей
Автоматизация Часть процесса временно выполняет поддержка Есть ли у неё полномочия и ресурс, приемлемы ли задержки
Объём Ограниченная группа заказов или клиентов Сохраняется ли смысл первой поставки
Способ получения способности Доработка своего продукта, внешнее решение или изменение процесса Каковы ограничения, зависимости и стоимость сопровождения

Даже отложенный сценарий должен иметь определённое поведение: например, действие недоступно и пользователь понимает причину. Нельзя считать его исключённым из объёма, если система продолжает принимать такие запросы и обрабатывать их непредсказуемо.

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

Сравнить варианты и дать рекомендацию

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

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

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

8. Как разрешать конфликт требований и ожиданий

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

Показать, что именно несовместимо

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

Если весь объём не помещается к дате, лид объясняет, какие части работы и зависимости определяют прогноз. Разговор должен позволить выбрать: изменить объём, срок, порядок поставки или отказаться от первоначальной формы.

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

Объяснить техническое ограничение через последствия

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

К пятнице мы можем предоставить повторную оплату пользователям провайдера A. Для него проверено, какие состояния позволяют начать новую попытку и как исключить повторное списание.

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

Предлагаю сохранить дату и ограничить первый выпуск провайдером A. Второй вариант — дождаться проверки остальных контрактов и после неё уточнить прогноз общего выпуска. Сегодня нужно решение Product Owner, подходит ли ограниченный охват для кампании.

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

Получить решение и сохранить разногласия

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

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

После выбора сохраняются основание, принятые последствия и условия пересмотра. Участники, чьи предложения не вошли в решение, должны понимать, что именно выбрано и почему.

В учебном примере Product Owner принимает выпуск с провайдером A к пятнице и учитывает ограниченный охват в условиях кампании. Остальные провайдеры отложены до проверки контрактов и оценки первой поставки. Владельцы финансовых правил и резерва подтверждают допустимые состояния повторной оплаты.

9. Как зафиксировать и проверить договорённость

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

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

Собрать краткое описание требования

Requirement Brief — краткое описание договорённости. Для нашего примера оно может выглядеть так:

Проблема и цель. В обращениях и при воспроизведении сценария подтверждено: после отказа банка заказ сохраняется, но со страницы заказа нельзя начать новую оплату. Цель — снизить долю таких заказов, оставшихся неоплаченными.

Пользователи и объём. Первый выпуск к пятнице охватывает веб-интерфейс и заказы с оплатой через провайдера A. Доступны банковская карта и электронный кошелёк. Другие провайдеры, мобильное приложение и восстановление истёкшего резерва отложены.

Поведение. На странице заказа покупатель выбирает повторную оплату и доступный способ. Создаётся новая платёжная попытка для того же заказа; сохраняются сумма, состав и введённые данные. Пользователь видит текущий статус попытки.

Правила и качество. Новая попытка разрешена после окончательного отказа при активном резерве. Резерв истекает через 30 минут после создания заказа и не продлевается. При неизвестном результате показывается ожидание; при истёкшем резерве — объяснение и переход к оформлению нового заказа. Повторная отправка операции не приводит к дополнительному списанию, доступ к оплате имеет только владелец заказа. Для времени ответа применяется критерий из раздела 5 с указанными там нагрузкой и границами измерения.

Приёмка. Проверяются сценарии из раздела 5, повторные действия и задержанные события, права доступа и согласованное время ответа. После выбора объёма добавляются критерии: новая возможность доступна только для заказов провайдера A в веб-интерфейсе; выбор способа ограничен картой и кошельком этого провайдера. Для остальных заказов сохраняется прежнее поведение без предложения новой функции.

Переход и сопровождение. Возможность должна работать и для созданных до выпуска заказов, если соблюдены условия повторной оплаты. Команда проверяет совместимость их данных. До включения поддержка проходит обучение; ей доступны состояния попыток и причины недоступности повторной оплаты. Команда предусматривает отключение новых попыток при сбое с сохранением обработки уже начатых платежей.

Решения и открытые вопросы. Product Owner согласовал охват и дату; лид с командой отвечает за техническое решение; владельцы финансовых правил и резерва подтвердили условия. Инженер интеграции проверяет контракты остальных провайдеров до решения о расширении. Этот вопрос не блокирует выпуск для A. Product Owner поддерживает актуальность описания после согласованных изменений.

Проверка результата. Через две недели после включения Product Owner и лид разбирают использование функции, затруднения и долю заказов, оплаченных после первоначального отказа, в выбранном сегменте. Для сопоставления нужны данные до выпуска с теми же условиями отбора и периодом наблюдения за заказом. Сбор событий включён в работу. По результатам решают, расширять ли охват или сначала исправить найденные проблемы.

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

Сохранить основание выбора

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

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

Проверить понимание до обязательства

Лид организует короткий разбор выбранного сценария с участниками, от которых зависит его выполнение и приёмка. Product Owner подтверждает результат и границу объёма, команда — понимание реализуемого поведения и зависимостей, QA — способ проверки. Владельцы отдельных правил подтверждают затрагивающие их условия.

Полезно попросить участников своими словами описать, что получит пользователь и чего он пока не получит. Расхождения в таком пересказе показывают, какие части договорённости ещё нуждаются в уточнении.

Документ должен иметь ответственное лицо за актуальность. Им может быть Product Owner, аналитик, лид или другой участник в зависимости от организации работы. Важно, чтобы команда знала, где находится действующая версия и кто обновляет её после решения.

10. Как пересматривать требования во время разработки

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

Установить, что изменилось

Сначала нужно сравнить новую информацию с текущей договорённостью. Возможны разные ситуации: реализация нарушает уже согласованное правило; в требовании обнаружено упущение; изменилось внешнее условие; появилась новая потребность.

Различение помогает выбрать действие. Ошибка реализации требует исправления и оценки влияния на поставку. Упущенное правило требует решения о поведении. Новая потребность требует продуктового выбора. Любой из этих случаев может изменить объём работы и прогноз.

Оценить последствия до нового обещания

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

Теперь нужно выяснить, можно ли восстановить резерв, остаются ли товары в наличии, сохраняется ли цена и что пользователь увидит при невозможности продолжить заказ. Лид привлекает владельца этих правил и команду. Изменение может затронуть несколько сценариев, данные, тесты и ранее названный срок.

Для пересмотра нужно показать:

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

Обновить общую договорённость

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

Если новая информация показывает, что исходная потребность уже исчезла или выбранный способ её не удовлетворяет, нужно обсудить остановку либо пересмотр работы. Затраченные усилия не подтверждают полезность продолжения.

11. Как проверить результат после поставки

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

Подготовить проверку заранее

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

Для повторной оплаты можно различить три уровня проверки:

Вопрос Что может служить свидетельством
Выполнено ли согласованное требование? Проверки выбранных сценариев, правил и свойств качества
Может ли пользователь решить свою задачу? Прохождение реального сценария после отказа, наблюдение затруднений, обращения в поддержку
Изменилась ли ситуация, ради которой начата работа? Доля завершённых заказов после неуспешной оплаты, объём ручной помощи и другие согласованные признаки

Product Owner отвечает за продуктовую оценку и дальнейший выбор. Лид обеспечивает необходимую техническую наблюдаемость и помогает отличить ограничения реализации от ошибок в понимании потребности.

Разобрать расхождение между ожиданием и результатом

Кнопка может работать по всем критериям, но пользователи её не находят. Они могут находить её, но повторная попытка снова завершается отказом. Может выясниться, что к моменту возвращения покупателя резерв уже истёк. Каждая ситуация требует своего изменения.

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

Изменение метрики само по себе тоже не объясняет причину. Нужно учитывать охват выпуска, состав пользователей, сезонность, работу платёжного провайдера и другие существенные условия. Для ограниченного пилота сначала может быть достаточно подтверждения, что выбранные пользователи способны завершить нужный сценарий.

Принять следующее решение

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

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

12. Как организовать поступление запросов

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

Договориться о пути запроса

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

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

Отдельно определить срочную реакцию

Для инцидентов нужен понятный порядок немедленных действий: например, при недоступности production, потере данных или активной угрозе безопасности. Критерии и полномочия такой реакции должны быть заранее согласованы.

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

Сделать правила общими для команды

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

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

13. Как улучшать работу команды с требованиями

Отдельные ошибки полезно рассматривать вместе: повторяются ли они, на каком шаге возникают и какое устройство работы их воспроизводит. Лид выбирает наблюдения, которые помогают найти конкретное затруднение.

Наблюдение Что проверить
Работа часто ждёт ответа или решения Понятны ли владельцы вопросов, нужны ли ответы раньше, доступна ли эскалация
Реализацию переделывают из-за разного понимания результата Проверяли ли участники сценарии и границу объёма до начала работы
Существенные правила обнаруживаются после поставки Кого не вовлекли, какие состояния и зависимости пропустили
Объём постоянно меняется во время разработки Появляются ли новые сведения или участники меняют приоритет через личные поручения
После выпуска нельзя оценить пользу Были ли согласованы признак результата, способ наблюдения и ответственный

Для повторяющейся проблемы можно измерять время ожидания, число и причины переделок, момент обнаружения упущений. Нужно заранее определить, что именно считается событием, и рассматривать данные вместе с конкретными случаями.

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

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

Итоги модуля

Лид должен провести запрос через совместное прояснение: установить потребность и цель, найти участников, определить полномочия, уточнить поведение и ограничения, подготовить варианты и добиться проверяемой договорённости.

Достаточный результат этой работы можно проверить по следующим признакам:

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

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

Справочное примечание: типы требований по BABOK

BABOK выделяет четыре типа требований. Они помогают описать содержание изменения с разных сторон. (IIBA: Understanding Requirements and Designs)

Тип Что описывает Пример
Бизнес-требования Цели и ожидаемые результаты изменения Снизить долю незавершённых заказов после неуспешной оплаты
Требования стейкхолдеров Потребности участников, необходимые для достижения целей Покупателю нужно завершить покупку без повторного сбора заказа
Требования к решению Необходимое поведение и свойства решения: функциональные и нефункциональные требования Повторная оплата существующего заказа; согласованное время ответа системы
Переходные требования Временные условия и возможности для перехода в новое состояние Обучить поддержку работе с новыми состояниями платежа до включения функции

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

Источники

Subscribe
Прокрутить вверх