Про_БА

Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
М. Хаммер, Л. Хершман. Год издания: 2010

Когда вы читаете все, что еще год назад сохранили списком в Notion или еще где-то? Я вспоминаю о своем списке, когда оказываюсь где-то в ожидании или в пути, в остальное время всегда находится что-то ужасно срочное или интересное ☺️

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

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

Издание вышло почти полтора десятка лет назад и вряд ли покажутся новыми рассуждения о культуре KPI или общее описание процессной культуры в компаниях. Эти мысли стали приходить с первых же слов предисловия к книге.

Что может быть полезно?
На примерах посмотреть как отличаются в процессах шаги добавляющие ценность и прочие операционные, административные шаги. Как выглядит процесс, где только 3 шага добавляют ценность, а 15 – передача информации из рук в руки.
Мне понравился пример с процессом обрезки деревьев. Чтобы снизить количество аварий на линиях электропередач нужно было построить процесс обрезки деревьев и следить за его эффективностью. Хорошо передан контекст исследования проблемы и поиска решений.

Полезно обобщение семи принципов проектирования:
• какие операции будут выполняться;
• будут ли они выполняться и при каких условиях;
• кто будет их выполнять;
• когда это будет происходить;
• где они будут выполняться;
• насколько точно они будут выполняться;
• какая информация будет при этом использоваться.

Глава о показателях эффективности. Мне понравился прием, с перечислением "грехов", которые могут привести к ошибкам в выборе системы показателей. Оставлю их здесь, а вы сами читайте в книге или предполагайте, как они влияют на выбор метрик процессов:
• тщеславие;
• самолюбование;
• лень;
• нежелание масштабно мыслить;
• бессмысленность;
• легкомыслие.

Кому может быть полезно?
Создалось впечатление, что в книге слишком мало конкретики для начинающего специалиста, который еще не сталкивался с запутанными процессами крупных предприятий и не разобрался в цепочках создания ценности.
Эксперту с опытом в построении бизнес-процессов может быть интересно познакомиться с описанием принципов проектирования, описанием организационных изменений и некоторыми примерами, как иллюстрацией и дополнением к собственному опыту.

#книжки

Что здесь есть о выявлении требований?

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

🔅Интервью
Про ошибки при проведении интервью с пользователями
Какие вопросы?
Интервью на удаленке

🔅Бенчмаркинг
Как посмотреть, что делают другие?

🔅Прототипирование
Что такое прототипы и какими они бывают?
Каркасное проектирование или wireframes

🔅Анализ процессов
Причины использовать Process Mining
Способы использования BPMN
Стартовые события, сквозные процессы, process mining...

🔅Опрос
Мифы о применении опросов при выявлении требований

🔅Мозговой штурм
Мозговой штурм (brainstorm) работает или нет?


#навигация #что_почитать

Нужно ли команде тратить время на ревью требований? (peer-to-peer review)

Когда работаю над большой задачей, отправляю первую версию описания требований команде и другим аналитикам с просьбой посмотреть и дать комментарии. Обычно мало надежды на развернутую обратную связь. На нее мало у кого находится время и интерес. Пока "мячик на стороне аналитика" не очень понятно зачем тратить время на какие-то задачи, которые еще не пришли в разработку. Тем не менее есть преимущества от такой траты времени

📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать ☺️
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.

Самопроверка при этом не отменяется, не стоит перекладывать на команду контроль соответствия формату, терминологии и орфографических ошибок.

Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут

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

#инструменты #кейс #что_почитать

Аналитик с опытом может быть новичком!

Сегодня думаю про адаптацию в новой команде. Участвую в подготовке курса для онбординга аналитиков, отсюда и #мысливслух.

Прием в новой компании и команде может оставлять впечатления очень надолго. У меня в прихожей прячется от дождя зонтик-трость с логотипом одной прекрасной компании. Мне там хорошо работалось и этот бесполезный остаток welcome-pack меня радует как старое семейное фото. К чему это я? ))

В новой команде даже самый опытный эксперт на пару дней чувствует себя новичком. Есть мнение, что эксперту онбординг не требуется. Правильно ли при адаптации полностью полагаться на экспертный опыт? Разве он поможет найти доступы в нужные системы и быстро разобраться в названиях в вашем бэклоге? Конечно, коллега с опытом рано или поздно разберется в вашей схеме работы, но какие впечатления и уровень доверия к команде у него останутся? 🤔

"Адаптация" не равно "развитие". Помнится, пару лет назад коллега в новой команде встретила меня словами "Так я же тебя знаю, твои вебинары смотрела!" (Аня, привет! 👋) Это было приятно, что никому не нужно ничего доказывать насчет развития. Не всегда так везет. Переход в новую команду бывает похож на изучение нового языка, когда человека считают глупым, потому что он неправильно называет аббревиатуры названий отделов. И вот уже бадди дружелюбно и очень навязчиво объясняет, что "дейли – это каждый день, а диаграмма - она из квадратиков". Наверное, в таких случаях тоже может эмоционально выручать какой-нибудь зонтик с логотипом какой-то прекрасной компании )))

Какие у вас мысли об онбординге? Как вас встречали в вашей нынешней команде?

#мысливслух

Подборка про приоритеты
#что_почитать

Была у меня как-то задумка написать статью о методах приоритизации. План так и остался нереализованным, но я успела перебрать пару десятков статей о приоритетах и выбрать несколько полезностей. Вдруг и вам пригодится?

Здесь можно познакомиться с методами:
- RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия)
- ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации)
- Value vs Effort (ценность против усилия)
- Модель Кано
- Story mapping 
- MoSCoW (Must, Should, Could, Won't)
- Opportunity scoring (оценка возможностей)
- Product tree (дерево продукта)
- Cost of delay (стоимость задержки)
- Buy a feature (купи функцию)
- Weighted scoring (взвешенная оценка)
- WSJF (Weighted Shortest Job First, сначала — более важная и короткая работа)
- Метод Вигерса
- Feature Bucket

📍Что делать в первую очередь? Простая приоритизация задач при помощи риса Статья о методе RICE. Есть пример, можно подсмотреть как автор работает с этим методом

📍12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие В статье речь о расстановке приоритетов продуктовых целей, но для пользовательских историй эти техники тоже работают. Кроме того, что есть в заголовке, речь о девяти методах

📍Определяем, что важнее: методы расстановки приоритетов в Big Data и цифровизации Big Data мне здесь показалось притянутым, в целом это статья о приоритетах без особого акцента на данных. Понравилось разделение на тактический и стратегический уровни приоритизации, а еще сравнение подходов из BABOK с подходами портфельного управления. Дополнительно к методам из предыдущих статей, здесь упомянуты метод Вигерса и Feature Bucket

📍Техники скоринга и приоритизации бэклогов Еще одна точка зрения на те же методы Story mapping, Value & Effort, MoSCoW, Kano, ICE, RICE, а еще техники оценки задач с картинками и примерами

📍Почему не удалось с первой попытки найти приоритеты? Давний пост в нашем канале с кейсом неудачного применения метода Кано и удачного применения Value vs Effort. Здесь тоже есть пара полезных ссылок на статьи о методе Кано

Мифы о применении опросов при выявлении требований

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

📍Быстро и относительно недорого применять, заявляет BABOK 3.0 (п.10.45.4 о преимуществах опросов). Кто хотя бы раз всерьез составлял опрос, тот понимает, что можно запросто потратить несколько дней на составление недвусмысленных формулировок вопросов и подбор вариантов ответов так, чтобы они не пересекались и были исчерпывающими. Эти формулировки должны неукоснительно отвечать целям опроса и позволять получить информацию в результате. После составления опросник нуждается в тестировании, так что придется отвлечь кого-то из коллег на проверку работоспособности и наличия ошибок в текстах. Если составитель хорошо потрудился, то респонденту не понадобится много времени на ответы, но респондента нужно в этот опрос еще завлечь и вообще убедиться, что вопросы задаются подходящей аудитории. Нужно составить такую рассылку, где вы правильно объясните цель активности и заинтересуете в прохождении. Отправить нужным адресатам и аккуратно повторить несколько раз в разных каналах коммуникации. А в остальном опросы - это и правда быстро 😉

📍Легче собирать информацию от большей аудитории, чем с помощью других техник, таких как интервью, снова убеждает нас BABOK 3.0 и не только он. Опросы и интервью совсем не нужно сравнивать. Интервью – качественное исследование поможет ответить на вопросы "как?" и "почему?". Совсем не обязательно разговаривать с каждым из многотысячной аудитории, а достаточно грамотно выбранных нескольких респондентов. Ценность интервью не связана напрямую с количеством участников. Опросы - количественные исследования отвечают на вопрос «Насколько? Как сильно? Сколько?» Опрос поможет, когда вы уже что-то знаете об объекте исследований и понимаете, что именно хотите измерить. При этом есть достаточно большая аудитория для статистической значимости. Вот тут я рассказала как ошиблась с объемом выборки и получила недостоверный результат.

📍Временами слышу, что через опрос можно получить много новых идей. А вас не удивляют вопросы вида: "Помогите нам стать лучше и напишите, что нам еще сделать?" В одном из опросов мне запомнился прямой и грубый ответ: "Просто сделайте, чтобы уже внедренное нормально работало" 🙈 Такого рода вопросы звучат как будто команде продукта не обязательно наблюдать за использованием, собирать данные, проводить интервью и пр. , а достаточно включить открытый вопрос в анкету. К тому же всегда ли вы готовы дать развернутый подробный ответ в окошке опросника, который открыли в расчете пройти за 5 мин?

Из того, что я видела по теме опросников, мне запомнился вебинар Как (не) надо составлять опросники Полезное начинается только после 12й минуты

#инструменты #что_почитать

Что здесь интересного?
#навигация

Как и положено весной, хочу навести порядок и отряхнуть пыль с предыдущих публикаций 🧹 В марте больше всего набрали просмотров

📍Разнообразие начальных событий в BPMN
📍Нужно ли аналитику работать в Figma?
📍Сможете придумать логлайн для своей задачи?
📍Про БА и про СА (подборка)
📍Мозговой штурм (brainstorm) работает или нет?
📍Подборка про User Story и USM
📍Чашки и их свойства в разных системах

[ноябрь'23][декабрь'23][январь][февраль]

Как посмотреть, что делают другие?
#инструменты #кейс

На прошедшей неделе пришлось пару раз обращаться к бенчмаркингу для выявления требований. Понадобилось поискать идеи для рабочей задачки

В моем опыте я позже прочих техник добралась до анализа приложений других компаний. Однажды в работе над вариантом CRM-системы для меня оказалось своего рода открытием, что моя система не уникальна и можно посмотреть как сделаны такие же. Когда я начинала работать, рынок еще не был настолько заполнен автоматизированными решениями. Теперь уже просто обязательно оглядеться на существующие решения, если только вы не работаете над совершенно инновационным продуктом.

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

1️⃣Сформулировать, что и с какой целью вы ищете. Формулировка вида "Хотим улучшить страницу", не поможет очертить границы исследования и понять, какие идеи считать улучшающими эту самую страницу. Нужно понимать для какой аудитории, с какой целью нужно анализировать варианты решения. Например, "За счет изменения функциональности и дизайна главной страницы, ожидаем привлечь N% клиентов малого бизнеса к покупке нового продукта"

2️⃣Определить компании для анализа. Это не обязательно прямые конкуренты, могут быть и компании смежных отраслей, если клиенты нанимают их на похожую работу. Если вам нужно изучить варианты бронирования жилья для поездки в отпуск, то могут пригодиться не только приложения для бронирования отелей, но и сайты авиакомпаний, которые предлагают забронировать отель в месте назначения поездки или сайты аренды квартир и апартаментов

3️⃣Определить критерии для анализа и сравнения. Выбор критериев зависит от целей анализа. Это могут быть особенности навигации по приложению, подходы к фильтрам на странице, механики привлечения внимания и пр.

4️⃣Сформулировать найденные идеи в формате, который позволит обобщить и провести сравнительный анализ идей. Например, в формате таблицы, где идеи собраны по каждому критерию, для каждой выбранной компании

5️⃣Помнить, что вы сможете получить информацию о том, какие решения выбрали другие компании, но не обязательно поймете как эти решения сделаны, почему именно они выбраны и насколько помогли достичь к цели. Вы получите идеи, но придется проверять самим подойдут ли эти идеи вашей компании и действительно ли хорошо сработают для достижения именно ваших целей

Analyst Marathon #10. Теория и кейсы
#конференции #мысливслух

Суббота 10 утра для меня бывает временем неспешного завтрака, только на прошлой неделе пришлось изменить свой распорядок, чтобы подключиться к Analyst Marathon. В этой онлайн конференции мне нравится атмосфера — нет пафосных студий с белыми стенами и красивыми микрофонами, а есть эксперты, которые пришли пообщаться. Здесь доклады идут в записи, так что спикер выходит на связь, чтобы бодро и предметно ответить на вопросы из чата, где все участники набрасывают разной степени ехидности вопросы. Создается ощущение настоящего общения, потому что в динамике видишь и движуху чатике, и как докладчик на нее реагирует. Случались накладки, когда спикер подключался раньше, чем закончилась его запись или наоборот сильно опаздывал, но все это хорошо работало на теплую неформальную атмосферу.

Проводится конференция третий год, собирались уже 10й раз с темой «Технические навыки БА/СА”. Всего 6 докладов примерно за 6 часов.

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

Первый доклад был про единые подходы к управлению интеграциями систем и команд. Запомнилось наблюдение, что межкомандные регламенты важны если работает более трех команд, три команды еще могут договориться напрямую. Речь зашла о встречах-синхронизациях при разработке интеграций и мне стало интересно, кто на них ходит: разработчики, архитекторы, аналитики, QA? Докладчик Ильяс Мухамадуллин ответил - это человек, который в контексте задачи и может принимать решения в части интеграций: аналитик, архитектор, разработчик или тимлид 🤨

Неожиданно меня увлек доклад про выбор NoSQL в кейсе про справочник налогообложения для формирования чеков в ресторанах. Запомнилось, что в этом кейсе 180 секунд оказалось достаточно, чтобы оформить заказ в киоске, на кассе или в приложении. Это был предметный и искренний рассказ о выборе NoSQL для кеширования данных заказа. Татьяна Павлюченкова поделилась ссылкой на Миро, где выложена табличка с типами таких БД и критериями выбора для этого конкретного кейса.

Был доклад Ирины Матвеевой про ТРИЗ. Рассказ о постановке задачи по ТРИЗ и о сути подхода. Из переписки в чате сохранила себе ссылку на табличку из статьи Альтшуллера Г.С. Алгоритм изобретения (1973), где в зависимости от того, что нужно изменить для решения конкретного типа задачи указаны номера методов решения. Чтобы начать решать задачу нужно понять главную полезную функцию системы. Так что вопрос «какую проблему мы решаем?» выглядит вполне вопросом по ТРИЗ.

Некоторые доклады досматривала уже после окончания конференции и тогда же дочитывала чатик, где не обошлось без очередного обмена мнениями о разделении функций СА и БА, без него теперь редко обходится 🤷‍♀️

Вышло так, что в прошлую субботу перед ужином снова слушала доклады. И то, и другое было полезным 🌱

Про зомби-Scrum
#agile #что_почитать

Хочу поделиться парой статей о применении Agile фреймворков. Здесь скептические высказывания.

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

Зомби-Scrum: симптомы, причины и их лечение о слепом следовании ритуалам

Темная сторона Agile публикация давняя, но здесь понравился разбор картины с точки зрения кодовой базы, реформирования тестирования, мониторинга и пр.

Сможете придумать логлайн для своей задачи?
#мысливслух

Термин логлайн я узнала пару недель назад. В киноиндустрии это суть истории, изложенная в 25-30 слов. Из логлайна должно быть понятно, чем уникальна история, кто является ее героем и какие трудности ему предстоит преодолеть. Оказывается, не только ИТ-командам трудно с большими ТЗ. Читать большой сценарий тоже трудно, гораздо проще оценить потенциал фильма по одному предложению. Логлайн может дать представление продюсеру насколько эта история адаптируется и можно вкладывать в нее деньги.

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

Этот прием привел меня к мысли «всегда ли мы можем коротко сказать, какую задачу решаем? Зачем она и для кого?».

Ассоциация с ИТ довольно яркая, ведь формат логлайна напомининает формат пользовательской истории. Он обязан содержать такие элементы: главный герой, проблема, цель и конфликт. Может начинаться со слов «это история о...».

Это история о члене мафиозной семьи, который пытался от нее дистанцироваться, но убийство брата и смерть отца вынудили его взять управление кланом в свои руки. Крестный отец (источник текста)

Слабый на алкоголь собиратель кавказского фольклора невольно становится соучастником кражи девушки, в которую влюблен. Он бросается спасать ее, не подозревая, что организатором преступления является крупный чиновник. Кавказская пленница (источник текста)

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

Стало интересно попробовать, можно ли в таком формате рассказать о каких-то задачах? Как думаете, какой класс систем пыталась описать ниже?

Нужно ли аналитику работать в Figma?
#мысливслух #прототипы

Недавно слушала лекцию о производстве кино. В нем еще до ИТ появилось то, что называется раскадровка (storyboard), а мы называем мокапом или каркасом (wireframe). То есть отрисовка каждого кадра в кино, а в нашем случае отрисовка страниц. Оказалось, что сложности эта самая раскадровка создает те же, что и прототипы в разработке. Если она слишком тщательно и красиво отрисована, то отвлекает от смысла кадра и динамики кино. Если слишком точно следовать раскадровке, которая на самом деле не отражает динамики переходов между кадрами, то ничего хорошего не получится.

Ровно так же и с работой ИТ команды. Прототип не может быть основным способом описания ожидаемого решения, самой по себе визуальной модели для этого не достаточно.

В одном из моих первых проектов, по совпадению разных организационных и географических факторов, сбор требований поручили дизайнеру. В качестве описания требований мы получили набор детально отрисованных в MS Visio прототипов со словом storyboard в названии каждого файла. Именно по ним велась разработка. В получившемся продукте полностью отсутствовала передача данных между логическими компонентами системы. То есть можно было ввести данные об объекте «Книга» и указать автора на форме ввода, но потом нельзя увидеть эти данные в списке книг автора или в алфавитном указателе на странице «Библиотека». Визуальная модель никак не передавала связи между объектами данных, вот их и не создали. После нескольких суток подряд переписывания и тестирования этого приложения, я твердо запомнила, что прототип не может претендовать на необходимое и достаточное описание требований.

Красивый прототип не заменит работу профессионального дизайнера. Многие команды не привлекают профессиональных дизайнеров и аналитики стараются восполнить пробел, но лучше много раз подумать браться ли за такую задачу? Сделать дизайн и сделать иллюстрацию к разговору с заказчиком - далеко не одно и то же. Дизайн подразумевает проработку всех элементов интерфейса во всех состояниях или адаптацию существующих дизайн-систем под особенности вашего приложения. Как бы качественно вы ни представили десяток экранов, это не заменит необходимости проработать 3-4 состояния (Default, Hover, Active, Disable) для каждого поля, кнопки и иконки, понять оставшиеся состояния экранов, особенности каждого перехода между страницами и сделать много другой работы. Может получиться, что аналитик покажет клиенту красивую картинку и договорится о реализации, а разработчик окажется перед необходимостью адаптировать картинку во что-то пригодное к реализации: переделывать *.png в *.svg, менять размеры, придумывать внешний вид для разных состояний. Аналитик рискует потратить кучу времени и не услышать благодарностей.

В работе аналитиков случается переоценка возможностей прототипирования. Часто приходится слышать что-то вроде «вот картинку нарисуем и все-все будет понятно». А еще бывает, что аналитику просто интересно рисовать картинки, так как они вызывают положительные эмоции и у него, и у заказчиков. При этом заказчикам нужен продукт, а не только эмоции. Нужно понимать какие вопросы ожидается решить с помощью прототипа и не тратить сил больше, чем требуется. Если аналитик умеет работать в графических редакторах вроде Figma или Sketch, это большой плюс - он быстрее сможет подготовить материалы к обсуждению. Если не умеет, то может обходиться каркасным проектированием (wireframe)

По аналогии с кино, если режиссер кино умеет рисовать, то ему проще набросать эскиз кадра и поставить задачу съемочной команде, а если не умеет, то нарисует как сможет. Кажется, эти рисунки режиссеров называют огурцами 😉

О чем еще подумать при выборе прототипа можно найти в посте Что такое прототипы и какими они бывают?

Про БА и про СА
#что_почитать

Пара полезностей от одной из дискуссий на Flow. Метка «что_ почитать» здесь немного не в тему, потому что все ссылки на видео, но у нас тут пока только такая метка для подборок ☺️

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

📌Подкаст Из Бизнес-аналитика в Бизнес консультанта Здесь Александр Белин рассказал своих шагах в карьере, о своей работе БА и бизнес-консультантом, а еще поделился мыслями об обучении бизнес-аналитиков и карьере БА

Flow. Вопросы к бизнес-анализу и системным требованиям?
#конференции #мысливслух

Вчера была возможность освободить день, удобно устроиться перед экраном и поучаствовать в конференции Flow, на этот раз JUG RU предложили только онлайн. Приманкой были не записываемые пара воркшопов и дискуссии после докладов.

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

▫️Нажала плашку с названием «Бизнес-анализ: Ремесло или искусство». Александр Белин выступал в формате живой беседы без презентации. Разговор пошел о том, что бизнес-анализ не должен быть ни ремеслом, ни творчеством. Анализ как часть процесса проектирования продукта должен быть воспроизводимым, в отличие от свободного творчества. Аналитик тратит время на создание объемных артефактов и делает это в отрыве от команды. Вся информация бизнес-анализа, кроме конечной постановки, остается не востребованной другой частью команды. Чтобы этого не происходило, нужно анализ превратить в инженерию разработки систем.

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

В ожидании записи вчерашнего интервью можно посмотреть доклад Александра Белина на Flow 2023

▫️Еще была плашка с провокационным названием «Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту». Не уверена, что провокация удалась. Иннокентий Бодров поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. Причины: 1) решаемая проблема мало изучена, команда предпочитает находиться в области решений 2) на согласование выносится много деталей решения, чтобы основную ответственность за проектирование перенести на согласующих. В случае экспертной, зрелой команды аналитику лучше оставить проектирование системы архитекторам и разработчикам, сосредоточиться на исследовании проблем бизнеса и не тратить время на мега-детальные описания решений. В презентации был показан пример классического верхнеуровневого Use Case в табличном формате. Подход не предлагает отказаться от системных требований, а предлагает сместить фокус работы аналитика на задачи более важные в его роли, если того позволяет зрелость команды.

Подключилась послушать дискуссию после доклада. Когда взглянула на иконку с человечком под основным экраном, она показала 32 участника. В разговоре выяснили, что детальные описания совсем не плохо, просто дорого. В нынешней команде спикера не ведется описания объектов, есть только глоссарий, атрибуты можно найти в коде. Не обошлось без карьерных вопросов. Погрустили о том, что никто не знает, чем занимается аналитик, настолько сильно тренд ушел в сторону проектирования. Закончится ли это? Кажется, закончится с развитием ИИ, который вытеснит рутинную работу и тех, кто умеет делать только ее.

Тут я заслушалась и пропустила закрытие ☺️

7 часов онлайна — это тяжко. Очень не хватало контакта между спикерами и аудиторией, того самого нетворкинга, ради которого мы и ходим на конференции. Не нашла в этот раз даже какого-нибудь шумного холиварного чатика. Просто выключила монитор, закрыла ноут и пошла сочинять этот пост 🌱

Мозговой штурм (brainstorm) работает или нет?
#что_почитать #мысливслух

Подход мозговых штурмов давно вошел в моду и так же давно под сомнением. Поделюсь статьями с разными точками зрения и своим опытом.

Мозговой штурм возник еще в 1940-х как способ поиска новых идей и решений через генерацию их в группе людей. BABOK выделяет его как одну из техник выявления требований. Список этих техник можно найти в посте тут.

В моем опыте brainstorm выручает, когда нужно собрать точки зрения на будущее решение от разных экспертов в команде. Бывает важно создать у каждого участника понимание причастности к решению, чтобы при реализации не было ощущения работы над чем-то навязанным аналитиком. Очень здорово, когда удается создать атмосферу доверия и общего движения к поиску решения. Это вдохновляет и мне такое нравится. Правда, вопросы все равно могут оставаться. Если вариантов несколько, то кто-то может топить за альтернативный и остаться недовольным выбором, но в любом случае будет проще двигаться дальше, когда у всех участников разработки есть понимание инструментов принятия решений.

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

В статье Мозговой штурм. Почему этот метод на самом деле не работает приведено несколько экспериментов, показавших несостоятельность идеи
📍1951 по 1956 год, исследование Соломона Аша показало, что под влиянием группы люди чаще дают неверные ответы даже на очень простые вопросы
📍1963 год. Исследование Марвина Данетта привело к мысли, что самостоятельно люди с большей вероятностью предлагают те же или лучшие идеи, чем люди в группах
📍2005 год, исследование Грегори Бернса подтвердило результаты прошлого века и показало, что когда человек работает самостоятельно, у него лучше вовлечены доли мозга, отвечающие за принятие решений

А вот здесь в блоге ScrumTrek автор будто попытался дать ответ на сомнения. Говорится, что технику нужно применять как инструмент, чтобы объединить точки зрения разных экспертов, провести более глубокий анализ вопроса и чтобы организовать командную работу. Думаю, это очень похоже и на мой опыт

В статье Проблемы мозговых штурмов интересно мнение автора о проведении мозговых штурмов удаленно и его взгляд на подмеченные проблемы

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

Как у вас с мозговыми штурмами? Если проводите, то бывает ли полезно?

Богатыри, цветы и дворцы
#мысливслух #истории

В те далекие времена, когда я работала в заказной разработке, было принято отправлять аналитиков в командировки. Чаще, чтобы изучить заказчика в его собственном офисе, а иногда — познакомиться с сильно распределенной частью команды. Оказаться на проекте с перспективой интересных командировок считалось хорошим опытом.

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

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

Оказалось, за моей спиной выстроились все парни нашей команды, чтобы меня одну поздравить заранее и я не осталась без праздника! Уже не могу вспомнить сколько именно ребят было в тот момент. Теперь кажется, что их было ровно 33 ИТ-богатыря ☺️

8е марта в том году был для меня очень рабочим, зато потом я отвела душу в прогулке по дворцам и паркам Людвигсбурга. Никогда бы не подумала, что и фото пригодятся.

Девушки, сказочного вам настроения, прекрасных цветов, тепла и внимания!💐