Контекст решения

10 июля 2024

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

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

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

Далее в статье мы рассмотрим 7 основных аспектов Контекста Решения.

Рисунок 1. Основные аспекты контекста решения

Использование клиентом

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

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

Примеры:

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

Физическая среда

Физические условия окружающей среды также влияют на дизайн решения.

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

Примеры:

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

Стандарты и нормативы

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

Примеры:

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

Техническое обслуживание и поддержка эксплуатации

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

К ним относятся многие «рутинные» функции, такие как:

  • Настройка параметров системы и бизнес-правил
  • Обслуживание учетных записей пользователей и административный доступ
  • Диагностика и устранение неполадок
  • Применение модулей оперативной коррекции и патчей безопасности
  • Масштабирование программного обеспечения, оборудования и инфраструктуры для повышения производительности

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

Пример:

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

Поддерживающая инфраструктура

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

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

Примеры:

  • Решение на основе искусственного интеллекта (ИИ) может требовать все большей вычислительной мощности по мере его усложнения.
  • Сервису потоковой передачи фильмов может потребоваться корректировать свои алгоритмы сжатия по мере увеличения пропускной способности сотовой сети.

 Функциональная совместимость с другими решениями

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

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

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

Пример:

  • Портал для сотрудников может работать со сбоями из-за изменения API-интерфейсов подключенных к нему систем расчета заработной платы.

 Система систем

Часто решение выполняет какую-то функцию в составе более крупной системы систем. В этом случае решение может быть подсистемой в сложном киберфизическом решении (например, развлекательная система в автомобиле).

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

Примеры:

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

Статья подготовлена по материалам Scaled Agile, Inc.

Другие статьи в блоге

Новая Big Picture SAFe® 6.0
Новый дизайн Big Picture позволяет организациям на начальном этапе знакомства с SAFe проще ориентироваться во фреймворке и сосредоточиться на наиболее важных аспектах, в первую очередь влияющих на бизнес-результаты организации.
Что делать, когда приходят изменения Фичи во время Интервала Планирования?
В статье Алексей Ионов делится своим опытом о том, как решать проблемы, связанные с появлением новых вводных со стороны бизнеса.
Пре-Планирование (Pre-Plan)
Для совместной подготовки нескольких поездов к своим мероприятиям планирования интервала в SAFe предусмотрен набор мероприятий и артефактов, совместно называемых «Пре-Планирование». Эти подходы и техники на практике могут использоваться как в рамках Поезда Решения, так и для независимых Поездов на уровне Портфеля. В статье приводятся общие описания подходов, входящих в «Пре-Планирование».