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

Методика карты процесс—опыт схематизирует процесс-механизм и опыт взамодействия в самых конкретных деталях. Метод помогает вдумчиво проектировать услуги и человеко-машинные системы.

Методика дерева гипотез развития помогает планировать развитие продукта на основе поддержания причинно-следственного дерева из гипотез. Каждая гипотеза вносит вклад в общий поток ствола дерева. Совместное рассмотрение гипотез во взаимосвязи их вклада помогает более взвешено принимать решения.

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

Без саморефлексии невозможно двигаться самостоятельно. Особенно в решении проблем. Будешь вязнуть или сбиваться с пути. Эти вопросы как способность Мюнхаузена вытащить себя из болота, схватившись за макушку.

···

— Что со мной сейчас происходит? Что я ощущаю и чувствую? В чём я присутствую?
— Что я в действительности делаю тем, что делаю?
— Что у меня получилось сделать? Мне повезло или это результат осмысленных действий? Что из этого можно будет переиспользовать в будущем? Как зафиксировать полученный опыт и знания?
— Что у меня не получается? Почему? Кто или что мне может помочь ответить на эти два вопроса?
— Куда я теперь направляюсь? Что важно на этом пути?

Подвёл итоги творческого года. Если вы что-то пропустили, можно посмотреть сейчас.

~

Самообразование
Освоен курс по СМД-методологии, растянувшийся на 2/3 года. Как и с ТРИЗ это дало разработку новых практик на стыке двух дисциплин: СМДМ и проектирования цифровых сервисов.

Рабочие проекты Byndyusoft
— Настроил работу над матрицей грейдов и системой развития и оценивания сотрудников компании. Наконец-то, благодаря усилиям коллег, она была запущена в этом год. Построили модель компетенций, процедуры рекрутинга оценщиков, оценивания, придумали и реализовали процедуры расчёта и визуализации оценки, формирования индивидуальных планом развития на основе базы средств развития, проверили всё это в бою, описал методики, сейчас она уже воплощена в нашей внутренней системе управления.
— Основным проектом года стал выход в розничный сегмент федеральной сети по продаже автозапчастей, где я ситуативно играю роли продуктового дизайнера, аналитик и консультанта по управлению продуктом.
— Мы стали аккредитованными технологическими партнерами Сбера. Среди 170 компаний в этом списке только 7 способны разрабатать софт с нуля. В нашем случае это ещё и софт любой сложности.

Разработки
— Открыл схему СМД-молекул, позже названный методом ключевых действий. Описал и опробовал дважды метод ключевых действий, выпустил статью про него — https://ashapiro.ru/articles/key-actions-method
— Книга «Карта процесс-опыт. Проектирование механизма услуги». Это книга с описанием подхода к CJM, который я развивал 8 последних лет. В действительности это подход к проектированию механизма и опыта цифрового сервиса или классической услуги. Книга завершена на 80% и на данный момент содержит 90 страниц и 50 схем-иллюстраций. В январе планировал закончить писать и самостоятелно редактировать, затем перейти к активной доработке по обратной связе и к процессу вёрстки и издания.
— Книга «Как проектировать» сузилась в предмете до «Как проектировать цифровые системы и их интерфейс». Написаны главы «Типология средств проектирования», «Ситуации проектирования», «Управление проектными знаниями и сложностью», описаны авторская позиция и программа написания книги.
— По одной из глав книги «Как проектировать» написана статья «Управление знаниями в продукте», с этой же темой выступил на ProductSense — https://ashapiro.ru/articles/system-episteme
— Описан первый подход к структурному языку интерфейса. Моя давнишняя мечта привнести строгого символьного языка по типу математического в интерфейсы.
— Был основан консорциум исследования интерфейса — объединение из UX-дизайнеров и методологов разрабатывающих язык описания интерфейса и номенклатуры элементов и сборок для стандартизации отрасли UX/UI. Участие в исследованиях и разработки приветствуются: https://github.com/UIRC/ui-language
— Придумал схему потока данных преобразователь-предохранитель для описания интерфейсов. Вскоре опубликую.

Выступления и публичность
— Апрель, Выступление на DUMP с докладом о методе описания процесса Event Storming — https://ashapiro.ru/talks/tpost/hfphhlof91-event-storming-udachnoe-popolnenie-v-ars
— Июнь, Выступления на UWDC с докладом о Event Storming
Сентябрь, Выступление на Product Sense с темой «Инструменты укрощение сложности» — https://ashapiro.ru/talks/tpost/x2kpcc4631-ukroschaya-slozhnost-tsifrovogo-produkta
— Ноябрь, Беседа о воле и самоопределении — https://ashapiro.ru/talks/tpost/51blbh6g11-fenomen-voli-itehnika-samoopredeleniya
— Декабрь, Первое обучение методу карта процесса-опыта
— Обновил наконец-то сайт и наполнил его. Перенёс все ключевые статьи с Медиума и продолжаю писать уже в разделе «Очерки» сайта. Впервые опубликовал свои стихи, часть прозы, афоризмы, музыку в разделе «Лира».

Музыка
— Дебютировал как композитор, написав пять треков для детского спектакля студии «Всёцензурно» — 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

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