Привет, Хабр!
Сегодня рассмотрим метод, который может стать для вас интересным инсайтом в стратегическом планировании разработки — Wardley Mapping.
Если кратко, Wardley Map — это схема, где мы располагаем все компоненты нашего продукта или системы в двух измерениях: по оси «ценность для пользователя» (вертикаль) и по оси «эволюция/зрелость» (горизонталь).
Вертикальная ось отражает цепочку ценности (value chain) — насколько компонент близок к конечному пользователю или, наоборот, скрыт глубоко в инфраструктуре. Самый верх карты — это потребности пользователя, то, ради чего вообще существует ваш проектe. Ниже будут компоненты, которые эти потребности удовлетворяют, еще ниже — то, что нужно для работы этих компонентов, и так далее, вплоть до самых базовых технических услуг.
Горизонтальная ось показывает стадию эволюции каждого компонента — от совсем нового и сырого (слева) до общедоступного стандартизованного решения (справа). Выделяются четыре стадии развития вещей: генезис (идея или уникальная разработка), кастомное решение под задачи (Custom‑built), продукт/аренда (Product/Rental) и commodity/utility — то есть полностью утилитарная commodity‑компонента или услуга, доступная «как электричество из розетки».
На карте слева всякие новаторские штуки, которые встречаются редко, несут высокие риски и могут дать конкурентное преимущество. Справа — то, что уже стало рутиной и легко приобретается как готовый сервис с минимальными рисками (вспомним, например, облачные серверы сейчас). Верхний левый угол карты — это то, что очень ценно для пользователя, но пока ново и нестабильно. Нижний правый угол — незаметные для пользователя бэкэнд‑вещи.
Саймон Уордли (создатель методологи) утверждает, что ценность карт в том, что они выявляют наши предположения и позволяют их оспорить, создавая общее видение продукта.
Оси карты: ценность для пользователя и эволюция компонентов
Цепочка ценности показывает, как компоненты связаны в доставке пользы пользователю. Начинаем всегда с четко обозначенного пользователя и его потребности. Для продуктовой команды это может быть конечный пользователь приложения и его цель — например: «Получить заказ дронами за 30 минут» или «Хранить данные без потерь». Это ставим наверху. Далее спрашиваем себя: «Что нужно, чтобы удовлетворить эту потребность?». Ответы — это наши компоненты/сервисы. Их помещаем под пользовательской потребностью.
Потом для каждого из этих компонентов опять спрашиваем: «А что нужно, чтобы этот компонент работал?» — и добавляем еще уровни ниже. Так постепенно выстраивается цепочка: от очевидных для пользователя вещей — до бэкэнда и инфраструктуры.
Эволюция компонентов — это вторая ось, отражающая насколько зрелым и распространенным является решение на рынке. Тут нужна объективность: оценить, на каком этапе находится каждый компонент:
Genesis (зарождение) — уникальная разработка, аналоги отсутствуют. Например, ваш собственный экспериментальный алгоритм, про который в научных статьях еще не писали. Высокий риск, много неизвестностей.
Custom‑Built (кастомное) — решение есть, но делается под ваши специфические нужды. Аналоги есть, но вы пилите свое, потому что стандартных продуктов нет или они не подходят.
Product/Rental (продукт или аренда) — компонент доступен как готовый продукт или сервис. Можно купить лицензии или арендовать (SaaS, PaaS). Технология уже стандартизирована, хотя может обновляться.
Commodity/Utility (commodity или утилита) — полностью утилитарная вещь, доступная всем по очень низкой цене, зачастую как коммунальная услуга. Конкуренция идет за счет цены/объема. Та ж облачная вычислительная мощность, хранилище, интернет‑коннект — всё это commodity.
Каждый компонент из цепочки помещаем по горизонтали согласно его стадии. Новые или редкие технологии — ставим левее. То, что уже есть на каждом углу, сдвигаем вправо. Не нужно пытаться нанести точное числовое значение — позиция относительная. Главное, кто левее, а кто правее друг друга. Например, если вы используете PostgreSQL для хранения данных — это явно правее (готовый продукт с десятилетней историей), чем ваш самописный модуль машинного обучения, который пока сделан «на коленке» под ваши задачи (левее).
Но конечно же, карта Уордли — это не архитектурная схема. Она не про последовательность вызовов или сетевые диаграммы. Это про ценность и эволюцию. На ней не показываем временные потоки или масштаб, только относительную позицию компонентов. При этом на карте проводим линии зависимостей (обычно стрелки сверху вниз): кто чем пользуется. Верхние узлы зависят от нижних. Можно сказать, что стрелка означает «для работы X необходим Y». Например, фронтенд зависит от API, API зависит от базы данных. Пользовательская потребность удовлетворяется через ряд зависимостей вниз по цепочке.
Как составлять Wardley Map
Перейдем к практике. Как построить карту Уордли для проекта? Опишу пошагово на примере.
1. Определяем пользователя и его нужды. Начинаем я с того, что четко сформулировали, кто конечный пользователь нашего продукта и что ему надо. Без этого карта бессмысленна — она всегда должна быть привязана к тому, кому мы приносим ценность.
Например, предположим, разрабатываем сервис доставки дронами. Пользователь — допустим, клиент интернет‑магазина, его потребность — получить заказ как можно быстрее. Это и ставим на вершину карты как отправную точку. Иногда рисуют вверху значком человечка «User» и подписывают потребность рядом.
2. Расписываем цепочку ценности. Далее перечисляем все крупные вещи, которые нужны, чтобы удовлетворить эту потребность. Что должно произойти, чтобы дрон доставил посылку быстро? Ну, например: нужна сама платформа дронового сервиса — то есть флот дронов, которые могут летать с грузом; нужен софт для маршрутизации этих дронов; нужны какие‑то базовые данные — скажем, информация о погоде, чтобы не запускать дрон в шторм; карты и GPS для прокладки маршрута; связь для управления дроном и передачи данных, и т. д. Выписываем все такие элементы. Каждый из них — компонент цепочки. Затем связываем их: дроновый сервис (как ключевой компонент) опирается на флот дронов и на ПО маршрутизации. ПО маршрутизации в свою очередь зависит от данных погоды, картографического сервиса и от канала связи. Дроны зависят от связи (для управления) и от погоды (решение о вылете). И так далее.
В итоге получается дерево зависимостей, ориентированное на пользователя. Наверху — «доставка посылок дронами быстро» (потребность пользователя). Под ним — «платформа доставки дронами» (наш сервис, удовлетворяющий эту потребность). Еще ниже — основные компоненты: «флот дронов (hardware)» и «система маршрутизации (software)». Еще ниже — поддерживающие компоненты: «API погоды», «картографический сервис (GPS)», «сеть связи». Это и есть наша цепочка ценности сверху вниз.
3. Оцениваем стадию эволюции каждого компонента. Теперь для каждого узла думаем, насколько он нов или распространен. В примере:
Дроновый сервис доставки — вещь новая, мало у кого есть. Ставим ее ближе к левому краю (скажем, зона между Genesis и Custom). Пока что это уникальное предложение на рынке.
Флот дронов — сами по себе дроны уже продаются на рынке (товар), но дронов, способных безопасно доставлять грузы, не так много. Можно оценить это как ближе к продуктовой стадии, но не commodity. Ставим где‑то на границе Custom/Product.
Система маршрутизации дронов — специфичный софт, скорее всего разрабатываем на заказ под себя. Возможно, частично есть решения, но для нашей задачи кастомизируем. Значит, это Custom‑built — левее, но не совсем Genesis.
Погодный API — ну тут все ясно, погоду можно получить от кучи провайдеров. Это commodity‑сервис, доступный по запросу за копейки или бесплатно. Ставим далеко вправо.
Картографический сервис/GPS — тоже commodity (например, Google Maps API или открытые карты). Практически утилита.
Сеть связи — сама по себе интернет/мобильная связь — commodity. Если дроны используют сотовую сеть или спутниковую, для нас это утилита, мы просто платим за трафик.
4. Наносим все на карту. Рисую двумерное поле: горизонталь — эволюция (слева генезис, справа commodity), вертикаль — ценность (вверху пользователь). Расставляем компоненты по прикинутым координатам. Затем проводимлинии зависимостей: от потребности пользователя вниз к сервису, далее к подчиненным компонентам и так далее. Получается такая карта:
Анализируем получившуюся карту. Теперь самое интересное — что нам говорит эта картина? На что сразу смотреть:
Несоответствия. Ищем компоненты, которые очень высоко по ценности, но при этом сидят слева в незрелых стадиях. Это потенциально опасно: пользователь этого требует, а технология еще сырая — риски, сбои, неудовлетворенность клиентов.
Возможности для инноваций. Смотрим на левую часть карты: там зоны Genesis и Custom. Эти компоненты еще не стали массовыми — возможно, тут наше конкурентное преимущество. Тимлиду стоит задать вопрос: не упускаем ли мы что‑то? Может, стоит вложиться именно в эти области, пока конкуренты спят?
Где можно сэкономить за счет commodity. Правый край карты — все, что уже стандартизовано. Здесь зачастую выгоднее купить или взять в аренду, чем развивать свое. Если какой‑то важный для цепочки компонент сидит далеко справа, стоит рассмотреть аутсорс, облако, готовые продукты.
Взаимосвязанные движения. Продумываем, как изменения одного компонента влияют на другие. Карта помогает видеть расклад сил: если, скажем, появятся десятки конкурентов в доставке дронами, наш верхний левый компонент (сервис) поедет резко вправо. Тогда нынешний козырь станет базовой необходимостью, и придется придумывать новые фишки слева, чтобы выделяться.
Ограничения и инерция. Стоит подумать, что может мешать сдвигать компоненты так, как хотелось бы. Инерция в компаниях — страшная сила: даже понимая, что компонент уже commodity, люди могут продолжать тянуть с миграцией из‑за «мы всегда так делали». На карте можно помечать факторы инерции или внешние ограничения. Например, для наших дронов серьезное ограничение — регулирование авиации.
6. Действуем на основе карты. Наконец, имея карту и анализ, можно набросать варианты стратегий. Что мы делаем с этой информацией? Например, видим риск: важный компонент незрелый — решаем вложиться в его развитие, может быть, привлечь экспертов, увеличить команду, написать больше тестов, чтобы повысить надежность. Видим возможность сэкономить на commodity — выносим план миграции на облачный сервис, закрываем свой дата‑центр (классический пример: когда‑то собственные сервера давали конкурентное преимущество, а сейчас это commodity и разумно переехать в AWS или аналог). Видим возможность для инновации — убеждаем бизнес выделить время на R&D по компоненту слева, который может через год‑два выстрелить. Например, начинаем экспериментальный проект по новой технологии, которая пока генезис.
7. Обсуждаем и пересматриваем. Wardley Map — не статичная картинка для отчета, ее сила именно в совместном обсуждении. Нужно приглашать все важные лица к этому диалогу. Главное — регулярно сверяться с реальностью и не бояться поправить карту. Мир меняется — карта тоже.
Так же есть несколько подходов визуализации карты:
Рисование «вручную» на электронных досках или диаграммах.
Специализированные онлайн‑инструменты. Самый известный — Online Wardley Maps.
Заключение
Wardley Map — мощный инструменТ. Он не решит за вас всех проблем, но здорово прокачает ваше стратегическое зрение. Попробуйте на своем проекте: возьмите час досуга, нарисуйте карту — и, может быть, вы увидите то, что раньше ускользало от внимания. Без преувеличений, это интересный процесс, который к тому же приносит прямую пользу делу. Удачного картирования, и пусть ваши самые рискованные затеи окажутся в верхнем левом углу карты (а затем благополучно переедут вправо, став вашей заслуженной победой).
Если по вашей Wardley-карте видно, что команде не хватает зрелости в паре критичных узлов, это закрывается адресным обучением: корпоративные треки OTUS по программированию, DevOps/инфраструктуре, аналитике и управлению процессами, в форматах от участия в открытых группах до кастомных программ. Вечерние живые занятия с практикой и доступом к записям помогают встроить обучение в рабочий ритм без простоя. Это понятный способ точечно усилить нужные компоненты вашей цепочки ценности без лишней бюрократии.
А чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram‑канал OTUS4Business.