🎞️ Запись эфира о Карте реализации историй
В эфире подробно разобрана история появления практики записи пользовательских историй, основные техники вокруг неё и трудности, встреченные автором за 15 лет применения.
Как ответ на вопрос о встреченных трудностях предложен новый формат рабочих историй, а также новый формат карты историй.
На нескольких примерах показано как работает карта, как связаны её слои. Новая структура карты помогает направить беседу о том, что нужно спроектировать.
ВКонтакте
Рутуб
Ютуб
В эфире подробно разобрана история появления практики записи пользовательских историй, основные техники вокруг неё и трудности, встреченные автором за 15 лет применения.
Как ответ на вопрос о встреченных трудностях предложен новый формат рабочих историй, а также новый формат карты историй.
На нескольких примерах показано как работает карта, как связаны её слои. Новая структура карты помогает направить беседу о том, что нужно спроектировать.
ВКонтакте
Рутуб
Ютуб
VK Видео
Карта реализации историй. Технология осмысленной работы с детальными требованиями
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе с тем, их инструментарий настолько давно не развивался, что пришло время это исправить. Карта реализации историй дает аналитику, исследователю и проектировщику утонченную…
👍6🔥6❤1
Меня много раз спрашивали когда будет обучение по Карте процесса-опыта. Ещё есть шанс попасть на очный тренинг 22 мая в Москве. Когда будет следующий и будет ли — пока неизвестно
Forwarded from Пименов Вещает
Возможно вы пропустили, но у нас тут организовался тренинг по инструменту Карта Процесса-Опыта. 22 мая в Москве, офлайн.
Тренинг будет вести автор подхода - Андрей Шапиро. Считайте уникальный шанс поучиться у автора.
Кому интересно - велком сюда: https://neogenda.com/karta-processa-opyta
Тренинг будет вести автор подхода - Андрей Шапиро. Считайте уникальный шанс поучиться у автора.
Кому интересно - велком сюда: https://neogenda.com/karta-processa-opyta
👍3🤷1
Хочу поделиться введением для моей новой книги «Рабочие истории. Практика проектирования с текстовыми моделями Карты реализации историй». За счёт примера из него должна стать понятна суть работы с рабочими историями.
❞
Введение
Все люди проектируют. Чаще всего человек проектирует приспособления для собственной жизни. Не беда, когда мы подолгу ищем способ решить какой-то вопрос для себя лично. На это могут уходить дни и месяцы, а то и годы проб и ошибок. Этот процесс, в конце концов, может быть развлекающим нас приключением.
Другое дело, когда нас просят спроектировать что-то на заказ. Цена ошибки при работе на заказ сильно выше. Когда создаваемое затрагивает жизни множества людей, степень ответственности сильно возрастает. Кажется, любой бы мечтал иметь волшебное средство, сокращающее число таких ошибок.
В этой книге я хочу поделиться одной из технологий проектирования. Технология предполагает ясную и точную последовательность операций при работе с некоторым сырьём в его превращении в какой-то продукт. Проектировщик, применяющий эту технологию, потратит меньше времени времени в бесплодных поисках и сделает меньше ошибок.
Проектировщик работает со знаками. Он выстраивает конструкцию будущего решения в таких знаковых формах как схемы, чертежи и тексты. Работа проектировщика может дойти и до конструкций макетов и прототипов, но это вовсе необязательно. Проектировщик замещает части будущей конструкции знаками и оперирует ими в мыслительной имитации. Когда решение достаточно хорошо показало себя в действительности знаковых форм, переходят к его претворению в жизнь и проверке опытным путём. Наименее прозрачная часть мыслительной работы, что приходится на работу со знаками, до сих пор была недостаточно технологизирована.
Что же является сырьём на входе в этот производственный процесс и что будет его продуктом, раз мы говорим о технологии? Сырьём проектировщику служат любые речевые вводные от задачедателя. Заказчик рассказывает о своей деятельности и текущей ситуации в ней, расставляет акценты на местах затруднений и желаемых эффектах от изменений.
Технология должна помочь проектировщику преобразовать речь задачедателя в некоторый промежуточный продукт анализа и помочь с этим продвинуться в проектировании. Таким промежуточным продуктом и являются рабочие истории. И первая операция в предлагаемой технологии — записать историю, то есть превратить объёмное и разнородное речевое высказывание в ёмкую текстовую модель, сконструированную особым образом.
❦
Давайте представим, что мы оказались в самом разгаре беседы о будущей технической системе. Беседуют дизайнер и заказчик. Их совместный проект — это веб-сервис, соединяющий на своей площадке множество продавцов и покупателей. Дизайнер в беседе с заказчиком применяет технологию записи рабочих историй. В ходе диалога мы увидим как будет изменяться текстовая запись истории.
— Хорошо, что происходит дальше? — спросил дизайнер.
— Дальше уведомление у продавца — отвечает заказчик.
— Здесь важно написать кто и как действует. Действует у нас вроде бы продавец.
— Продавец получит мгновенное уведомление.
Дизайнер записывает что-то в странный формуляр:
— Так, хорошо. А почему ему это важно?
— Что важно?
— Я услышал так: продавцу важна мгновенность сообщения
— Ну, как? Он же хочет продать, — улыбается заказчик
— Да, но почему важна скорость? Пусть, например, получит «медленное» сообщение. Скажем, через час или сутки. Что тогда?
— Тогда он вероятнее всего останется без заказа.
Дизайнер быстро черкнул в формуляр рабочей истории:
❞
Введение
Все люди проектируют. Чаще всего человек проектирует приспособления для собственной жизни. Не беда, когда мы подолгу ищем способ решить какой-то вопрос для себя лично. На это могут уходить дни и месяцы, а то и годы проб и ошибок. Этот процесс, в конце концов, может быть развлекающим нас приключением.
Другое дело, когда нас просят спроектировать что-то на заказ. Цена ошибки при работе на заказ сильно выше. Когда создаваемое затрагивает жизни множества людей, степень ответственности сильно возрастает. Кажется, любой бы мечтал иметь волшебное средство, сокращающее число таких ошибок.
В этой книге я хочу поделиться одной из технологий проектирования. Технология предполагает ясную и точную последовательность операций при работе с некоторым сырьём в его превращении в какой-то продукт. Проектировщик, применяющий эту технологию, потратит меньше времени времени в бесплодных поисках и сделает меньше ошибок.
Проектировщик работает со знаками. Он выстраивает конструкцию будущего решения в таких знаковых формах как схемы, чертежи и тексты. Работа проектировщика может дойти и до конструкций макетов и прототипов, но это вовсе необязательно. Проектировщик замещает части будущей конструкции знаками и оперирует ими в мыслительной имитации. Когда решение достаточно хорошо показало себя в действительности знаковых форм, переходят к его претворению в жизнь и проверке опытным путём. Наименее прозрачная часть мыслительной работы, что приходится на работу со знаками, до сих пор была недостаточно технологизирована.
Что же является сырьём на входе в этот производственный процесс и что будет его продуктом, раз мы говорим о технологии? Сырьём проектировщику служат любые речевые вводные от задачедателя. Заказчик рассказывает о своей деятельности и текущей ситуации в ней, расставляет акценты на местах затруднений и желаемых эффектах от изменений.
Технология должна помочь проектировщику преобразовать речь задачедателя в некоторый промежуточный продукт анализа и помочь с этим продвинуться в проектировании. Таким промежуточным продуктом и являются рабочие истории. И первая операция в предлагаемой технологии — записать историю, то есть превратить объёмное и разнородное речевое высказывание в ёмкую текстовую модель, сконструированную особым образом.
❦
Давайте представим, что мы оказались в самом разгаре беседы о будущей технической системе. Беседуют дизайнер и заказчик. Их совместный проект — это веб-сервис, соединяющий на своей площадке множество продавцов и покупателей. Дизайнер в беседе с заказчиком применяет технологию записи рабочих историй. В ходе диалога мы увидим как будет изменяться текстовая запись истории.
— Хорошо, что происходит дальше? — спросил дизайнер.
— Дальше уведомление у продавца — отвечает заказчик.
— Здесь важно написать кто и как действует. Действует у нас вроде бы продавец.
— Продавец получит мгновенное уведомление.
Дизайнер записывает что-то в странный формуляр:
Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц:
— Так, хорошо. А почему ему это важно?
— Что важно?
— Я услышал так: продавцу важна мгновенность сообщения
— Ну, как? Он же хочет продать, — улыбается заказчик
— Да, но почему важна скорость? Пусть, например, получит «медленное» сообщение. Скажем, через час или сутки. Что тогда?
— Тогда он вероятнее всего останется без заказа.
Дизайнер быстро черкнул в формуляр рабочей истории:
Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц: Чтобы не остаться без заказа
👍1
— А почему он останется без заказа?
— Ну, мы же на рынке. Всем нужно быстро. У нас B2B-маркетплейс, покупатели это станции технического обслуживания. Им нужно быстрее своих клиентов обслуживать. Когда продавец подолгу не отвечает сможет ли он поставить товар, поиск продолжается, — выпалил заказчик. Затем, усмехнувшись, добавил: — Вы же, небось, когда поступали в университет сразу документы в несколько подавали. Чтобы наверняка.
Дизайнер дописал на глазах у заказчика:
— Вот. Именно! Выиграть в конкурентной борьбе. Они и по цене конкурируют друг с другом.
— Хорошо, а как происходит эта борьба? Кто с кем соревнуется?
— Ну, смотри, если мы определили, что товар есть у нескольких поставщиков, то есть продавцов, мы при покупательском заказе смотрит какого выбрать. Там множество критериев: территориальная близость, рейтинг продавца: скорость его реакции, скорость поставки, качество продукции по оценкам потребителей, количество возвратов. Всё это мы смотрим, и, скажем, выиграл у нас продавец «Быстрые тяги». Мы ему отправили запрос, он должен его успеть взять.
— Ага, становится понятнее, — проговорил на автомате дизайнер, чтобы дать понять, что слушает, пока дописывал подробности в историю.
— Но всё таки непонятно почему нужна мгновенность сообщения. Ведь продавец уже выиграл в конкуренции на площадке.
— Э, нее-ет. Мы у него отберём заказ и отдадим другому продавцу, если он будет медлить.
— Это через сколько?
— Ну, положим, через полчаса нужно отбирать и отдавать следующему в нашем списке победителей. Пусть конкурируют. Хотя я не уверен насчёт периода. Это нужно будет опытным путём определить.
— То есть, если я верно понял, важно вовремя увидеть, что заказ пришёл и успеть отреагировать на него?
— Точно!
— Тогда я бы это так записал, наверное:
— Да, всё так.
— По технологии мы ещё должны заполнить слой объектов оперирования. Это вещи и данные, с которыми продавец работает на этом шаге.
— Ммм...
— Я бы записал так. Раз продавцу необходимо успеть отреагировать, то ему важен сам сигнал о поступлении, а также, наверное, время, которое у него есть на его обработку.
— Да. И содержание заказа. Ему надо проверить наличие. Там у него обычно несколько сторонних учётных систем и разных маркетплейсов. Информация о реальных остатках всегда запаздывает. Мы можем продать то, чего уже нет.
— Ага, значит допишем, — печатает дизайнер.
— Отлично. История готова. Я бы подумал о вариантах её реализации.
— Ну, я же говорил уведомление.
— Да, теперь мы понимаем, что важно как-то оповестить продавца. С чем сейчас работают типичные продавцы? Что у них есть из оборудования?
— Все сидят в телефонах. Это самое простое. У большинства компьютеры у прилавков, но часто продавец болтается на складе, его надо оповещать и там. Мобила самый простой вариант.
— Сообщение в чат-боте?
— Ну, мы же на рынке. Всем нужно быстро. У нас B2B-маркетплейс, покупатели это станции технического обслуживания. Им нужно быстрее своих клиентов обслуживать. Когда продавец подолгу не отвечает сможет ли он поставить товар, поиск продолжается, — выпалил заказчик. Затем, усмехнувшись, добавил: — Вы же, небось, когда поступали в университет сразу документы в несколько подавали. Чтобы наверняка.
Дизайнер дописал на глазах у заказчика:
Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц: Чтобы выиграть в конкурентной борьбе
— Вот. Именно! Выиграть в конкурентной борьбе. Они и по цене конкурируют друг с другом.
— Хорошо, а как происходит эта борьба? Кто с кем соревнуется?
— Ну, смотри, если мы определили, что товар есть у нескольких поставщиков, то есть продавцов, мы при покупательском заказе смотрит какого выбрать. Там множество критериев: территориальная близость, рейтинг продавца: скорость его реакции, скорость поставки, качество продукции по оценкам потребителей, количество возвратов. Всё это мы смотрим, и, скажем, выиграл у нас продавец «Быстрые тяги». Мы ему отправили запрос, он должен его успеть взять.
— Ага, становится понятнее, — проговорил на автомате дизайнер, чтобы дать понять, что слушает, пока дописывал подробности в историю.
Н: Продавец
С: Когда поступает новый заказ
Д: Получает мгновенное сообщение
О:
Ц: Чтобы выиграть в конкурентной борьбе
— Но всё таки непонятно почему нужна мгновенность сообщения. Ведь продавец уже выиграл в конкуренции на площадке.
— Э, нее-ет. Мы у него отберём заказ и отдадим другому продавцу, если он будет медлить.
— Это через сколько?
— Ну, положим, через полчаса нужно отбирать и отдавать следующему в нашем списке победителей. Пусть конкурируют. Хотя я не уверен насчёт периода. Это нужно будет опытным путём определить.
— То есть, если я верно понял, важно вовремя увидеть, что заказ пришёл и успеть отреагировать на него?
— Точно!
— Тогда я бы это так записал, наверное:
Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О:
Ц: Чтобы не упустить его, когда система отдаст его конкурентам
— Да, всё так.
— По технологии мы ещё должны заполнить слой объектов оперирования. Это вещи и данные, с которыми продавец работает на этом шаге.
— Ммм...
— Я бы записал так. Раз продавцу необходимо успеть отреагировать, то ему важен сам сигнал о поступлении, а также, наверное, время, которое у него есть на его обработку.
— Да. И содержание заказа. Ему надо проверить наличие. Там у него обычно несколько сторонних учётных систем и разных маркетплейсов. Информация о реальных остатках всегда запаздывает. Мы можем продать то, чего уже нет.
— Ага, значит допишем, — печатает дизайнер.
Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О: Работая с сигналом о новом заказе, содержанием заказа и временем на его обработку,
Ц: Чтобы не упустить заполучить заказ до того как его отдадут конкурентам
— Отлично. История готова. Я бы подумал о вариантах её реализации.
— Ну, я же говорил уведомление.
— Да, теперь мы понимаем, что важно как-то оповестить продавца. С чем сейчас работают типичные продавцы? Что у них есть из оборудования?
— Все сидят в телефонах. Это самое простое. У большинства компьютеры у прилавков, но часто продавец болтается на складе, его надо оповещать и там. Мобила самый простой вариант.
— Сообщение в чат-боте?
Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О: Работая с сигналом о новом заказе, содержанием заказа и временем обработки,
Ц: Чтобы не упустить заполучить заказ до того как его отдадут конкурентам
Р: Сообщение в чат-боте
— Как вариант. Не разоримся на разработке?
— Чат-бота придётся разрабатывать, да. Чуть дороже будет. Можем подавать громкий сигнал как в ЖизньМарт или МакДональдс, когда поступил заказ. У компьютеров на прилавках есть колонки?
— Поставят, если ещё не поставили. Им же важно успевать.
— Тогда основным вариантом будет звуковое оповещение в основном веб-приложении, чат-бот отложим как альтернативу.
— Положим.
❦
Я надеюсь этот отрывок диалога дизайнера и заказчика помог увидеть как рабочие истории помогают структурировать беседу о разрабатываемой системе. Шаблон рабочей истории направляет мышление, подсказывая вопросы, которые ещё необходимо задать в процессе совместного изучения ситуаций. Эта книга расскажет о подробностях технологии проектирования через рабочие истории.
— Чат-бота придётся разрабатывать, да. Чуть дороже будет. Можем подавать громкий сигнал как в ЖизньМарт или МакДональдс, когда поступил заказ. У компьютеров на прилавках есть колонки?
— Поставят, если ещё не поставили. Им же важно успевать.
— Тогда основным вариантом будет звуковое оповещение в основном веб-приложении, чат-бот отложим как альтернативу.
— Положим.
Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О: Работая с сигналом о новом заказе, содержанием заказа и временем обработки,
Ц: Чтобы не упустить заполучить заказ до того как его отдадут конкурентам
Р: 1. Звуковой сигнал в веб-приложении + информация о содержании и времени на обработку заказа в перечне входящих заказов
Р: 2. Сообщение в чат-боте
❦
Я надеюсь этот отрывок диалога дизайнера и заказчика помог увидеть как рабочие истории помогают структурировать беседу о разрабатываемой системе. Шаблон рабочей истории направляет мышление, подсказывая вопросы, которые ещё необходимо задать в процессе совместного изучения ситуаций. Эта книга расскажет о подробностях технологии проектирования через рабочие истории.
❤8
Антон Григорьев, автор канала UX-Notes, законспектировал содержание статьи о Карте реализации историй. Если откладывали её чтение, то вот возможность чтения по диагонали.
Forwarded from UX Notes (Антон Григорьев)
Андрей Шапиро написал о придуманной им Карте реализации историй.
— Она развивает практику User story mapping благодаря новому шаблону историй и слоям для экспресс-проектирования;
— Она лаконично выявляет сценарии использования и определяет форму их технической реализации;
— Первая проблема историй: они наводят на одно конкретное решение, которое часто оказывается неверным, так как задача ещё слабо изучена, либо проблема лишь подразумевается и формулируется в виде решения-кандидата;
— Оперировать альтернативами в разработке крайне важно, так как время и деньги ограничены, и непонятно, какое решение уложится в срок и бюджет;
— Вторая проблема: они не описывают предметную область. Эти знания появляются слишком поздно, что нередко приводит к перепроектированию;
— По горизонтали карта состоит из историй, выкладываемых в порядке их следования;
— По вертикали — из 7 смысловых слоёв: цель действия (зачем?), носитель (кто или что выполняет действие), ситуация (контекст, когда происходит действие), способ действия (каким образом что-то делается), объекты оперирования (с чем взаимодействует носитель, что получается в итоге), форма решения (варианты технических решений), структура экранных блоков;
— Реализация сопряжена с реальным миром и всегда вносит коррективы в замысел. Хоть нам и проще говорить о конкретной форме будущего решения («кнопочное мышление»), замысел должен всегда главенствовать;
— В Карте реализации историй мы постепенно спускаемся от чистой функции к реализации процесса и конкретного инструмента или нескольких, обеспечивающих этот процесс;
— Часто у него могут быть разные варианты срабатывания, в зависимости от ситуации;
— Это деятельностные истории. В отличие от пользовательских в них на первом месте цели и механики деятельности, а потребности вовлечённого в деятельность человека — на втором. На схеме носитель расположен сразу под целью лишь для того, чтобы избежать дублирования;
— Без прикидки объектов оперирования с высокой вероятностью потом придётся возвращаться к перепроектированию. Их можно просто перечислить, но лучше разделить на объекты до взаимодействия и после;
— Форм решения на карте может быть множество. Но приоритизировать разработку и планировать релизы с картой удобно не более чем на сейчас и на потом;
— Начать заполнение карты можно с любого слоя. Самый верхний слой смыслов зачастую не удаётся взять с первого раза. Главное, чтобы все слои в конце концов оказались согласованы.
Видео о карте: ВК, Рутуб, Ютуб. #user_story
— Она развивает практику User story mapping благодаря новому шаблону историй и слоям для экспресс-проектирования;
— Она лаконично выявляет сценарии использования и определяет форму их технической реализации;
— Первая проблема историй: они наводят на одно конкретное решение, которое часто оказывается неверным, так как задача ещё слабо изучена, либо проблема лишь подразумевается и формулируется в виде решения-кандидата;
— Оперировать альтернативами в разработке крайне важно, так как время и деньги ограничены, и непонятно, какое решение уложится в срок и бюджет;
— Вторая проблема: они не описывают предметную область. Эти знания появляются слишком поздно, что нередко приводит к перепроектированию;
— По горизонтали карта состоит из историй, выкладываемых в порядке их следования;
— По вертикали — из 7 смысловых слоёв: цель действия (зачем?), носитель (кто или что выполняет действие), ситуация (контекст, когда происходит действие), способ действия (каким образом что-то делается), объекты оперирования (с чем взаимодействует носитель, что получается в итоге), форма решения (варианты технических решений), структура экранных блоков;
— Реализация сопряжена с реальным миром и всегда вносит коррективы в замысел. Хоть нам и проще говорить о конкретной форме будущего решения («кнопочное мышление»), замысел должен всегда главенствовать;
— В Карте реализации историй мы постепенно спускаемся от чистой функции к реализации процесса и конкретного инструмента или нескольких, обеспечивающих этот процесс;
— Часто у него могут быть разные варианты срабатывания, в зависимости от ситуации;
— Это деятельностные истории. В отличие от пользовательских в них на первом месте цели и механики деятельности, а потребности вовлечённого в деятельность человека — на втором. На схеме носитель расположен сразу под целью лишь для того, чтобы избежать дублирования;
— Без прикидки объектов оперирования с высокой вероятностью потом придётся возвращаться к перепроектированию. Их можно просто перечислить, но лучше разделить на объекты до взаимодействия и после;
— Форм решения на карте может быть множество. Но приоритизировать разработку и планировать релизы с картой удобно не более чем на сейчас и на потом;
— Начать заполнение карты можно с любого слоя. Самый верхний слой смыслов зачастую не удаётся взять с первого раза. Главное, чтобы все слои в конце концов оказались согласованы.
Видео о карте: ВК, Рутуб, Ютуб. #user_story
ashapiro.ru
Карта реализации историй
Метод анализа-синтеза требований к цифровым системам и предварительного их проектирования
🔥5
Если вы в эту субботу будете в Казани, заходите на Дизайн-выходные. Буду рассказывать о том как быстрее и с гарантией прийти к взаимопонимаю в команде и с заказчиком.
Поделюсь проверенным в 15-летней практике инструментом направления беседы — рабочими историями.
ИТ-парк им. Башара Рамеева, Казань
Зал 11, «Цифровой дизайн»
31 мая, 12:00—13:00
Поделюсь проверенным в 15-летней практике инструментом направления беседы — рабочими историями.
ИТ-парк им. Башара Рамеева, Казань
Зал 11, «Цифровой дизайн»
31 мая, 12:00—13:00
🔥7👍2
На прошлой неделе рассказал ребятам из МТС Диджитал о картах процесса-опыта и рабочих историй. Получил горсть обратной связи. Особенно в меня попала фраза:
Отдельное спасибо Арсению Лаврухину и Наталье Дудко за приглашение выступить и организацию.
Если вы хотите, чтобы я рассказал у вас в компании об одной из карт или о подходах к проектированию цифровых сервисов, напишите мне.
Привожу отзывы без купюр.
❞
Мне в целом кажется интересно — потестить сам шаблон сторей проблемы не вижу, хотя мне в нем больше нравится первая часть — 5 блоков с описанием контекста, то что касается описания ui нам не очень релевантно, зачем текстом описывать элементы, если можно сразу набросать драфт ? В целом та же причина, по которой варфреймы не приживаются в компаниях, где есть курс на стандартизацию и не нужно продумывать ui каждый раз индивидуальный
❞
Карта процесса-опыта — хорошенькая, интересно попробовать ее применить, кажется, что может пригодиться. Но сначала надо чтоб задача подходящая попалась, конечно
❞
Андрей похож на свои методики, а они на него — понравились попытки отсечь лишнее. Это круто! Карта очень заинтересовала, буду пробовать, когда эпик подходящий появится. На мой взгляд, главный потенциал в простоте схемы для тех, кто будет на неё опираться и возможность наглядно прописать взаимодействия сервисов. В общем плюсую, оба подхода классные!
❞
Мне показалось, что перейти на такую методику будет тяжеловато. По времени они в любом случае более затратные, а во внутренних продуктах с этим может быть проблемка
❞
КПО очень круто работает (её сила как бы) в отлове межлюдских взаимодействиях. Когда надо разобраться как устроена "сложная" фича, которой пользуются многие, где пересекаются много разных историй. Когда процесс простенький, задача маленькая, либо роль только одна, тогда КПО выглядит слегка избыточной. Хотя даже 1 человек всегда взаимодействует с микросковисами/FE и тд, т.е. можно "наполнить". Но тут уже вопрос цели, которую преследует дизайнер
Андрей похож на свои методики, а они на него — понравились попытки отсечь лишнее.
Отдельное спасибо Арсению Лаврухину и Наталье Дудко за приглашение выступить и организацию.
Если вы хотите, чтобы я рассказал у вас в компании об одной из карт или о подходах к проектированию цифровых сервисов, напишите мне.
Привожу отзывы без купюр.
❞
Мне в целом кажется интересно — потестить сам шаблон сторей проблемы не вижу, хотя мне в нем больше нравится первая часть — 5 блоков с описанием контекста, то что касается описания ui нам не очень релевантно, зачем текстом описывать элементы, если можно сразу набросать драфт ? В целом та же причина, по которой варфреймы не приживаются в компаниях, где есть курс на стандартизацию и не нужно продумывать ui каждый раз индивидуальный
❞
Карта процесса-опыта — хорошенькая, интересно попробовать ее применить, кажется, что может пригодиться. Но сначала надо чтоб задача подходящая попалась, конечно
❞
Андрей похож на свои методики, а они на него — понравились попытки отсечь лишнее. Это круто! Карта очень заинтересовала, буду пробовать, когда эпик подходящий появится. На мой взгляд, главный потенциал в простоте схемы для тех, кто будет на неё опираться и возможность наглядно прописать взаимодействия сервисов. В общем плюсую, оба подхода классные!
❞
Мне показалось, что перейти на такую методику будет тяжеловато. По времени они в любом случае более затратные, а во внутренних продуктах с этим может быть проблемка
❞
КПО очень круто работает (её сила как бы) в отлове межлюдских взаимодействиях. Когда надо разобраться как устроена "сложная" фича, которой пользуются многие, где пересекаются много разных историй. Когда процесс простенький, задача маленькая, либо роль только одна, тогда КПО выглядит слегка избыточной. Хотя даже 1 человек всегда взаимодействует с микросковисами/FE и тд, т.е. можно "наполнить". Но тут уже вопрос цели, которую преследует дизайнер
❤5👍1🤔1
Сегодня дважды на Дизайн-выходных в Казани ребята из МТС и Алиэкспресс рассказывали о картах процесса-опыта и реализации историй и про наш фреймворк проектирования социотехнических систем.
Радостно видеть такой отклик в дизайнерском сообществе. Работаем дальше
Радостно видеть такой отклик в дизайнерском сообществе. Работаем дальше
❤10🔥4👍3🤔1
Как проектировать
Если вы в эту субботу будете в Казани, заходите на Дизайн-выходные. Буду рассказывать о том как быстрее и с гарантией прийти к взаимопонимаю в команде и с заказчиком. Поделюсь проверенным в 15-летней практике инструментом направления беседы — рабочими историями.…
Рассказал сегодня о Карте реализации историй на Дизайн выходных. Удалось записать доклад. По ссылке презентация, видео и материалы по КРИ
🔥12❤5
Методы фреймворка проектирования социотехнических систем
1. Карта гипотез
Канал — @hypothesismap
Чат — @hmappingchat
2. Карта процесса-опыта
Канал — @xpmap
Чат — @xpm_chat
3. Карта реализации историй
Канал — @simapping
Чат — @simap_chat
1. Карта гипотез
Канал — @hypothesismap
Чат — @hmappingchat
2. Карта процесса-опыта
Канал — @xpmap
Чат — @xpm_chat
3. Карта реализации историй
Канал — @simapping
Чат — @simap_chat
Telegram
Как проектировать
📢 Три метода проектирования социотехнических систем на примере охоты на косуль
Андрей Шапиро показал применение методов проектирования на примере того, как древние охотились на диких животных. Всё начинается со стратегии, потом переходим на процесс-опыт…
Андрей Шапиро показал применение методов проектирования на примере того, как древние охотились на диких животных. Всё начинается со стратегии, потом переходим на процесс-опыт…
👍7
Если пробуете примерять несколько методов социотех-фреймворка вместе, вам будет полезна схема их взаимного увязывание. Спрашивайте и предлагайте в комментариях Холста
👍1
Forwarded from Мыслим вместе с Бындю
Начали с Андреем Шапиро соединять все 4 метода, чтобы показать, как они связаны. Первые результаты уже можно изучить на доске https://app.holst.so/share/b/8eb96b43-d151-422d-b527-89c870925e05
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2