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

Ну мы и делаем. Чуть чуть сделали – показали заказчику, как завещает 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 так коротко, как только смогла. Хочу верить, что это вам хоть в чем-то поможет. Если не сама статья, то хотя бы видеодоклад Сергея Баранова, на который я там ссылаюсь.

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


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

Готовлюсь рассказывать разработчикам про Event Storming.

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

У меня проблемы. О чем я только думала, когда соглашалась. С чего я вообще решила, что мне есть о чем рассказать разработчикам.

Мой доклад про Event Storming назывался “Дешёвый способ ошибаться”. Это придумал Артем – один из людей орг.группы. Где-то в середине первой трети черновика он дочитал до мысли про то, что Event Storming – это как проект и модель дома. Мы заранее можем сделать расчеты и проверить их. Мы можем узнать что с нашим домом не так еще до того, как его построим. Мы сэкономим ресурсы. Артем выделил эту мысль и написал что-то вроде: “Вынеси это в самое начало”. Вероятно только тут у него забрезжело хоть какое-то понимание – зачем тут столько букв и про что все они. Я вынесла в заголовок, хотя, скорее всего, от меня просто хотели, чтобы я выбросила то, что было написано выше.

На самом деле дешёвым способом ошибиться стал мой доклад. Я ожидаемо облажалась: неправильно подготовила презентацию (не делайте темный фон, если трансляция через проектор); забывала перелистывать слайды и повторялась; какую-то чушь отвечала на возникающие вопросы (сейчас, когда у меня было время подумать, я бы ответила другое); не смогла доходчиво объяснить довольно простую тему Шторминга, в конце-концов.

Я облажалась, но ничего страшного не произошло. Мероприятие проходило в баре. У всех было пиво. Никто не расстроился.

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

А пока я очень благодарна за то, что в местном сообществе находятся люди, которые вкладывают огромные силы в создание безопасного пространства. В городе, где я сейчас обитаю, есть АйТи завтраки, АйТи прогулки, АйТи волейбол, АйТи пивные четверги и даже IT Girls Club.

Мы тут сходили на NextConf. Засиделись там допоздна так как самым полезным и запоминающимся событием дня оказался Круглый стол. А на следующий день в шесть утра уже стремились в сторону другого города.

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

В связи с двумя вышеперечисленными событиями приняла три очень важных для себя решения:

1️⃣ Больше никаких конференций.
Придется съездить на ЛАФ потому, что билеты были куплены еще в начале января. Но если бы мы сейчас принимали это решение, то не поехали бы. Возможно стану покупать записи докладов. Все равно их ценность – обзорно-ознакомительная. Не знаю пока как решать задачи нетворкинга. Планирую нанять на эту работу комментинг. Но так, чтоб на весь день онлайн или (еще хуже) оффлайн – хватит. Да, Дмитрий Савченко. Наконец-то я тоже доросла до этой мысли.

2️⃣ Больше никаких воркшопов и мастерклассов.
После воркшопа Анны Вичуговой и Зои Степановой я испытывала такую жгучую смесь ненависти к себе, досады и отчаяния, что поспешила извиниться перед Натальей Козловой за то, что напросилась к ней на тестовый прогон МК по моделированию угроз. У меня есть очень большие вопросы к формату воршопов (не к Анне и Зое – они офигенные).

3️⃣ Нет курсам.
Год только начался. А мы бросаем уже второй курс. В основном это приходится делать из-за того, как организован процесс. На самоорганизацию и подгонку своей жизни под расписание приходится так много сил, что на учебу не остается вообще. И на работу тоже. Но дело даже не в этом. Всю дорогу я не могу перестать чувствовать себя обманутым покупателем.

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

На примере курсов Наташи Бабаевой это выглядит так:

Упакован как e-mail рассылка. В письме только маленький кусочек каждого урока. Полная версия – браузерная. Эти штуки делают сервисы рассылки. Хранится контент у них. Что если с сервисом рассылки, где хранится мой курс по затаскиванию проектов в срок, что-то случиться?

А еще я, не ожидая подвоха, указала при регистрации на курс почту Гугла и теперь с ужасом жду, что мне могут ее заблокировать. Что тогда?

Я, конечно, пробовала копировать. Но получается фигня. Задолбаешься редактировать. Особая боль с картинками. Их сначала придется сохранить к себе на комп, а потом повставлять в нужные места повествования. А без картинок ничего не понятно. То есть мне придется это все заново сверстать. Я не могу найти время на то, чтобы это прочесть. Мне нужно время для того, чтобы это осмыслить и законспектировать. Шансов найти время на заново сверстать – нет вообще.

Почему оплатив курс я не могу оставить себе материал? И почему я должна об этом переживать?

Но у Наташи я сделала не одну покупку. Вторая – про тексты. Курс огромный поэтому лежит не в почтовой рассылке, а на сайте.

Сайты Наташи Бабаевой имеют особый дизайн – бесящий. Так специально. По ее мнению это должно бодрить. Но, простите, я уже отдала вам своим деньги. Может хватит меня бесить?

Неудобно читать курс с сайта. Приходится прилагать для этого дополнительные усилия. А они мне очень-очень нужны чтобы воспринимать новую информацию. Скопировать нельзя. Вернее – можно, но задолбаешься форматировать. Хочется заплатить денег каким-нибудь пиратам, чтобы они украли для меня эти курсы и переупаковали так, чтобы мне не приходилось заставлять себя их читать. К тому же с сайтом Наташи Бабаевой тоже что-то может случится. Хотелось бы иметь резервную копию материала на своем компе.

Здесь нужно признать, что курсы Наташи – единственные, которые я решилась бы покупать дальше, если бы не их упаковка (если не считать курса Андрея Буракова по Систем-дизайну, но это для Игоря).

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

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

Из всех остальных курсов я могу унести только то, что удалось осмыслить прямо во время урока. А это в моем случае очень-очень мало. Поэтому я планирую получать знания какими-то другими путями. Сейчас вижу это как связку: поговорить с нейросетью + статьи \ видео в свободном доступе + менторы + книжные клубы.

Ребята из великого кан-бан метода завещали: “Перестаньте начинать. Начните заканчивать”. Начинаю заканчивать конференции, курсы и воркшопы. Освобождаю место для нового. Весна же. Время уборки. А у вас как дела?

Страдания про Event Storming

Я решила написать статью про три маркера границ контекста в Event Storming потому, что я это уже рассказывала в баре и материал как будто готов на 90%.

Но до меня дошло, что сначала нада написать про то, как я придумала начинать Event Storming с конца и что мне это дает. Решение оказалось настолько удачным, что я теперь все время так делаю. Даже забыла, что в методологии ничего подобного нет, а это значит, что придется пояснить что я творю. И пояснила.

Игорь прочитал, сказал что это полная фигня, звучит как бла-бла-бла и нифигашечки непонятно.

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

Стала подбирать примеры и поняла, что сначала нужно рассказать про то, почему Event Storming это как С4, только Event Storming.

Когда это закончится?

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

Столько вопросов…

Вы верите в приметы?

Мой знакомый из Приэльбрусья недавно запостил в соц.сеть фотографию перистых облаков с подписью “К смене погоды”. По образованию мой знакомый – гляциолог (изучает ледники Эльбруса) и знаком с причинами формирования перистых облаков. То есть, с законами физики. Но любой гид, даже не имеющий высшего образования, знает – если светит яркое солнышко, но на небе вот это, то в горы лучше не соваться. Рискуешь застрять в буране.

Пока я писала статью про Маркеры микросервисов в Event Storming, поняла, что приметы – это способ пользоваться законами физики не зная их.

Я – ненастоящий аналитик и у меня не так много практики Шторминге, но уже появились свои приметы, указывающие на границы выделенных контекстов. При этом как минимум одной из них можно пользоваться даже не зная Event Storming. Это когда что-то начинает зваться иначе.

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

Вот отзыв Екатерины Пантелей на свой собственный воркшоп.

А статья про маркеры границ контекста в EventStorming тут. Комментарии принимаются под данным постом.

Проблемы процессов найма в АйТи

На ЛАФ 2025 Татьяна Бунто спросила Андрея Буракова о том, с каким запросом сейчас приходят учится системному анализу и получила ответ, что основной запрос – пройти собеседование. Я изумилась: “Что вообще нет тех, кому интересно разобраться?” – и столкнулась с суровой реальностью, которая голосом Андрея сообщила: “Сейчас практически уже нет”.

Кажется, будто вся поездка на фестиваль была только ради этой фразы. На самом деле, там наверняка случилось что-то ещё полезное. Но все это временно отложено в коробочку: “Будет обработано позже”.

Незадолго до поездки у меня случалась “заруба” в клубе (вне)системных аналитиков. Я настаиваю на том, что в BPMN не видны разрывы в логике процесса. Упускаются многие моменты, которые могут быть неочевидны при исследовании, но неизбежно встают в полный рост на этапе сдачи проекта. Это приводит к взаимным обвинениям в том, что одни неправильно рассказали, а другие неправильно отразили. Однако, если мыслить событиями, а не задачами, то ещё на этапе моделирования становится очевидно – где процесс проваливается. В EventStorming специально даже заложен этап проверки. Большинство высказавшихся по теме со мной не согласны. Они утверждают, что в BPMN все прекрасно видно, просто я не умею смотреть.

Решили отрисовать один и тот же процесс в BPMN и EventStorming. В качестве учебного кейса-задачки мой оппонент выбрал кейс про найм специалистов в IT команду.

Примерно в этом же самое время мой знакомый сталкивается на работе с тем, что у него в команде случается две подряд ошибки найма системных аналитиков. Первого кандидата, который не справился, собеседовали и нанимали без него. Второго — сам. То есть сам ошибся. Но и с первым неудачным кандидатом беседовал тоже не дурак. У интервьюера достаточно компетенции для оценки навыков. Вопросы были сложными. Задачки заковыристыми. А опыт кандидата в роли аналитика на предыдущем месте работы – внушительным. Придраться не к чему, кроме того, что ни первый, ни второй кандидат (который тоже очень хорошо показал себя на собесе) не справляются с рабочими задачами.

В результате уже работающие аналитики делают работу за себя и за нанятого “парня”. А наставники вообще в запаре потому, что процесс выглядит примерно так:
1. Поставить задачу так, чтобы она была понятна новенькому. Подумать о том, какая дополнительная информация ему может понадобится и где он должен её взять.
2. Дать на задачу в два раза больше времени, чем стоило бы, ведь человек – новенький.
3. Проверить выполнение задачи.
4. Афигеть.
5. Долго и подробно разбирать задачку с новеньким.
6. Объяснять что не так.
7. Объяснять почему не так.
8. Спросить о том для чего делать именно как просят, а не как привык делать на другом проекте.
9. Просить переделать.
10. Следить за тем, чтобы переделал.
11. Параллельно делать всё самому потому, что сроки давно горят и процесс поставки никак нельзя останавливать.
12. Повторить все пункты с новой задачей.

За каждую ошибку найма приходится платить трижды:
- стоимость найма;
- расходы на ФОТ;
- отодвинутые сроки проекта, которые придется компенсировать деньгами (реже – содержанием).

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

От специалиста по переговорам слышала: “Если два раза подряд бьют по лицу, значит дело в лице”.

Мой знакомый понимает что две подряд ошибки найма говорят о том, что в процессе найма что-то не так.

К счастью, ЛАФ принёс мне не только возможность побеседовать с Татьяна Бунто и Андреем Бураковым, но и знакомство с Вероникой, благодаря которой у меня появился доменный эксперт – Александр, проработавшим in-house HR так долго, что ему успело надоесть.

Сессия EventStorming уже состоялась. Я услышала от Александра много любопытных вещей. Вот например, одна из них:

Проходить собеседование и работать – два разных навыка, которые, на удивление, вообще никак не пересекаются. Это самая странная вещь.

#процессыНаймаIT

Итого, что получается?

1. На рынке много людей с хорошо прокачанным навыком прохождения собеседований.
2. Процессы отбора специалистов всё время усложняются: добавляются этапы, расширяется перечень вопросов, придумываются игры. Но это все равно не помогает нам понять – сможет ли кандидат справляться с теми задачами, которые мы собираемся ему доверить. В этот момент мне вспоминаются все рассказы Александры Брызгаловой про то, что метрика – это такая вещь, которой очень быстро становится невозможно доверять.
3. Найм дорожает и растягивается во времени.
4. Риски для работодателя увеличиваются.
5. Уже работающие в командах люди выгорают от нагрузок, если не удается быстро доукомплектовать команду.
6. Риски для кандидатов с навыками по профессии, но без навыка прохождения интервью драматичны: подушка безопасности тает, самооценка падает, да еще и стресс от необходимости всё время что-то доказывать.
7. Усложненные этапы отборов отпугивают крепких специалистов, но не представляют сложности для имитаторов.
8. Единственный более-менее точный способ понять – подойдет ли кандидат для закрытия вакансии – поработать с ним хотя бы месяц.
9. Привести хорошего специалиста к тебе на испытательный срок может только Госпожа Удача. Кто-нибудь знает как связаться с этой дамой?

Это все следствия. А в чем причины?

Как видите, я погружена в процессы найма так глубоко, что не видно поверхности. Единственный способ выбраться – рассказать вам всё это. В ближайшее время я планирую очень много писать про найм, но не переключайтесь. Упомянутые процессы – это всего лишь иллюстрация для разговора про EventStorming, BPMN и UML.

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

#процессыНаймаIT

Хочу срочно рассказать вам «страшную» историю про найм. О том, как суперзнающего человека не взяли на работу. И все это посреди дикого «голяка» на хороших специалистов. Нет, дело было не в оверквалифайд. Всё там нормально было с квалифайд. В сам раз. Просто оказалось, что никакие отмены тарологов не спасают от проклятия знания.

https://notes-analyst.ru/stati/proverka-na-sposobnost-somnevatsya-v-sobstvennyh-resheniyah/