Музыка
— Дебютировал как композитор, написав пять треков для детского спектакля студии «Всёцензурно» — https://vk.com/wall-172549389_16
— Запись альбома лирики «Романа». Подготовил за этот год трэки «Халий-йа», «Сага о счастье», «Мне снилось», «Лира прочь», «Не твоя красавица».
— Написал несколько треков в стиле похожем на минимал хаус, хочу опубликовать как руки дойдут.
— Выпустил видеоряд к «Лира прочь» — https://youtu.be/OL6afkTeTwA?si=FEGJRaHLE-UambVJ
— Поднаторел в аккомпонировании на фортепиано

Завершая писать основной текст книги о методе карты процесса-опыта (моя авторская версия CJM, с которой мы в бою уже 8 лет), решил описать этой картой то как её же строить. Встречайте карту процесса-опыта составления карты процесса-опыта.

Так как процесс итеративный, то в основе карты петля. Но куда важнее взаимодействия. Здесь их немного, но есть точки контакта с задачедателем, исследователем, аналитиком.

Хочу познакомить вас с моими коллегами, занимающимися разработкой методик стратегического планирования и проектирования микросервисной ИТ-архитектуры. Если вам интересны эти части практики, посмотрите и на их материалы.

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

Соучредители нашей компании подвели творческие итоги за 2023 год, где перечислили все конференции, статьи, интервью и мастер-классы, в которые они вкладывали силы в течение года:
1. Александр Бындю https://blog.byndyu.ru/2024/01/2023.html
2. Андрей Шапиро https://vk.com/@117105-sdelano-v-2023
3. Руслан Сафин https://vk.com/@3061206-tvorcheskie-itogi-2023

Наша компания является одной из сильнейших фабрик мысли в России в плане IT-практик и аналитических инструментов для создания продуктов. И есть ощущение, что мы только начали набирать обороты.

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

Закончил писать черновик книги «Карта процесса-опыта. Проектирование механизма услуги». Две главы книги доступны в виде статьи, которой хочу поделиться с вами. Я обновил её по последнему содержанию книги, если вы ее смотрели раньше.

Если вам приходится собирать требования о процессе или моделировать его, если вам не хватало чего-то в CJM, Service Blueprint или BPMN, например, простоты, скорости составления схем или учёта человеческого взаимодействия. Во всех эти случаях книга и статья вам будут полезны.

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

http://ashapiro.ru/articles/xpm

Завёл базу знаний по карте процесса-опыта на Гитхаб. Буду пополнять шаблонами, примерами и типичными ситуациями в картах. Уже размещены четыре примера и шаблоны для 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