Спасибо всем, кто принял участие в голосовании по имени блога.

Большинство голосов за старое название. А второй популярный вариант "Мама, я системный аналитик!" за время голосования перестал нравится мне.

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

Если вы еще не поняли, скоро Новый год. 😆 Та самая волшебная дата, к которой горят все дедлайны и сходят с ума коллеги. Надеюсь, вы не в числе последних.

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

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

Исчезаю с радаров до января. До встречи в новом году.

Всем привет. Я Катя. 🍾И Я книгоголик. 🍾

#выходной_контент #книги

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

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

В рабочие дни это доставляет проблемы, поэтому я строго контролирую себя: "Катя, новую книгу — только на выходных." А если дел много, книги откладываются на недели и месяцы.

Зимних каникул я ждала с особенным трепетом, чтобы погрузиться в книги. Из за длительного ожидания, в этом году встал вопрос: Начать новые или перечитать проверенные? Выбор пал в сторону тепла от уже знакомых историй.

Вот моя подборка книг, которая возможно порадует и вас.

👀 Фредрик Бакман

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

👀 Макс Фрай

Более 40 книг о том, что может произойти, если согласиться во сне переехать в новый мир. Смесь юмора, фантастики и неожиданных выводов о нашей реальности.

👀Терри Пратчетт

Знаменитая серия "Плоский мир" и та самая песня о ежике, которая ни разу не была описана на страницах книг. Даже ежики с ежиком могут...

👀Диана Сеттерфилд

Книги с неожиданными сюжетными поворотами. Они радуют финалом, но после них невероятно грустно, что приходится возвращаться в реальность. "Пока течёт река" — моя любимая.

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

А в комментариях предлагаю поделиться, что вы читаете в новогодние каникулы?

Каникулы прошли успешно, и я чувствую, что готова попробовать новый уровень контента.

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

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

1️⃣ Добить Event Storming.

Освежим основы, проведу практический вебинар и поделюсь мыслями после 1,5 лет использования. Расскажу, когда ES работает, а когда нет. Чаще не работает!

2️⃣ Очереди и брокеры сообщений.

Обещанная ещё в прошлом феврале тема. Проверим знания, соберём базу для уверенного аналитика и, возможно, проведём практическое занятие с брокерами.

3️⃣ Не микросервисами едиными.

Для тех, кто уже привык отвечать на вопрос об архитектуре собеседования: «монолит» или «микросервисы», давайте расширим горизонты. Я расскажу, какие ещё бывают архитектуры, и мы попробуем их классифицировать. Также поделюсь интересными кейсами из своей практики. Уверена, что о некоторых типах архитектуры вы, даже не слышали.

4️⃣ REST и API First.

Расскажу о собственном опыте внедрения: как команда перешла на API First, как обучила системных аналитиков работать со Swagger и Open API, а также о полезных находках в открытых API.

5️⃣ Event Modeling, или почему в ИТ так много праздников :)

Инструмент, который в отличии от ES, чаще встречается у системных аналитиков. Посмотрим на него глубже и, конечно, попробуем.

6️⃣ Постановка загадочных задач разработчикам.

Что за загадочные задачи разработчикам и почему аналитики их ставят? А главное — как. Требование в вакансиях «Постановка задач разработчикам» до сих пор ставит меня в тупик. Казалось бы, ответ лежит на поверхности, но, как известно, когда кажется — лучше перепроверить. Расскажу, как понимаю это я. Дискуссия с вами тоже будет.

Мне кажется, темы интересные. Помогите выбрать, с какой начать. Голосование выше ☝🏼

P.S.: Не волнуемся. Лайфовые посты и мои посты-нытье никуда не денутся. 😊

Шаблоны: любим или ненавидим?

Сейчас я часто выкладываю шаблоны (например, Шаблон названия задач и Шаблон требований к валидации). Это хороший контент — видно по вашим сохраненкам и реакциям. Да и у каждого аналитика есть свой набор золотых шаблонов: документы, чек-листы, вопросы, и многое другое.

Но... всегда есть "но".

👆🏼Шаблоны нужно осмыслять
Переносите шаблоны в новые команды? Адаптируйте их. Ваш опыт растет? Дорабатывайте под себя. Технологии поменялись? Поменяйте шаблоны. Без этого шаблоны превращаются в формальность и теряют ценность.

✌🏼Ограничения для опытных специалистов
С ростом опыта шаблоны часто становятся тесными. Чем опытнее я становлюсь, тем сложнее работать в рамках шаблонов, а задачи попадаются всё менее стандартизированные.

🤌🏻Потеря уникальности и возможностей проявить себя
Например, у нас сейчас активно внедряются и автоматизируются рабочие процессы. Это важно для нашей быстрорастущей команды. Но не все мои задачи и действия можно уложить в эти рамки. И именно за эти уникальные, нестандартные действия команда меня ценит и отмечает. А теперь для них нет места.

🦾 Шаблонное мышление
Это особенно заметно у новичков: освоил шаблон, начал расти, но не научился смотреть шире. А пересечение функционала обнаруживают уже после релиза, когда "всё упало".

Шаблоны снимают ответственность: "заполнил поля — всё правильно". Аналитик должен понимать, зачем и почему шаблон устроен именно так.

🫵🏼Избыточность и формализм
Шаблоны могут быть излишне детализированными. Заполняем поле просто ради галочки, хотя оно никак не влияет на задачу.

🫱🏼Устаревание
Шаблоны часто остаются без ответственных и устаревают со временем. Пока/если не придёт проактивный человек.

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

🫲🏼Сложность изменений
Шаблоны стабилизируют работу команды, но делают её аморфной к изменениям: лишние трудозатраты, необходимость пересматривать процессы и внедрять новое.

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

❓А с какими "но" шаблонов сталкивались вы❓

#СистемныйАнализ #полезныешаблоны #инструментыаналитика

На фоне того, что материалы профессиональных конференций выкладываются в интернет (например, Analyst Days, ЛАФ и ВАВ), часто возникает вопрос: а зачем ездить?

Я уже писала об этом кратко в прошлом году, но вот мои основные причины:

1️⃣ Нетворкинг.
Вы можете лично пообщаться не только со спикерами, но и с другими участниками. У меня, например, появилось три хороших друга из разных городов, а также коллеги, с которыми мы периодически обсуждаем профессиональные темы. Когда решу менять работу, точно обращусь к ним за советом и рефералками.

2️⃣ Прямой контакт со спикером.
У вас есть возможность напрямую поговорить с нужным человеком, уточнить детали, лучше понять доклад или вдохновиться на новые практики — и даже на собственные выступления.

3️⃣ Атмосфера.

Например, ЛАФ — это не только конференция, но и фестиваль, где есть место и костру, и концертам. Саммер Merge вообще больше напоминает IT-лагерь, чем классическую конференцию. Я всегда возвращаюсь с конференций с мыслями, в какой же классной сфере я работаю!


4️⃣ Разгрузка от рутины.

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

5️⃣ Вы устали от удалёнки.

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

6️⃣ Узнавать о новом раньше.

Вы не только первыми слышите доклады, но и ощущаете актуальное волнение сообщества.

7️⃣ Случайные открытия.

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

С другой стороны, нормально, если конференции не ваш формат. Есть множество других способов прокачивать скиллы и достигать профессиональных целей. Главное — составить мнение, побывав хотя бы на одной конференции.

Кого получилось вдохновить? Ставьте реакции! Если вас, то напоминаю, что недавно писала о том, как попасть на конференции, если компания их не оплачивает.

#ИТконференции #ИТмероприятия #СистемныйАнализ

На курсе по архитектуре от Get Analyst задали интересный вопрос: «Может ли Event Storming трансформироваться в User Story Mapping и наоборот?» Я не смогла остаться в стороне: первый метод я активно осваиваю, а со вторым уже успела поработать. Кажется, мой ответ вышел неплохим. Не углубляясь в детали, делюсь им с вами.

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

Однако у них разные цели:

⭐️Event Storming (ES) — про анализ и проектирование событий, а также обучение и сохранение знаний.
👥User Story Mapping (USM) — про планирование развития продукта и формирование дорожной карты.

Эти методы можно использовать вместе. Например: сначала с помощью Event Storming проектируем бизнес-домены, а затем с помощью User Story Mapping организуем разработку.

Если рассматривать какие роли их используют:

👉🏼Event Storming чаще выступает инструментом аналитиков и архитекторов.
👉🏼User Story Mapping — больше менеджерский инструмент.
Тем не менее инициаторами использования обоих подходов нередко выступают бизнес-аналитики.

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

А какой у вас опыт? Если вы сталкивались с другими подходами или комбинациями, поделитесь!

#eventstorming #UserStoryMapping #СистемныйАнализ

Проявлять инициативу в работе — это хорошо или плохо?

Последние полгода жизнь всё чаще пытается показать мне, что инициатива — это плохо 👎🏻. Когда её проявляю я, как правило, за предложенное решение приходится брать и нести ответственность. А впоследствии с тебя ещё и спрашивают, как за полноценную часть работы. Ещё хуже, когда инициативу проявляют другие, а разгребать приходится тебе.

👉🏼Вот буквально в этом месяце был случай: разработчик в своё свободное время сделал решение, которое позволило продуктовой команде снять часть нагрузки и решить боли клиентов. Но тестировать и писать требования по существующему скрипту пришлось мне — в дополнение к и без того высокой загрузке.

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

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

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

💸Во-первых, это зарплата. У меня есть уникальный кейс: как можно вырасти внутри компании. Это стало возможным потому, что мне было не всё равно. Я предлагала, брала ответственность и тащила.

🫰🏼Во-вторых, интересные возможности роста. Не только в плане ЗП, но и за счёт появления новых вызовов и крутых задач.

🤟🏼В-третьих, повышение экспертизы. Когда я общаюсь с HR-специалистами, они все в один голос говорят: «Вы так много делали. Ваше резюме сильно выделяется». Это потому, что я не боюсь выделяться.

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

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

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

#карьеравИТ #инициатива #СистемныйАнализ

🍓Безопасная инициатива🍓 как не оказаться в роли жертвы своих идей

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

1️⃣ На берегу договориться об условиях и вознаграждениях

И с самим собой, и с руководством.

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

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

2️⃣ Оценивать собственные возможности

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

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

3️⃣ Не размениваться по мелочам

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

4️⃣ Искать единомышленников

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

5️⃣ И из последнего вытекает не менее важное: не перетягивать одеяло на себя
В команде важно давать проявлять себя окружающим. Это причина, почему я отдала своё любимое начинание. хотя в моменте было очень неприятно.

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

А кто ты в мире работы?

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

Чёткий работник, который строго выполняет только то, что входит в его должностные обязанности.

Плохиш, который получает за инициативу по заслугам 💶.

Тот, кто пытается сделать меньше за те же деньги 😁.

#карьеравИТ #советыначинающим

Достаточно интересные ответы. Удивлена, что побеждает первый.

Кто из "хороших" готов поделиться своей мотивацией?

Давно мы не говорили про ошибки. Исправимся?

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

🥨Предпосылки:
Я устроилась на работу после эмоционально тяжёлого поиска, в непростой момент своей жизни. Внутренние силы и уверенность были на нуле.

Компания работала по московскому времени, а я жила в Самаре (+1). У меня уже был опыт работы с коллегами из других регионов, в том числе московских. Однако я всегда жила и работала по местному времени, и часы на всех устройствах были настроены на Самару.

🙈Что пошло не так:
Первые две недели работы. Я очень волновалась, что не пройду испытательный срок. Встречи в календаре были выставлены по московскому времени, а на всех моих устройствах стояло самарское.

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

Конечно, ко мне сразу пришёл руководитель с вопросами. Из за всех переживаний в тот момент, эта ситуация для меня воспринималась ужасно. "Точно уволят", — подумала я тогда.

Естественно, увольнять меня никто не собирался.

Но пришлось немного изменить свой образ жизни:

1️⃣Перевела рабочий компьютер на московское время.
2️⃣Добавила в телефон второе время — московское.
3️⃣Всегда уточняю в переписках и разговорах, какое время указано — московское или местное.
4️⃣Настроила корректную работу со временем в календарях, браузерах и других приложениях. Регулярно проверяю, чтобы настройки не сбивались. (В целом сейчас неплохо работают почтовые и другие клиенты, но если вы путешествуете в разные часовые пояса или живете на границе их, то промахи случаются).
5️⃣Предупреждаю коллег о разнице во времени. Прошу не назначать рядовые встречи после 16:00 мск и забиваю время после 17:00 мск в календаре. Если забывают — спокойно напоминаю.
6️⃣Использую функцию отложенных сообщений для коллег из часовых поясов +3 и более к Москве.
7️⃣Выделила основные часы для коммуникации. Эти часы учитывают разницу во времени, чтобы охватить максимум взаимодействий с коллегами. На это время стараюсь не планировать важную работу.

🤌🏻Результат:
Простые действия помогли мне больше не пропускать встречи и избавили от лишних переживаний.

Кстати проблема с часовыми поясами и разными форматами времени часто вызывает сбои и в ИТ системах. Системный аналитик должен внимательно учитывать это в своих требованиях.

👉🏼Оставляйте реакции если тоже сталкивались с такими проблемами, и делитесь в комментариях как вы работаете с разными часовыми поясами.

#карьеравИТ #удаленнаяработа

✌🏼Проводила необычное собеседование.

Необычное, потому что собеседовала человека на должность руководителя проектов. И задача была не столько оценить кандидата, сколько дать ему возможность оценить своё будущее место работы и возможные трудности.

Меня восхищает 😍 моя компания, которая даёт кандидатам шанс узнать больше о предстоящей должности и её особенностях в таком формате. А ещё восхитила кандидатка, которая подготовила вдумчивые вопросы ❔, чтобы убедиться, что место ей подходит, и что она подходит ему.

👉🏼Многие из её вопросов пересекались с теми, которые я задаю, когда выступаю в роли кандидата. Хочу поделиться ими с вами:

1️⃣ Какой опыт работы вы ждёте от кандидатов на старте?

Этот вопрос помогает понять ожидания компании и сравнить их со своими возможностями и планами.

2️⃣ Как проходит обычный рабочий день {ваша роль} у вас в команде? Какие постоянные или итерационные задачи бывают?

Один из лучших вопросов.

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

3️⃣ С кем чаще всего взаимодействует {ваша роль}?

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

4️⃣ Как вы оцениваете атмосферу в команде?

Многие компании спотыкаются на этом вопросе! Да и себе его время от времени полезно задавать.

5️⃣ Как я буду получать обратную связь о своей работе? Как часто?

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

😌Было приятно общаться с человеком, который так ответственно подходит к роли руководителя и задаёт такие крутые вопросы. В них чувствуется, что кандидатке не всё равно: она хочет приносить пользу, но и о себе не забывает.

❔А есть у вас важные вопросы, которые вы задаёте на собеседованиях❔

#карьеравИТ #итсобеседования #поискработывИТ #ВойтивАйти

❓Почему у вас везде POST❓

Казалось бы, все знают методы HTTP, принципы REST, и вообще, как делать "по стандарту". Но вот вы смотрите на свою систему, а там всё POST. Почему?

👆🏼POST ради безопасности
Забавно, но одна из самых распространённых причин — требования безопасности. Давайте разберём подробнее, зачем это может быть нужно.

1️⃣ Скрытие запросов
GET-запросы содержат параметры в URL. Это позволяет их видеть в истории браузера, логах серверов и прокси. Упоминания об этой уязвимости можно найти в OWASP (проект обеспечения безопасности веб-приложений).

В POST же данные передаются в теле запроса, что исключает утечку через URL.

2️⃣ Ограничения кэширования
GET-запросы по умолчанию могут кэшироваться в браузерах или прокси-серверах (через настройки Cache-Control). Это может привести к утечке данных или конфликтам.

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

3️⃣ Упрощённая проверка входных данных
Существует мнение, что в POST проще настроить проверку входных данных. Почему так считается — не всегда понятно, ведь современные библиотеки поддерживают работу со всеми методами. Но этот аргумент регулярно звучит в разговорах с разработчиками.

4️⃣ Ограничения инфраструктуры
Некоторые корпоративные шлюзы или прокси-серверы накладывают ограничения. Как правило, в таких случаях разрешены только методы POST и GET.

😏Мой взгляд

Использовать POST "ради безопасности", на мой взгляд, странно. Для всех перечисленных случаев существуют альтернативные решения. Если бы на моём проекте было так, я бы обязательно докапалась:

Почему выбрано именно такое решение?
Есть ли обоснование этому подходу в текущей архитектуре?
Должно ли это продолжаться в будущем?
Опиралась на стандарты, такие как RFC 7231, рекомендации OWASP, а также подходы к безопасности регламентированные стандартами ФСТЭК.

А теперь слово вам: делитесь было ли вам больно из-за повсеместного использования POST? Действительно это было обоснованно, и какие проблемы создавала вам?

#POSTзапросы #СистемныйАнализ #OpenAPI #информационнаябезопасность

Вчера наконец-то добралась до Клуба проектирования NextWay (сайт).

⭐️Что это такое?

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

👀Мой отзыв будет состоять из двух постов:

1️⃣О воркшопе: организация, кейс, степень полезности и кому подходит.
2️⃣Мои собственные впечатления о том, как проходить такие воркшопы и о сложностях участия.

✌🏼Кейс✌🏼
Проектировали систему A/B-тестирования для сравнения версий функционала путём их предоставления разным группам пользователей. Огромный плюс - это не избитый кейс, типа работы книжного магазина.

👂🏻Как проходит👂🏻

В командах по 3 человека мы итерациями строили архитектуру уровня компонентов в нотации C4. Итерации включали выяснение требований, логическую модель данных и последующие.

👉🏻Организация👉🏼

Не без косяков: материалы иногда задерживали, выход из тайминга на 1,5 часа был болезненным (особенно в выходной), поэтому часть людей не дошла до конца. С другой стороны, последнее можно рассматривать как "больше пользы" за те же деньги. Ещё была некоторая путаница в ответах, из-за чего я путалась и теряла время. Хотя, если честно, вряд ли отсутствие путаницы помогло бы мне успешнее дойти до конца.

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

🤌🏻Полезность🤌🏻

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

👍🏻Кому полезно👍🏻

Если проектирование архитектуры вам интересно, и вы либо начали уже прикасаться к этой теме, либо планируете в обозримом будущем — однозначно полезно. Но нормально, если вы, будучи системным аналитиком, не видите в этом пользы для себя.
Стоит также смотреть на кейсы — возможно, в следующий раз будут разбирать именно ту тему, над которой вы сейчас работаете, и тогда безусловно стоит участвовать.
Если вы опытный архитектор или супер продвинутый СА, и, уже читая описание кейса, у вас в голове сложилась картина действий и достаточно точная диаграмма компонентов, то, вероятно, вам стоит попроситься в команду организаторов или подумать, где ещё можно применить свои силы.

⭐️Итог⭐️
Несмотря на небольшие промахи, я в восторге. Это было увлекательно и полезно. Есть, что обдумать и куда копать дальше.

#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем #NextWay #школысистемногоанализа

👀Как стать гением архитектуры👀

Продолжаю делиться впечатлениями о клубе проектирования NextWay.

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

😱Выяснение требований: ФТ и НФТ

Первыми этапами стали сбор функциональных (ФТ) и нефункциональных требований (НФТ). Привычная задача для аналитиков. Мы с энтузиазмом бросились собирать информацию: задали кучу вопросов, узнали массу деталей. Но сколько из этого мы реально использовали? В лучшем случае, процентов 15.

🤔Провал с НФТ

Лично для меня этап с НФТ стал провалом. Я часто говорю своим менти, что одна из главных проблем аналитиков — это сбор НФТ "по-детски". То есть: спросили, записали и забыли, даже не пытаясь понять, зачем эти требования нужны.

В этот раз произошло то же самое. Все НФТ собрали, но использовала их только одна команда, да и то — минимально. Вспоминаю, как архитекторы на других мероприятиях, задавая меньше вопросов, использовали НФТ для расчетов, вплоть стоимости разработки и учёта в архитектуре. Это важный навык, которому аналитикам стоит учиться.

😁Проблемы внутри команд

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

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

🙈Моя грустная реальность

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

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

❔Как хакнуть архитектуру❔

1️⃣Не забывать, что это учебный кейс.

Не нужно выяснять все требования до мельчайших деталей. В подобных задачах почти всегда есть конечный набор вопросов по ФТ и НФТ, который стоит задавать. После 5–10 практик я, возможно, смогу поделиться этим списком.

2️⃣Избегать конфликтов в команде.

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

3️⃣ Не тратить время на второстепенные сервисы.

Компоненты вроде аутентификации и API Gateway часто вторичны. Чтобы избежать "стопора", можно сразу нарисовать эти блоки на схеме и больше к ним не возвращаться.

4️⃣ Провокационные ответы ради обратной связи.

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

5️⃣ Работай на знакомом уровне абстракции.

Если не знаете деталей многих решений, сосредоточьтесь на общем: интерфейс, бэкенд, кэш, БД. Главное — фокусироваться на системах, критичных для решения кейса.

6️⃣ Архитектура любит поцелуи
"KISS" (Keep It Simple, Stupid). Если систему можно не добавлять — не добавляйте. А если не понимаете, зачем она нужна, лучше не включайте её в архитектуру.

7️⃣ Освой базовые знания.
Минимальный набор: знание нотации C4 (до третьего уровня) и понимание технологий первого выбора.

8️⃣ Рефлексируй после практики.

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

⚡️Заключение⚡️

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

#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем