Меня можно поздравить)

Первый опыт получен! И, субъективно, он прошёл очень хорошо. Видеть улыбки на лице слушателей - огромная радость. 
А количество вопросов, отличный показатель, что тема животрепещущая. 

Всем хороших стажеров и интересных вызовов)

Презентация по EventStorming


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

Легенда, термины, пример этапа BigPicture и пример ProcessModeling + Software Design.

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

В реальных примерах, у вас не должно оставаться моментов "ну может быть так".

Примеры команд выложу в комментариях.

Свои впечатления о воркшопе и наблюдения опишу уже на след. Неделе. 

А в комментариях под постом можете оставить обратную связь или задать вопросы. 

Впечатления от собственного воркшопа EventStorming

Во время подготовки было тяжело. Когда время на подготовку, перевалило за 60 часов, я засомневалась: "Разве этого времени не достаточно, чтобы с нуля освоить метод EventStorming?". А между тем количество часов подготовки продолжало расти. Это не считая времени куратора и тех, кто помогал тестировать формат.

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

Часы подготовки помогли справиться и с главным кризисом - количеством людей. Их должно было быть не больше 30, это несколько раз обговаривалось с организаторами, но во время подготовки я упустила момент, как это будет проконтролировано. И оно не было (Сколько в итоге было людей?). Предчувствуя это, я с волонтерами заранее подготовила дополнительное рабочее пространство. А когда уже в процессе и этого стало мало, смогли сориентироваться и создать еще одно. Мои волонтеры - лучшие.

Формат живого EventStorming очень крутой. Заполненные стикеры так и вылетали из под маркеров участников. А сколько возможностей поспорить и договориться в живом пространстве! Как ведущей, мне было легче отслеживать "скучающих" и отличать их от активно наблюдающих. С ними разная механика работы.

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

Удивила команда, та самая дополнительная от дополнительной. Рабочий способ справиться с ситуацией и унести пользу для себя. Это, конечно, стало шоком и проблемой уже для меня, но и очень интересным кейсом, который у меня теперь стоит на осмыслении.

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

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

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

Еще раз спасибо все пришел, и отдельно всем кто помогал)

У меня это лето очень насыщенное на ИТ мероприятия. 

Настолько, что от следующего приняла решение отказаться. 

Но если вам интересна атмосфера Волжского гедонизма и полезных ИТ докладов - это повод доехать на этих выходных  под Ульяновск на ULCAMP. 

Бонус - крутое место проведения, а вечером в пятницу выступает топовый диджей DJ Kradson и очень юморная группа Дископровокация. 

Взять ответственность или обвинить?
На этой неделе я не появлялась в блоге, и на это была веская причина.

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

Желание оправдываться исчезло, но перед командой мне было неудобно – я добавила им лишнюю работу. Для меня это было самое неприятное в этой ситуации.

Хочу отдать должное моей команде: они восприняли ситуацию с юмором и быстро взялись за новые вводные.

В двух абзацах всё звучит логично и правильно. В реальности эмоции всегда сложнее. Желание защититься кажется вполне обоснованным.

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

А как вы справляетесь с подобными ситуациями? Берете на себя ответственность или предпочитаете искать виноватых?

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

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

День 1
⭐️Алексей Трошин: Воркшоп "Звёздная карта команды"
Я удачно начала ЛАФ с воркшопа от Алексея Трошина. Это произошло случайно: я шла проверить, сколько людей собирается в зале, где через два часа будет мое выступление, и увидела, что в соседнем зале стартует воркшоп. Решила остаться. Алексей - харизматичный спикер, зарядил меня энергией и хорошей атмосферой на весь день.

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

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

⚡️Можно легко уйти в сторону, если среди инициаторов окажется человек, продвигающий свои интересы.
⚡️Легко манипулировать навыками, чтобы скрыть нежелательные компетенции.
Тем не менее, метод стоит попробовать в команде, особенно если остро стоит вопрос "бутылочного горлышка" и bus-фактора.

⭐️Андрей Бураков: Воркшоп "Как аналитику (не) выбрать технологию интеграции"
Это было единственное выступление, на которое я пошла осознанно. В прошлом году на FLOW воркшоп Андрея вдохновил меня самой провести воркшоп. Я впервые увидела, что этот формат можно преподносить так интересно. (У меня так не получилось, но хотелось бы в будущем достичь такого уровня.)

В этот раз воркшоп был снова на высоте. Андрей - спикер, который умеет увлечь аудиторию, оставляя ощущение "Я сам додумался".

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

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

Как и год назад, это был пример для подражания и источник множества мыслей для осмысления.

👀Если бы у меня было больше времени, я бы с удовольствием посетила:

Юлия Литвинюк: "Как мы учим парному проектированию аналитиков вместе с разработчиками" - опыт прямо по больному.
Татьяна Емельянова: "Ревью ТЗ: от ненависти к пониманию" - история и выводы, что получается, когда команде дают делать то, что они хотят.
Надежда Смирнова: "Оценка внутренней документации" - и снова по больному.
Кристина Ширкунова: "Игровой подход к развитию джунов" - осознанно не пошла, чтобы не расстроиться, что кто-то обучает джунов лучше меня.
Татьяна Половинкина: "HumanOps" - Татьяна - крутая. При личном общении с ней постоянно ловишь себя на мысли "Как чудесно можно видеть этот мир. И видеть при этом его глубоко". Очень интересно узнать, как она передает это со сцены.

ЛАФ: Доклады, День 2

⭐️Илья Бравин: Доклад "Аналитик фича-лид - точно ли спаситель?!"
Этот доклад я застала случайно, пытаясь найти зал с комфортной температурой (почему на всех конференциях такие проблемы с вентиляцией, особенно если они проходят в отелях?). Честно говоря, по названию я бы его не выбрала. В зале Ильи можно было ЖИТЬ, и первые мгновения только эта мысль крутилась у меня в голове. Но чем больше он рассказывал, тем больше я понимала, что он делится опытом, который мы с командой переживаем сейчас и еще не успели оценить и систематизировать.

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

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

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

⭐️Круглый стол: Александр Чувашев "Процессное моделирование для проектирования систем: актуальность и применимость на разных стадиях проекта"
Эта тема хорошо продолжает мой воркшоп по EventStorming, поэтому я очень хотела на него попасть. Тем более обсуждать планировали очень интересные участники, за блогами некоторых я уже давно слежу.

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

Пропущенные доклады
Если бы у меня было больше времени, я бы еще посетила:

Алина Миронова: Доклад "ЛЮСТРА. Методика разработки бизнес-требований в проекте по автоматизации" - очень интересная подача материала. Спикер оформила его атмосферно с помощью ИИ. Вышло просто ВАУ.
Наталья Веселова: Воркшоп "Визуализация данных – убеждает или обманывает?!" - с Натальей мы познакомились на завтраке, и меня поразил ее подход к мастер-классам. Уровень проработки точно может посоревноваться с Андреем из моего прошлого поста. Слышала много восторженных отзывов об этом воркшопе.
Анна Подолина: Мастер-класс "Юмор для выступлений и коммуникаций. 10 упражнений для умного юмора, для карьеры и отношений" - люблю, когда в докладах есть юмор. Сразу вспоминаю свой любимый ScienceSlam. Круто, что об этом говорят на ИТ-конференциях.
Честно говоря, после ЛАФ было столько мыслей, что мне казалось, что я успела застать больше докладов. Но, возможно, в этом и сила. Я замечала, что когда посещаешь все подряд, мозг перестает обрабатывать информацию. А у меня до сих пор идет осмысление и внедрение в практику услышанного и пройденного.

Сегодня в рабочем процессе мы расширяли количество участников EventStorming и столкнулись с неожиданным препятствием.

Коллегам было слишком легко. А в их глазах легко равно бесполезно.

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

Другая сложность, с которой мы столкнулись, — "Как формировать знания об области, которой еще не существует". Ранее такой потребности у наших пользователей просто не было, она появилась из-за импортозамещения. Бизнес-экспертов просто нет. Поэтому мы больше ориентируемся на гипотезы и, в некотором понимании, уходим от типичной сессии ES.

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

Интересно узнать, кто уже сталкивался с подобным? Как вы справлялись с такими вызовами?

Мне кажется, я продешевил...

Три года назад мой знакомый уволился с работы, чтобы войти в ИТ. Бэкграунд у него был совершенно не связан с этой сферой, и из умений он мог похвастаться только знанием Word и Excel, про Google Документы он ничего не слышал.

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

И вот недавно мы встречаемся. А человек всё ещё без работы.

👀Какие у вас мысли?

На деле всё интереснее. За эти 2,5 года он самостоятельно прошел ещё четыре раза те же самые курсы, постоянно смотрел видео о том, как войти в ИТ. Иногда ходил на собеседования, приписывая себе год опыта в той самой конторе, где проходил курсы. Он успешно проходил собеседования, получая офферы от 100 до 180 тысяч.

И ни на один из них не согласился. Потому что на YouTube говорят, что это мало, и он чувствует, что продешевил.

Я не знаю, что меня больше раздражает:

1️⃣ Человек, который три года сидит на шее у родителей, чья зарплата 60к) и не соглашается на офферы 180к?
2️⃣ Компании, которые не смогли нормально проверить его и таким образом рождают этих самых джунов в овечьих шкурах.
3️⃣ Новички, которые своим подходом обесценивают сферу, в которую хотят попасть.
4️⃣ Или то, что я по работе столкнулась с таким "мидлом", который не мидл. Я на себе убедилась, как такие люди опасны для продукта и более опытных коллег.

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

P.S. У меня есть знакомые, которые приходили в ИТ сразу мидлами, но у них всегда были предпосылки для этого. В данном случае это не такой человек.

Вчера я побывала на концерте группы "Обними кита". Помимо музыки, меня поразило, как профессионально солистка взаимодействовала с аудиторией. Я сразу провела параллели с нашей сферой. Навык профессионального выступления важен и для IT-специалистов.

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

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

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

Ваши идеи, как можно в наших спичах реализовать пункт 2?

Появилась срочная необходимость в наставнике-консультанте

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

Мои пожелания:

1️⃣Более 10 лет в профессии;
2️⃣ Уровень сеньора, работа в роли лида;
3️⃣ Опыт работы с карьерными запросами.
4️⃣ Предпочтительно женщина, но это не принципиально.
Нашлось всего 8 человек. В основном это платные консультации, что вполне логично.

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

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

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

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

Девочка, девочка, а хочешь код покажу?👀

Один из моих любимых типов созвонов и практик по повышению собственных скиллов — это наблюдать, как разработчики кодят.

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

Как это выглядит:
Мы созваниваемся, коллеги начинают шарить экран и показывают, над чем работают. Честно говоря, в начале (да и сейчас) бывает сложно понять, что происходит. Здесь помогают старые добрые вопросы и просьбы:

❔"Объясни, почему здесь работает так."
❔"Расскажи, как ты это смотришь."
И все другие вариации, которые помогают разобраться в деталях.

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

Коллеги, похоже, уже привыкли к этому и все чаще сами пишут: "Пошли, покажу тебе что-то ужасное." Если у меня есть время, я с удовольствием смотрю.

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

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

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

А практикуете ли вы или ваши аналитики что-то подобное?