#систематика /// Воплощение и описание
Воплощение — это перетекшие функциональные единицы из описания.
Всё, что можно сделать в рамках описания, а не воплощения, надо делать именно в рамках описания.
Все работы, какие только возможно, стоит перенести из правой части V-диаграммы в левую часть. Ошибки гораздо дешевле исправлять на этапе описания.
Описание имеет:
- носитель (в случае отсутствия носителя — это незадокументированное описание, такие почти не рассматриваются)
- то, к чему оно отсылает, предмет описания — будущее воплощение
- метод описания, метамодель, способ отсылания; здесь рассматриваются такие понятия как
- контекстуальность
- полнота
- etc
Воплощение же — всегда 4D-объект. И важно не терять фокус на воплощении, не делать описание ради описания.
___
#воплощение #описание #метод_описания #метамодель
Воплощение — это перетекшие функциональные единицы из описания.
Всё, что можно сделать в рамках описания, а не воплощения, надо делать именно в рамках описания.
Все работы, какие только возможно, стоит перенести из правой части V-диаграммы в левую часть. Ошибки гораздо дешевле исправлять на этапе описания.
Описание имеет:
- носитель (в случае отсутствия носителя — это незадокументированное описание, такие почти не рассматриваются)
- то, к чему оно отсылает, предмет описания — будущее воплощение
- метод описания, метамодель, способ отсылания; здесь рассматриваются такие понятия как
- контекстуальность
- полнота
- etc
Воплощение же — всегда 4D-объект. И важно не терять фокус на воплощении, не делать описание ради описания.
___
#воплощение #описание #метод_описания #метамодель
#систематика /// Интерес и предпочтение роли
Интерес — это характиристика системы, обычно несколько ролей имеют один интерес, но часто разные предпочтения (и как следствие намерения по реализации предпочтений).
Интересы есть у проектных ролей (их играют люди)
Интерес обсуждается с помощью модели, и необходимо выбрать метод описания интереса для уторговывания.
Ряд обсуждения:
роль <> интерес <> (метод описания) <> предпочтение <> намерение
Роль — выявляем
Интерес + предпочтение в нём — определяем
Намерение — предыгудываем
Метод описания — выбираем (для договорения по интересу и предпочтениям)
Это используется для создания модели, которая позволит описать как удовлетворяется интерес роли в воплещении (в предполагаемой успешной системе).
Интересы влияют друг на друга, например, интерес надёжность влияет на интерес цена, интерес высота полёта может влиять на интерес вес.
___
#роль #интерес #предпочтение #намерение #метод_описания
Интерес — это характиристика системы, обычно несколько ролей имеют один интерес, но часто разные предпочтения (и как следствие намерения по реализации предпочтений).
Интересы есть у проектных ролей (их играют люди)
Интерес обсуждается с помощью модели, и необходимо выбрать метод описания интереса для уторговывания.
Ряд обсуждения:
роль <> интерес <> (метод описания) <> предпочтение <> намерение
Роль — выявляем
Интерес + предпочтение в нём — определяем
Намерение — предыгудываем
Метод описания — выбираем (для договорения по интересу и предпочтениям)
Это используется для создания модели, которая позволит описать как удовлетворяется интерес роли в воплещении (в предполагаемой успешной системе).
Интересы влияют друг на друга, например, интерес надёжность влияет на интерес цена, интерес высота полёта может влиять на интерес вес.
___
#роль #интерес #предпочтение #намерение #метод_описания
#систематика /// Кооперация в коммуникации - количество
Максима количества в коммуникации говорит о том, чтобы передавать достаточно информации, но не передавать лишнюю информацию. Для этого:
1) Стоить понимать / необходимо знать, какой информацией располагает агент, что он уже знает — необходимо понимать эпистемический статус агента относительно объекта коммуникации.
2) Важно понимать какой шаг умеет делать агент — то есть, насколько большими или маленькими итерациями надо обсуждать объект / интерес коммуникации, насколько подробно надо описывать обсуждаемые объекты / сущности.
Вот эти два пункта вместе составляют понятийное расстояние между агентами. В оценке понятийного расстояния часто делают ошибки. Понятийное расстояние это про агентов
3) Важно четко понимать разницу между текущим набором убеждений и желаемым — понимать чем отличается текущий эпистемический статус от желаемого.
4) Надо уметь на основании этой разницы построить коммуникацию — нарратив или при необходимости компактное объяснение. Нарратив уместен при краткосрочных коммуникациях, а объяснение при долгосрочных.
Эвристика: при первичной коммуникации (незнакомый человек / агент) лучше выстраивать коммуникацию снизу вверх, то есть от заземленных 4D-объектов вверх к абстракции. А при налаженных коммуникациях лучше сразу начинать с верхних уровней и при необходимости спускаться и заземлять.
___
#коммуникация #кооперация #метод_описания
Максима количества в коммуникации говорит о том, чтобы передавать достаточно информации, но не передавать лишнюю информацию. Для этого:
1) Стоить понимать / необходимо знать, какой информацией располагает агент, что он уже знает — необходимо понимать эпистемический статус агента относительно объекта коммуникации.
2) Важно понимать какой шаг умеет делать агент — то есть, насколько большими или маленькими итерациями надо обсуждать объект / интерес коммуникации, насколько подробно надо описывать обсуждаемые объекты / сущности.
Вот эти два пункта вместе составляют понятийное расстояние между агентами. В оценке понятийного расстояния часто делают ошибки. Понятийное расстояние это про агентов
3) Важно четко понимать разницу между текущим набором убеждений и желаемым — понимать чем отличается текущий эпистемический статус от желаемого.
4) Надо уметь на основании этой разницы построить коммуникацию — нарратив или при необходимости компактное объяснение. Нарратив уместен при краткосрочных коммуникациях, а объяснение при долгосрочных.
Эвристика: при первичной коммуникации (незнакомый человек / агент) лучше выстраивать коммуникацию снизу вверх, то есть от заземленных 4D-объектов вверх к абстракции. А при налаженных коммуникациях лучше сразу начинать с верхних уровней и при необходимости спускаться и заземлять.
___
#коммуникация #кооперация #метод_описания
#систематика /// Кооперация в коммуникации - качество
Максима качества:
1) Говорим правду.
2) Как минимум, говорим то, что в данный момент считаем правдой / истиной.
3) Если в текущем домене нет признанной (нами или смежными агентами) истины, то прямо говорим, что это не правда, а некая степень нашей уверенности в истинности излагаемых фактов. В данном случае обязательно ориентируемся на цель коммуникации. Это этический выбор!
4) Самый слабый вариант максимы качества — не говорим лжи.
___
#коммуникация #кооперация #метод_описания
Максима качества:
1) Говорим правду.
2) Как минимум, говорим то, что в данный момент считаем правдой / истиной.
3) Если в текущем домене нет признанной (нами или смежными агентами) истины, то прямо говорим, что это не правда, а некая степень нашей уверенности в истинности излагаемых фактов. В данном случае обязательно ориентируемся на цель коммуникации. Это этический выбор!
4) Самый слабый вариант максимы качества — не говорим лжи.
___
#коммуникация #кооперация #метод_описания
#систематика /// Кооперация в коммуникации - модальность
Максима модальности:
1) Помним нить беседы. Нашей с другим агентом.
2) Знаем / отслеживаем нити предыдущих коммуникаций агента, с которым коммуницируем.
3) Обосновываем смену тему / фокуса / объекта коммуникации (резких поворотов) — снижаем таким образом затраты на переключение. Если в сеансе коммуникации несколько коммуникаций (несклько тем в повестке), то важно их явно разделять, а в идеале подсвечивать связь между объектами разных коммуникаций: "мы поговорили об этом, теперь обсудим это, так как это связано с этим, важно мне потому-то, а тебе потому-то".
___
#коммуникация #кооперация #метод_описания
Максима модальности:
1) Помним нить беседы. Нашей с другим агентом.
2) Знаем / отслеживаем нити предыдущих коммуникаций агента, с которым коммуницируем.
3) Обосновываем смену тему / фокуса / объекта коммуникации (резких поворотов) — снижаем таким образом затраты на переключение. Если в сеансе коммуникации несколько коммуникаций (несклько тем в повестке), то важно их явно разделять, а в идеале подсвечивать связь между объектами разных коммуникаций: "мы поговорили об этом, теперь обсудим это, так как это связано с этим, важно мне потому-то, а тебе потому-то".
___
#коммуникация #кооперация #метод_описания
#систематика /// Кооперация в коммуникации - способ
Максима способа:
1) Используем язык агента, привычный и понятный ему, но на котором и мы можем легко общаться. Если мы не умеем общаться на языке агента, либо если агент не может или не готов воспринимать коммуникацию на нашем языке, то необходимо установить явное соответствие — публиковать интерпретатор. это может быть тезаурус, индекс, список условных обозначений, etc.
2) Убираем шум от сигнала.
___
#коммуникация #кооперация #метод_описания
Максима способа:
1) Используем язык агента, привычный и понятный ему, но на котором и мы можем легко общаться. Если мы не умеем общаться на языке агента, либо если агент не может или не готов воспринимать коммуникацию на нашем языке, то необходимо установить явное соответствие — публиковать интерпретатор. это может быть тезаурус, индекс, список условных обозначений, etc.
2) Убираем шум от сигнала.
___
#коммуникация #кооперация #метод_описания
#систематика /// Уровни целеполагания в коммуникации
Помимо основного принципа кооперации про то, что у агентов должна быть минимум одна общая цель, могут быть также различия в стоящих рядом целях или в отношениях агента к общей цели.
Что это может быть:
Текущая или позиционная цель
Текущая цель подразумевает результат коммуникации прямо сейчас, как результат текущей коммуникации, например, получить ответ на вопрос, побудить к действию.
Позиционная цель подразумевает изменение или удержание позиции агента в будущем. То есть, сейчас коммуникация не будет иметь целевого результата, но в последствии будет, и текущая коммуникация есть один из шагов к целевой позиции.
Содержание или форма коммуникации
Коммуникация о содержании ставит целью изменить / развить / улучшить картину мира агента/агентов, объяснить наблюдение или дать инструкции.
Пример 1: обсуждение с бригадиром как класть плитку при ремонте, какого цвета выбрать затирку для плитки, кто будет это всё закупать и привозить.
Пример 2: обсуждение с проектной командой какой именно софт будет отвечать за печать документов — своей разработки или закупленный на стороне.
Коммуникации об установлении языка ставит целью договориться о форме коммуникации, выбрать понятый и удобный агентам мета-язык / метод описания / интерпретатор / способ моделирования.
Пример 1: обсуждение с бригадиром как передать требования к ремонту — в виде устного описания пожеланий по телефону / в виде распечатанного дизайн-проекта / в виде 3D-модели помещения с наложенными текстурами в виде файла, доступного для просмотра на планшете.
Пример 2: обсуждение с проектной командой в каком видео описывать и согласовывать процесс — UML, BPMN, естественный язык со схемоидами в Confluence.
___
#коммуникация #цель #содержание #форма #метод_описания #описание #интерпретатор
Помимо основного принципа кооперации про то, что у агентов должна быть минимум одна общая цель, могут быть также различия в стоящих рядом целях или в отношениях агента к общей цели.
Что это может быть:
Текущая или позиционная цель
Текущая цель подразумевает результат коммуникации прямо сейчас, как результат текущей коммуникации, например, получить ответ на вопрос, побудить к действию.
Позиционная цель подразумевает изменение или удержание позиции агента в будущем. То есть, сейчас коммуникация не будет иметь целевого результата, но в последствии будет, и текущая коммуникация есть один из шагов к целевой позиции.
Содержание или форма коммуникации
Коммуникация о содержании ставит целью изменить / развить / улучшить картину мира агента/агентов, объяснить наблюдение или дать инструкции.
Пример 1: обсуждение с бригадиром как класть плитку при ремонте, какого цвета выбрать затирку для плитки, кто будет это всё закупать и привозить.
Пример 2: обсуждение с проектной командой какой именно софт будет отвечать за печать документов — своей разработки или закупленный на стороне.
Коммуникации об установлении языка ставит целью договориться о форме коммуникации, выбрать понятый и удобный агентам мета-язык / метод описания / интерпретатор / способ моделирования.
Пример 1: обсуждение с бригадиром как передать требования к ремонту — в виде устного описания пожеланий по телефону / в виде распечатанного дизайн-проекта / в виде 3D-модели помещения с наложенными текстурами в виде файла, доступного для просмотра на планшете.
Пример 2: обсуждение с проектной командой в каком видео описывать и согласовывать процесс — UML, BPMN, естественный язык со схемоидами в Confluence.
___
#коммуникация #цель #содержание #форма #метод_описания #описание #интерпретатор
#систематика /// Метод описания
Для работы с описанием, особенно с описанием для создания чего-либо (например, техническое задание), важно учитывать какие аспекты создаваемой системы будут описаны и как. Включение или не включение каких-то рассмотрений в описание — метод описания.
Метод описания — способ представления характеристик, по которым обсуждаются интересы. Можно сказать, что это язык обсуждения интересов и предпочтений в них.
Пример: мы хотим договариваться о пространстве для выставки. Меня как организатора интересует наличие естественного света в первую очередь. В этом случае в описании системы "Выставочное пространство" я обязательно буду указывать пункт "освещение" с подпунтками "ествественное", "искуственное", "динамическое" и тд. И скорее всего варианты с отметкой "отсутствует" в подпункте "естественное освещение" я рассматривать не буду.
Такие характеристики как площадь, высота потолков, стоимость аренды никуда не денутся, но важно включить пункт освещения в этот метод описания, так как это важно для меня.
___
#метод_описания #интерес #предпочтение
Для работы с описанием, особенно с описанием для создания чего-либо (например, техническое задание), важно учитывать какие аспекты создаваемой системы будут описаны и как. Включение или не включение каких-то рассмотрений в описание — метод описания.
Метод описания — способ представления характеристик, по которым обсуждаются интересы. Можно сказать, что это язык обсуждения интересов и предпочтений в них.
Пример: мы хотим договариваться о пространстве для выставки. Меня как организатора интересует наличие естественного света в первую очередь. В этом случае в описании системы "Выставочное пространство" я обязательно буду указывать пункт "освещение" с подпунтками "ествественное", "искуственное", "динамическое" и тд. И скорее всего варианты с отметкой "отсутствует" в подпункте "естественное освещение" я рассматривать не буду.
Такие характеристики как площадь, высота потолков, стоимость аренды никуда не денутся, но важно включить пункт освещения в этот метод описания, так как это важно для меня.
___
#метод_описания #интерес #предпочтение
#систематика /// Описание и его интерпретатор
Интерпретатор = описание описания. То есть метамодель. Язык, описывающий язык описания, мета-язык.
При работе с описанием важно различать само описание и его интерпретатор.
Если описание принять за язык объектного уровня (то есть описание рассказывает про рассматриваемые объекты), например, это будет естественный язык, то при попытке этим же языком описать понятия из интерпретатора будут возникать парадоксы. Чтобы этого избежать, стоит разделять термины, применяемые в описании и в интерпретаторе, и использовать для описания и интерпретатора разные наборы слов/терминов.
Пример на уровне кавычек во фразе: «я верю, что высказывание «снег белый» верно в том случае если снег белый» — внутренние кавычки есть описание / модель / язык объектного уровня, а внешние кавычки есть интерпретатор / метамодель / метаязык. Так как внутри и снаружи внутренних кавычек есть "снег белый", то это сообщение ничего не объясняет из-за описанного парадокса.
Часто интерпретатор не даётся потребителю описания в явном виде. Например, в устной речи так случается почти всегда: интерпретатора явно нет. В таких случаях потребитель интерпретирует, опираясь на:
- опыт верных / полезных / успешных интерпретаций подобных описаний / выражений
- контекст и исторчник получения описания
Чаще всего, когда интерпретатор не задан явно, потребитель не осознает выбор и/или распознавание интерпретатора, это происходит фоном.
Этим можно пользоваться при шифровании, когда потребитель даже не подозревает, что у выражения есть интерпретатор, позволяющий получить целевое прочтение выражения / описания.
Также интерпретатор может быть дан явно и намеренно ложно, чтобы не допустить нежелательного прочтения выражения (допустить только желательное прочтение тем потребителем, кто имеет также верный / целевой вариант интерпретатора).
Если же интерпретатор дан явно (и не является ложным), то всё просто — интерпретируем согласно интерпретатору. Например, читаем схему, поглядывая в условные обозначения, или смотрим инфографику, сверяясь с легендой.
При выборе позиции "верить или не верить" описанию (часто этот выбор не осознанный) этот вопрос веры применим как к самому описанию, так и к интерпретатору, который также является описанием. То есть, при оценке достоверности рассматривается вся мегамодель. Это рассмотрение мегамодели — для принятия решения верить описанию или нет — основано на:
- контекст потребления описания;
- прагматическая цель коммуникации, то есть не только в соответствии с роль агента-интерес-предпочтение-намерение, но и цель текущей коммуникации агента (цель часто тоже выводится из контекста: опыта прежней коммуникации с агентом);
- эпистемический статус агентов, о нём подробнее завтра.
___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
Интерпретатор = описание описания. То есть метамодель. Язык, описывающий язык описания, мета-язык.
При работе с описанием важно различать само описание и его интерпретатор.
Если описание принять за язык объектного уровня (то есть описание рассказывает про рассматриваемые объекты), например, это будет естественный язык, то при попытке этим же языком описать понятия из интерпретатора будут возникать парадоксы. Чтобы этого избежать, стоит разделять термины, применяемые в описании и в интерпретаторе, и использовать для описания и интерпретатора разные наборы слов/терминов.
Пример на уровне кавычек во фразе: «я верю, что высказывание «снег белый» верно в том случае если снег белый» — внутренние кавычки есть описание / модель / язык объектного уровня, а внешние кавычки есть интерпретатор / метамодель / метаязык. Так как внутри и снаружи внутренних кавычек есть "снег белый", то это сообщение ничего не объясняет из-за описанного парадокса.
Часто интерпретатор не даётся потребителю описания в явном виде. Например, в устной речи так случается почти всегда: интерпретатора явно нет. В таких случаях потребитель интерпретирует, опираясь на:
- опыт верных / полезных / успешных интерпретаций подобных описаний / выражений
- контекст и исторчник получения описания
Чаще всего, когда интерпретатор не задан явно, потребитель не осознает выбор и/или распознавание интерпретатора, это происходит фоном.
Этим можно пользоваться при шифровании, когда потребитель даже не подозревает, что у выражения есть интерпретатор, позволяющий получить целевое прочтение выражения / описания.
Также интерпретатор может быть дан явно и намеренно ложно, чтобы не допустить нежелательного прочтения выражения (допустить только желательное прочтение тем потребителем, кто имеет также верный / целевой вариант интерпретатора).
Если же интерпретатор дан явно (и не является ложным), то всё просто — интерпретируем согласно интерпретатору. Например, читаем схему, поглядывая в условные обозначения, или смотрим инфографику, сверяясь с легендой.
При выборе позиции "верить или не верить" описанию (часто этот выбор не осознанный) этот вопрос веры применим как к самому описанию, так и к интерпретатору, который также является описанием. То есть, при оценке достоверности рассматривается вся мегамодель. Это рассмотрение мегамодели — для принятия решения верить описанию или нет — основано на:
- контекст потребления описания;
- прагматическая цель коммуникации, то есть не только в соответствии с роль агента-интерес-предпочтение-намерение, но и цель текущей коммуникации агента (цель часто тоже выводится из контекста: опыта прежней коммуникации с агентом);
- эпистемический статус агентов, о нём подробнее завтра.
___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
#систематика /// Эпистемический статус агента
Если взять высказывание / описание какой-то части мира, то у вас будет мнение относительно этого высказывания, допустим, вы согласны с описанием и считаете, что часть мира именно такая как описано, а пусть и с сомнениями, если описание выражено множеством высказываний и с частью из них вы не согласны. Это эпистемический статус высказывания на вашей стороне (в вашей голове).
У других агентов (часто это люди) может быть другое мнение о том же высказывании. И вот набор мнений относительно высказывания на стороне агента есть эпистемический статус агента.
Пример: вы считаете, что "Архаров бегает хорошо" и при этом думаете, что ваш коллега Барханов считает про Архарова так же. Поговорив с Бархановым про бег Архарова, вы меняете ваше представление о том, как считает Барханов относительно бега Архарова. При этом сами вы можете и не менять своё мнение о беге Архарова.
То есть:
любая коммуникация, любой акт обмена информацией, меняет представление об эпистемическом статусе агента.
В примере:
Барханов — агент
ваше знание о том, каково мнение Барханова о беге Архарова — эпистемический статус агента.
Отстутствие информации при коммуникации тоже меняет представление об эпистемическим статусе агента (на вопрос "Как тебе бег Архарова?" Барханов молчит).
Язык многоуровневый — описания и их интерпетаторы при этом рекурсивны в обе стороны.
Множество агентов в мире, каждый агент имеет представление о представлениях других агентов. Это представление о представлениях агентов изменяется в ходе коммуникации, когда агенты отдают и получают информацию. И эту информацию можно интерпретировать на разных уровнях — на уровне описания / объектном уровне языка или на уровне интерпретатора / мета-языка.
___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
Если взять высказывание / описание какой-то части мира, то у вас будет мнение относительно этого высказывания, допустим, вы согласны с описанием и считаете, что часть мира именно такая как описано, а пусть и с сомнениями, если описание выражено множеством высказываний и с частью из них вы не согласны. Это эпистемический статус высказывания на вашей стороне (в вашей голове).
У других агентов (часто это люди) может быть другое мнение о том же высказывании. И вот набор мнений относительно высказывания на стороне агента есть эпистемический статус агента.
Пример: вы считаете, что "Архаров бегает хорошо" и при этом думаете, что ваш коллега Барханов считает про Архарова так же. Поговорив с Бархановым про бег Архарова, вы меняете ваше представление о том, как считает Барханов относительно бега Архарова. При этом сами вы можете и не менять своё мнение о беге Архарова.
То есть:
любая коммуникация, любой акт обмена информацией, меняет представление об эпистемическом статусе агента.
В примере:
Барханов — агент
ваше знание о том, каково мнение Барханова о беге Архарова — эпистемический статус агента.
Отстутствие информации при коммуникации тоже меняет представление об эпистемическим статусе агента (на вопрос "Как тебе бег Архарова?" Барханов молчит).
Язык многоуровневый — описания и их интерпетаторы при этом рекурсивны в обе стороны.
Множество агентов в мире, каждый агент имеет представление о представлениях других агентов. Это представление о представлениях агентов изменяется в ходе коммуникации, когда агенты отдают и получают информацию. И эту информацию можно интерпретировать на разных уровнях — на уровне описания / объектном уровне языка или на уровне интерпретатора / мета-языка.
___
#интерпретатор #описание #метод_описания #метамодель #мегамодель #эпистемический_статус #мета_язык
#дизайн /// 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 #мероприятия #метод_описания #коммуникация #ЖЦ