#систематика /// Онтологический дребезг
Это ощущение, что в описании, речи, коммуникации что-то не так. Ощущение, что допущены ошибки при работе с типами объектов, отношениями объектов.
Это чувство / ощущение важно тренировать, чтобы вылавивать места, где скрыты ошибки, где надо распутать клубок объяснений, пониманий, связей. В противной случае ошибки рассуждения / описания будут пропущены и проявятся позже, уже на этапах проектирования и моделирования, что значительно дороже исправлять.
Чувство онтологического дребезга тренируется и калибруется, чтобы через призму этого восприятия также рассматривать описания, коммуникации, объяснения.
Онтологический радар, ловящий это чувство дребезга, лучше всего не выключать вообще (чем включать при необходимости проверки), так как ситуаций — когда ошибки есть и их надо отловить — происходят чаще, чем мы сможем заметить и успеть включить радар.
___
#описание #коммуникация #объяснение #иерархия #класс #тип #объект
Это ощущение, что в описании, речи, коммуникации что-то не так. Ощущение, что допущены ошибки при работе с типами объектов, отношениями объектов.
Это чувство / ощущение важно тренировать, чтобы вылавивать места, где скрыты ошибки, где надо распутать клубок объяснений, пониманий, связей. В противной случае ошибки рассуждения / описания будут пропущены и проявятся позже, уже на этапах проектирования и моделирования, что значительно дороже исправлять.
Чувство онтологического дребезга тренируется и калибруется, чтобы через призму этого восприятия также рассматривать описания, коммуникации, объяснения.
Онтологический радар, ловящий это чувство дребезга, лучше всего не выключать вообще (чем включать при необходимости проверки), так как ситуаций — когда ошибки есть и их надо отловить — происходят чаще, чем мы сможем заметить и успеть включить радар.
___
#описание #коммуникация #объяснение #иерархия #класс #тип #объект
#систематика /// Целеориентированное описание
Описание обязательно создается для совершения дейстия в реальном мире. У описания обязательно есть цель — чтобы целевое действие совершилось.
Описать N, чтобы агент A выполнил действие X.
Хорошее, работающее описание можно создать по простым шагам:
1) Выявить, узнать целевое действие для описания. Без этого описание обречено на провал. Целевое действие запрашивается у заказчика описания, если в самом запросе описания цель не ясна. О цели лучше всего спросить прямо — "в результате потребления описания что должно произойти, с кем и как"; с кем и как важны, чтобы не скатываться в размытые и общие запросы вроде "чтобы стало лучше, чтобы доход рос, чтобы сотрудники не ругались". Если нет возможности спросить прямо, то узнать косвенно: собираем/выявляем максимум контекстной информации о заказчике, прямо спрашиваем про его роль/роли ("вы как кто спрашиваете?") или понимаем их из контекста. На основе этой информации строит гипотезы о целях описания и проверяем эти гипотезы, лучше всего явно — "я верно понимаю, что вы хотите … ?".
2) Провести исследование — чего не хватает, чтобы подобрать язык для описания. На выходе — список недостающей информации. Кроме языка здесь важны эпистемический статус агента (адресата описания), понятийное расстояние. По шагам:
- Кто адресат описания — это максимально важно, так как не зная адресата мы составим описание для никого, потратим время впустую, шанс, что описание сработает, минимальный.
- Какие объекты надо описать? в какой части реального мира эти объекты находятся? в разрезе каких понятий / в какой нарезке* их надо описать? насколько детально и насколько конкретно?
Пример про нарезку: описать панамку в разрезе материалов и техники сшивания или в разрезе фасона, цвета или в разрезе себестоимости и цены?
- На каком языке описывать? какие термины будут понятны адресату? надо ли приложить интерпретатор?
- В каком формате описываем (картинка, схема, текст, видео-инструкция, канбан-карточка, устное объяснение) и в какой нотации?
- Какая цель агента-потребителя описания? Он будет использовать описание для работы, для каких-то других дел / целей?
- Каков эпистемический статус агента? Что он уже знает о той предметной области, про которую мы собираемся ему сообщать? Выполнял ли он подобные действия раньше?
- Какое должно быть содержание описания, чтобы привести агента-потребителя в необходимый нам статус?
4) Собрать недостающую информацию — в идеале собирать информацию у прямых адресатов, у тех, кто будет читать описание и что-то делать по нему. По шагам:
- Прямо спросить у адресатов всё, что нам непонятно.
- В случае если спросить нельзя, то построить гипотезы и проверить их:
- предположили нарезку и язык — пообщались этим языком по этой нарезке — при необходимости скорректировали язык и нарезку
- предположили уровень подробности и уровень абстракции — проговорили самые мелкие и самые крупные объекты интереса, проговорили максимально конкертные и наиболее абстрактные объекты / понятия — скорректировали при необходимости.
6) Спроектировать описание — подобрать язык, настроить максимы кооперации. По шагам:
- Чтобы подобрать язык стоит также понять на каком участке спектра точности удобно / привычно / комфортно общаться потребителю описания.
- Также важно предположить понятийное расстояние, чтобы понимать шаг, который может делать агент, то есть как быстро он будет усваивать новые для него картины мира из нашего описания.
8) Создать описание — по шагам:
- Явно (текстом/таблицей) изложить (для себя!) все мета-данные для описания: целевое действие, роль заказчика, кто адресат, его статусы, язык и нарезка, понятийное расстояние и удобный уасток спектра, etc.
- Создать полный текст, соблюдая правила:
- Один абзац — одна мысль в формате тезис—аргумент—вывод.
- В начале обозначить, о чем будет описание и зачем оно нужно агенту-потребителю
___
#описание #коммуникация #цель #надсистема
Описание обязательно создается для совершения дейстия в реальном мире. У описания обязательно есть цель — чтобы целевое действие совершилось.
Описать N, чтобы агент A выполнил действие X.
Хорошее, работающее описание можно создать по простым шагам:
1) Выявить, узнать целевое действие для описания. Без этого описание обречено на провал. Целевое действие запрашивается у заказчика описания, если в самом запросе описания цель не ясна. О цели лучше всего спросить прямо — "в результате потребления описания что должно произойти, с кем и как"; с кем и как важны, чтобы не скатываться в размытые и общие запросы вроде "чтобы стало лучше, чтобы доход рос, чтобы сотрудники не ругались". Если нет возможности спросить прямо, то узнать косвенно: собираем/выявляем максимум контекстной информации о заказчике, прямо спрашиваем про его роль/роли ("вы как кто спрашиваете?") или понимаем их из контекста. На основе этой информации строит гипотезы о целях описания и проверяем эти гипотезы, лучше всего явно — "я верно понимаю, что вы хотите … ?".
2) Провести исследование — чего не хватает, чтобы подобрать язык для описания. На выходе — список недостающей информации. Кроме языка здесь важны эпистемический статус агента (адресата описания), понятийное расстояние. По шагам:
- Кто адресат описания — это максимально важно, так как не зная адресата мы составим описание для никого, потратим время впустую, шанс, что описание сработает, минимальный.
- Какие объекты надо описать? в какой части реального мира эти объекты находятся? в разрезе каких понятий / в какой нарезке* их надо описать? насколько детально и насколько конкретно?
Пример про нарезку: описать панамку в разрезе материалов и техники сшивания или в разрезе фасона, цвета или в разрезе себестоимости и цены?
- На каком языке описывать? какие термины будут понятны адресату? надо ли приложить интерпретатор?
- В каком формате описываем (картинка, схема, текст, видео-инструкция, канбан-карточка, устное объяснение) и в какой нотации?
- Какая цель агента-потребителя описания? Он будет использовать описание для работы, для каких-то других дел / целей?
- Каков эпистемический статус агента? Что он уже знает о той предметной области, про которую мы собираемся ему сообщать? Выполнял ли он подобные действия раньше?
- Какое должно быть содержание описания, чтобы привести агента-потребителя в необходимый нам статус?
4) Собрать недостающую информацию — в идеале собирать информацию у прямых адресатов, у тех, кто будет читать описание и что-то делать по нему. По шагам:
- Прямо спросить у адресатов всё, что нам непонятно.
- В случае если спросить нельзя, то построить гипотезы и проверить их:
- предположили нарезку и язык — пообщались этим языком по этой нарезке — при необходимости скорректировали язык и нарезку
- предположили уровень подробности и уровень абстракции — проговорили самые мелкие и самые крупные объекты интереса, проговорили максимально конкертные и наиболее абстрактные объекты / понятия — скорректировали при необходимости.
6) Спроектировать описание — подобрать язык, настроить максимы кооперации. По шагам:
- Чтобы подобрать язык стоит также понять на каком участке спектра точности удобно / привычно / комфортно общаться потребителю описания.
- Также важно предположить понятийное расстояние, чтобы понимать шаг, который может делать агент, то есть как быстро он будет усваивать новые для него картины мира из нашего описания.
8) Создать описание — по шагам:
- Явно (текстом/таблицей) изложить (для себя!) все мета-данные для описания: целевое действие, роль заказчика, кто адресат, его статусы, язык и нарезка, понятийное расстояние и удобный уасток спектра, etc.
- Создать полный текст, соблюдая правила:
- Один абзац — одна мысль в формате тезис—аргумент—вывод.
- В начале обозначить, о чем будет описание и зачем оно нужно агенту-потребителю
___
#описание #коммуникация #цель #надсистема
#систематика /// Зачем учитывать контекст
Необходимо учитывать контекст при коммуникации: принимать его и передавать.
Это нуждля того, чтобы текст, явное сообщение, лучше было принято и усвоено.
Метафора: у адресата сообщения есть фон с дыркой для текста-объекта, который мы ему коммуницируем; эта дырка в форме прямоугольника, а наш объект круглый; и вот нам надо понять какие уголки контекста надо достроить, чтобы объект максимально полно сложил пазл на стороне адресата / агента.
Что же именно может делать контекст при коммуникации:
- Помогает соблюсти максиму модальности, делает сообщеня для адресата более связным
- Дает намек на интерпретатор для передаваемого сообщения
- Помогает привести адресата в нужное состояние
- Сообщает адресату нашу роль, из которой мы коммуницируем
- Помогает сообщить адресату его роль, к которой мы коммуницируем
___
#текст #контекст #фон #объект #роль #коммуникация
Необходимо учитывать контекст при коммуникации: принимать его и передавать.
Это нуждля того, чтобы текст, явное сообщение, лучше было принято и усвоено.
Метафора: у адресата сообщения есть фон с дыркой для текста-объекта, который мы ему коммуницируем; эта дырка в форме прямоугольника, а наш объект круглый; и вот нам надо понять какие уголки контекста надо достроить, чтобы объект максимально полно сложил пазл на стороне адресата / агента.
Что же именно может делать контекст при коммуникации:
- Помогает соблюсти максиму модальности, делает сообщеня для адресата более связным
- Дает намек на интерпретатор для передаваемого сообщения
- Помогает привести адресата в нужное состояние
- Сообщает адресату нашу роль, из которой мы коммуницируем
- Помогает сообщить адресату его роль, к которой мы коммуницируем
___
#текст #контекст #фон #объект #роль #коммуникация
#систематика /// Как принимать и передавать контекст
Для принятия / выявления нужного контекста выделяем объекты внимания (из фона, да).
- Цель акта коммуникации — какое целевое действие у нашей коммуникации?
- Какого масштаба нужный нам контекст — он будет отличаться в зависимости от адресата / времени, условий и цели коммуникации.
- Какой уровень абстракции у нужного нам контекста? — обсуждаем какую-то конкретную ситуацию или же надо концептуализировать? на сколько уровней?
- Эпистемический статус адресата — что он уже знает и знает ли он что мы знаем о его знании?
- Эмоциональный статус адресата — каковы сейчас его ресурсы относительно внимания, его фокус сейчас на что направлен? надо ли его фокусировать на объекты нашей коммуникации? возможно ли это сделать?
- Расположение слушать именно нас
- каков у агента контекст относительно нас в данной роли? как агент нас воспринимает?
- как агент видит себя "нашими глазами" (и далее рекурсивно)
- какова атрибуция у агента относительно нас и у нас относительно агента — как наши модели (модель нас у агента и модель агента у нас) воспринимают причинно-следственные связи?
Передавая в сообщении контекст, полезно разделять в уме этот контекст на два потока
1) Постоянная часть контекста, то, что нам надо постоянно доносить до агентов в ходе коммуникации
- роль/роли (а вместе с ними интерес-предпочтение-намерение)
- уровень компетентности в обсуждаемом домене
- (наша) способность осваивать новые компетенции
- эпистемический статус + способы мышления/рассуждения, то есть то, как мы нашего эпистемического статуса достигаем
- частый эмоциональный статус, состояние внимания
- комфортный промежуток на спектре примерно—точно
2) Ситуативно важная часть — то, что меняется при каждой коммуникации
- текущая роль (это важно, так как ролей обычно несколько)
- уровень компетентности в рассмотрении системного уровня, который обсуждается
- эпистемический статус именно по текущей коммуникации, ее объектам
- текущий эмоциональный статус, состояние внимания
- комфортный промежуток на спектре примерно—точно
В зависимости от агентов и ситуации делаем ревизию постоянной части и настраиваем ситуативную часть для каждой коммуникации.
____
#контекст #атрибуция #коммуникация #эпистемический_статус #роли
Для принятия / выявления нужного контекста выделяем объекты внимания (из фона, да).
- Цель акта коммуникации — какое целевое действие у нашей коммуникации?
- Какого масштаба нужный нам контекст — он будет отличаться в зависимости от адресата / времени, условий и цели коммуникации.
- Какой уровень абстракции у нужного нам контекста? — обсуждаем какую-то конкретную ситуацию или же надо концептуализировать? на сколько уровней?
- Эпистемический статус адресата — что он уже знает и знает ли он что мы знаем о его знании?
- Эмоциональный статус адресата — каковы сейчас его ресурсы относительно внимания, его фокус сейчас на что направлен? надо ли его фокусировать на объекты нашей коммуникации? возможно ли это сделать?
- Расположение слушать именно нас
- каков у агента контекст относительно нас в данной роли? как агент нас воспринимает?
- как агент видит себя "нашими глазами" (и далее рекурсивно)
- какова атрибуция у агента относительно нас и у нас относительно агента — как наши модели (модель нас у агента и модель агента у нас) воспринимают причинно-следственные связи?
Передавая в сообщении контекст, полезно разделять в уме этот контекст на два потока
1) Постоянная часть контекста, то, что нам надо постоянно доносить до агентов в ходе коммуникации
- роль/роли (а вместе с ними интерес-предпочтение-намерение)
- уровень компетентности в обсуждаемом домене
- (наша) способность осваивать новые компетенции
- эпистемический статус + способы мышления/рассуждения, то есть то, как мы нашего эпистемического статуса достигаем
- частый эмоциональный статус, состояние внимания
- комфортный промежуток на спектре примерно—точно
2) Ситуативно важная часть — то, что меняется при каждой коммуникации
- текущая роль (это важно, так как ролей обычно несколько)
- уровень компетентности в рассмотрении системного уровня, который обсуждается
- эпистемический статус именно по текущей коммуникации, ее объектам
- текущий эмоциональный статус, состояние внимания
- комфортный промежуток на спектре примерно—точно
В зависимости от агентов и ситуации делаем ревизию постоянной части и настраиваем ситуативную часть для каждой коммуникации.
____
#контекст #атрибуция #коммуникация #эпистемический_статус #роли
#систематика /// Агентские модели
У нас в голове есть модели агентов, с которыми мы коммуницируем; у тех агентов в головах есть модели нас; у нас есть модели друг друга.
Эти модели связно объясняют поступки, поведение агентов.
Эти модели позволяют предсказывать поведение агентов.
К агентским моделям можно применить все те же требования, что и к другим моделям объяснений:
- они должны быть опровержимы (и чем больше попыток опровержения выдержано, тем сильнее модель)
- они должны иметь малое количество допущений
- должны иметь предсказательную силу
Можно и нужно улучшать в голове модели других людей, наших объектов коммуникации.
И что менее очевидно, но не менее важно — можно и нужно улучшать модель нас в головах окружающих нас агентов.
___
#модель #коммуникация
У нас в голове есть модели агентов, с которыми мы коммуницируем; у тех агентов в головах есть модели нас; у нас есть модели друг друга.
Эти модели связно объясняют поступки, поведение агентов.
Эти модели позволяют предсказывать поведение агентов.
К агентским моделям можно применить все те же требования, что и к другим моделям объяснений:
- они должны быть опровержимы (и чем больше попыток опровержения выдержано, тем сильнее модель)
- они должны иметь малое количество допущений
- должны иметь предсказательную силу
Можно и нужно улучшать в голове модели других людей, наших объектов коммуникации.
И что менее очевидно, но не менее важно — можно и нужно улучшать модель нас в головах окружающих нас агентов.
___
#модель #коммуникация
#систематика /// Речевые импликатуры
Импликатуры в речи — намеренное нарушение одной из максим кооперации, при этом нарушении сам факт нарушения заметен и несет в себе отдельный слой коммуникации. Необходимо, чтобы агент понимал, что это импликатура, то есть нужно соблюдение "я знаю, что ты знаешь, что я знаю" в обе стороны — в нашу от агента и в сторону агента от нас.
Человек говорит слишком много или слишком мало
Пример: человек говорит очень-очень подробно, особенно выделяя детали, при этом зная, что адресат всё это знает. Коммуникация через импликатуру может быть такая "я это все повторяю, а ты и так это должен знать и знаешь, сколько уже можно объяснять??!!?!?"
Пример: на вопрос человек отвечает односложно или явно в обзем виде, без подробностей, которые запрашиваются в вопросе. Импликатура в этом случае может содержать посыл: "я знаю, что вы знаете, что я знаю больше вашего, и понимаю, что именно поэтому меня спрашиваете; но я намеренно говорю только то, что вы знаете и без меня, говорю очевидные вещи, потому что я не намерен делиться в с вами информацией; формально я вам ответил, но вы не получили ответ”.
Человек говорит явную неправду
Пример: "Да-да, разумеется, мы выполним это в лучшем виде, в срок, да ещё и украсим ленточкой!" — коммникацией же является посыл примерно такой: "то, что вы просите, невозможно, мы точно это не сделаем", но по ряду причин это не высказывается вслух. Это сродни сарказму. Сарказм — как раз пример такой импликатуры.
Человек резко и без предупреждения меняет тему
Пример: "Да-да, панама продается. Но вы заметили?! Как много посетителей в этот сезон! Знаете, тут приходила одна пара, такие панки!" — вариантов считывания такой импликатуры может быть несколько: нежелание коммункации, желание переключить тему или объект обсуждения, что-то ещё.
Человек намеренно выражается неясно
Пример: "Требования как бы есть, да. Но только не стоит их брать за основу, там еще не все участники подключились. Давайте начнем без аналитики и в текущем составе, позже доработаем. Для начала все уже сделано, по идее, надо только переделать одну часть, хотя и она работает хорошо." — здесь тоже считывается нежелание обсуждать предмет текущей коммуникации, угадывается желание отменить или перенести обсуждение;
Важно уметь считывать импликатуры, а также грамотно адресовать. Часть агентов при массовой / публичной коммуникации может не воспринять импликатуру, и если поняли не те, кому импликатура адресовалась или если не поняли те, кому адерсовалась, то коммуникация может провалиться.
___
#коммуникация #импликатура #кооперация
Импликатуры в речи — намеренное нарушение одной из максим кооперации, при этом нарушении сам факт нарушения заметен и несет в себе отдельный слой коммуникации. Необходимо, чтобы агент понимал, что это импликатура, то есть нужно соблюдение "я знаю, что ты знаешь, что я знаю" в обе стороны — в нашу от агента и в сторону агента от нас.
Человек говорит слишком много или слишком мало
Пример: человек говорит очень-очень подробно, особенно выделяя детали, при этом зная, что адресат всё это знает. Коммуникация через импликатуру может быть такая "я это все повторяю, а ты и так это должен знать и знаешь, сколько уже можно объяснять??!!?!?"
Пример: на вопрос человек отвечает односложно или явно в обзем виде, без подробностей, которые запрашиваются в вопросе. Импликатура в этом случае может содержать посыл: "я знаю, что вы знаете, что я знаю больше вашего, и понимаю, что именно поэтому меня спрашиваете; но я намеренно говорю только то, что вы знаете и без меня, говорю очевидные вещи, потому что я не намерен делиться в с вами информацией; формально я вам ответил, но вы не получили ответ”.
Человек говорит явную неправду
Пример: "Да-да, разумеется, мы выполним это в лучшем виде, в срок, да ещё и украсим ленточкой!" — коммникацией же является посыл примерно такой: "то, что вы просите, невозможно, мы точно это не сделаем", но по ряду причин это не высказывается вслух. Это сродни сарказму. Сарказм — как раз пример такой импликатуры.
Человек резко и без предупреждения меняет тему
Пример: "Да-да, панама продается. Но вы заметили?! Как много посетителей в этот сезон! Знаете, тут приходила одна пара, такие панки!" — вариантов считывания такой импликатуры может быть несколько: нежелание коммункации, желание переключить тему или объект обсуждения, что-то ещё.
Человек намеренно выражается неясно
Пример: "Требования как бы есть, да. Но только не стоит их брать за основу, там еще не все участники подключились. Давайте начнем без аналитики и в текущем составе, позже доработаем. Для начала все уже сделано, по идее, надо только переделать одну часть, хотя и она работает хорошо." — здесь тоже считывается нежелание обсуждать предмет текущей коммуникации, угадывается желание отменить или перенести обсуждение;
Важно уметь считывать импликатуры, а также грамотно адресовать. Часть агентов при массовой / публичной коммуникации может не воспринять импликатуру, и если поняли не те, кому импликатура адресовалась или если не поняли те, кому адерсовалась, то коммуникация может провалиться.
___
#коммуникация #импликатура #кооперация
#систематика /// Лестница причинности
Три уровня прослеживания причинно-следственной связи:
- Наблюдаемая связь
- Вмешательство
- Контрфактическое суждение
1) Наблюдаемая связь — когда какое-то наблюдение А говорит о Б, о том как что-то устроено.
Примеры:
Если идёт дождь (А), то земля мокрая (Б).
Если я гуляю в панаме и на улице дождь (А), то панамка мокрая (Б).
Если сотрудник устал (А), то в его работе появляются ошибки (Б).
В этих случаях, за редким ислючением, есть связь "если А, то Б".
2) Вмешательство — когда какое-то действие А оказывает эффект на Б.
Примеры:
Если я буду поливать из шланга (А), то она станет мокрая (Б).
Если я в панаме встану под душ (А), то панама будет мокрая (Б).
Если загрузить сотрудника овертаймами (А), то в его работе появятся ошибки (Б).
Здесь добавляется действие, которое является причиной: "сделать А, чтобы получить Б" или же "НЕ делать А, чтобы НЕ получить Б"
3) Контрфактическое суждение — когда мы разбираем альтернативный вариант событий: случилось бы Б, если б не произошло А?
Примеры:
Будет ли земля мокрая (Б), если я НЕ поливаю из шланга (А)? Будет ли земля мокрая если не идет дождь?
Будет ли панама мокрая (Б), если я НЕ гулял под дождем (А)? Будет ли панама мокрая, если я НЕ буду стоять в ней под душем?
Будут ли ошибки в работе сотрудника, если НЕ загружать его овертаймами?
В этом случае мы разбираем варинаты событий, альтернативные нашим действиям, можно сказать проверяем устойчивость связи А и Б.
Будет ли земля мокрая (Б), если я НЕ поливаю из шланга (А)? Будет ли земля мокрая если не идет дождь? — вполне может быть, проехала поливалка и земля мокрая.
Будет ли панама мокрая (Б), если я НЕ гулял под дождем (А)? Будет ли панама мокрая, если я НЕ буду стоять в ней под душем? — очень вероятно: я оставил панамку на улице и она мокрая из-за росы.
Будут ли ошибки в работе сотрудника, если НЕ загружать его овертаймами? — запросто: сотрудник может делать ошибки из-за каких-то других переживаний даже при щадящем режиме и малой загрузке.
Как применять в коммуникации:
Наблюдать, предполагать и строить модели — выявлять связи между причиной им следствием в поведениях агентов, выявлять их объекты интереса и связанные с ними результаты поведения.
Наблюдать, предполагать и строить модели с критическим (контрфактическим) анализом — выявлять неявные причины для налюдаемых следствий, строить более сильные причинно-следственные модели.
Действовать — анализировать наблюдения, чтобы понять, что можно сделать, чтобы изменить поведение агента в нужную нам сторону, спроектировать вмешательство с жидаемым результатом (помним про win-win стратегию!).
____
#коммуникация #причинно_следственная_связь #наблюдение #псс
Три уровня прослеживания причинно-следственной связи:
- Наблюдаемая связь
- Вмешательство
- Контрфактическое суждение
1) Наблюдаемая связь — когда какое-то наблюдение А говорит о Б, о том как что-то устроено.
Примеры:
Если идёт дождь (А), то земля мокрая (Б).
Если я гуляю в панаме и на улице дождь (А), то панамка мокрая (Б).
Если сотрудник устал (А), то в его работе появляются ошибки (Б).
В этих случаях, за редким ислючением, есть связь "если А, то Б".
2) Вмешательство — когда какое-то действие А оказывает эффект на Б.
Примеры:
Если я буду поливать из шланга (А), то она станет мокрая (Б).
Если я в панаме встану под душ (А), то панама будет мокрая (Б).
Если загрузить сотрудника овертаймами (А), то в его работе появятся ошибки (Б).
Здесь добавляется действие, которое является причиной: "сделать А, чтобы получить Б" или же "НЕ делать А, чтобы НЕ получить Б"
3) Контрфактическое суждение — когда мы разбираем альтернативный вариант событий: случилось бы Б, если б не произошло А?
Примеры:
Будет ли земля мокрая (Б), если я НЕ поливаю из шланга (А)? Будет ли земля мокрая если не идет дождь?
Будет ли панама мокрая (Б), если я НЕ гулял под дождем (А)? Будет ли панама мокрая, если я НЕ буду стоять в ней под душем?
Будут ли ошибки в работе сотрудника, если НЕ загружать его овертаймами?
В этом случае мы разбираем варинаты событий, альтернативные нашим действиям, можно сказать проверяем устойчивость связи А и Б.
Будет ли земля мокрая (Б), если я НЕ поливаю из шланга (А)? Будет ли земля мокрая если не идет дождь? — вполне может быть, проехала поливалка и земля мокрая.
Будет ли панама мокрая (Б), если я НЕ гулял под дождем (А)? Будет ли панама мокрая, если я НЕ буду стоять в ней под душем? — очень вероятно: я оставил панамку на улице и она мокрая из-за росы.
Будут ли ошибки в работе сотрудника, если НЕ загружать его овертаймами? — запросто: сотрудник может делать ошибки из-за каких-то других переживаний даже при щадящем режиме и малой загрузке.
Как применять в коммуникации:
Наблюдать, предполагать и строить модели — выявлять связи между причиной им следствием в поведениях агентов, выявлять их объекты интереса и связанные с ними результаты поведения.
Наблюдать, предполагать и строить модели с критическим (контрфактическим) анализом — выявлять неявные причины для налюдаемых следствий, строить более сильные причинно-следственные модели.
Действовать — анализировать наблюдения, чтобы понять, что можно сделать, чтобы изменить поведение агента в нужную нам сторону, спроектировать вмешательство с жидаемым результатом (помним про win-win стратегию!).
____
#коммуникация #причинно_следственная_связь #наблюдение #псс
#имплозия /// До-письменная коммуникация
С вами снова рубрика Имплозия по Маклюэну и сегодня про коммуникацию, но немного вбок : )
Упражнение заключается в том, чтобы представить как вы будете коммуницировать — общаться, работать, жить в семье/общине — не применяя письменность.
Надо сказать, что до книгопечатания, так оно и было, грамотность в понимании способность писать и читать написанное было элитной привилегией, книги читались на площадях вслух, и информация из этих книг разносилась устным пересказом. Мир был аудиальным.
Представьте, что вы работаете или что-то делаете совместно, и у вас НЕТ возможности записать и прочитать. Рисовать, кстати, допустимо; как и звонить по телефону.
Как вы будете действовать? Что предпремите?
Как будете запоминать и/или фиксировать полученную информацию?
Как будете ее передавать?
На чем сделаете упор?
Какие способы коммуникации выберете?
Буду рад мыслям, вопросам и комментариям в ответах на пост : )
___
#коммуникация #письменность #текст
С вами снова рубрика Имплозия по Маклюэну и сегодня про коммуникацию, но немного вбок : )
Упражнение заключается в том, чтобы представить как вы будете коммуницировать — общаться, работать, жить в семье/общине — не применяя письменность.
Надо сказать, что до книгопечатания, так оно и было, грамотность в понимании способность писать и читать написанное было элитной привилегией, книги читались на площадях вслух, и информация из этих книг разносилась устным пересказом. Мир был аудиальным.
Представьте, что вы работаете или что-то делаете совместно, и у вас НЕТ возможности записать и прочитать. Рисовать, кстати, допустимо; как и звонить по телефону.
Как вы будете действовать? Что предпремите?
Как будете запоминать и/или фиксировать полученную информацию?
Как будете ее передавать?
На чем сделаете упор?
Какие способы коммуникации выберете?
Буду рад мыслям, вопросам и комментариям в ответах на пост : )
___
#коммуникация #письменность #текст
#систематика /// Слова — синонимы и омонимы
Важно мыслить понятиями, а не терминами.
Вот демонстрация того, как слова/термины быстро меняют свое значение, начинают реферировать с другим понятиям, моделям, объектам:
Посылка — Отправление
Место — Позиция
Редактировать — Изменить
Это пары синонимов, (здесь) они обозначают одно понятие разными терминами.
Возьмем по одному из них:
Отправление
Позиция
Изменить
и сделаем омонимами:
Отправление
1) предмет для доставки — отправление с трек-номером 0987654321
2) точка во времени — отправление парома назначено на 11:11
Позиция
1) координаты на складе — переместить паллету на позицию А5-16-001;
2) элемент списка — позиция №2 в заказе отсутствовала при доставке;
3) должность — на позицию руководителя был назначен сотрудник из другой компании;
Изменить
1) внести правки — по кнопке "Изменить" переводим документ в режим редактирования;
2) отступить от традиции — изменил обычаю ездить летом в горы и поехал на карнавал.
За терминами важно следить, так как для разных ролей они означают разные вещи:
Клиенты у OZON / Wildberries / etc — это разные люди. И покупатели на сайте, и продавцы через маркетплейс являются клиентами для этих компаний.
Как следить за терминами?
- Понимать, в какой роли находится агент в коммуникации — для него "возврат" это сценарий в мобильном приложении, ожидаемая сумма денег на карте или задание для курьера?
- Принимать контекст — в каких ролях агенты? что обсуждаем? эта коммуникация суть продолжение коммуникации о чем?
- Переспрашивать и уточнять — если информация может быть воспринята неоднозначно, стоит обязательно уточнить, какое понятие стоит за указанным термином.
___
#терминология #коммуникация #контекст #роли
Важно мыслить понятиями, а не терминами.
Вот демонстрация того, как слова/термины быстро меняют свое значение, начинают реферировать с другим понятиям, моделям, объектам:
Посылка — Отправление
Место — Позиция
Редактировать — Изменить
Это пары синонимов, (здесь) они обозначают одно понятие разными терминами.
Возьмем по одному из них:
Отправление
Позиция
Изменить
и сделаем омонимами:
Отправление
1) предмет для доставки — отправление с трек-номером 0987654321
2) точка во времени — отправление парома назначено на 11:11
Позиция
1) координаты на складе — переместить паллету на позицию А5-16-001;
2) элемент списка — позиция №2 в заказе отсутствовала при доставке;
3) должность — на позицию руководителя был назначен сотрудник из другой компании;
Изменить
1) внести правки — по кнопке "Изменить" переводим документ в режим редактирования;
2) отступить от традиции — изменил обычаю ездить летом в горы и поехал на карнавал.
За терминами важно следить, так как для разных ролей они означают разные вещи:
Клиенты у OZON / Wildberries / etc — это разные люди. И покупатели на сайте, и продавцы через маркетплейс являются клиентами для этих компаний.
Как следить за терминами?
- Понимать, в какой роли находится агент в коммуникации — для него "возврат" это сценарий в мобильном приложении, ожидаемая сумма денег на карте или задание для курьера?
- Принимать контекст — в каких ролях агенты? что обсуждаем? эта коммуникация суть продолжение коммуникации о чем?
- Переспрашивать и уточнять — если информация может быть воспринята неоднозначно, стоит обязательно уточнить, какое понятие стоит за указанным термином.
___
#терминология #коммуникация #контекст #роли
#систематика /// Отношения между объектами
Помимо того, что объекты бывают разных типов, между собой объекты могут быть связаны разными отношениями.
1) Иерархии — надкласс-класс-подкласс, класс-экземпляр, часть-целое.
2) Репрезентация — как термин / слово реферирует к сущности / концепту / понятию / объекту. Слово отсылает, объект — к чему оно отсылает.
3) Язык и мета-язык — есть язык и есть договоренность / правила его использования. И между ними граница, разделяющая репрезентации: референция для одного термина будет разная для языка и мета-языка.
4) Агент и роль — агент играет роль в момент времени, а в целом играет набор ролей; у агента есть статусы (например, эпистемический), а у роли есть интерес, предпочтение в нем и намерение по воплощению этого предпочтения.
5) “Верить в" + "допускать, что" — "коммуникационное" отношение между агентом и картиной мира, содержащей объкеты; это два степени (первая сильнее) для описания отношений агента и объектов.
6) "Хотелось бы, чтобы" + "Обязательно нужно, чтобы" — "коммуникационное" отношение агентов и объкетов; две степени (вторая сильнее), применимо как для агентов, так и для ролей.
___
#иерархия #референция #мета_язык #роль #коммуникация
Помимо того, что объекты бывают разных типов, между собой объекты могут быть связаны разными отношениями.
1) Иерархии — надкласс-класс-подкласс, класс-экземпляр, часть-целое.
2) Репрезентация — как термин / слово реферирует к сущности / концепту / понятию / объекту. Слово отсылает, объект — к чему оно отсылает.
3) Язык и мета-язык — есть язык и есть договоренность / правила его использования. И между ними граница, разделяющая репрезентации: референция для одного термина будет разная для языка и мета-языка.
4) Агент и роль — агент играет роль в момент времени, а в целом играет набор ролей; у агента есть статусы (например, эпистемический), а у роли есть интерес, предпочтение в нем и намерение по воплощению этого предпочтения.
5) “Верить в" + "допускать, что" — "коммуникационное" отношение между агентом и картиной мира, содержащей объкеты; это два степени (первая сильнее) для описания отношений агента и объектов.
6) "Хотелось бы, чтобы" + "Обязательно нужно, чтобы" — "коммуникационное" отношение агентов и объкетов; две степени (вторая сильнее), применимо как для агентов, так и для ролей.
___
#иерархия #референция #мета_язык #роль #коммуникация
#дизайн /// UX-марафон 26-2 — Проектирование сложных систем
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования
#дизайн /// UX-марафон 26-3 — Проектирование сложных систем
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Хороший доклад про исследования. Практики исследования упакованы в кустарный (в хорошем смысле) фреймворк, который используется, и, судя по рассказу, приносит профит.
Системно:
⁃ Снова дается определение — какие системы считать сложными; и снова среди признаков множество сущностей и связей между ними, множество сценариев упакованы в мета-сценарий.
⁃ Далее рассказ про разные уровни в системе, на которых применяются исследования. Похоже, что речь идет именно про системные уровни. Например, сквозное исследование направлено на весь жизненный цикл сервиса, а точечные исследования целятся в конкретные стадии этого цикла. Упомянутые быстрые исследования, вероятно, нацелены еще на более мелкие части системы в декомпозиции.
⁃ Два блока целиком посвящены коммуникации — работа с внутренними заказчиками и донесение результатов это самая коммуникация и есть. Цель этой коммуникации — обсудить интересы проектных ролей и договориться о методе описания и доступности рабочих артефактов.
⁃ Кейсы сквозного и точечного исследований подтверждают фокусировку на разных уровнях: глобально вся система и zoom-in на одну из подсистем.
⁃ Третий блок про коммуникацию — на этот раз с клиентом. Подробно расписан метод описания (инструкция для респондента).
⁃ Приведены наблюдения из практики (в данном случае имею в виду деятельность исследователя), используемые для донастройки метода / фреймворка.
Доклад показывает, что исследования это в первую очередь коммуникация; направлена в разные концы — респондент и коллеги, цели коммуникации отличаются; и фреймворки позволяют более слаженно выстроить и процесс и коммуникации.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Системно:
⁃ Снова дается определение — какие системы считать сложными; и снова среди признаков множество сущностей и связей между ними, множество сценариев упакованы в мета-сценарий.
⁃ Далее рассказ про разные уровни в системе, на которых применяются исследования. Похоже, что речь идет именно про системные уровни. Например, сквозное исследование направлено на весь жизненный цикл сервиса, а точечные исследования целятся в конкретные стадии этого цикла. Упомянутые быстрые исследования, вероятно, нацелены еще на более мелкие части системы в декомпозиции.
⁃ Два блока целиком посвящены коммуникации — работа с внутренними заказчиками и донесение результатов это самая коммуникация и есть. Цель этой коммуникации — обсудить интересы проектных ролей и договориться о методе описания и доступности рабочих артефактов.
⁃ Кейсы сквозного и точечного исследований подтверждают фокусировку на разных уровнях: глобально вся система и zoom-in на одну из подсистем.
⁃ Третий блок про коммуникацию — на этот раз с клиентом. Подробно расписан метод описания (инструкция для респондента).
⁃ Приведены наблюдения из практики (в данном случае имею в виду деятельность исследователя), используемые для донастройки метода / фреймворка.
Доклад показывает, что исследования это в первую очередь коммуникация; направлена в разные концы — респондент и коллеги, цели коммуникации отличаются; и фреймворки позволяют более слаженно выстроить и процесс и коммуникации.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ