Всем привет! Сегодня на подходе видео про архитектуру кода. Да, я не только про продукты, еще немного за архитектуру шарю 😃
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. И вот этого современным аналитикам по моим наблюдениям не хватает, именно погружения в проблематику заказчика. Все больше ориентируются на технику решения, меньше думают о бизнесе и проблемах, о ваших общих проблемах, даже если вы работаете в рамках заказной разработки.
А вы что думаете?

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

Достаточно техническая статья про сравнение WebSocket и gRPC. Подойдет для тех, кто уже понимает технологию, но хочет погрузиться чуть глубже https://devby.io/blogs/posts/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket#google_vignette

Сегодня был план написать светлый и радостный пост про мастер класс у Кати, но не судьба.
Будет пост негодования, который я таки постараюсь обернуть в пользу.
Итак, у меня есть счет за рубежом. И как законопослушный гражданин (не такой как герой Батлера в одноименном фильме), я пошел на сайт налоговой, чтобы подгрузить отчет о движении средств по счету. Пришел, увидел, победил, прикрепил выписку со счета, создал завление прямо в ЛК, все удобно, все по делу, отправил и пошел по своим делам, а через несколько часов прилетел отказ в приеме.
Причем отказ по очень интересной причине (на скрине), даже я с ИТ бекграундом и опытом работы с форматами налоговой могу лишь гадать, что же я сделал не так.
И чтобы это не выглядело просто нытьем - два полезных вывода:
1. Очевидное. Делайте человеческие ошибки на фронте, любите своих пользователей, дайте им шанс понять, где они ошиблись.
2. Делайте интеграционное тестирование!!! Сервис ЛК успешно сформировал заявление. Сервис валиадции успешно отфутболил невалидное сообщение. Команды обоих сервисов - молодцы, все работает как надо. Вот только взаимодействие никто не тестировал.

P.S. если есть кто из ИТ налоговой, потыкайте палочкой в них, пожалуйста.

А теперь по делу. Мы проводим исследование потребностей аналитиков в развитии, росте и самоидентификации. Первый шаг - собираем количественные данные. Буду очень благодарен вам, моим подписчикам, если вы заполните формочку https://forms.gle/xNc7kdSTyKkmqtLj6
А тем, кто оставит свой контакт и готов будет пообщаться на тему саморазвития ждет отдельный огромный респект и пара плюшек на будущее.

Короткая вводная статья по архитектуре хранилищ данных https://habr.com/ru/articles/806347/, если не сталкивались с это темой, дает понимаение, что дальше гуглить в глубину.

На выходных ходил к Кате Лысенко на мастер класс по рискам. За деньги ходил, между прочим.
Что было:
1. Теория, без явных откровений, но очень круто и логично упакованная и мастерски поданная Катей. Типы риском, карточка риска, ROAM борд.
2. Примеры из практики и личной жизни - вот тут самая мякотка, Катя на этих историях собаку съела. Ради этого я и приходил. 🔥
3. Групповая работа. Попрактиковались пилить "выдуманный кейс" на кусочки, обсуждать его по ролям и переодевать шапочки (недооцененное умение, кстати).
4. Катя очень интересно сначала дала нам наошибаться вволю, а потом объяснила наши ошибки
4. Новый метод мозгоштурма с обратной проблемой и обратными идеями - его на 100% забрал себе в копилку методов работы и, скорее всего, упакую в отдельный пост.
5. Набил много шишек по работе с рисками, увидел новые горизонты, буду дальше копать в эту тему.

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

Если коротко резюмировать - я очень доволен и считаю что МК стоит и своих денег и, что самое важное - потраченного времени.

В "свободное" время я еще немного интересуюсь футболом. Ну как интересуюсь, матчи я уже давно не смотрел, не получается 2 часа на это выделить. Но хайлайты, результаты, аналитику я с удовольствием смотрю и анализирую. Иногда перекладывают на свою жизнь и профессиональную деятельность.
Например, сегодня я посмотрел ролик про Карло Анчелотти https://www.youtube.com/watch?v=08J1iSFUtFs. Хотя я и не люблю Мадридский Реал, который он тренирует, я не могу не признавать величие этого тренера.
И я искренне восхищаюсь его подходом к работе. Многие его называют не иначе, как Папа Карло. Для многих футболистов он действительно становится как отец, в хорошем смысле этого слова. Он готов поддержать их в сложную минуту, проявить сочувствие и понимание. Тренер признается, что он отошел от догматических тактических схем, а вместо этого постоянно ориентируется на сильные качества своих игроков, старается максимально эффективно их использовать и вместе и по отдельности. При этом, судя по всему, он является еще и крутейшим переговорщиком, раз ему удавалось не раз найти подходы к избалованным футбольным звездам и сподвигать их на новые свершения.
Благодаря ему Реал выигрывал Лигу Чемпионов в одном из слабейших своих составов за последние годы, просто на каком то сумасшедшем драйве и морально волевых усилиях. При этом он так же эффективно встраивает в этот механизм и новых\молодых игроков, обеспечивая плавную смену поколений.
Если переложить на работу любого руководитеся, то он очень грамотно работает с коллективом, знает сильные и слабые стороны сотрудников и умеет эффективно использовать первые и маскировать вторые. Лично мне не доводилось работать с настолько крутым менеджером. Безусловно были у меня крутые руководители, но чтобы человек умел сразу и в мотивацию и в эмоциональный интеллект и в построение стратегии, такого, надеюсь ПОКА, не было.
А вы встречали подобное в своей жизни?

Коллеги, всем привет! Я напоминаю, что мы проводим исследование потребностей аналитиков в развитии, росте и самоидентификации. Первый шаг - собираем количественные данные. Буду очень благодарен вам, моим подписчикам, если вы заполните формочку https://forms.gle/xNc7kdSTyKkmqtLj6

Всем привет! В понедельник на открытом уроке в Отус рассказавал про ДДД. Тема для меня новая, в плане доклада, естественно. Поэтому при подготовке я отсмотрел много источников и хочу поделиться с вами.
Собственно - мой открытый урок https://www.youtube.com/live/S4tGNWU9CqA?si=EYTpOrfy_lS1X1pt
Владимир Хориков - про самое главное в ДДД (тут еще и про анемичную и богатую модель в контекте ДДД) https://youtu.be/JOy_SNK3qj4?si=M2Hy0QMEyDHjZU6D
Катя Лысенко - про словарь, определения и семантику - https://www.youtube.com/live/RkaRSFsVGrw?si=EbOH68XRsjiW0szn
Алексей Мерсон - про подходы ДДД и про С# на русском - https://youtu.be/CR9mLGN9jh0?si=dEk8ABHPGR1Gdjut
Сергей Баранов - тут про Event Storming как про один из инструментов в рамках ДДД - https://youtu.be/NSN-NXfbEqM?si=gc9o9cmy0befF26I
Еще, конечно, статья Мартина Фаулера про ограниченный контекст https://martinfowler.com/bliki/BoundedContext.html
И три книжки - Зеленая, Красная и Синяя (синяя зашла меньше всего)

Вот такая картинка, очень жизненно, как мне кажется. Очень много видел кандидатов, которые проходят собеседования, как боженька, а вот в работе, ну так себе.
От таких людей частично спасает даже не тестовое задание, а что то липа live coding/design. Когда вы с человеком разбираете какой то кейс, причем желательно от начала (то есть бизнес требования и смыслы) до конца - то есть HLD, Компонентная архитектура и даже какие то наброски АПИ и БД.
Но как бы то ни было - навык эффективно продать себя по своей "цене" и даже немного дороже - один из главных навыков в этой жизни, причем тут речь далеко не столько про работу, а про подход к самооценке и самопозиционированию.

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

Всем привет! Посмотрел митап ребят из Nexign, честно говоря не понял, почему оно про трудности перевода от аналитика к разработчику, ну да ладно. Из 4 докладов первый и последний понравились больше всего. https://www.youtube.com/watch?v=HSEEvQO3r-E
Первый очень неплохо подсвечивает разницу в подходах к документам в стартапах и корпорациях. От ее отсутствия до задержки релизов именно из за формального отсутствия документов. Ещё раз убедился, что не хочу работать в Энтерпрайзе и писать тонны никому не нужных документов. Да, я понимаю, что там много нужных тоже, но ненужных все же больше)
Последний доклад очень неплохо подсветил проблемы избыточного документирования - эти документы по факту никто не читает. Как в той байке про студента на отлично защитившего диплом, в середине которого было 500 страниц рецептов из поваренной книги. И все равно все решается на встрече, где люди глазками и ртами обсуждают, а что же было надо сделать.
Если тема больная, то ставьте лайки. Будет 30 лайков и я сделаю открытый мастер класс по работе с требованиями и документами, на котором разберём несколько подходов к документам, чтобы это было вин вин для всех сторон продукта или проекта.