Сегодня сложные конструкции. Размышлял над общими принципами нарождающегося подхода к социотехническому проектированию, соединяющего все развиваемые нами методы.
1. Принцип визуализации: всё, что невидимо, неуправляемо. Как только ты выклыдываешь что-то на доску, ты обретаешь силу управлять этим в мышлении. Также, Rumpelstiltskin principle: When you name something then you have a power to talk about it.
2. Многослойность знания. Приходится работать в разных пространствах, чтобы смотреть на один и тот же объект с разных сторон. Речь о проектно-инженерном знании и о предметном или онтологическом, что возвращает картину мира деятельности.
3. Строгость категориального мышления. Отказ от мыслительной «склейки» и работы с ассоциациями. Упор на различение тонкостей.
3.1. Отделение формы воплощения от смысла (как следствие). Все три метода фреймворка построены так, что они отделяют принципиальное от деталей реализации. КГ разделяет цели и задачи, соединяя их через принципы-стратегемы. КПО выделяет значимые функциональные места в процессе, отделяя их от способ воплощения. КРИ расщепляет модель поведения или действия человека на рабочем месте или в жизни на слои от смысла шага до форм реализации иснструмент. Журнал проектирования различает фрагменты знания по их смыслу в проектной деятельности.
4. Социотехничность: любое действие в современном мире может быть продуктивным только когда оно согласовано в нескольких пространствах. В смысловом, в социокультурном, в коммуникационном, в пространственно-временном. Первое, что мы увидели как важное недооцениваемое — политический ландшафт проектов.
5. Программный подход. Учёт, а не отказ от сложности. Вовлечение всех заинтересованных лиц в формирование знаний. Знаковые конструкции из фрагментов знаний направляют и «выдавливают» итоговое решение
6. Принцип пережигания неопределенности в работоспособность. В нашей работе всегда есть две направляющие силы: движение в сторону сжигания неопределенности (белых и серых пятен) и движение в сторону достройки работоспособной конструкции деятельности в мыслительной имитации с опорой на схемы.
★
К методам социотехнического подхода на данный момент относятся:
— Карта гипотез
— Карта процесса-опыта
— Карта реализации историй
— Связанный свот-анализ
1. Принцип визуализации: всё, что невидимо, неуправляемо. Как только ты выклыдываешь что-то на доску, ты обретаешь силу управлять этим в мышлении. Также, Rumpelstiltskin principle: When you name something then you have a power to talk about it.
2. Многослойность знания. Приходится работать в разных пространствах, чтобы смотреть на один и тот же объект с разных сторон. Речь о проектно-инженерном знании и о предметном или онтологическом, что возвращает картину мира деятельности.
3. Строгость категориального мышления. Отказ от мыслительной «склейки» и работы с ассоциациями. Упор на различение тонкостей.
3.1. Отделение формы воплощения от смысла (как следствие). Все три метода фреймворка построены так, что они отделяют принципиальное от деталей реализации. КГ разделяет цели и задачи, соединяя их через принципы-стратегемы. КПО выделяет значимые функциональные места в процессе, отделяя их от способ воплощения. КРИ расщепляет модель поведения или действия человека на рабочем месте или в жизни на слои от смысла шага до форм реализации иснструмент. Журнал проектирования различает фрагменты знания по их смыслу в проектной деятельности.
4. Социотехничность: любое действие в современном мире может быть продуктивным только когда оно согласовано в нескольких пространствах. В смысловом, в социокультурном, в коммуникационном, в пространственно-временном. Первое, что мы увидели как важное недооцениваемое — политический ландшафт проектов.
5. Программный подход. Учёт, а не отказ от сложности. Вовлечение всех заинтересованных лиц в формирование знаний. Знаковые конструкции из фрагментов знаний направляют и «выдавливают» итоговое решение
6. Принцип пережигания неопределенности в работоспособность. В нашей работе всегда есть две направляющие силы: движение в сторону сжигания неопределенности (белых и серых пятен) и движение в сторону достройки работоспособной конструкции деятельности в мыслительной имитации с опорой на схемы.
★
К методам социотехнического подхода на данный момент относятся:
— Карта гипотез
— Карта процесса-опыта
— Карта реализации историй
— Связанный свот-анализ
👍8❤3
Программирующее дерево
В последнее время меня занимает идея программирующего дерева. Это когда, пока проектируешь, не только собираешь записи в журнал проектирования, но и специальным образом организуешь части журнала в структуру, направляющую работу.
В программирующем дереве такой структурой является иерархия. Но задана она хитрым образом. Часть высказываний в дереве требуют что-то от нас, в другой части мы отвечаем на эти требования, вводя допущения. И так они чередуются друг за другом, вплетая в дерево всё бо́льшие подробности.
Пока у меня скверно получается писать на эту тему. Всё, что есть, написано на каком-то около-методологическом языке. Знаю из первых обсуждений текста, читать такое трудно. Вместе с тем, эта практика — самая интригующая, потому что помогает выгрузить в метод то, как я сам собираю сложные системы, путём выращивания.
Текст сейчас такой не потому что мне наплевать на читателя. Дело в том, что чтобы что-то качественно донести, нужно самому досконально и с разных сторон это потрогать и понять, а практика только нарождается. Понятные описания вероятно последуют, сейчас же стадия движения на ощупь. Делюсь этим больше в поисках первых интересантов и единомышленников.
На сегодня из самых коротких текстов с примерами есть описание программирующего дерева на примере ситуации коммуникативного дизайна. Если трудно идёт, но интересно, гляньте недавнюю статью про практику дерева гипотез, четыре года спустя. Если пока тёмный лес, не переживайте — позже последуют более доступные тексты.
В последнее время меня занимает идея программирующего дерева. Это когда, пока проектируешь, не только собираешь записи в журнал проектирования, но и специальным образом организуешь части журнала в структуру, направляющую работу.
В программирующем дереве такой структурой является иерархия. Но задана она хитрым образом. Часть высказываний в дереве требуют что-то от нас, в другой части мы отвечаем на эти требования, вводя допущения. И так они чередуются друг за другом, вплетая в дерево всё бо́льшие подробности.
Пока у меня скверно получается писать на эту тему. Всё, что есть, написано на каком-то около-методологическом языке. Знаю из первых обсуждений текста, читать такое трудно. Вместе с тем, эта практика — самая интригующая, потому что помогает выгрузить в метод то, как я сам собираю сложные системы, путём выращивания.
Текст сейчас такой не потому что мне наплевать на читателя. Дело в том, что чтобы что-то качественно донести, нужно самому досконально и с разных сторон это потрогать и понять, а практика только нарождается. Понятные описания вероятно последуют, сейчас же стадия движения на ощупь. Делюсь этим больше в поисках первых интересантов и единомышленников.
На сегодня из самых коротких текстов с примерами есть описание программирующего дерева на примере ситуации коммуникативного дизайна. Если трудно идёт, но интересно, гляньте недавнюю статью про практику дерева гипотез, четыре года спустя. Если пока тёмный лес, не переживайте — позже последуют более доступные тексты.
👍7
Forwarded from Alena Valter
📣 Привет, на связи дизайн-секция UWDC!
До конференции осталось меньше месяца, и мы продолжаем знакомить вас с программой.
Андрей Шапиро, арт-директор и партнёр в Бындюсофт, поделится новым взглядом на пользовательские истории в докладе «Мышление историями. Как текстовые модели поведения помогают дизайнеру проектировать».
«Истории издревле были ёмкими накопителями образцов человеческого поведения. В последние 30 лет одна из разновидностей историй — пользовательские истории — активно применяется в дизайне цифровых систем и их интерфейсов.
Я расскажу как применять практику записи историй, какие техники работы с историями доступны на сегодня и как работа через истории обогощает мышление дизайнера».
Для получения билета регистрируйтесь на сайте UWDC
🚀 До встречи на конференции!
До конференции осталось меньше месяца, и мы продолжаем знакомить вас с программой.
Андрей Шапиро, арт-директор и партнёр в Бындюсофт, поделится новым взглядом на пользовательские истории в докладе «Мышление историями. Как текстовые модели поведения помогают дизайнеру проектировать».
«Истории издревле были ёмкими накопителями образцов человеческого поведения. В последние 30 лет одна из разновидностей историй — пользовательские истории — активно применяется в дизайне цифровых систем и их интерфейсов.
Я расскажу как применять практику записи историй, какие техники работы с историями доступны на сегодня и как работа через истории обогощает мышление дизайнера».
Для получения билета регистрируйтесь на сайте UWDC
🚀 До встречи на конференции!
👍2😁1
Попробовал в деле новую практику Связанный SWOT-анализ. Александр предложил к анализу прикрутить технику работы с карточками на основе дополнительной инфографики с тегами и маркерами.
Мне понравилось. Техника помогла подготовиться к грядущей сессии по Карте гипотез с заказчиком. До этого в беседе, он уже перечислил опорные точки. Из текста речи заказчика я зафиксировал их в тело SWOT, а после вытащил первые 2 гипотезы для проверки.
К технологии Карты гипотез добавился предваряющий шаг со своей логикой. Рекомендую
Мне понравилось. Техника помогла подготовиться к грядущей сессии по Карте гипотез с заказчиком. До этого в беседе, он уже перечислил опорные точки. Из текста речи заказчика я зафиксировал их в тело SWOT, а после вытащил первые 2 гипотезы для проверки.
К технологии Карты гипотез добавился предваряющий шаг со своей логикой. Рекомендую
👍4🎉3🔥1😁1
6 мая в 19:00 мск расскажу о технологии работы с детальными требованиями с Картой реализации историй.
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе с тем, их инструментарий настолько давно не развивался, что пришло время это исправить.
Карта реализации историй дает аналитику, исследователю и проектировщику утонченную структуру для бесед с пользователем, бизнесом и командой разработки. Пользовательские истории в ней эволюционировали до рабочих историй, а время на запись содержательных историй сократилось.
Метод Карты реализации истории входит во фреймворк проектирования социотехнических систем.
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе с тем, их инструментарий настолько давно не развивался, что пришло время это исправить.
Карта реализации историй дает аналитику, исследователю и проектировщику утонченную структуру для бесед с пользователем, бизнесом и командой разработки. Пользовательские истории в ней эволюционировали до рабочих историй, а время на запись содержательных историй сократилось.
Метод Карты реализации истории входит во фреймворк проектирования социотехнических систем.
Forwarded from Системный подход
6 мая, во вторник вечером, Андрей Шапиро, проектировщик цифровых сервисов и методолог проектирования, расскажет о переосмыслении личного и отраслевого опыта работы с пользовательскими историями.
Ссылка на регистрацию
Ссылка на регистрацию
🔥6👍1
Forwarded from Карта процесса-опыта
📍 22 мая в Москве проведу долгожданный дневной тренинг по Карте процесса-опыта. Занимаемся с 10 до 18 с перерывом на обед. В группе будет до 10 человек, чтобы успеть проработать карты. Приходите учиться.
Записаться на тренинг
Записаться на тренинг
🔥2
В 19:00 по Москве начинаем про Карту реализации историй. В этот раз начнём с подробного разбора недостатков классических пользовательских историй. Затем выйдем на рабочие истории КРИ
https://youtube.com/live/16syPUiuNT4
https://youtube.com/live/16syPUiuNT4
YouTube
Андрей Шапиро Карта реализации историй. Технология осмысленной работы с детальными требованиями
Андрей Шапиро, проектировщик цифровых сервисов и методолог проектирования, расскажет о переосмыслении личного и отраслевого опыта работы с пользовательскими историями.
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе…
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе…
🎞️ Запись эфира о Карте реализации историй
В эфире подробно разобрана история появления практики записи пользовательских историй, основные техники вокруг неё и трудности, встреченные автором за 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