#систематика /// Системы: целевая, наша, надсистема, подсистема, в окружении
Целевая система (ЦС) — это продукт, наиболее привязанный к физическому миру.
В случае Почты это физически доставленное отправление.
Целевая система выявляется для определения коллективной цели!
Наша система (НС) — та, с которой мы работаем и на которую непосредственно влияем. В случае разработки софта чаще всего это какая-то система в цепочке обеспечения ЦС.
Над- и под- системы — соответственно на уровень выше и ниже в "матрёшке" системного разбиения, и тут ВАЖНО: разбиение делается только вниманием и только по признаку часть-целое.
Системы в окружении — системы, не являющиеся над- и под- системами, но которые влияют на ЦС или зависят от ЦС. Ближнее окружение это смежные системы в составе надсистемы (для ЦС). Дальнее окружение – за пределами надсистемы ЦС.
___
#часть_целое #целевая #нашасистема #надсистема #подсистема #система_в_окружении
Целевая система (ЦС) — это продукт, наиболее привязанный к физическому миру.
В случае Почты это физически доставленное отправление.
Целевая система выявляется для определения коллективной цели!
Наша система (НС) — та, с которой мы работаем и на которую непосредственно влияем. В случае разработки софта чаще всего это какая-то система в цепочке обеспечения ЦС.
Над- и под- системы — соответственно на уровень выше и ниже в "матрёшке" системного разбиения, и тут ВАЖНО: разбиение делается только вниманием и только по признаку часть-целое.
Системы в окружении — системы, не являющиеся над- и под- системами, но которые влияют на ЦС или зависят от ЦС. Ближнее окружение это смежные системы в составе надсистемы (для ЦС). Дальнее окружение – за пределами надсистемы ЦС.
___
#часть_целое #целевая #нашасистема #надсистема #подсистема #система_в_окружении
#систематика /// Управление вниманием
Управление вниманием делается за счёт системного разбиения и дает пособность:
- рассматривать в нужный момент времени нужный уровень системного разбиения — фокусироваться на необходимом системном уровне, помнить, что мы выделяем его лишь вниманием, понимать, что другие агенты могут прыгать по уровням, и нам надо отслеживать эти прыжки, и в идеале возвращать обсуждение / коммуникацию на нужный уровень.
- выделять фигуру из фона — видеть те объекты, к которым у нас интерес и предпочтение на рассматриваемом системном уровне.
- играть подходящую в данный момент роль — занимать позицию "я проявляю интерес к объектам на этом системном уровне как ..."
- выявлять роли при обсуждении проекта / системы — понимать с позиций каких ролей общаются другие агенты при обсуждении объектов, следить, чтобы основные интересы этих ролей относились к объектам на рассматриваемом системном уровне.
___
#внимание #часть_целое #целевая #системное_разбиение #роли #интерес #предпочтение
Управление вниманием делается за счёт системного разбиения и дает пособность:
- рассматривать в нужный момент времени нужный уровень системного разбиения — фокусироваться на необходимом системном уровне, помнить, что мы выделяем его лишь вниманием, понимать, что другие агенты могут прыгать по уровням, и нам надо отслеживать эти прыжки, и в идеале возвращать обсуждение / коммуникацию на нужный уровень.
- выделять фигуру из фона — видеть те объекты, к которым у нас интерес и предпочтение на рассматриваемом системном уровне.
- играть подходящую в данный момент роль — занимать позицию "я проявляю интерес к объектам на этом системном уровне как ..."
- выявлять роли при обсуждении проекта / системы — понимать с позиций каких ролей общаются другие агенты при обсуждении объектов, следить, чтобы основные интересы этих ролей относились к объектам на рассматриваемом системном уровне.
___
#внимание #часть_целое #целевая #системное_разбиение #роли #интерес #предпочтение
#систематика /// Исправление ошибки в статье про разбор
Наконец-то я опубликовал исправление в моей статье на Хабре.
Я ошибочно полагал, что созданное и доставляемое отправление уже эксплуатируется, но это не так. Эксплуатация начинается только в момент вручения отправления, потому что только тогда отправление может считаться успешно доставленным.
В статье обновлены рисунки и описания, касающиеся стадии эксплуатации в жизненном цикле целевой системы.
Напомню, что целевой системой я считаю успешно доставленное и врученное клиенту отправление. То есть, стадией эксплуатации является отрезок времени от момента вручения клиенту (целевая система — посылка в целости и сохранности — "изготовлена" Почтой, передана клиенту, "эксплуатируется") и до момента снятия упаковки (отправления как целевой системы уже нет, выведено из эксплуатации).
Это яркий пример контринтуитивности; кажется, что мы эксплуатируем ЦС пока изготавливаем ее, но по факту эксплуатирует ее только клиент и только после успешного воплощения на всех отрезках ЖЦ в стадии изготовления.
___
#эксплуатация #целевая #ЖЦ
Наконец-то я опубликовал исправление в моей статье на Хабре.
Я ошибочно полагал, что созданное и доставляемое отправление уже эксплуатируется, но это не так. Эксплуатация начинается только в момент вручения отправления, потому что только тогда отправление может считаться успешно доставленным.
В статье обновлены рисунки и описания, касающиеся стадии эксплуатации в жизненном цикле целевой системы.
Напомню, что целевой системой я считаю успешно доставленное и врученное клиенту отправление. То есть, стадией эксплуатации является отрезок времени от момента вручения клиенту (целевая система — посылка в целости и сохранности — "изготовлена" Почтой, передана клиенту, "эксплуатируется") и до момента снятия упаковки (отправления как целевой системы уже нет, выведено из эксплуатации).
Это яркий пример контринтуитивности; кажется, что мы эксплуатируем ЦС пока изготавливаем ее, но по факту эксплуатирует ее только клиент и только после успешного воплощения на всех отрезках ЖЦ в стадии изготовления.
___
#эксплуатация #целевая #ЖЦ
#систематика /// Дополнение к исправлению ошибки в статье
Обновление (2) в моей статье на Хабре.
Коллега Антон @zGrav правильно подсказал, что в рассмотрении нет кейса проверки со вскрытием упаковки. Это действительно так, такой кейс не рассматривался. В разделе "2. Поиск целевой системы" добавлено упоминание этого кейса.
Состояния целевой системы по стадиям жизненного цикла в итоге можно описать так::
1) замыслено: отправление как идея;
2) разрабатывается: отправление собрано—упаковано—принято—доставляется—сортируется—доставлено—готово к вручению;
3) эксплуатируется: вручено клиенту в целости и сохранности, от клиента получено подтверждение успешной доставки (например, вскрытие упаковки клиентом для проверки, если это предусмотрено бизнес-кейсом);
4) выведено из эксплуатации: распаковано клиентом*, архивировано на уровне предприятия.
* В бизнес-кейсе проверка вложения со вскрытием упаковки распаковка будет находиться в стадии эксплуатации.
___
#эксплуатация #целевая #ЖЦ
Обновление (2) в моей статье на Хабре.
Коллега Антон @zGrav правильно подсказал, что в рассмотрении нет кейса проверки со вскрытием упаковки. Это действительно так, такой кейс не рассматривался. В разделе "2. Поиск целевой системы" добавлено упоминание этого кейса.
Состояния целевой системы по стадиям жизненного цикла в итоге можно описать так::
1) замыслено: отправление как идея;
2) разрабатывается: отправление собрано—упаковано—принято—доставляется—сортируется—доставлено—готово к вручению;
3) эксплуатируется: вручено клиенту в целости и сохранности, от клиента получено подтверждение успешной доставки (например, вскрытие упаковки клиентом для проверки, если это предусмотрено бизнес-кейсом);
4) выведено из эксплуатации: распаковано клиентом*, архивировано на уровне предприятия.
* В бизнес-кейсе проверка вложения со вскрытием упаковки распаковка будет находиться в стадии эксплуатации.
___
#эксплуатация #целевая #ЖЦ
#дизайн /// Требования в 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 сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.