Буквально за несколько дней проглотил книжку про 45 татуировок. Как писали в комментариях к предыдущему посту, книга не даёт никакой системы или фреймворка для построения эффективной системы управления, но лично я ее не за тем и читаю.
Для меня невозможно взять чужую систему и переиспользовать, невозможно натянуть на себя чужой фреймворк, идёт огромное внутреннее сопротивление, хочется сбросить это ярмо 😁. Звучит смешно и по детски, но так оно есть.
Поэтому книги в формате коротких историй, вредных советов или вот таких принципов мне заходят на ура. Я могу сам выбрать, что принять и отрефлексировать, а что выбросить и пройти мимо и никто тебе не скажет, что ты не прав или без этого вся система не взлетит. Мне, кстати, поэтому и скрам не сильно зашёл, наверное)
Но вернусь к книге. Собственно, она стала для меня первой профессиональной книгой, которую я прочитал, именно она подтолкнула меня к тому, что не только художка может быть интересной и не вся проф литература такая скучная, как методички в универе. И мне очень понравилось то, что я смог сопоставить свои впечатления тогда и сейчас.
Конечно, восторга такого уже нет, но есть такое приятное удовольствие от того, что ты как профессионал можешь согласиться с автором или даже внутренне поспорить, причем обоснованно. И это даёт очень крутую мотивацию.
И одна татуировка у меня с тех самых пор появилась. В книге она идёт под номером два. "Читайте, осмысливайте. Тренируйте главную мышцу".
За прошедшие 5 лет я свою очень неплохо натренировал.

Всем привет! Тут нашел гайд, как праввильно делать программное обеспечение с помощью ChatGPT. Гайд короткий и поместрился в один твит, но вот взять из него кусочки и приложить к нашим реалиям проектирования систем вполне можно. https://twitter.com/paraschopra/status/1746942751839797670?utm_source=tldrnewsletter

Это реально лучшая схема BPMN из виденных мной! И самая понятная

Раскрыто истинное предназначение BPMN!

Пора возвращаться. Посмотрел интересный доклад "Долой 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. Самое неприятное - люди, которые не в терапии постепенно начинают отваливаться из твое жизни, грустно, но факт.

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

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

Всех обнял!