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

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

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

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

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

Способы использования 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@pro_ba_it

👇

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

@pro_ba_it

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

📚Книги

📍Прототипирование. Практическое руководство. Вафел Т.
Книга 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)
Про пользу простых набросков элементов интерфейса. Есть пример, рассказ об уровнях детализации и о чем стоит подумать, когда начинаешь их рисовать

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

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

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

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

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

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