А если серьезно, что тема очень актуальная, ведь проекты медленно, но все же сдают позиции, оставляя за собой очень формальные области или типовые проекты, в которых далеко не все интересно.
В продукта работать очень круто, но крутые продуктовые компании типа Amazon или Google в своем штате не имеют аналитиков, там наши функции размазаны по продакту, разработчиками, архитекторам и тестировщикам (эти ребята, кстати, очень к нам близки)
Вот и получается, что сейчас для аналитиков переходный период, в рамках которого им надо понять, куда двигаться в этом динамичном продуктовом мире.
Лично я вижу два основных трека - в бизнес, то есть в продакты или в технику, то есть в архитекторы. И то и то для нас и близко и далеко. Продакт - это очень про деньги, мы не все так умеем, а архитектор - это про разработку, надо не только писать код, но и знать все необходимые паттерны разработки, алгоритмы и структуры данных и много чего еще.

Кстати, приходите послушать Дмитрия Безуглого, который так же расскажет примерно про это: https://www.youtube.com/watch?v=cnPvfP_B_D0

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

Прочитал интересную статью от ребят из SimbirSoft про то, как выявлять и собирать требования на удаленке.
В основном, конечно. советы достаточно понятные, но материал хорошо структурирован и если вы только учитесь работать с удаленным заказчиком, то материал будет очень полезен.
А часть советов, как например, формирование грамотной повестки, умение следовать ей и держать других участников встречи в теме встрече, будут полезны при любом общении с заказчиком. #requirements #remote #article

А вот и анонс моего доклада на Analyst Marathon подъехал. Приходите послушать.

Друзья! До старта конференции AM#5 остался месяц, и мы начинаем представлять вам наших замечательных спикеров.

…Когда я искал материал для прошлой конференции - познакомился с Иннокентием Бодровым. Мы очень быстро нашли общий язык, так как представленный им материал был «на уровне», и оставалось только немного переработать его под формат конференции. Однако, вся программа конференции на тот момент уже была сформирована, и я смог выделить Иннокентию только «короткий слот». Но это же не проблема для профессионала – он отлично осветил важную тему даже в коротком докладе! Исправляем ситуацию и предоставляем возможность Иннокентию Бодрову открыть конференцию, на этот раз уже с полноценным по времени докладом:

«Аналитик в Agile. Как задумывалось — и как сейчас работать»

У Иннокентия большой опыт работы аналитиком в разных доменах: начинал с ERP, работал в FinTech и Telecom компаниях. На собственном опыте испытал, каково это — работать в огромных корпорациях и в небольших стартапах. Поэтому речь пойдет именно о том, как аналитику эффективно действовать в рамках гибких методологий — в зависимости от типа и размера организации. Иннокентий обоснует и продемонстрирует разные варианты организации работы аналитика с командой, подтвердит эффективность этих подходов кейсами из собственного опыта. А ещё поделится идеями - как нужно профессионально расти или двигаться аналитику, чтобы не потерять актуальность в быстром мире гибких методологий.

Присоединяйтесь к Аналитическому марафону#5, берите на вооружение глубоко осмысленный опыт профессионалов!
Доступ здесь: https://bit.ly/2ZxZfGP

Интересный взгляд та то, что далеко не все возможности сконцентрированы в цифровом мире, а пожилое население тоже может быть хорошей ЦА

Сегодня будет митап для аналитиков от Альфа банка. Будет и онлайн и оффлайн в московском офисе Альфы. Москвичи - хороший шанс на нетворкинг, а еще обещают и закрытую оффлайн часть мероприятия

ANALYZEIT#5 — митап от сообщества аналитиков Alfa Digital
Пройдёт 7 октября 2021 в 19:00 в Москве в двух форматах: онлайн и офлайн.
Регистрация и адженда тут

Думаю тут заглянуть на митап живьем, редко такие мероприятия в последнее время проводят оффлайн.

​​🔥 Интереснейший митап для системных и бизнес аналитиков!

📌 Подробнее о мероприятии:
Уже долгое время FinTech является одним из самых бурно развивающихся доменов. Банки окончательно перебираются в онлайн и всеми силами стараются обеспечить себе конкурентное преимущество, предложив своим клиентам самые передовые IT-решения. И, разумеется, подобные проекты просто не могут обойтись без бизнес- и системных аналитиков. Именно для них и предназначается наш митап!

Эксперты из Andersen, Альфа-Банк и Deutsche Bank TechCentre расскажут вам о развитии проектов, о работе банковских SA и использовании интеграций.
Будет полезно!

👉🏻 Когда: Ждём вас 27 октября, в 19.00 (GMT +3)

🏛 Где: Санкт-Петербург, БЦ Ренессанс холл, Владимирский пр. д. 23, 8 этаж
Нетворкинг, вопросы спикерам, возможность обсудить доклады с комьюнити - это стоит того, чтобы выбраться из дома!

🖍 Как записаться: Для участия в митапе заполните форму:
https://forms.gle/6djkhFmCcDVFeKox6

🗣 Спикеры:
👉🏻 Андрей Абразовский
Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.

👉🏻 Алексей Лобзов
Альфа-Банк
Три факта о работе системного аналитика в Банке

👉🏻 Олег Кармалеев
Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.

Google Docs
SA/BA meetup 27 октября
27.10.21, 19.00 (GMT+3)
Санкт-Петербург Владимирский пр. 23, БЦ Ренессанс холл, 8 этаж
офис международной ИТ-компании Andersen

SA & BA Meetup by Andersenlab.com
Митап пройдет в нашем офисе в Санкт-Петербурге (РФ). А так же будет транслироваться в онлайн

Смог на выходных выделить время на чтение статей. Прочитал небольшую статью Дениса Гобова про термины в BABOK 3. Денис разобрал 4 термина: Требование, Дизайн, Бизнес-аналитическая информация и Архитектура требований. Вышло емко и интересно, рекомендую к прочтению. Если кто то видел вторую и последующие части - пишите в комментарии
#article #BABOK #requirements

И еще раз всем привет!
Последнее время, в ходе работы в продуктовых командах обратил внимание, что многие недооценивают важность и плюсы грумминга бэклога.
Грумминг или в новом Scrum Guide- Product Backlog Refinement (PBR), это один из ритуалов в работе с бэклогом продукта и подготовке к планированию спринта. Многие команды воспринимают грумминг, как встречу лидов, где они планируют спринта, а на планировании просто уже распределяют задачи на команду.
Но на самом деле грумминг - это фиксация того самого этапа Дизайна, отсутствие которого так беспокоит многих сторонних водопадной модели. Результатом Грумминга являются истории, который четко соответствуют критериям готовности к разработке (Definition of Ready) и перечень вопросов по тем историям, которые еще не готовы пойти в работу.
Подготовка у Груммингу - это по сути основная часть аналитической работы, с которой сталкиваюсь я, как член команды разработки. И от качества моей работы напрямую зависит, сколько времени займет грумминг даже одной истории. Например, могу сказать, что когда я не нашел двух часов на проработку задачи перед груммингом, грумминг вылился в эти же два дополнительных часа, но только уже для 9 человек, итого вместо двух - восемнадцать рабочих часов. Этот момент стал для меня уроком, теперь максимум проработки делаем до грумминга, иногда привлекая других членов команды или архитектора для детальной проработки.
Итак, как мы готовим историю к груммингу:
1. Продакт приносит фичу, как правило эпик, поэтому первая часть - это обсудить все с продактом, сформировать список открытых вопросов по бизнес-смыслам, понять, что нужно бизнесу. Дальше мы делим этот список по тем стейкхолдерам, которые могут нам помочь, и решаем кто из нас к какому стейкхолдеру пойдет. Определяем, как правило, по уровню отношений со стейкхолдерами и по направлению бизнеса. Например, сейчас у меня сложились хорошие отношения с нашими департаментом финансов и все истории, касающиеся финансов или бухгалтерии, прорабатываю я (да-да, занудство с проводками - наш конёк).
2. Общаемся с архитектором, чтобы понять, может ли история затронуть бизнес-критичные сервисы или сервисы других команд. Понимаем, нужно ли нам создавать новые сервисы и куда мы это будем размещать физически - на отдельную машину, в отдельный контейнер, думаем про нагрузку, балансировку и т.п. Обычно на выходе есть набор НФТ и компонентов + понимание, какие технические таски могут понадобиться.
3. Опционально. Если история затрагивает несколько команд и добавляет значимые изменения, то мы собираем архитектурный комитет со всеми заинтересованными командами, техническим и корпоративным архитекторами. На комитете обсуждаем, какая команда когда и что сможет реализовать и как это будет аффектить на остальных. На выходе это обычно роад мап по реализации всей истории в продуктиве.
4. Дальше начинаемся много "бумажной работы". Надо описать все стори, на которые побили фичу, подготовить по ним критерии приемки, описать бизнес-правили, которые влияют на истории, описать основные кейсы, которые будем покрывать, на основании кейсов тестировщики потом подготовят свои тестовые кейсы для проверки фичи и для включения в регресс. Это основное время, которое тратится на подготовку к груммингу.
5. Еще раз по всему пройтись с продактом, проверить, что все сходится и ничего не упустили.
6. И вот теперь можно рассказать всей команде, что же нам нужно будет сделать. Тут, как правило, возникает еще целая пачка вопросов, которые мы с продактом и архитектором пропустили. И это нормально, ради этого грумминг и проводится. Наша задача - подготовить для команды бизнес-смыслы и наброски решения. Если мы хорошо подготовились к груммингу, то на все вопросы мы можем сразу найти ответы и у нас с командой зафиксируется правильно понимание того, что нужно сделать, сформируется список тасок для реализации истории и оценка по реализации, влезем мы вообще в один спринт или нет.

У нас достаточно большие истории и, как правило, в спринт мы делаем от 2 до 5 историй, поэтому вопрос, а влезет ли в спринт для нас актуален. Иногда приходится выделять самостоятельные истории и выносить их дальше.
Описанный выше процесс у нас в стадии отладки, полируем, вносим небольшие корректировки, но он уже показал себя, как достаточно эффективный и мы планируем развивать его дальше.
Если у вас эта тема отозвалась или у вас процесс построен совсем по-другому, добро пожаловать в комментарии - обсудим.
P.S. Спасибо автору вот это статьи про грумминг историй, за то что натолкнул меня на эти мысли!

Всем привет! Прочитал интересный гайд по User stories. Если это пока ещё сложно для вас, то рекомендую почитать https://habr.com/ru/post/577420/
#article #userstory

Всем привет. Очень короткая статья про Definition of done. Простыми словами описываются три основных критерия, по сути, реальные DoD являются производными от них, время чтения 3 минуты.
#userstory #article