Небольшая напоминалка о том, что такое "девятки доступности" в реальном мире

Доброго вечера! Еще немного полезного от Андрея Буракова - крутой вебинар "Брокеры сообщений для самых маленьких" https://www.youtube.com/watch?v=nshPJ2Ycrrk. Если не знакомы с брокерами - самое подходящее видео, чтобы начать.

В октябре уже рекомендовал вам курс по хардам для СА.
А сейчас у ребят вышло большое обноваление, которое доступно и новым и действующим студентам.
Материал по прежнему годный, дальше про сами обновления:
📚 Первое: в портфолио включили примеры интеграций от крупных BigTech-компаний. Это позволит вам понять, как технологии применяются в реальных бизнес-контекстах.
🌐 Второе: обновили портфолио. Теперь в нём есть задания повышенного уровня сложности для каждой темы. Это небольшие реальные проекты, с помощью которых можно не только проверить, но и улучшить свои навыки!
✔️Третье: вышел новый модуль про проектирование баз данных - нормализация, транзакции, основы DWH, индексы.
—————
• Результат после прохождения курса: 15 рабочих проектов в портфолио-резюме
• Доступ к урокам и всем обновлениям останется навсегда
• Фундаментальная база
• Всю программу и отзывы смотрите в боте курса

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

@studyit_help_bot

Скидка на курс от канала
— 1 000₽ на Stepik по промокоду SPHE до 29 февраля.

Немного интересного для Кати Лысенко, как основного ДДДолога в моем круге общения

Всем привет! Внезапно буду выступать на WAW, расскажу про взгляд на работу системного и не только аналитика в РФ и в Европе.
Мне организаторы дали три промокода со скидкой на 50% (пятьдесят процентов). Если вы все еще думаете, ехать или нет и ждете знак, то это он!

Добрый вечер! Я тут зачастил с анонсами. 12 марта буду в очередной раз рассказывать, почему считаю описание системных требований потерями и бесполезной тратой времени, особенно в продуктовой разработке!
https://flowconf.ru/talks/00f0bd14499b470bb367b383eda356be/?referer=/persons/8df2ab2fb2424eca85b6b4560c3b60b8/

Звкончил читать книгу "Scrum and XP from trenches" by Henrik Kniberg.
На русский перевод не нашел, но она и на английском читается прекрасно и легко. Написана в моем любимом стиле - истории из личного опыта.
Хенрик в первой редакции описал опыт использования скрама через год после начала. А вот вторую версию не стал менять, просто добавил врезки с комментариями по прошествии 8 лет. Получилось очень живо и полезно.
Какие основные мысли вынес я:

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

2. В первой версии самой важной встречей называется Планирование. Оно, кстати, было совмещено с груммингом (PBR), что тоже не совсем классический подход. А вот уже вот втором издании Хенрик признает - важнейшее события - ретро! Без него команда не может двигаться вперед.

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

4. Очень важными практиками Хенрик называет и инженерные практики вроде TDD и парного программирования. Из скрама их намеренно убрали (со слов автора, ссылающегося на Джеффа Сазерленда) в угоду простоте. Но их использование приносит огромную пользу программному продукту.

5. Демо спринта правильнее называть спринт ревью. Потому что демо - презентация, а на демонстрации результатов спринта должен быть быть и обзор и обсуждение и в целом ворох задач для развития. Это очень ценное замечание.

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

Кто тоже читал книгу - приходите в комменты, обсудим

Новости о нашем раунде разлетелись по интернетам. Но главное, что стоит учитывать, что за раундом почти всегда следует и расширение команды. В нашем случае так оно и есть, у нас идет активный найм:
💻 в ИТ команды: фронты, бэки, QA;
🧑‍💻 в продуктовую команду заниматься задачами продуктового анализа и менеджмента, сопряженного и с БА и немного СА;
🏦 в бизнесовые команды финансов, комплаенс, customer due dilligence.
Все вакансии вот тут: https://careers.finom.co/
Если вы или ваши друзья ищете новые карьерные возможности и хотите поработать в крутой развивающейся европейской компании - жду ваши резюме на английском языке в личку!

Всем привет! На следующей неделе будем с Егором Марюшко идем в гости к Спортмастер ЛАБ, поговорить об аналитиках и образовании, приходите послушать!

Друзья, мы готовим крутую трансляцию для тех, кто хочет ворваться в мир бизнес-анализа!

Поговорим о том, где получать образование аналитика, как пройти процесс отбора и ожидания работодателей. Спикеры - Егор Марюшко, основатель школы STENET School, и Иннокентий Бодров, создатель и руководитель курса для системных аналитиков с опытом. Оба наших гостя - авторы образовательных каналов по бизнес-, системному анализу и архитектуре.

Трансляция закрытая, пройдёт 21 февраля в 19:00 в нашем телеграм-канале. Подключайтесь по ссылке сами и зовите тех, кто в поиске работы и призвания!

Ссылка на трансляцию

***

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

Хорошая статья про разницу системного и бизнес аналитика. https://habr.com/ru/companies/pgk/articles/794002/.

Если коротко резюмировать: Бизнес аналитик - он про цели, процессы, про бизнес, он вообще не про ИТ и информационные системы. И я с этим согласен на 100%.
Есть хороший комментарий, что эту роль на себя может брать продакт, если в компании есть продуктовый подход и продуктовая культура и это тоже абсолютно нормально. У нас в Finom именно так и построена работа.

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

Вчера на Winter analyst weekend рассказывал про отличие роли СА в России и на западе, а так же выдвинул несколько гипотез, почему так получилось. Презентация в сообщении выше

Всем доброго вечера. Сегодня немного необычный пост. Я раньше писал, что хожу к психологу, тут посчитал и понял, что в терапии я уже больше полугода. Хочу с одной стороны поделиться своими впечатлениями, а с другой дать контекста и описать предпосылки.
Основный впечатления и результаты:
1. Я стал гораздо спокойнее, меня сложнее вывести из себя, я стал понимать реальные причины своего грева и с ним справляться
2. Я просто вывожу то, что происходит вокруг меня. Эмиграция, переезды, родительство, новая работа, новые активности. У меня на это хотя бы как то хватает сил
3. Я стал по-иному смотреть на поведение других людей, видеть, что стоит за их раздражением, гневом, истеричностью, агресией и могу хотя бы пробовать им на это указать.
4. Я стал лучше отстаивать свои границы и научился достаточно решительно ставить на место тех, кто их основательно нарушает.
5. Самое главное, я работаю над собой, чтобы все те травмы, которые нанесли мне родители (а каждому из нас родители нанесли множество травм, в подавляюшем большинстве, конечно, невольно), разобрать и не переносить на своего сына.
6. Самое неприятное - люди, которые не в терапии постепенно начинают отваливаться из твое жизни, грустно, но факт.

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

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

Всех обнял!

Всем привет! Сегодня на подходе видео про архитектуру кода. Да, я не только про продукты, еще немного за архитектуру шарю 😃
https://www.youtube.com/watch?v=FVFqAu47umc. Видео - озвучка статьи про антипаттерны архитектуры с точки зрения именно кода. Думаю, что многие так или инача слышали про Спагетти код или Золотой молоток.
Но что больше всего меня порадовало, так это паттерн "Mushroom management". Если держать команду разработки в неведении о конечных целях, то на выходе скорее всего будет все не так, как ожидалось.
У меня это отзывается очень сильно, потому что для меня основа продуктивной работы - это открытось и общий контекст, а грибной менеджмент - антипод такого подхода.
Я на своей практике достаточно давно убедился, что принести отораванную задачу разработчику в моменте реально быстрее, но на долгой дистанции у тебя это выльется в постоянные доделки и костыли, потому что нет контекста и задача решается локально.

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

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

Достаточно занятная статья от JugRu про использование ИИ в работе аналитика https://habr.com/ru/companies/jugru/articles/795699/.
Статья скорее обзорная и описывает основные запросы и рекомендации самих аналитиков, как они с ними работают.
Это и код и SQL запросы и валидация требований. Последнее, кстати, смело, потому что требования могут содержать чувствительные данные и передавать их в стороннюю модельку может быть не очень законно, не говоря уже об этических аспектах.
Как я использую ChatGPT?
SQL я ей не пишу, слишком лень описывать контексты, мне проще самому запрос наваять, скилл позволяет.
А вот код на питоне, по крайней мере его скелет - это самое оно, пользуюсь часто.
Основной сценарий - это поиск определенной информации о различного вида регуляторных ограничениях и особенностях работы с различными данными. Понятно, что я это все перепроверяю через юристов, но для построения прототипа этого достаточно.
А как вы используете нейросети?

Всем привет! Ребята из Спортмастера сделали статью на базе нашего эфира про БА\СА и образование. Заходите почитать и покомментировать. https://habr.com/ru/companies/sportmaster_lab/articles/797271/

Шикарный доклад Юрия Куприянова. Очень последовательно расписано, чем занимается системный аналитик и почему он занимается именно проектированием систем. Дальше комментировать - только портить. Позднее ещё напишу свой пост рефлексию на этот доклад

Переварил доклад Юрия. Мыслей возникло много, но поделюсь основными.
1. Очень сильно откликнулась мысль по мотивам статей Пола Ральфа про инженерию требований и то, что мы сразу проектируем решения. И особенно та ее часть, где гоаорится о вреде излишней декомпозиции и даже дистиляции задач. Примерно про это я в начале марта рассказывал на Flow, продвигая работу с пользовательскими требованиями вместо системных. И это еще перекликается с принципом, что структурировать задачу и проектировать решение должны одни и те же люди. Мне как будто еще один кусочек пазла принесли.
2. Методы совместного проектирования решений, вроде Event storming, будут все больше набирать популярность в силу их универсальности, простоты и уникальной способности к выстраиванию коллаборации. Буду глубже копать и изучать эту тему, особенно через призму работы аналитика.
3. Классная мысль про то, что мы не просто выявляем требований, а именно консультируем заказчика, вместе с ним думая, не только как решить проблему, а как ее для начала просто сформулировать и измерить.
4. И вот этого современным аналитикам по моим наблюдениям не хватает, именно погружения в проблематику заказчика. Все больше ориентируются на технику решения, меньше думают о бизнесе и проблемах, о ваших общих проблемах, даже если вы работаете в рамках заказной разработки.
А вы что думаете?

Из рубрики и смешно и грустно.