https://www.youtube.com/watch?v=RkaRSFsVGrw заскакивайте на эфир к Кате Лысенко

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

Всем привет! Новый года я начал просто потрясающе - свалился с лютующим в Португалии гриппом А, кашлем и температурой под 39. Зато появилось время немного притормозить, подумать, переосмыслить.
И первое решение - это все таки начать делать более авторский контент. Да, вначале я буду опираться на чужие материалы, но не как на основу для обзора, а как на подводку к какой то своей мысли, которая мне так или иначе отозвалась. Поэтому я буду очень благодарен вам за любую обратную связь, особенно если она будет конструктивной. Если вам не понравился пост - не стесняйтесь ставить какашку, а если при этом вы еще и напишите, что вам не понравилось - форма или содержание, будет вообще круто.

И начну с небольшого рассуждения про книги. Думаю, многие видели, что я искренне считаю того же Вигерса сильно устаревшим и вообще не очень полезным современному аналитику, особенно начинающему. Кто то говорит, что он помогает систематизировать знания. Возможно, лично мне не помог, знания лучше не стали, но, может быть - дело во мне.
Я потратил на Вигерса чертову тучу времени и нервов, делал несколько подходов, чтобы его прочитать, наконец осилил целиком, через насилие над собой и тут меня постигло разочарование, описанное выше, знаний не прибавилось, система не построилась. Сложно, долго, нудно.
И есть обратный пример - я точно так же заставлял читать себя Коберна про Use Case,но там мне реально открылась новая вселенная и понимание, что все то, что в банках называют Use Case это дико извращенное понимание методологии и от такого ее использования Коберн открещивался. Я про до жути детализированные Use Case до вызовов API, которые еще иногда и бизнесу носят на утверждение. Там мне истина открылась где то через 50 страниц.
И вот сейчас я смог это отрефлексировать и перестать себя заставлять читать книгу, если не получается ее читать хоть по немного и если за первые 50 страниц ты не понял, зачем оно тебе.
Вот буквально вчера принял решение прекратить мучить "Как пасти котов", которую многие считают очень полезной для организации работы команды разработки, а я же все таки теперь продакт менеджер 😁, с разработкой надо общаться немного по-другому. Но она тоже выглядит устаревшей и насквозь пронизана тем - что вы больше не программист, не надо писать код. За 60 страниц я не увлекся. Скажу сразу, что тот же Скрам, что от Сазерленда, что от Швабера проглотил за несколько дней,хотя написаны они примерно в те же года, так что я не то чтобы не уважаю старшых..
И принял очень правильное на мой взгляд решение - перечитать "45 татуировок менеджера", с которой началось мое увлечение профессиональной литературой. И за два дня, больной и с температурой прочитал 200 страниц. Попутно рефлексируя каждую татуировку. Но это уже в следующих постах.
https://www.labirint.ru/books/872445/ (никакой рекламы, просто первая ссылка)

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

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

***

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