#систематика /// Часть-целое, разбиение, эмерджентность
Основа системного разбиения — отношение часть-целое.
Это отношение в СМ рассматривается только на физическом уровне:
Правильно: собака есть часть популяции собак
Неправильно: собака есть часть семейства псовых
Как проверить является ли что-то часть целого: если без этого претендента на часть целое физически продолжит существовать, то это НЕ часть, а что-то другое (класс, тип, етс).
При этом частью может являться "отверстие" — тоннель (он суть отсутствие материи, но у его него есть материальные части, например, облицовка), антракт (запланированный отрезок времени, когда воплощение системы не эксплуатируется, но этим самым эксплуатируется).
Важно начинать с поиска целого, рассматривать нашу систему с позиции "часть чего она является?"
Системные уровни выделяются вниманием! Физически они могут быть никак не разделены.
Их выделение обязательно для рассмотрения и обсуждения.
Переход между уровнями меняет эмерджентность: если на уровне N создают эмерджентность, то на уровне N+1 ею пользуются, а на уровне N-1 про эту неё вообще не думают, там другая система со своей эмерджентностью, которая будет использоваться на уровне N.
Переход между системными уровнями (мета-системный переход) переключает не только внимание на уровне и его системном свойстве (эмерджентности), но переключает также задействование ролей, компетенций, интересов, etc.
___
#часть_целое #эмерджентность #системное_разбиение
Основа системного разбиения — отношение часть-целое.
Это отношение в СМ рассматривается только на физическом уровне:
Правильно: собака есть часть популяции собак
Неправильно: собака есть часть семейства псовых
Как проверить является ли что-то часть целого: если без этого претендента на часть целое физически продолжит существовать, то это НЕ часть, а что-то другое (класс, тип, етс).
При этом частью может являться "отверстие" — тоннель (он суть отсутствие материи, но у его него есть материальные части, например, облицовка), антракт (запланированный отрезок времени, когда воплощение системы не эксплуатируется, но этим самым эксплуатируется).
Важно начинать с поиска целого, рассматривать нашу систему с позиции "часть чего она является?"
Системные уровни выделяются вниманием! Физически они могут быть никак не разделены.
Их выделение обязательно для рассмотрения и обсуждения.
Переход между уровнями меняет эмерджентность: если на уровне N создают эмерджентность, то на уровне N+1 ею пользуются, а на уровне N-1 про эту неё вообще не думают, там другая система со своей эмерджентностью, которая будет использоваться на уровне N.
Переход между системными уровнями (мета-системный переход) переключает не только внимание на уровне и его системном свойстве (эмерджентности), но переключает также задействование ролей, компетенций, интересов, etc.
___
#часть_целое #эмерджентность #системное_разбиение
#систематика /// Управление вниманием
Управление вниманием делается за счёт системного разбиения и дает пособность:
- рассматривать в нужный момент времени нужный уровень системного разбиения — фокусироваться на необходимом системном уровне, помнить, что мы выделяем его лишь вниманием, понимать, что другие агенты могут прыгать по уровням, и нам надо отслеживать эти прыжки, и в идеале возвращать обсуждение / коммуникацию на нужный уровень.
- выделять фигуру из фона — видеть те объекты, к которым у нас интерес и предпочтение на рассматриваемом системном уровне.
- играть подходящую в данный момент роль — занимать позицию "я проявляю интерес к объектам на этом системном уровне как ..."
- выявлять роли при обсуждении проекта / системы — понимать с позиций каких ролей общаются другие агенты при обсуждении объектов, следить, чтобы основные интересы этих ролей относились к объектам на рассматриваемом системном уровне.
___
#внимание #часть_целое #целевая #системное_разбиение #роли #интерес #предпочтение
Управление вниманием делается за счёт системного разбиения и дает пособность:
- рассматривать в нужный момент времени нужный уровень системного разбиения — фокусироваться на необходимом системном уровне, помнить, что мы выделяем его лишь вниманием, понимать, что другие агенты могут прыгать по уровням, и нам надо отслеживать эти прыжки, и в идеале возвращать обсуждение / коммуникацию на нужный уровень.
- выделять фигуру из фона — видеть те объекты, к которым у нас интерес и предпочтение на рассматриваемом системном уровне.
- играть подходящую в данный момент роль — занимать позицию "я проявляю интерес к объектам на этом системном уровне как ..."
- выявлять роли при обсуждении проекта / системы — понимать с позиций каких ролей общаются другие агенты при обсуждении объектов, следить, чтобы основные интересы этих ролей относились к объектам на рассматриваемом системном уровне.
___
#внимание #часть_целое #целевая #системное_разбиение #роли #интерес #предпочтение
#систематика /// Описание и требования к нему
К описанию бывают требования двух видов
- Требования к формату описания
- содержанию — запрос на описание части физического мира, ограниченного чем-то
- языку — как выделяются объекты из фона и какими словами обозначаются
- нотации
- Требования к цели — запрос на описание, чтобы агент А по описанию сделал действие N
в этом случае надо догадываться:
- сколько на самом деле нужно описаний, так как "чтобы агент А сделал действие N" может наступить только при участии других агентов, для которых тоже потребуется описание.
- на каком языке и нотации требуется описание
- что должно являться содержанием описания, то есть к какой части мира описание реферирует
Эти виды требований могут и комбинироваться, а также скорее всего каждый из нас тяготеет к одному из видов как более комфортным и понятным или привычным требованиям.
Важно уметь выявлять одно из другого — на основе запроса по формату надо уметь выявить или предположить цель применения этого описания, а на основе запрос по цели надо уметь выявить требования по формату: содержание-язык-нотация.
Часто требования к описанию на бытовом уровне выдвигаются только как требования к содержанию.
И тогда надо догадаться:
- на каком языке описывать? — язык уже где-то закреплен или его надо выявить / снять с речи и применить?
- насколько детально описывать — насколько мелкий самый мелкий наш объект внимания в этом описнаии? Это системные уровни в системном разбиении часть-целое — здесь речь про масштаб рассмотрения, позиция в спектер zoom in - zoom out рассмотрения.
- насколько конкретно описывать — вот тут надо предполагать, что получаетнль описания будет с описанием делать — выявлять общие законы или рассматривать конкретную описываемую часть мира; это про выбор предмета описания — класс или экземпляр.
Раз к описанию есть требования, то есть и потребности, из которых эти требования проистекают, а значит у описания обязательно должна быть цель — соответствующая цели того, кто запрашивает описание. Запрашиваемое описание — это про предпочтение в интересе той роли, которая запрашивает это описание.
___
#описание #часть_целое #системное_разбиение #требования #нотация #роли #интерес
К описанию бывают требования двух видов
- Требования к формату описания
- содержанию — запрос на описание части физического мира, ограниченного чем-то
- языку — как выделяются объекты из фона и какими словами обозначаются
- нотации
- Требования к цели — запрос на описание, чтобы агент А по описанию сделал действие N
в этом случае надо догадываться:
- сколько на самом деле нужно описаний, так как "чтобы агент А сделал действие N" может наступить только при участии других агентов, для которых тоже потребуется описание.
- на каком языке и нотации требуется описание
- что должно являться содержанием описания, то есть к какой части мира описание реферирует
Эти виды требований могут и комбинироваться, а также скорее всего каждый из нас тяготеет к одному из видов как более комфортным и понятным или привычным требованиям.
Важно уметь выявлять одно из другого — на основе запроса по формату надо уметь выявить или предположить цель применения этого описания, а на основе запрос по цели надо уметь выявить требования по формату: содержание-язык-нотация.
Часто требования к описанию на бытовом уровне выдвигаются только как требования к содержанию.
И тогда надо догадаться:
- на каком языке описывать? — язык уже где-то закреплен или его надо выявить / снять с речи и применить?
- насколько детально описывать — насколько мелкий самый мелкий наш объект внимания в этом описнаии? Это системные уровни в системном разбиении часть-целое — здесь речь про масштаб рассмотрения, позиция в спектер zoom in - zoom out рассмотрения.
- насколько конкретно описывать — вот тут надо предполагать, что получаетнль описания будет с описанием делать — выявлять общие законы или рассматривать конкретную описываемую часть мира; это про выбор предмета описания — класс или экземпляр.
Раз к описанию есть требования, то есть и потребности, из которых эти требования проистекают, а значит у описания обязательно должна быть цель — соответствующая цели того, кто запрашивает описание. Запрашиваемое описание — это про предпочтение в интересе той роли, которая запрашивает это описание.
___
#описание #часть_целое #системное_разбиение #требования #нотация #роли #интерес
#дизайн /// Требования в UI-задачах
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.