Про_БА

Публикации января
#что_почитать #навигация

В январе к нам присоединилось рекордное количество подписчиков за все четыре месяца существования этого канала. На этом фоне я стала чувствовать все больше ответственности за каждый пост и временами готовить материал и редактировать текст дольше, чем свой самый первый текст. А собиралась научиться составлять тексты быстро 🙈 По-прежнему искренне радуюсь всем реакциям и комментариям! Спасибо за интерес тем, кто читает канал уже несколько месяцев, и приветствую всех, кто присоединился недавно ! 👋

Собрала здесь самые читаемые материалы января и ссылки на другие навигационные дайджесты.

📍Что такое прототипы и какими они бывают?
📍Про ошибки при проведении интервью с пользователями
📍Кейс с событиями-таймерами BPMN. Сколько нужно времени, чтобы проснуться и выпить кофе?
📍Способы использования BPMN
📍Подборка статей про дизайн-мышление

🌱Материалы декабря’23 и новогодние пожелания
🌱Навигация по материалам сентября-ноября’23

Стартовые события, сквозные процессы, process mining...
#кейс #что_почитать

Давайте обсудим ответы на вопросы из прошлого поста...

1. Стартовое событие BPMN должно иметь хотя бы один исходящий поток управления
📍В BPMN стартовое событие не является обязательным, его наличие на диаграмме носит рекомендательный характер. Если вы моделируете исполняемый процесс, то среда исполнения может иметь свои ограничения. Например, по tutorial к Camunda стартовое событие является обязательным.
📍Стартовых событий может быть несколько, признак хорошего стиля не злоупотреблять этим, чтобы не усложнять понимание модели.
📍В некоторых инструментах моделирования (например, в Business Studio) инициирующие процесс события – зеленые, но классическая диаграмма черно-белая.
📍В любом контексте применения будет верным, что стартовое событие обязательно должно иметь хотя бы один исходящий поток управления.

2. «От начала до конца рабочего дня» не является сквозным процессом
Свод знаний по управлению бизнес-процессами BPM CBOK 3.0 определяет процесс как полную совокупность действий, приводящую к достижению ценного результата или предоставлению услуги. Подходит ваш обычный рабочий день под это описание? 🤔
В 2022м вышел BPM CBOK 4.0, но у меня все лежит 3.0 в бумажной версии и оказалось проще туда заглянуть.

3. Технология Process Mining НЕ требует наличия в логе информационной системы идентификатора бизнес-объекта
📍В Process Mining отслеживаются экземпляры процесса и исполнение задач в этом экземпляре. Экземпляр процесса — конкретный случай исполнения процесса. В межпроцессном взаимодействии с точки зрения запуска одного процесса другим «взаимодействуют не абстрактные графические схемы, а конкретные экземпляры различных процессов» (из книги Моделирование бизнес-процессов в нотации BPMN).
Например, для процесса доставки посылок отслеживается конкретное отправление, которое должно пройти через все системы с неизменным идентификатором. Отправление может проходить задачи вида «Создать отправление», «Передать на сортировочный пункт», «Доставить в пункт выдачи» и т. п.
📍Идентификатором экземпляра процесса может служить ID одного из объектов в модели данных, если именно этот объект проходит все задачи процесса с неизменным идентификатором. Например, ID заявки в процессе обработки заявок. Ответ «в логе должен быть идентификатор бизнес-объекта» близок к правильному, но не является однозначным. ID не всякого объекта указывает на экземпляр процесса.
📍Таким образом для майнинга процессов требуется наличие в логе
• идентификатора экземпляра процесса
• даты и времени события
• названия задачи
О майнинге процессов можно еще почитать в статье тут и в материалах из подборки на нашем канале

Системная практика управления бизнес-процессами. Впечатления
#конференции

26 января подключалась к онлайн конференции по процессному управлению. Это ежегодное мероприятие при поддержке российской Ассоциации профессионалов управления бизнес-процессами (ABPMP). Как это часто бывает с онлайн мероприятиями в рабочее время, я много пропустила и теперь жду публикации записей, чтобы наверстать упущенное. Поделюсь первыми впечатлениями.

Целевая аудитория — процессные аналитики, методологи, руководители в сфере оптимизации бизнес-процессов. Обсуждаются методические подходы и инструменты управления бизнес-процессами. Формат общения отличается от ИТ-конференций. Здесь традиционно много представителей госсектора и промышленного сектора. Чувствуете, как у меня немного слог изменился и появились «ассоциация профессионалов», «сектор», «методические подходы»? ☺️

Из того, что запомнилось:

📌Доклад об автоматизации сквозных процессов в управлении финансовыми потоками. Речь шла о процессах движения финансов, которые в реальности неразрывно связаны с ограничениями производства и логистики. Кроме того вовлечены управленческий учёт, казначейство и бюджетирование. Типовое проектирование шагов «от заказа до наличных» (O2C) или «от закупки до оплаты» (P2P) не покрывает всех особенностей финансовых потоков с их планированием и учетом.

📌Доклад о создании процессного офиса в Комитете по информатизации и связи (КИС) Правительства Санкт-Петербурга. Подробный последовательный доклад по привычной добротной схеме: Цели — Шаги — Инструменты — Планы на будущее. Шаги — информировать, обучить, поставить Business Studio, регламентировать, создать библиотеку процессов. Инструменты — тренинги, общий процессный словарь, чек-листы с элементами диаграмм и правилами моделирования. Мне здесь запомнился важный шаг в описании бизнес-процесса — валидация диаграммы приглашенным внешним экспертом-методологом. На примерах были диаграммы в сотни действий, но и при меньших объёмах этот этап мне показался важным.

📌Президент российского ABPMP Анатолий Белайчук рассказал о сертификации специалистов по процессному управлению. Речь о сертификации по профстандарту «Специалист по процессному управлению» (стандарт 07.00). Есть 4 разных экзамена, разделенные на два уровня. Уровень 6: Специалист по регламентации процессов, процессный аналитик. Уровень 7: Процессный методолог, процессный архитектор. Обратите внимание, что здесь архитекторы и методологи на одном уровне. Сертификат действителен три года, потом нужно подтверждать. Входные требования — профильное высшее образование или доп. обучение управлению процессами, подтвержденный опыт работы в регламентации процессов или управлении процессами.
Экзамены включают теоретическую и практическую части. Теоретическая часть состоит из 80ти вопросов, на которые нужно ответить за ограниченное время. В вариантах ответов нужно выбрать однозначно правильный ответ среди вариантов, которые содержат еще неправильные и контекстнозависимые ответы. Ниже для иллюстрации поделюсь несколькими пробными заданиями. Все пробные задания есть в открытом доступе на сайте экзаменационного центра. Есть вопросы по BPMN, может быть полезно для отработки навыков.

Материалы недавней конференции еще не опубликованы, поэтому поделюсь пока ссылкой на материалы прошлого года.

Кто-то еще подключался к конференции? Какие впечатления остались? Как вам пробные вопросы экзаменов?

Трудно быть в ИТ аналитиком?
#мысливслух

Выяснила для себя, что термин «престиж профессии» рассматривается в социологии, а методы его оценки являются объектами научных исследований. Престиж профессии, как оказалось, исследуется с 1925го года и с тех пор проведены сотни исследований по разным методикам. В течении десятков лет разные измерения давали очень похожие результаты и в 1970х некоторые из ученых пришли к выводам, что социальная оценка профессий не меняется во времени и пространстве. Рассматривалась гипотеза, что даже в исторической перспективе вплоть до XIV века понимание престижа профессий может оказаться неизменным. Вот несколько результатов исследований разных лет и по разным методикам из статьи Методология и основные результаты исследований престижа профессии в зарубежной социологии:

📍В 1931 г. провели серию опросов среди 38 878 школьников. Были получены высокие оценки статуса таких профессий: Врач, Банкир, Священник, Летчик, Юрист, Преподаватель
📍В начале 40х другое исследование дало рейтинг, где первые места заняли Судья, Высшие госчиновники, Банкир, Врач, Президент колледжа
📍В исследованиях 1947го и 1963 года первые места в рейтинге престижных профессий распределились в таком порядке: Судья Верховного суда, Врач, Физик-ядерщик, Ученый, Научный работник (государственный), Губернатор штата, Член правительства
📍 В исследовании 1989 года первые места рейтинга распределились так Врач, Юрист, Системный аналитик\ученый — компьютерщик, Преподаватель в колледже, Физик\астроном

Люди оценивают уровни квалификации, образования, доходов, привилегий, контроля над людьми и ресурсами, а еще существуют субъективные доверие и уважение. Часто думаю об этом. Особенно, когда сталкиваюсь с очередным обесцениванием роли аналитика что бизнес-, что системного.

Так как критерии качества результатов работы аналитика размыты, у многих возникает недоверие к этой сфере деятельности. С разработчиком более-менее понятно - либо работает приложение, либо нет. Тестировщик либо находит баги, либо нет. С аналитиками сложнее. Аналитик может выявить потребность, предложить решение. Решение внедрят через год и обнаружат ухудшение метрик продукта. Опоздали внедрить или аналитик предложил ерунду? Или разработали криво? Мне доводилось видеть и такие случаи, когда команда годами работает по неполным, противоречивым требованиям, удивляется количеству открытых вопросов в каждой задаче, но не может связать это со значением и качеством работы аналитика. Аналитик же написал чего-то красивое по шаблону и разве от него нужно что-то еще?

Если честно, то не хочется думать, что социальное восприятие профессий — это константа. Нас точно ждет следующий явный или неявный пересчет показателей. Как думаете, каким он будет для аналитиков?

Материалы о прототипах
#что_почитать

📚Книги

📍Прототипирование. Практическое руководство. Вафел Т.
Книга 2013 года, поэтому не вся информация полностью актуальна. Тем не менее можно найти многое о прототипах от их ценности и процесса создания до работы в конкретных редакторах Visio, Axure, Fireworks, PowerPoint и в HTML.

📍Спринт. Джейк Кнапп, Брейден Ковитц, Джон Зерацки
Приведены конкретные примеры из проектов для медицинской клиники, для робота-дворецкого, для Slack и некоторых других. Прототипы в этих проектах не обязательно веб-приложения или что-то их заменяющее, есть примеры переоборудования помещений, продажи фич через буклет, имитации функций робота… Чуть более подробный обзор книги на Дзене

🎥Видео

📍Игра «Что, где, когда» с вайрфреймами, мокапами и прототипами
Доклад на Analyst Days-11 о том, с какими прототипами работают аналитики на проектах мобильной разработки

🗞Статьи

📍Wireframes Are not Just for Designers: Wireframes as a Tool for Product Managers (EN)
О том, чем вайрфреймы могут быть полезны и 5 шагов их создания. Рекомендации адресованы продактам, но могут пригодиться и аналитикам

📍How to use requirements gathering techniques to determine product requirements from non-verbal subjects (EN)
Про выявление требований для четвероногих пользователей через тестирование прототипа (чуть больше деталей в обзоре этой статьи на Дзен)

📍«Волшебник страны Оз» или как провести юзабилити-тестирование голосового интерфейса
Об аналоге прототипа для тестирования сценариев голосовых помощников

📍Power of wireframes (EN)
Про пользу простых набросков элементов интерфейса. Есть пример, рассказ об уровнях детализации и о чем стоит подумать, когда начинаешь их рисовать

👇

📍Потребуется ли развивать прототип по мере решения задач или для использования в других задачах? Если потребуется, то не стоит ограничиваться набросками на бумаге.
📍Должен ли прототип поддерживаться как один из поставляемых проектных артефактов? Если должен, то выбор инструментов и уровня детализации будет зависеть от требований к проектным артефактам.
📍На данном этапе уже определены технологии решения? Самый неприятный подводный камень визуализации в возможности создать у зрителя нереалистичные ожидания и даже не понять этого. Например, у вас на раскадровке показана прямая ссылка на какую-то страницу, на этапе разработки обнаруживается, что сгенерить динамически такую ссылку не получится. При этом заинтересованные стороны уже на нее рассчитывают. Любая визуализация так или иначе опирается на понимание технологического стека и возможностей разработки. Если вы еще не понимаете деталей, то лучше удержаться от их визуализации, чтобы не создать нереалистичных ожиданий.
📍В вашей команде есть UX-специалист? Какая у вас договоренность об ответственности за составление прототипов? Есть опасность переоценить свою роль в команде и невольно зайти в сферу ответственности дизайнера. Перед созданием какого-либо прототипа нужно обсудить совместную работу. Возможно, вы составите каркас для первых обсуждений, а более детальную проработку передадите дизайнеру, но не исключено, что всю работу по визуализации коллега ожидает выполнить сам.

@pro_ba_it

Что такое прототипы и какими они бывают?
#кейс #инструменты #прототипы

В этой статье будем понимать под прототипом модель поведения системы. Такие модели можно построить без особых технических средств на бумаге или доске, а можно создать экспериментальный образец, воспроизводящий функции приложения. В книге Карла Вигерса «Разработка требований к программному обеспечению» читаем: «Создание прототипов ПО — пробный шаг в мир решений. Оно делает требования более реальными, приближает варианты использования к реальности и закрывает пробелы в вашем понимании требований.” У Вигерса прототипы разделены на типы.
📍По назначению
◦ горизонтальные, которые показывают интерфейс с точки зрения поведения пользователя, но не затрагивают логику обработки и базу данных;
◦ вертикальные, которые показывают все слои системы и выполняются в тех же средах разработки, что запланированы и для системы.
📍По использованию в будущем
◦ одноразовые, которые предназначены, чтобы провести обсуждение или исследование, их развитие не планируется;
◦ эволюционные, которые могут последовательно развиваться и перерасти в код самой системы;
📍По форме
◦ бумажные, которые могут представлять собой набросок на бумаге или любую другую имитацию ответов на действия пользователя на доске, в графическом редакторе;
◦ электронные, которые выполнены в среде разработки и представляют собой работающее ПО части решения.

В работе чаще всего встречаются такие термины:
🔅Каркасное представление (вайрфрейм) — в терминах Вигерса это одноразовый горизонтальный прототип без деталей элементов дизайна и динамики. Он может быть выполнен и на бумаге, и в графическом редакторе.
🔅Раскадровка (мокап) — более детальное изображение экранов, показывает изменение состояний экранов в ответ на действия пользователя. Чаще всего выполняется с учетом цвета и стилей элементов. По терминологии выше — это горизонтальный одноразовый прототип. Этот вариант еще могут называть моделью или макетом. Может быть активным, если добавить средства анимации. Чаще всего выполняется в инструментах вроде Figma, Axure, Adobe XD
🔅Экспериментальный образец (часто именно его называют прототипом) - ПО одной из частей приложения с учетом дизайна элементов, навигации между экранами, логики обработки данных. Такой прототип ориентирован не на выявление нюансов пользовательского интерфейса, а на проверку технического решения. В терминах Вигерса это вертикальный эволюционный электронный прототип.

Какой из вариантов прототипирования выбрать аналитик решает в зависимости от целей создания прототипа и ожидаемых сроков. Cтандарт BABOK 3.0 предлагает использовать прототипы для таких задач (сохранен текст перевода на русский):
⚙️Выявление требований: используется для выяснения и подтверждения потребностей заинтересованных сторон через итеративный процесс создания модели или дизайна требований.
⚙️Определение будущего состояния: используется для моделирования вариантов будущего состояния и может также помочь определить потенциальную ценность.
⚙️Анализ требований и определение дизайна: используется для оказания помощи заинтересованным сторонам в визуализации внешнего вида и возможностей запланированного решения.
⚙️Оценка решения: используется для имитации нового решения, чтобы определить и собрать показатели эффективности.

Чтобы выбрать вид прототипа, нужно сформулировать задачу, для которой он понадобился, и ответить на несколько вопросов 👇

@pro_ba_it

Про ошибки при проведении интервью с пользователями
#мысливслух #интервью

В очередной раз вчера столкнулась с мнением, что «нет проблем пойти и узнать, чего хочет бизнес». Проблем, конечно, нет, а есть навыки, которые нужны как и в любом другом деле. Хочу вернуться к теме интервью и показать несколько типичных ошибок, которые бывают очень заметны и могут сделать бесполезной не только работу аналитика, но и всей команды, которая будет работать по его описаниям.

Предвзятость
Заметила, что, чем ближе интервьюер к области решений, тем сложнее ему быть непредвзятым в разговоре с пользователем. В моей теперешней команде коллеги часто меня пытаются убедить, что пользователю лучше «именно так». Потом выясняется, что коллеги ночь не спали, придумывая как решить вопрос с учетом всех ограничений и смогли придумать «именно так». Тут включаются разные когнитивные искажения, связанные с значимостью собственного выбора, игнорированием противоречащей информации и это совершенно естественно. Вот тут статья про ловушки мышления. Например, «ошибка меткого стрелка», когда стрелок сначала выстрелил в стену сарая, а потом вокруг отверстия нарисовал мишень.
На интервью это проявляется
• в наводящих вопросах: «Вы же заметили наше новое удобное меню?» и «А разве не будет вот так проще…?»;
• в вопросах, которые задаются так, чтобы интервьюеру подтвердить свое понимание.
Мне очень помогает возможность записать разговор на видео или диктофон, через некоторое время переслушать, исключить или поставить под сомнение ответы на наводящие вопросы. А еще лучше ходить на интервью в компании с кем-то менее предвзятым, кто может потом рассказать свою версию.

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

Решения вместо потребностей
Вы замечали, что многие люди очень быстро из области проблем переходят в область решений? Действительно проще сказать, что «Нужна кнопка», чем объяснить, почему она нужна. На интервью можно честно записать «Пользователю нужна еще одна кнопка», а можно перед этим спросить «Что должно происходить, если эта кнопка нажата?» и постараться довести разговор до реальных причин. Тут можно узнать неожиданные вещи, например, что такая кнопка уже есть, но расположена неудобно и никто ее не видит...
На интервью важно самому не переходить к решениям, если только это не решенческое интервью. Если речь заходит именно о решении, то дополнительными вопросами уточнять насколько требуемая функциональность вписывается в рабочий процесс или личный опыт пользователя.

Подборка статей про дизайн-мышление
#что_почитать

Наверняка вы часто слышите термин «дизайн-мышление». Определения встречаются очень разные - это и идеология, и процесс, и набор методик для решения задач. И то и другое опирается на принципы клиентоориентированности, эмпатии, сотрудничества и некоторые другие.

Дизайн-мышление — противоположность группового мышления, однако, что парадоксально, оно протекает в  группах. Обычный эффект «группового мышления», как объяснил Уильям Уайт читателям Fortune еще в 1952 году, заключается в подавлении креативности отдельных людей. Дизайн-мышление, в  свою очередь, стремится к  высвобождению такой креативности (из книги Тима Брауна «Дизайн-мышление в бизнесе: от разработки новых продуктов до проектирования бизнес-моделей»)

📍Применение дизайн-мышления при выявлении требований (ENG) Чтобы понимать потребности конечных пользователей и предлагать работающие решения, БА важно применять принципы дизайн-мышления. Поэтапно описано применение стенфордской модели дизайн-мышления. Эти этапы: Эмпатия,Определение, Идея, Прототип, Тест. Картинка к посту взята из этой статьи
📍Концепция Дизайн-мышления: что это такое, основные принципы, идеи и методики Подробное пошаговое описание известной модели дизайн-мышления Double Diamond. После статьи завершающей эту подборку, мне не очень зашли примеры применения дизайн-мышления
📍Карта эмпатии - первый шаг в дизайн-мышлении (ENG) В блоге Norman Nielsen Group о технике картирования знаний об отношении и поведении пользователей. Есть не только описание и пошаговые рекомендации, но и пример
📍Спорность дизайн-мышления Это перевод статьи автора Jon Kolko. Понравились рассуждения об истории дизайн-мышления и появлении его основных принципов. Приведена критика дизайн-мышления как процесса. По мнению автора невозможно разделить дизайн-мышление и создание вещей, а без понимания психологии решения задач и долгосрочного погружения в культуру дизайна, дизайн-мышление превращается в забавную разминку, но не в серьезную работу по созданию чего-либо

Можно ли войти в ИТ через калькулятор?
#мысливслух #что_почитать #истории

Недавно в одном из чатиков обменивались рассказами о том кто как «вошел в ИТ». Как обычно, я описала свои поиски, которые сегодня могут выглядеть неправильно смонтированными кадрами фильма о карьере. Трансформация там такая: разработчик — тестировщик — QA Lead — BA — BA Lead... Потом поняла, что могу рассказать историю поинтереснее. Расскажу здесь, чтобы немного скрасить утро понедельника ☀️

Впервые и неудачно я вошла в ИТ в первом или втором классе школы. Это совсем не о юных гениях, которые в первом классе выигрывают студенческие олимпиады. Это о двоечнице, которая решила потихоньку от родителей подсчитать примеры по математике на калькуляторе. В конце 80-х в нашей математической семье появился новый модный гаджет — программируемый калькулятор МК-61. Он бережно хранился в дермантиновом чехле и в коробке, подальше от детских глаз, и появлялся на столе только когда у кого-то из родителей находилось время на эксперименты в программировании. К тому же он стоил, как я сейчас понимаю, процентов 80 от зарплаты каждого из моих родителей 🙈

Разве можно что-то спрятать от ребенка в однокомнатной хрущевке? Сидеть одной и что-то там складывать и умножать было скучно и, пока никто не видит, бесценный агрегат был извлечен, включен, кнопки нажаты и полученные ответы записаны в тетрадку. На следующий день получила двойку. Первое знакомство с ИТ оказалось провальным, зато научило не жать кнопки, не разобравшись, что к чему ☺️

Немного позже разобралась, что у МК-61 есть операционный стек из 4х регистров памяти, а есть 15 регистров общего назначения. Можно было писать программы до 105 шагов и энтузиасты публиковали статьи с алгоритмами для этих калькуляторов. Особенно популярно было писать на них игрушки. Ну и я, затаив дыхание от ощущения причастности к чему-то научному и технологичному, честно выписывала на листочке команды:
[50][X→П][2] — заносим в REG2 значение 50,
[32][X→П][3] — заносим в REG3 значение 32….

Если вам интересна история ИТ, то вот пара статей об этой серии калькуляторов МК-61: история, эмуляция, устройство и Карманный компьютер из 1985 года: программируемый калькулятор «Электроника МК-54»

А каким вам запомнился "вход в ИТ"? Есть у вас гаджеты, которые ассоциируются с первым знакомством с ИТ?

Сколько нужно времени, чтобы проснуться и выпить кофе?
#кейс #bpmn

В продолжение темы BPMN хочу предложить небольшой кейс.Чтобы потренироваться в отображении времени на диаграмме, сделала пример с промежуточными событиями-таймерами, в том числе прикрепленными. Прерывающими и непрерывающими. Не придумала ничего лучше как изобразить на диаграмме свое собственное утро и борьбу не то со сном, не то с повторами будильника ☺️

🔅Прерывающее событие-таймер (Timer Boundary Event (Interrupting) ) показывает дату, шаг цикла или время ожидания в процессе. Когда бы ни произошло такое событие, связанное действие прерывается.
🔅Непрерывающее событие-таймер (Timer Intermediate Catch Event) показывает дату, шаг цикла или время ожидания в процессе. Когда бы это событие ни произошло, процесс может продолжаться.

По диаграмме на картинке, сколько нужно времени, чтобы подняться утром и выпить кофе?

Способы использования BPMN
#что_почитать

C BPMN (Business Process Modeling Notation) я впервые познакомилась, когда оказалась в продукте на PegaBPM — это платформа для автоматизации управления процессами. Исполняемая диаграмма процесса строится в ней в соответствии со стандартом BPMN. Когда я перешла в другую команду и получила задание составить диаграмму процесса в BPMN 2.0, то честнейшим образом использовала нотацию со всеми ее шлюзами и событиями. Следовало бы учесть, что диаграмма строится не для исполнения в каком-либо движке, а для предоставления заинтересованным сторонам. Заинтересованные стороны привыкли к упрощенной адаптированной версии и испытали шок от моих диаграмм :) Так я на собственном опыте столкнулась с преимуществами и недостатками моделирования процессов в BPMN. Диаграммы могут быть сложны для чтения неподготовленной аудиторией и это создает риск организовать непонимание вместо общей понятной картины процесса. Особенно, если применять нотацию там, где она не нужна. Хочу поделиться парой статей, которые очень бы мне пригодились тогда :)

🔅6 неправильных способов использовать BPMN и альтернативы BPMN. Статья от гуру нотации BPMN, в которой объясняется для каких задач не нужно ее использовать.
🔅 3 (and only 3) Reasons to Use BPMN (ENG) Если свести рекомендации к трем основным пунктам, то использовать BPMN нужно, если
• не получается увидеть детали процесса в другой нотации,
• в вашем продукте регламент или платформа требуют именно этой нотации,
• вы на собеседовании и требуется показать знание BPMN.

Про_БА pinned «Привет всем! Меня зовут Анастасия. Проектирую функциональность информационных систем более 15 лет. Началось все с разработки на ассемблере в одном из конструкторских бюро. Через пару лет я поняла, что мне интереснее делать продукты для людей, поэтому ушла…»

Привет всем!
Меня зовут Анастасия. Проектирую функциональность информационных систем более 15 лет. Началось все с разработки на ассемблере в одном из конструкторских бюро. Через пару лет я поняла, что мне интереснее делать продукты для людей, поэтому ушла сначала в тестирование, а позже в системный и бизнес-анализ. Добралась и до продуктового управления. Сейчас продолжаю карьеру и активно делюсь опытом в роли наставника, преподавателя, автора публикаций для аналитиков.

Помогаю аналитикам
• разбираться в техниках бизнес-анализа,
• готовиться к собеседованиям,
• решать кейсы,
• готовиться к выступлениям на отраслевых конференциях\семинарах,
• планировать развитие в профессии.
Чтобы договориться о консультации или задать вопрос нажмите кнопку "Задать вопрос" в этом закрепленном посте. В сообщении укажите детали вашего запроса.

Этот канал - способ поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ. Мне интереснее всего делиться наблюдениями и мыслями, а еще опытом применения техник бизнес-анализа. Обзоров статей и книг здесь чуть меньше. Это заметно, если посмотреть публикации под тегами:
📍#кейс — здесь разбор кейсов и примеры применения разных техник
📍#мысливслух — под этим тегом публикации с историями и профессиональным опытом
📍#что_почитать — этим тэгом отмечены подборки, обзоры статей и посты со ссылками на статьи
📍#agile – то, что связано с инструментами гибких методологий: бэклог, DOD, DOR, USM и не только
📍#книжки — обзоры книг

Еще можно найти мой канал в:
🟦ВКонтакте
🌟Дзен
🫟Сетка

На аватарке канала изображение от storyset на Freepik

☀️ Вернувшись с каникул рада видеть новых подписчиков! В начале нового рабочего года решила повторить и дополнить пост-приветствие.

С Новым годом и отличных каникул!
#что_почитать

Я очень признательна уходящему году за то, что решилась делиться знаниями о своей работе и что собралось столько читателей! Вы же понимаете - синдром самозванца нужно еще заслужить! ☺️

Канал отправляется на каникулы до 8го января. Вернусь с новыми статьями и историями. Прежде, чем наряжать елку, хочу пожелать всем нам, чтобы в новом году

✨заказчики были вовлеченными,
✨команды — дружными,
✨спроектированные решения — работающими,
✨процессы — понятными,
✨ТЗ — прочтенными и согласованными!

Если на каникулах будет время почитать, то вот тут
📍Навигация по статьям сентября-ноября
📍О трех мифах про БА (#мифы)
📍Памятка по источникам требований
📍О текстах в интерфейсе
📍О кнопочных телефонах и об источниках требований

🎄🎄🎄