Есть еще один дискуссионный стикер “Турист подписался на возможные ближайшие походы/Поставил статус, что готов пойти”. Мне кажется, что он нам точно понадобиться для туристов, которые не являются руководителями. Но как будто бы не сейчас. Зачем кому-то подписываться на поход, если он может сразу подать заявку? Допустим, если поход есть в системе, но находится в архиве. То есть проводить его в ближайшее время не планируют, но кому-то он нравится и хотелось бы пройти. Для архивных походов может пригодится функция “подписаться”. В этом случае не руководитель заводит поход, а поход будет искать своего руководителя. Интересная мысль. Но стоит ли ее описывать в самом начале?

Если все согласны с описанным мною выше процессом, то событийный ряд будет выглядеть так:

Турист зарегистрировался - Поход создан - Турист подал заявку \ Рассматривает заявку - Даты утверждены \ Маршрут утвержден \ Участники утверждены

События, обозначенные через дефис, идут последовательно, а через слеш - могут происходить одновременно.

При этом стикеры

Плановые даты похода и маршрут сформированы

Утверждены даты похода

Утверждена нитка маршрута

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

А для того, чтобы привести в порядок третий - из двух стикеров: “Группа туристов сформирована” и “Команда сформирована”, оставим только один - первый.

Есть возражения? Встречаемся в чате.

#ESWriting

Итерация 2: ответы на дополнительные вопросы к условному заказчику

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

Это сервис для города или распределенный по миру?

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

Сервис на одном языке?

Да, на текущем этапе сервис будет работать на одном языке. Более того, этот язык - русский. Почему? Потому, что я, как условный заказчик, нифига не понимаю в американских, турецких или балийских походах. Я знаю только ЕВСКТМ (Единый Всероссийский…)

#ESWriting

Резюме по Итерация 2

После второй итерации все доменные эксперты “встали и вышли”. Мне ещё предстоит разобраться в причинах возникновения этого эффекта. Сейчас - про походы.

Я остановилась на попытке разобрать карточки с событиями и выстроить их в порядке возникновения от более ранних к более поздним. В процессе поняла что какие-то стикеры хочется объединить, что-то убрать, а что-то – переименовать. И все это по отношению к самым ранним событиям. Буквально только старт процесса. У меня получилось что-то вроде горизонтальной пирамидки:

<турист зарегистрировался в приложении>
|
<поход создан в приложении>
|
<турист подал заявку на участие в походе> И <кто-то рассматривает эту заявку>
|
<даты похода утверждены> И <маршрут утвержден> И <участники утверждены>

Что дальше?

#ESWriting

Итерация 3: Error

Обычно после того как с составом группы датами и маршрутом все становится понятно начинается какая-то суета по поводу еды, снаряжения, транспорта, подготовке необходимых документов. И все это происходит одновременно. Раскладка никак не зависит от состава снаряжения, которое удалось раздобыть. Не зависят от всего этого ни документы, ни транспорт. Но внутри каждого из этих понятий существуют какие-то события. Это параллельные потоки. Обозначу их на Swim Line (плавательных дорожках). Но у меня уже как будто есть плавательные дорожки. Вот же стикеры стоят друг под другом и рассказывают про Даты, Маршрут и Участников. Еда, Снаряжение и Документы со всем этим никак не коррелируют. Как быть?

Сами собой в моих размышлениях выкристаллизовалась понятия, которые рискуют стать субдоменами для домена “Походы”. Я пока не знаю что с ними делать. Воспользуюсь красной карточкой.

Error в методологии Event Storming используется для обозначения того, на что стоит обратить внимание в уже составленной схеме. Это не обязательно ошибка. Может быть просто замечание. Я воспринимаю его как свободный стикер на котором можно написать то, чего не предусмотрено в методологии. Мне не нравится красный цвет. Хочется сделать его нейтральным. Но я столкнулась с тем, что базовую легенду менять нельзя. Те, кто уже знаком с методологией, глядя на схему автоматически считывают цвета и относят их к определенным типам (оранжевое – событие, бирюзовое – термин, синий – команда к действию и т.п.). Цветовое кодирование позволяет читать плоскую картинку как объемную модель. Но работает это только тогда, когда у всех одинаковый код. Иначе интерпретатор, работающий в наших сознаниях, ломается.

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

#ESWriting

Итерация 3: проверка методом прямого чтения (слева-направо)

Когда все события выстроены по Timeline проводятся две проверки: методом прямого чтения и методом обратного повествования). Проверку методом чтения слева-направо удобно проводить по шаблону:

Когда произошло <событие на первой карточке> тогда происходит <событие на второй карточке>.

Когда <пользователь зарегистрировался в приложении> – <поход в приложении создан>.

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

Допустим, он решит быть руководителем и получит право зарегистрировать (создать) свой поход в системе нашего приложения.

Когда <поход в системе создан> – <кто-то подал заявку на участие> И <кто-то рассматривает эту заявку>.

Ну, допустим. Тут вроде ничего не вызывает внутреннего противоречия. Дальше

Когда <турист подал заявку> И <эту заявку рассмотрели> – <даты похода утверждены>И <маршрут утвержден> И <состав утвержден>

Вот это полная фигня.

Поход “Идем не знаю куда не знаю когда” - невозможен. Не бывает походов без маршрута и дат. Бывают такие, где окончательное решение принимается спустя какое-то время. Ну так это требование к системе (возможность менять даты и маршрут в уже созданном походе), а не какое-то событие, которое блокирует возникновение последующих событий. Что тогда? Как будет выглядеть цепочка событий на Timeline?

Убираю карточки с датой и маршрутом. Добавляю две карточки про выбор роли. Между ними провожу красную черту (на предыдущей итерации она появилась в легенде). Таким образом у меня появились две плавательные дорожки Swimming Line. Тут же обнаруживаю что одна из карточек содержит формулировку в настоящем времени, а по правилам необходимо прошедшее. Исправляю “рассматрИВАЕТ заявку участника” на “РассмотрЕЛ…” и отношу исправлений стикер на дорожку, где была выбрана роль руководителя. А карточку с подачей заявки в поход переношу на дорожку, где была выбрана “произвольная” роль для участия в походе. Быстрая проверка методом прямого чтения:

Когда <пользователь зарегистрировался в приложении> – <роль руководителя похода выбрана>
|
Когда <роль руководителя похода выбрана> – <поход зарегистрирован в системе>
|
Когда <поход зарегистрирован в приложении> – <руководитель рассмотрел заявку на участие>
|
Когда <руководитель рассмотрел заявку на участие> – <участники похода утверждены>

Выглядит так, как будто работает. Возможно стоит сменить крайний оранжевый стикер с “участники утверждены” на “группа сформирована”.

А что будет, если мы пойдем по другой плавательной дорожке?

Когда пользователь зарегистрировался или авторизовался в системе – роль “произвольная” выбрана
|
Когда произвольная роль выбрана – … поход из каталога походов выбран
|
Когда поход выбран – заявка на участие в походе подана
|
Когда заявка на участие подана – группа сформирована?

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

#ESWriting

Цепочка событий – это муторно и долго. Хочется бросить примерно сразу. Есть же уже какое-то базовое понимание того, что должно получится. Примерно знаешь что там должно происходить. Представляешь даже за счет чего это может быть реализовано. Какую базу данных использовать, на какие таблицы делить. Какие технологии понадобятся. Чего мяться? Нада делать!

Ну мы и делаем. Чуть чуть сделали – показали заказчику, как завещает agile. Заказчик чуть-чуть скорректировал формулировки. Еще чуть-чуть сделали. А в конце получилось, что сделали не то, что собирались. И сделали как-то не очень. А денег на очень уже нет.

Из теории систем я знаю что анализ должен сочетаться с синтезом и важно, чтобы эти стадии были равными, последовательными и не особо длительными.

Нейробиолог Анна Обухова также рассказывает о том, как важно возвращать себе энергию из любого процесса иначе на новую итерацию топлива может просто не хватить.

Как же поступить, чтобы первая стадия Event Storming – Big Picture – была не столь длительна и не так утомительна?

Ответ пришел мне в голову когда мне захотелось превратить линейки событий про еду, снаряжение и подготовку документов в сворачивающиеся списки. Можно я сейчас схлопну всё это в один стикер, представив что еда, снаряжение и документы для похода уже готовы? Есть ли что-то дальше? А можно ещё чуть-чуть отодвинуться увидеть как выглядит картина в целом?

Укрупняем. Как выглядит процесс походов если писать его крупными мазками?

Собрались - Пошли - Вернулись.

В этом лесу совсем не видно деревьев. Так не пойдет.

Можно разобраться подробно с тем, что там нужно для подготовки и сбора еды. Потом понять как организовать поиск и подготовку необходимого снаряжения. А потом соберем все это в одну картину. Многие именно так и работают. Но я не нашла способов, методов и даже примеров того, как много маленьких Штормингов собирают связывают друг с другом.

Есть риск не увидеть за деревьями лес.

Похоже, чтобы мы видели лес и знали какие в нем деревья, нужно уметь делать и то, и другое – прописывать процесс крупными мазками (но так, чтобы все-таки было понятно о чем он) и детализировать то, что в этом нуждается. При этом важно удерживать себя от соблазна начать разработку раньше, чем закончится планирование и проектирование.

Попробую исправиться:

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

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

Есть другие предложения?

#ESWriting

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

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

https://excalidraw.com/#room=d551383ae076bd5d2081,7KlSutOHA7x6rROeUYFp2w

#ESWriting

Как писать Требования к IT системам хорошо

Вы, возможно, знакомы с Юрием Куприяновым — автором канала «Системный сдвиг». На одном из Летних Аналитических Фестивалей он прочел доклад о стоп-словах для системного аналитика.

Список этих слов представляет собой значительную работу по автоматизации контроля качества Требований. Критерии качества легко нагуглить. Ими можно пользоваться, но существует эффект, который принято называть «глаз замылился». Вот если бы существовали маркеры, помогающие обнаружить ошибки… Юрий предлагает использовать определенные слова в качестве таких маркеров.

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

📑 Статья с чек-листом https://notes-analyst.ru/stati/kak-pisat-trebovaniya-dlya-it-sistem-horosho/

P.S.
Я оформила чек-лист так, как смогла. Буду рада предложениям по его улучшению.

Организовали на сайте раздел «Шаблоны».

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

Пока в разделе только два артефакта:
📄 пример документирования REST API;
📄 пример документирования API для JSON-RPC.

Комментарии к обоим примерам и ко всему разделу в целом, а также:
📑 примеры шаблонов получше,
🔗 ссылки на другие шаблоны,
📥 заказы на шаблоны документирования,
🎁 свои шаблоны, -
всякое такое ждем в комментах к этому посту ⤵️

Event Storming примиряющий

Недавно у меня была возможность понаблюдать как работает Event Storming на реальном проекте. К сожалению, не полный цикл, а только стадию Big Picture (общая картина). Но мне все равно удалось сделать несколько любопытных выводов.

Жизнь и методология часто стоят очень далеко друг от друга. Вот и в Event Storming есть несколько нереалистичных требований: собрать всех в одной комнате в одно время, работать с доменными экспертами… И много разных нереализуемых моментов. Сейчас не о них.

В этот раз человек работал вообще без доменных экспертов. Он даже оранжевые стикеры по-началу не применял. Но сразу, с первой встречи получил интересный эффект – системные и бизнес-аналитики, которые до этого никак не могли понять друг друга, внезапно смогли спокойно и продуктивно поговорить.

Я планировала написать небольшой пост, но не влезло даже в два. Опубликовала на сайте

Конечно, будем рады комментариям. Особенно интересно узнать как сделать так, чтобы Excalidraw не «материлась» от большого объема стикеров. Может кто уже сталкивался и подскажет решение.

2 января собираемся с Андреем Бураковым и Владимиром Невзоровым проектировать маркетплейс методом Event Storming. Все желающие могут присоединиться, только предупредите меня заранее, пожалуйста.

Во время неудачной попытки поштормить сервис организации походов Владимир несколько раз просил меня дать общую инструкцию процесса. Какие в нем этапы? Что за чем идет? Я отбивалась как могла по двум причинам:

1️⃣ Не считаю себя достаточно знающим человеком.
2️⃣ Статьи о том, как делать Event Storming есть. Хорошие. Но из них ничего непонятно.

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

Описала этапы Event Storming так коротко, как только смогла. Хочу верить, что это вам хоть в чем-то поможет. Если не сама статья, то хотя бы видеодоклад Сергея Баранова, на который я там ссылаюсь.

Критику и вопросы складывайте в комментарии.


До встречи в чатике в новом году.