«Разработать систему записи самим или купить готовую?» звучит как одно решение. Но сервис записи состоит из нескольких частей: клиентского опыта, правил планирования, данных календаря, уведомлений и инфраструктуры. Если считать весь сервис одним компонентом, команда рискует разработать слишком многое или приобрести решение, которое не поддерживает самое важное для её клиентов.
Карта Уордли разделяет эти компоненты и показывает их в контексте. На примере условной службы ремонта оборудования разберём, где команда могла бы экспериментировать, где — сравнивать готовые продукты и что ещё нужно выяснить до выбора решения.
Правильно прочитайте обе оси
Метод Wardley Mapping, созданный Саймоном Уордли, связывает потребности пользователя с возможностями, которые их обеспечивают. Вертикальное измерение отражает цепочку создания ценности и то, насколько её компоненты видны пользователю. Горизонтальное — эволюцию; стадии обычно называются Genesis, Custom, Product и Commodity: зарождение, индивидуальная разработка, продукт и стандартизированная услуга или ресурс. В руководстве Learn Wardley Mapping объясняется, как положения компонентов и их зависимости образуют карту.
Эволюция — не календарный план. Перемещение вправо не означает, что команда закончит компонент в следующем месяце. Низкое положение по вертикали тоже не говорит о незначительности: сбой инфраструктуры способен остановить весь сервис.
Эта карта отличается и от стратегической карты, построенной вокруг целей организации (на английском). Здесь мы рассматриваем, как базовые возможности сервиса связаны с потребностью пользователя и насколько они сформировались в соответствующей среде.
Начните с потребности заказчика ремонта
Сервис из нашего примера организует ремонт профессионального кухонного оборудования. Пользователь — управляющий рестораном, которому нужен подходящий мастер в удобное время. Его непосредственная потребность не в том, чтобы «воспользоваться нашей платформой записи», а в том, чтобы организовать выезд, который действительно поможет устранить неисправность.
Напишите эту потребность в верхней части доски. Ниже перечислите необходимое: процесс оформления заявки, сведения об оборудовании и неисправности, подбор мастера с нужными навыками, свободные интервалы и понятное подтверждение для заказчика.
Теперь определите зависимости этих возможностей. Для доступных интервалов нужны данные календаря. Для подбора мастера — сведения о типах оборудования и компетенциях. Для подтверждения — сервис уведомлений. Цифровому сервису также нужны вычислительные ресурсы, хотя клиент обычно не взаимодействует с ними напрямую.
Проводите связь только там, где один компонент нуждается в другом. Принадлежности одному подразделению недостаточно. Если команда начинает обсуждать каждую базу данных и API, вернитесь к вопросу встречи: какие части сервиса записи разрабатывать, а какие получать извне?
Размещайте компоненты по признакам, а не по привычке
В нашем примере предположим, что команда нашла несколько зрелых продуктов для записи, но ещё экспериментирует со способом подбора мастера для необычных неисправностей. Эти допущения задают учебный сценарий, а не оценку рынка или конкретных поставщиков.
| Компонент | Положение в примере | Основание | Что нужно проверить реальной команде |
|---|---|---|---|
| Экспериментальный подход к подбору мастера по неисправности | Зарождение | Предлагаемый подход нов, и его полезность ещё не ясна | Существующие альтернативы и результаты проверки работоспособности подхода |
| Особый сценарий записи на ремонт | Индивидуальная разработка | В примере нужна адаптированная последовательность для необычных заказов | Наблюдения за задачами клиентов и сравнение с доступными рабочими процессами |
| Планирование выездов | Продукт | В сценарии предполагаются зрелые продукты с понятными функциями | Текущие возможности, ограничения и требования к интеграции |
| Уведомления клиентов | Продукт | В сценарии настраиваемый сервис способен покрыть базовую потребность | Доставку сообщений, доступность для пользователей, операционную совместимость и условия поставщика |
| Базовые вычислительные ресурсы | Стандартизированный ресурс или услуга | В примере это типовая обеспечивающая возможность | Требования сервиса, доступные варианты предоставления и ограничения использования |
Сценарий оформления заявки расположите сравнительно высоко: он близок к клиентскому опыту. Обеспечивающие компоненты поместите ниже и соедините зависимости. Не превращайте строки таблицы в пять изолированных точек: именно связи придают конкретность обсуждению выбора решения.
«Мы написали это сами» ещё не означает стадию индивидуальной разработки. Компания может поддерживать собственную реализацию возможности, которая широко доступна как готовый продукт или типовая услуга. И наоборот: оплата специализированной разработки не делает лежащую в её основе возможность стандартизированным продуктом.
Если участники не согласны с положением компонента, запишите разные основания. Возможно, «модуль записи» стоит разделить на обычное распределение интервалов и подбор мастера для нестандартной задачи. Широкое название способно скрывать компоненты с совершенно разными свойствами.
Уточните с помощью карты, что именно разрабатывать или покупать
Первоначально предлагалось разработать всю систему записи. Карта подсказывает более узкий вопрос: можно ли взять готовое обычное планирование, сохранив возможность развивать особый клиентский сценарий ремонта и проверять новый подход к подбору мастера?
Это вопрос для проверки, а не автоматическая рекомендация. Готовый продукт может навязывать жёсткую последовательность записи, требовать неизвестные клиенту сведения или затруднять изменение важной функции. Положение компонента не отменяет проверки соответствия задаче, эксплуатационных расходов, договоров, требований безопасности и сложности перехода.
В описании одной из своих первых карт Саймон Уордли показывает, зачем рассматривать компоненты на разных стадиях эволюции, а не считать систему неделимым целым. Служба ремонта может использовать этот способ рассуждения, не перенося на себя выводы исторического примера.
Сравните два конкретных варианта
Вариант А — вместе разработать клиентский сценарий, планирование и уведомления. Команда сможет контролировать их взаимодействие, но ей придётся поддерживать несколько возможностей, которые, возможно, уже доступны на рынке.
Вариант Б — создать небольшой клиентский слой поверх готового продукта планирования. Объём собственной поддержки может уменьшиться, но только если продукт позволяет реализовать нужные правила записи и получить данные, необходимые клиентскому сценарию.
Проверьте вариант Б на сложной заявке, а не только на удобной демонстрации. Возьмите ресторан с неясной неисправностью, мастера, который обслуживает лишь часть оборудования, и запись, которую может потребоваться изменить после уточнений. Если готовый компонент не поддерживает такую последовательность, разберитесь, связано ли это с настройкой, отсутствующим интерфейсом или принципиальным несоответствием задаче.
Нарисуйте карту сервиса в Boardmix
Откройте Boardmix и создайте пустую доску. Нарисуйте горизонтальную ось «Эволюция» и разделите её на стадии «Зарождение», «Индивидуальная разработка», «Продукт» и «Стандартизированный ресурс». Вертикальную ось подпишите «Видимость для пользователя»; более видимые компоненты находятся выше.
- Поместите «Управляющий рестораном» над потребностью «Организовать подходящий выезд на ремонт». Сохраняйте эту отправную точку в поле зрения при добавлении компонентов.
- Ниже добавьте «Сценарий записи на ремонт». Соедините его с «Подбором мастера по неисправности» и «Планированием выездов».
- Разместите пять компонентов из примера в предварительных позициях. Подпишите точки, чтобы карту можно было прочитать без опоры на цвет.
- Соедините сценарий записи с уведомлениями: подтверждение выезда входит в наш пример сервиса. Ниже покажите зависимость от вычислительных ресурсов.
- Возле подбора мастера добавьте заметку: «Экспериментальный подход — сравнить существующие альтернативы». Два варианта получения решения вынесите за пределы карты, чтобы они не выглядели дополнительными компонентами.
Разделяйте текущую и предлагаемую схему. Если хотите рассмотреть готовое планирование, скопируйте соответствующий участок рисунка и обозначьте вторую версию как вариант. Если просто передвинуть точку на исходной карте, предложение может выглядеть уже существующим положением дел.
Понимайте, чего карта не решает
Карта не вычисляет лучшего поставщика, не доказывает окупаемость и не предсказывает срок превращения возможности в массовую услугу. Не добавляйте точные координаты и прогнозные даты только ради аналитичного вида. Приблизительное положение с понятным основанием полезнее неподтверждённой десятичной дроби.
Для службы ремонта ближайший вопрос — можно ли отделить обычное планирование от логики нестандартных заказов, не ухудшив клиентский опыт. Небольшой интеграционный эксперимент даст часть ответа. Наблюдение за клиентами — другую. Карта помогает понять, почему эти проверки нужно рассматривать вместе.
Если готовый продукт подойдёт, команда сможет уделить больше внимания пока неясной части пути заказчика. Если не подойдёт, карта покажет, какая зависимость требует разбора, вместо вывода «покупка не сработала — значит, разрабатываем всё сами».
