Всем привет! В понедельник на открытом уроке в Отус рассказавал про ДДД. Тема для меня новая, в плане доклада, естественно. Поэтому при подготовке я отсмотрел много источников и хочу поделиться с вами.
Собственно - мой открытый урок 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 лайков и я сделаю открытый мастер класс по работе с требованиями и документами, на котором разберём несколько подходов к документам, чтобы это было вин вин для всех сторон продукта или проекта.

Всем привет! 30 лайков набежало очень быстро, значит мастер классу быть. Надо теперь выбрать удобное большинству время

Посмотрел видео про НФТ и их важность при построении будущей информационной системы. В целом, ничего существенно нового в докладе нет. Но мне врезалась в память начальная фраза: "Человек не хочет вашу информационную систему, он хочет быть счастливым". Фраза с одной стороны отсылает к методике разработки продуктов Jobs to be done, а с другой подсвечивает, что создание софта может быть лишь одним из способов удовлетворения потребности. И хороший архитектор всегда должен об этом помнить. И через эту призму автор как раз пробует подойти к НФТ и их влиянию на способ реализации и глубину архитектурной проработки.

Сегодня хочу рассказать про книгу "Визуализируй работу" Доминики Деграндис. Сразу оговорюсь, что я оцениваю книгу на 3\5.
Материал в книге в целом очень полезный и охватывает основные аспекты работы. Плюс книга содержит шаблоны и описание для практических упражнений, которые помогут сделать видимой всю вашу загрузку и загрузку вашей команды, что встречается далеко не во всех книгах.
Но почему только 3\5? Вся книга строится на 5 основных "расхитителях времени":
1. Слишком большой объем незавершенный задач
2. Неизвестные зависимости
3. Незапланированная работа
4. Конфликтующие приоритеты
5. Заброшенная работа
Автор очень красочно расписывает влияние всех 5. И вот эта красочность мне очень сильно мешала воспринимать информацию. Я понимаю, что это скорее всего мои особенности восприятия, но меня очень сильно отвлекала незапланированная работа, которая "приталась за углом с кочергой" и подобные пассажи. Плюс очень часто автор повторяет те же самые тезисы просто немного другими словами, от чего мне хочется сказать, "Да, я уже понял, давай дальше по сути". Но это реально претензии именно к подаче и оформлению.
По сути же - книга очень хорошо подталкивает к пересмотру собственного подхода к работе. Я в ходе ее прочтения таки снова слелал попытку вести задачи в виде канбан доски. Уже больше месяца практикую, главный положительный эффект - это то, что после попадания на доску задачи перестают висеть в голове расходуя оперативку. А это уже немало! Так что в целом книгу рекомендую к прочтению.

Всем хорошей среды! Ребята из WAW выложили записи и презентации докладов!
Winter Analyst weekend собрала в рекордно короткие сроки команда Летнего аналитического фестиваля, при этом спикеры подобрались очень сильные и темы были достаточно серьезные.

Всем хорошей субботы.
По результатам голосования победила суббота. Но ближайшие субботы заняты:
🗣24 и 25 мая я буду на конфе Analyst Days в Питере, где буду рассказывать, как аналитику поменять майндсет, если он хочет перейти в продуктовый менеджмент. Они солдаут, но если у вас уже есть билет - приходите пообщаться.
📉 с 30 мая по 1 июня я буду на конференции Анализ и управление в ИТ проектах, тут вроде еще билеты есть. Я буду рассказывать про бережливость в работе аналитика, в том числе, с требованиями и документами.
Так что мастер класс назначу на субботу 8 июня в 11 часов по Москве.
А чтобы он прошел еще интереснее - присылайте мне примеры своих документов, мы их разберем на мастер-классе и поймем, как их можно было сделать лучше и эффективнее.
Подробности самого МК выложу позднее.
Единственным условием участия в мастер классе будет написание честного отзыва)

Посмотрел видео из серии Design system для систем уровня youtube. Что понял?
Что я очень много еще чего не знаю. И что интернет, сетевые технологии и highload всегда найдут чем тебя удивить. Например, 6 петабайт в секунду на чтение. Да я столько нулей с трудом воображаю.
Это я все к чем. Как говорил незабвенный товарищ Саахов из Кавказской пленницы: Об этом думать никогда не рано и никому не поздно.
И я готов делиться с вами своими знаниями. Ютуб спроектировать, конечно, не помогу, но:
- Структурировать знания
- Прогнать собеседение на СА
- Разобраться с каръерной стратегией
- Построить план развития аналитика туда куда хочется
- Прокачать точечно в любом аспекте анализа и работы с командой
смогу успешно.
Так что приходите на менторинг!
Все подробности в личку

Очень толковая мысль от Дмитрия про вопросы и целеполагание. Как аналитику и продакту мне с невнятным запросом от бизнеса или заказчика приходится сталкиваться регулярно.
Эти вопросы стали для меня естественными:
Зачем мы это делаем?
Как ты видишь финальный результат?
Как ты поймешь, что получилось?
А постепенно, по мере роста доверия и взаимодействия с бизнесом, надобность в этих вопросах отпадает, потому что запросы уже приходят со всем целеполаганием.
А самая большая выгода в том, что часть запросов до нас просто не доходит, потому что бизнес сам прикидывает и понимает, что оно вроде и не особо надо или не столь приоритетно.
А какие главные вопросы у вас?

Всем привет. Ребята из Инфостарта опубликовали анонс моего выступления, а еще запись подкаста, где мы поговорили о ДДД и как его можно применить в работе аналитика