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

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

День 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-систему. Совместное рассматривание кода помогает быстрее решать проблемы в сложных и запутанных случаях.

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

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

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

Инструкция, как заставить плакать взрослого человека:

1️⃣Найдите взрослого человека, который впервые за 3 месяца освободил день от всех созвонов.
2️⃣С утра забросайте его "очень важными" встречами.
Готово! Вы заставили разрыдаться ещё одного коллегу.

Для тех, кто любит причинять боль профессионально:
Сделайте то же самое, но убедитесь, что человек в отпуске.

Нашла поговорку, которая неплохо описывает работу аналитиков.

Какие на ум приходят вам?

Рефлексия как ключ к качественной работе

В конце очередного квартала, оценивая свою продуктивность, я осознала, почему мои задачи часто выполняются качественнее среднестатистического аналитика. Просто частью задачи я считаю этап рефлексии после ее выполнения. Ну такая личная ретроспектива.

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

Конечно, рефлексию я провожу не для всех задач, а для:
- крупных;
- стратегически важных;
- нетривиальных;
- новых.

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

А как у вас обстоит дело с рефлексией? Есть в вашей команде время для оценки своей работы?

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

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

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

А как вы работаете с требованиями к безопасности?

Несколько месяцев назад была ситуация. 

Я делала постановку для DevOps и перепутала в описании для клиентов "И" с "ИЛИ". Заметили естественно, уже после того как ребята все сделали. Пришлось задачу возвращать. 

Сколько вылилось негатива! При всей команде. И обсуждалось, что вот ай ай яй, как можно быть такой невнимательной. Было неприятно. 

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

И в нескольких местах уже они совершили орфографические и стилистические ошибки. 

Я очень широко улыбалась, когда возвращала эти задачи. Правда уже 1 на 1, без обсуждений.

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

Как правильно уходить в отпуск

На первый взгляд, кажется, что здесь нечего обсуждать — всё и так ясно. Однако это только кажется.

Планирование:
1. Заранее планируйте даты. Убедитесь, что ваше отсутствие не пересечется с важными рабочими событиями, где ваше присутствие критично.
2. Добавьте в календарь отметки о занятости на нужные даты, чтобы другие видели, что вы недоступны.
3. Предупреждайте коллег за 2 недели до отпуска. Это даст им время обратиться к вам с вопросами не в последний момент.
4. Не берите новые задачи перед отпуском. Сосредоточьтесь на завершении текущих.
5. Договоритесь с коллегой, кто сможет подхватить ваши дела на время вашего отсутствия.
6. Закройте все "горящие" и почти завершённые задачи. Обновите статусы всех задач в трекере, чтобы другие могли легко понять, на каком этапе находится работа.
7. Приведите незавершённые дела в состояние, при котором их можно передать другим без лишней траты времени.
8. Убедитесь, что на время вашего отпуска не назначены встречи с вашим участием.
9. Поставьте статус в рабочих ресурсах, что вы в отпуске.
10. И, наконец, забейте на всех неудачников, кто остался работать, и отдыхайте!

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

Сохраняйте как чеклист, если тоже перед отпуском помните только о п. 10)

Так выглядит МЕЧТА

Нет, не машина. И не путешествие.

В этой машине сейчас все наши вещи, вся работа, цветы, кошки, и даже осталось место для друга)

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

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

Заканчивая тем, что организация путешествия со всеми вещами и кошками, которые не привыкли к дороге то ещё приключение.

Но ради мечты стоит идти и на сложности,  и на неудобства.

Теперь каждый мой рабочий день с видом на горы

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

Чтобы сегодняшний пост был для вас не только отчётом о нашем переезде, но и полезным, поделюсь маленьким советом по организации отпуска (в прошлый раз совет тоже оказался по душе многим):

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

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

А пока я с новыми силами запланировала для блога следующие посты:

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

Не пропустите, будет и интересно и полезно)