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