Пора возвращаться. Посмотрел интересный доклад "Долой SQL! Или краткий обзор мира нереляционных данных" от Максима Шаламовича и Евгения Асламова. В целом ребята сделали хорощий обзор на базы данных, что и когда использовать. Но самое ценное было, естественно в конце. Ребята оба - архитекторы, и как архитекторы они очень просили аналитиков не приходить с решением в виде схемы БД. Они настаивают на том, что работа аналитика - подготовить логическую модель предметной области, максимум информационную модель в виде диаграммы классов. И, конечно, сценарии использования данных, которые помогут разложить данные правильно.
И я не могу с ними не согласиться. С моей точки зрения - погружаться на такую глубину - работа архитектора, т.е. как правило у аналитика как правил нет нужного опыта и знаний для выбора БД и структуры хранения данных. Многие аналитики вынужденно занимаются такой проработкой, но по факту это уже работа для архитектора и за нее должны платить соответственно. https://www.youtube.com/watch?v=VxV-zwHPOfo

Достаточно занятная статья про гибкие методологии разработки. https://habr.com/ru/companies/magnus-tech/articles/788860/
Читаешь, и в целом чувствуешь боль автора. Я сам как то пытался по скраму в аутсорсе работать, было безумно больно, больше я так не хочу.
Но по прочтении статьи бросается в глаза следующее: автор не понимает и не проникся идеями гибкой управления разработкой ПО, либо специально некооторые ситуации возводит в определнную степень абсурда.

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

Про несоответствие методологии реалиям разработки - реальная боль, так бывает увы очень часто. Руководитель сказал - внедряем аджайл, послушные исполнители ответили - ЕСТЬ! Проходят треннинги, приглашают коучей, вот только руководитель в этом никак не участвует. И в целом, требует раз в месяц помимо обычных отчетов еще и отчет о внедрении аджайла! При этом сам он не готов меняться. И делегировать принятие решений в команды не готов, тогда никакого аджайла не получится, хотя утренируйся. Все будут страдать, как описывает автор. Кстати, про выбор скрама или канбана - отличное видео от Алексея Пименова https://www.youtube.com/watch?v=NCEqFh5M12M.

Насчет того, что гибкие методологии не учитывают состав и численность команд вообще смешно, особенно учитыаая, что потом идет речь про LeSS. Про то как он в России "не прижился" отлично рассказывает Артем Кротов из Мир Платформ. Про команды в 40 человек - так же странно, всегда можно попилить команды, было бы желание. Вот у нас сейчас как раз пилим команду из 20 человек на 5. Потом расскажу, как прошло.

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

Про нет метрик качества проделанной работы - тут даже комментировать нечего, чем не угодили Acceptance criteria непонятно. Хотя, учитывая, что автор их называет defenition of done, сразу есть вопросики по тому, как люди используют методологию.

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

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

Утащил у Андрея Буракова полезняшку

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

Доброго вечера! Еще немного полезного от Андрея Буракова - крутой вебинар "Брокеры сообщений для самых маленьких" 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/

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