ITMINE: о бизнес-анализе

Салют!

Пара вакансий с прицелом на выпускников ITMINE:

1. Компания Slotegrator в поиске нескольких бизнес-аналитиков, которым интересно не просто писать требования, а глубоко разбираться в системах и помогать находить лучшие решения для продукта. Вы будете работать с большим объемом интеграций, сложной продуктовой логикой и сильной командой разработчиков, архитекторов и аналитиков.
Преимущественно ищем кандидатов Senior-уровня, но также с интересом рассмотрим и Middle (если это подразумевает опыт от 4-х лет), которым близок системный подход, внимательность к деталям и желание развиваться в бизнес-анализе. 👍 Очень приветствуются отклики от выпускников ITMINE, потому что близок подход к бизнес-анализу, которому здесь обучают!

Подробнее: https://telegra.ph/Senior-Business-Analyst-09-17. Локация: удаленно / офис в Праге.
Контакты рекрутера: tg: https://t.me/ellie_vs, email: e.valts@talentgrator.com

2. Компания CELADONSOFT ищет в команду Junior BA (English - В2). Локация: Польша. Работаем через инкубатор. Если заинтересует, пишите в личные сообщения (Telegram @yuliakriv). Также предпочтительны выпускники ITMINE.

Подробнее: https://script.google.com/macros/s/AKfycbwUhFFd9lGcA_M9BQqQ2Y9dnULwUEV7-hqaZE8OxFixbJ2a2w4Rxk-lVMFKf645PkPL/exec

Интересно описанный кейс настройки процессов БА с ядром в виде Клода:

https://www.artofba.com/ru/post/claude-dlya-biznes-analiza-enterprise-case

Как думаете, огонь огненный или бомба замедленного действия? 🙂

В LI сейчас активно встречаю цикл советов по тестированию от Артема Русова. Возникла шальная идея переложить некоторые советы на работу аналитика — огонь же ведь, когда мы работаем с требованиями упреждающе, ага? Буду делиться по кусочкам и со ссылками на оригинальные посты — они сами по себе интересно читаются, хоть и коротенькие.

📌 3. Не берите на себя чужие активности.
Хех, а я уже давно писал похожую заметку тут: https://t.me/itmineba/47, https://t.me/itmineba/48. Рекомендую почитать, если вы тот самый БА, который проектирует бэдешки и чует, что что-то в жизни пошло не так.

📌 6. Согласуйте формат отчетов о дефектах с разработчиками. Для нас тут посыл еще критичнее, ибо наша документация в идеале должна быть на вес золота. Снова отправлю в архинужную заметку своего авторства о том, как не писать доки для сферической ЦА в вакууме: https://t.me/itmineba/46.

📌 11. Самый лучший способ разобраться в технологии – разработать свой сервис для автоматизации или упрощения быта для помощи себе любимому.
Я периодически советую для прокачки техбазы стать на время джун-девелопером. План нехитрый: если не знаем, с чего начать, берем веб-приложения как наиболее частый тип решений и пробуем запилить нечто базовое по любому учебнику для чайников (например, сайтец с CRUDL-менеджментом товаров). Нынче это в разы проще: дорогой чатик, проведи меня как ментор с заданиями по циклу разработки с нуля: фронтенд на простейших вещах (HTML, JS), бэкенд для обработки данных (например, на PHP), БД для хранения этих данных, хостинг и развертывание. Что мы поймем: алгоритмизацию, что такое код и как он работает, принципы работы веб-систем и их архитектуру, всякие фишки а-ля https, сертификаты, куки, домены и пр. Сириусли, с таким опытом наша коммуникация с командой может стать на порядок приятнее.

📌 15. Исчерпывающее тестирование невозможно — фундаментальный принцип тестирования.
У аналитика аналогично: невозможно проработать требования на 100%. Всегда есть как де-факто упущенные вещи (как система должна вести себя в високосный год с Сатурном в суперпозиции), так и собственная паранойя (перманентное ощущение, что мы где-то не доработали). Но: если наш арсенал — это “Глагольте, что нужно сделать”, то объем неполноты будет критичным. Если же владеем полезными техниками (”Построю-ка я модель/словарь данных”, “Пропишу сценарии юз кейсов с анализом всех негативных сценариев”, “А тут уместно ляжет диаграмма состояний, чтобы понять путь объекта данных”), мы самим инструментарием резко сокращаем неполноту и закрываем большинство гэпов.

Интересная авторская рассуждалка на тему ИИ (транскрипт доклада с NDC). Как минимум с позиции исторического экскурса увлекательно читается: https://habr.com/ru/articles/1072298/

Интересная заметка про путь в бизнес-анализе: https://habr.com/ru/companies/svoi_ru/articles/1071564/

Круто, что по тексту сквозит любовь к делу ❤️ Отдельно плюсую вот этому: “Тимлид – это тот самый учитель, который может привить тебе безграничную любовь к предмету, просто передать тебе необходимые знания, потому что это его работа, или же взрастить в тебе отвращение”. Мне, кстати, неиллюзорно повезло с таким в свое время (биг шатаут Юре Веденину).

ITMINE: о бизнес-анализе pinned «Тэкс, кому обучение/систематизация знаний/практика? 🙂 Мы нацелились на старт очередной группы по бизнес-анализу (с 26 августа) — уже 74-ая группа. Тренер я (Герман Шестеров), как обычно. Все в комплекте: ✅ Тренинги с практикой (💡с прошлой группы мы поменяли…»

Тэкс, кому обучение/систематизация знаний/практика? 🙂

Мы нацелились на старт очередной группы по бизнес-анализу (с 26 августа) — уже 74-ая группа.

Тренер я (Герман Шестеров), как обычно.

Все в комплекте:

✅ Тренинги с практикой (💡с прошлой группы мы поменяли структуру тренингов и увеличили количество часов в плане рассматриваемых тем, и пока по наблюдениям это отлично работает).

✅ Теория в классно сделанных видосах с тестами и заданиями для закрепления (💡по некоторым темам контента стало меньше с прицелом на опциональное изучение, зато стало больше по темам “Discovery” и “Работа с требованиями к решению”; плюс добавлен более детальный разбор UML Sequence и BPMN; плюс как аддон добавлен AI-промптинг и общие рекомендации по настройке AI для такого в контексте тем курса).

✅ Много самостоятельной работы, которую я проверю и разберу.

✅ Беседа на старте с обсуждением целей и ответами на вопросы; выходная беседа с проверкой и рекомендациями.

✅ Шаблоны работ, списки типовых ошибок, плюс конспект курса для заметок.

✅ Для самых мотивированных: авторская подборка материалов на углубленное изучение по каждой теме.

✅~4.5 мес. основного курса. Формат: по будним дням, 1 или 2 дня в неделю, с 19 до 22, со свободными неделями для самостоятельной работы.

✏️ Узнать больше деталей, глянуть на пример материалов и оставить заявку можно тут: https://itmine.by/baonline.
Или просто напишите нам на info@itmine.by или в Телеграм (https://t.me/itmineby) 😊

Доброго понедельника!

Немного занимательного чтива 😊

https://itmine.by/articles/tpost/tgvyd9cya1-greidi-biznes-analitikov-chto-oznachayut

Салют причастным!

Чутка интересностей на почитать за последнее время:

📌 How to Build BA Processes: Part 1 (рассуждения общего плана) и Part 2 (конкретно про настройку процессов) — от Art of BA. В целом, интересный очерк, но я лично высмотрел не так много понятных практических рекомендаций. Кстати, я ранее схожую тему описывал: что входит в планирование бизнес-анализа и как это кушать.

📌 Чем занимаются и сколько зарабатывают аналитики в IT. Обзорная статья, описывающая, какими бывают аналитики и сколько бабосиков могут загрести (по статистике Хабра). Первая часть, очевидно, для новичков.

📌 Нужна ли проектная документация в 26 году и что если ты пришел на новый проект, а там хаос и пустота? Легко читаемая статья о вечном вопросе аналитиков с классной аргументацией и рядом полезных советов (в частности по тому, как есть слона по кусочкам).

📌 Карточный LI-пост про БА: https://www.linkedin.com/posts/matthewthomasholliday_but-i-dont-have-a-technical-background-share-7492079699427217408-bSHW/. Я такие обычно либо игнорю, либо репорчу как ИИ-слоп 😈, но иногда попадаются толковые советы. Тут речь про некоторые иррациональные страхи аналитиков, и местами весьма в точку.

Наткнулся на книжку “Прайм-эра аналитика: для тех, кто в теме, и тех, кто только заходит”. Автор пока делится ей бесплатно, если плюсик ему отгрузить: https://www.linkedin.com/posts/kan1y_прайм-эра-аналитика-ugcPost-7482694941278638080-XOQH

- Главное — подача: легко и интересно читать, плюс живые примеры из практики. Поймал себя на том, что сложно оторваться и хочется проштудировать все до конца (не помню, когда в последний раз такое ощущал от книги на тему БА).
- Лаконично и круто описаны нужные для СА (ну или не лишние для БА) технические и смежные области: тестирование, БД/SQL, интеграции, архитектура, среды.
- Много полезных второстепенных тем: продуктивность, вайб-прототипы, векторы развития, собеседования и т. п.
- Печалька, но мало или нет базы по ряду ключевых моментов для БА: виды требований (сильно упрощено и неполно), извлечение требований (мало техник, советов, хитростей), документирование (имхо не позволяет построить непротиворечивую картинку подходов в голове), моделирование (выборка автора у меня не сильно отзывается), discovery (очень мало), работа с НФТ (аналогично). Надо понимать, что это не Вигерс в плане глубины и системности погружения в важные для БА темы.

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

Привет всем!

Пост-напоминалка о самых полезных материалах в канале/на сайте. Интересного нынче на горизонте маловато, поэтому вдруг да пригодится.

✔️ Типовые ошибки аналитика (практические советы в формате небольших заметок): https://docs.google.com/spreadsheets/d/1R4yYvW9WC-cD21JgThQCg3So0SK1os2xkAOWd-rTZlw/

✔️ Что такое требования и какими они бывают (большой лонгрид с примерами): https://t.me/itmineba/178
Пробные видосы на ту же тему: https://www.youtube.com/watch?v=Xfmid0muueo, https://youtu.be/4hU3CAkFJsQ?si=nag13XWVSIl-Awxn

✔️ “Всякие полезные советы”:
📌 Требования к внешним интерфейсам: https://t.me/itmineba/180 и вниз
📌 User Stories: https://t.me/itmineba/183 и вниз
📌 Cкоуп: https://t.me/itmineba/191 и вниз
📌 Письма: https://t.me/itmineba/195 и вниз
📌 Юз кейсы: https://t.me/itmineba/201 и вниз, https://t.me/itmineba/204 и вниз, https://t.me/itmineba/207 и вниз

✔️ Чеклист и примеры нефункциональных требований: https://t.me/itmineba/141

✔️ Гайд по юз кейсам:
📌 https://itmine.by/articles/tpost/dmdp3z0rk1-use-cases-yuz-keisi-varianti-ispolzovani
📌 https://itmine.by/articles/tpost/fpvuzdk8r1-use-cases-yuz-keisi-varianti-ispolzovani

✔️ Impact Map: https://t.me/itmineba/123

✔️ User Story Map: https://t.me/itmineba/125

✔️ CRUDL: https://itmine.by/articles/tpost/d5vyk97az1-crudl-tehniki-ba

✔️ Планирование бизнес-анализа (на пальцах о сложном): https://t.me/itmineba/224

✔️ Работа с AS IS: https://t.me/itmineba/168

✔️ Определение TO BE: https://t.me/itmineba/171

✔️ Стратегический анализ / discovery (+ Vision and Scope): https://t.me/itmineba/142

✔️ Описание функциональных требований через UI: https://itmine.by/articles/tpost/8tch99upd1-funktsionalnie-trebovaniya-cherez-trebov

✔️ Про всякие там рисуночки:
📌 Про UML в целом: https://t.me/itmineba/151
📌 Use Case Diagram: https://t.me/itmineba/152
📌 Class Diagram: https://t.me/itmineba/153
📌 Модель предметной области и логическая модель данных: https://itmine.by/articles/tpost/j9acle3jd1-model-predmetnoi-oblasti-i-logicheskaya
📌 Activity Diagram: https://t.me/itmineba/155
📌 State Machine Diagram: https://t.me/itmineba/157
📌 Sequence Diagram: https://t.me/itmineba/159
📌 Всякие разные диаграммы: https://t.me/itmineba/215

✔️ Грани аналитика:
📌 IT БA — это… IT: http://itmine.by/articles/tpost/k90kjs6sa1-it-ba-eto-it
📌 IT БА — это… анализ: https://itmine.by/articles/tpost/xkapfmlyu1-it-ba-eto-analiz

✔️ Agile VS Waterfall для БА: https://itmine.by/articles/tpost/rmx55e63k1-agile-vs-waterfall-spetsifiki-raboti-ana

Вот тут я ныл о том , как не нужно читать BABOK: https://t.me/itmineba/320.

Автор жжет дальше, и теперь уже я неиллюзорно пугаюсь, что в глаза долблюсь: https://habr.com/ru/companies/bcs_company/articles/1042548/

Подсобите, где та самая версия BABOK, рожающая такое? Может, аддон какой выходил?

Согласно глоссарию BABOK v3.0:
«Потребность — это проблема, возможность или ограничение, представляющие потенциальную ценность для заинтересованной стороны».
Важная деталь, которую легко упустить: BABOK намеренно использует три равнозначных варианта — проблема, возможность, ограничение.

Ну вот же глоссарий, не?
need: A problem or opportunity to be addressed
business need: A problem or opportunity of strategic or tactical importance to be addressed.

И дальше:
Чтобы не заблудиться в лабиринте «желаний» заказчика, BABOK предлагает разделять потребности на 4 уровня.
Бизнес-потребность (Business Need): Глобальная цель компании (???)
Потребность заинтересованной стороны (Stakeholder Need): Что нужно конкретным группам (ЗСт), чтобы бизнес-цель была достигнута.
Потребность в решении (Solution Need): Функциональные и нефункциональные требования к системе.
Переходная потребность (Transition Need): То, о чем забывают в 80% случаев! Что нужно, чтобы перейти от старого к новому?

Так все смешано в кучку, что ахтунг. Переходная потребность, потребность в решении. Это какой-то п...ц, товарищи, не?

Либо автор вообще не делает разницы между потребностями и требованиями, либо где-то живет такой вот вольный перевод, либо (что сильно вероятно) — это то, как ИИ прочел БАБОК. А может я не дочитал — коллеги, нужна помощь разбирающихся 🙊

Еще одна подборочка годного — сегодня с фокусом на Хабр.

Рекап прошедшего ЛАФа от Максима Цепкова (https://habr.com/ru/articles/1048838/) — чтобы понять, о чем говорят аналитики на конфах. Читать местами больно, ибо не до конца переваренный поток сознания, но интересно. Акцент, естественно, на ИИ.

Как я использую AI в работе продакт-оунера в EXANTE: от ресёрча до релиза (https://habr.com/ru/articles/1046443/) — интересная сборка личного опыта для дискавери и работы с требованиями с помощью Скайнета.

Порядок против хаоса: как не проиграть в битве за понятную документацию? (https://habr.com/ru/companies/rtlabs/articles/1048270/) — хороший опус о том, как делать юзабельную документацию. Если продраться через долгое вступление и закрыть глаза на ГОСТы, есть классные советы, полезные любому аналитику.

P. S. Кейс настройки личного ИИ-помощника на десктопе (https://t.me/psyreq/268) — возможно, наведет на мысли поиграться. От себя вкину, что это весело и местами действительно творится магия, но бесплатная игра заканчивается слишком уж быстро. Плюс будьте аккуратны с разрешениями — нужно быть морально готовым переустанавливать поломанный Джарвисом софт и искать удаленные данные.

Кстати, есть у кого успешные кейсы долгого активного юзания подобного умного помощника? Поделитесь?

Салют!

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

Из разработчика в системные аналитики: практический путь в профессию (https://habr.com/ru/articles/1040758/) — статья для начинающих о том, кто такие аналитики. Не обращаем внимание на бизнес vs системный анализ — все равно их усердно смешивают в кашу.

Ящик с AI-инструментами на май 2026 (https://t.me/psyreq/238) — собственно, описание такого ящика для аналитика. Можно ведрами черпать опыт автора и брать за основу.

Story Splitting: How To Split User Stories So Teams Can Finish (https://www.mountaingoatsoftware.com/agile/user-stories/story-splitting-how-to-split-user-stories-so-teams-can-finish) — Mike Cohn о декомпозиции историй (если не знаете, это серьезный известный дядька и не последний человек в теме аджайла и скрама). Ничего внезапного вы тут не найдете, но в кучу собрано много классных советов. Читать, если вы все еще делите US на бэкенд и фронтенд.

Кстати, skill для AI от него же для проверки US: https://www.mountaingoatsoftware.com/blog/story-critic-skill-better-backlog-items

Пара любопытных кейсов об “очевидных” требованиях (https://t.me/ba_and_sa/2703, https://t.me/ba_and_sa/2713). Имхо тут тема не соответствует наполнению — например, в первом случае это банальный фейл не-проработки требований. Второе же — отличный пример того, насколько полезно получать доступ к телу реальных юзеров.

Art of BA провели исследование аналитиков Украины и Польши: https://www.artofba.com/ba-survey-2026. Очень интересный и детальный ресерч.

Ключевые полезные моменты, если лень изучать оригинал:

- 470 респондентов (375 - Украина, 95 - Польша, остальные непонятно).
- Agile, хоть и доминирует, но занимает не настолько крупную часть, как ожидалось: 18% - тру аджайл, 31% - типа аджайл, 36% - непонятная фигня, где все намешано.
- В 31% случаев в компаниях приняты стандарты БА, которым участники следуют. Это радует, т. к. казалось, что должно быть печальнее. В 39% в компаниях есть шаблоны артефактов, в 52% - свои собственные шаблоны у аналитиков.
- Тайтлы: 45% - БА, 17% - БА + СА, 11% - БА + PO. Неясно, среди кого проводился опрос, но если по всем, у кого есть слово “аналитик”, то это подкрепление релевантности БА (no matter сколько ни кричали бы некоторые, что БА вымерли и кроме СА нет пути в счастье… хотя от рынка, конечно, зависит).
- БА с опытом < 1 года - 2.6 %. Это печально. Интересно, как они дальше будут появляться. Вероятно, сразу рождаться в миддлы, хотя это априори недостижимо.
- 83% не имеют сертификаций.
- 57% так или иначе участвуют в стратегическом анализе. Это безмерно радует - отходим от бездумных сториписаний (если предполагать, что участники верно эту область трактуют).
- Какие виды требований документируют: 84% - ФТ, 77% - БТ (огонь!), 62% - НФТ (тоже огонь!), 47% - UI, 47% - бизнес-правила, 31% - модели данных (маловато, но на это может влиять наличие систем без данных).
- Техники: 82% - User Stories, 76% - прототипы UI, 66% - юз кейсы (они еще очень даже живы!).
- Ключевые НФТ, с которыми работают те, кто трогает: security (82%), performance (79%), usability (71%).
- Сложности с обеспечением качеств требований: 35% - атомарность (в чем тут сложность? 🙂), 35% - полнота, 29% - краткость/точность
- AI: 44% пользуют регулярно, 36% - иногда. 42% считают, что это относительно полезно (именно с таким оттенком), 36% - нейтральны к эффекту от AI. 5% считают, что AI заменит аналитиков в будущем. 45% активно осваивают AI для работы. Gemini - у 50%, Copilot - 34%, прочие - небольшие доли (что интересно, Claude нет в списке).
- Для чего используется AI: черновики документации (67%), поиск информации (66%), подготовка к коммуникации (письма, протоколы) (58%), анализ документов (52%).
- Что не нравится в AI: глюки (74%), вопросы конфиденциальности (59%).
- Актуальные проектные проблемы: меняющиеся цели/требования - 52%, скрытые/неполные требования - 44%, времени не хватает - 40%, недостаточная валидация требований со стороны заказчика - 38%.
- На что они влияют: неверные проектные оценки (47%), превышения бюджетов/эффортов (41%), переделки (31%), разрыв между потребностями юзеров и функционалом (23%).

Видео с разбором вакансий jun, mid и senior: https://youtu.be/Gh5667GJnM0?si=RHGd_IegxsO1cA7e. В деталях я бы там по отдельным вещам подискутировал, но в целом рекомендую глянуть, если планируете путь в БА.

Кстати, еще из статьи, но уже вопрос на обсуждение: там пример RACI, и в ней Product Owner / Заказчик (да, два в одном) стоит как A для задач “Сбор и уточнение требований” и “Проектирование”. Как считаете, это ок и верна ли трактовка буквочки A?

Вот тут вышла статья для новичков: Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?»
В целом, она неплоха, хоть и просто копипастит BABOK. Однако копипастит местами как-то странно. Вкину субъективную критику — пригодится и для лучшего понимания теории (например, при подготовке к получению IIBA-регалий), и местами даже для работы.

📍Вот так автор описывает контекст (как одно из шести понятий модели BACCM из BABOK): Как новое решение повлияет на дальнейшую работу?

Ок, это упрощение, но оно нехило искажает смысл. BABOK гласит так (тут и далее будет собственный перевод, ибо, простите, не доверяю “официальным”): Обстоятельства, которые влияют на изменение или на которые оно влияет, либо которые углубляют понимание изменения. Т. е.: детали процессов и участников AS IS, часовые пояса и коммуникационные предпочтения стейкхолдеров, погода, законы — все это примеры контекста. Сравниваем с определением выше 🤷🏼 Но пока это сугубо теория, т. к. мы с вами не ведем отдельный документ под названием Контекст.

Далее автор говорит, мол, давайте разберем понятие Stakeholder, потому что все остальные понятия начинаются с него. Например, Контекст — это кто сейчас влияет и кто будет влиять на процесс? Не понимаю, как это работает, ибо выше автор давал иное определение, но whatever.

📍Автор дает определение Stakeholder: Согласно BABOK 3.0: «Заинтересованная сторона (часто используется сокращенное значение — ЗСт) — это физическое лицо или группа лиц, с которыми бизнес-аналитик, вероятно, будет взаимодействовать прямо или косвенно. Любая заинтересованная сторона может быть источником требований, допущений или ограничений».

Не знаю, откуда это взято, причем в кавычках как цитата. BABOK значительно более абстрактен: Группа или человек, имеющие отношение к изменению, потребности или решению. И это так-то важно. Как мы как БА определим, с кем будем прямо или косвенно взаимодействовать, когда занимаемся идентификацией стейкхолдеров? Нам вначале бы их как-то определить вообще, а потом уже думать, кто достоин с нами общаться.

Я рекомендую брать такое понимание (и это уже не из BABOK, а смесь понятий PMBOK и BABOK): Те (группа, человек, организация), кто могут повлиять на или на кого может повлиять изменение/решение/потребность. Кстати, что интересно, PMBOK еще добавляет сюда “или думают, что на них повлияет…”

Тут же я периодически привожу такой пример: Мы внедряем робот-пылесос в компанию и понимаем, что по итогу компания уволит текущую уборщицу. Она стейкхолдер? Конечно, ведь на нее повлияет изменение. Мы с ней будем взаимодействовать, как автор пишет выше? Аналитик вполне может такое сразу отмести, ибо а зачем — утешать ее как-то? 😢 Но это неверно. Ее нужно учесть, осмыслить влияние изменения на нее и лишь затем уже уделить хоть немного внимания вместе с заказчиком тому, какие работы с ней стоит провести кому бы то ни было из ЗЛ (вероятно, очертить ей перспективы заранее, продумать плюшки и пр.)

📍Мы в компании… разработали и поддерживаем матрицу коммуникаций — это матрица, в которой отражаются подразделения и заинтересованные стороны для выявления/обсуждения/согласования требований и ограничений при разработке, описании и автоматизации бизнес процессов.

На всякий случай: не стоит путать табличку, отражающую стейкхолдеров и их анализ (отношение, влияние и прочие детали), и матрицу коммуникаций. Матрица коммуникаций (хотя я чаще слышал и использую “план коммуникаций”) показывает то, какую информацию кому из ЗЛ когда и каким способом нужно доносить. Уборщица в такой матрице, например, едва ли будет. Если только вы не делаете эту матрицу для себя в контексте проекта, а готовите ее для всего изменения и с учетом коммуникаций всех ЗЛ между собой, но давайте спустимся на землю. Кстати, с удивлением не нашел такую технику в BABOK v3 (только ее упоминание). Знатоки, подскажите — плохо искал?

В общем, штука эта временами довольно полезна, поэтому ниже скину пример в виде скрина от того же IIBA.

ITMINE: о бизнес-анализе pinned «Друзья! А у нас в планах старт новой группы (Бизнес-анализ в IT, онлайн, с 28 апреля) 🧑‍🎓 Тренером буду все так же я (Герман Шестеров). Общая комплектация полезняшек остается той же: ✅ Тренинги с фокусом на практику. ✅ Теория в видео-формате с тестами…»