Завёл базу знаний по карте процесса-опыта на Гитхаб. Буду пополнять шаблонами, примерами и типичными ситуациями в картах. Уже размещены четыре примера и шаблоны для Miro и Excalidraw — последний на скриншоте.

https://github.com/Byndyusoft/xp-mapping

Шаблон карты процесса-опыта теперь доступен в Miroverse. Наконец-то он редактируем. Чуть позже добавлю мультидорожечный вариант.

https://miro.com/miroverse/experience-process-mapping-xpm-template/

Собрал накопившиеся размышления о методе карты гипотез Александра Бындю. В этой статье есть моя интерпретация понимания метода и несколько мыслей: о том какое место она занимает, что в ней важно, почему у многих «получается» и без неё, какие трудности встречаются при обучении её использованию.

https://ashapiro.ru/writing/tpost/uo2xglkyg1

Приступил к сравнению схем разных методов схематизации процесса на одном материале. Взял в качестве примера доставку пиццы. Этот пример в формате коллаборации рассматривает группа OMG в спецификации BPMN by Example.

На мой дизайнерский взгляд карта процесса-опыта выглядит аккуратнее, яснее и милее. В подробностях к ключевым точкам указано только то, что было в изначальной схеме.

Планирую также сравнить с вариантом BPMN хореографий, Event Storming, UML Sequence Diagram.

Итерации, гипотезы и адаптивность при разработке государственных ИС

Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.

Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:

1. Системная инженерия последнее десятилетие эволюционирует в сторону всё более высокой адаптивности и стремительности внедрения изменений: «требования» всё больше заменяются «гипотезами», описания проектируемых функций меняют модус от «система должна категорически и бесповоротно во веки вечные» в сторону «предполагается, что данная функция системы будет наиболее оптимальна для потребностей пользователей, а если нет, то по ходу дела мы ее улучшим».

2. Государственный процесс цифровизации – косный и неповоротливый в силу длительности согласований, выделения бюджета, карательной политики относительно неточности реализации проектируемых систем. А также потому что чиновники делают системы не на свои деньги, не для себя и ничем, как правило, не рискуют.

Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):

«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:

1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.

2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».

Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.

Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.

Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ

#егов #менеджмент #мцриап #минцифры

Вместе с небольшой группой исследователей собрали первый подход к структурному языку интерфейса пользователя.

Элементы интерфейса пользователя — это тоже отдельный язык. Но речь идёт не о нём, а об языке, который структурно пробует зацепить ситуацию проектирования интерфейса. То есть должен описывать, что нужно сделать.

Пример формулы в этом языке для задачи из книги Раскина:

~значение −> ~температураС, ~температураF

Полюбопытствуйте. Вот первое описание:

https://github.com/UIRC/ui-language

Вам интересно было бы послушать доклад или прочесть статью на тему, описанную ниже? Интригует ли? Понятно ли о чем речь? Лайкните, пожалуйста, или поставьте задумчивое лицо в знак одобрения или непонимания.

.

Язык интерфейсных ситуаций

Дизайнер сегодня — чёрный ящик проектирования, который нужно запустить, чтобы стало понятно, что именно и как предстоит разрабатывать. Разработчик не может оценить объём разработки по описанию пользовательской истории, потому что реализации могут разительно отличаться. Как дизайнеру и разработчику обретать видение о конечном решении ещё до того как дизайнер сядет за Фигму?

Предлагается структурный язык интерфейсных ситуаций, с одной стороны строгий и похожий на математические или химические формулы, с другой дающий власть гибко варьировать решения и обсуждать их сильно раньше первых эскизов.

Слушатели/читатели получат новый инструмент дизайн-мышления, помогающий решать интерфейсные задачи не интуитивно, по творческому наитию, а системно.

Спешу поделиться описанием нового подхода к проектированию. Это схема варьирования данных в точках их преобразований в системах с интерфейсами. С этой штукой мы уже спроектировали как минимум одну систему, ситуация в ней и потребовала особой схемы.

Мне всегда хотелось прикрутить к User Flow структуру потоков данных. Представленная статья — первый и, на мой взгляд, удачный подход к снаряду.

Рекомендую к ознакомлению тем, кто занимается проектированием и разработкой интерфейсов пользователя: дизайнерам, аналитикам, разработчикам фронта и бэка и, конечно, инженерам качества.

https://ashapiro.ru/articles/data-chain-scheme

С подачи Дениса Бескова добавил в текст книги про Карту процесса-опыта схему с универсальными верхнеуровневыми точками любой услуги. Какие ещё ключевые точки вы бы добавили?

Собрал вместе изображения функциональных ролей карт процесса-опыта разных лет. Работаем над унификацией дизайна карты и изображений агентов.

Забавно, что наибольше разнообразие получили искусственные агенты, то есть не люди.

Выделились три подхода. Характерные лица, конечно, цепляют сильнее, но для целей более широкой применимости проще использовать образы изображения с функциональными элементами. Человек с гарнитурой — поддержка, с галстуком — менеджер, с бабочкой — владелец, с микрофоном — ведущий.

22 марта проведу воркшоп по карте процесса-опыта на конференции AgileDays, в очном формате в ЦМТ, г. Москва. Приходите попробовать практику на материале своего проекта, если будете на конференции.

https://agiledays.ru/?speaker=5074

У Артёма Дапа в книге «Русский путь бизнеса и дизайнаß» есть понятие трёх уровней частот в детализации: низкие, средние, высокие. Он рассматривает их на примере выставочных стендов. Издалека стенд конкурирует с другими стендами выставки своими самыми грубыми формами. На среднем уровне мы видим объекты графдизайна, пром- и информационного дизайна, названия, вывески, медиа. На высоких частотах мы трогаем их, всматриваемся в качества бумаги и типографики, насколько с любовью сделано.

Считывание смыслов в интерфейсе не может идти на высокочастотной составляющей.