Процессы, их виды, отслеживание и автоматизация

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

📍Конформный анализ бизнес-процессов в Process Mining Статья с теорией подходов в Process Mining и практикой на примере использования одной из библиотек в Python.

📍(ENG) The Pitfalls Of Efficiency: Process Improvement Is A Balancing Act Пост о том как важно при оптимизации процесса правильно понимать интересы стейкхолдеров и что не существует "правильного" подхода к этим интересам, а всегда приходится искать баланс.

📍Девять процессов, готовых к автоматизации Переводная статья о том, как понять, что процесс можно автоматизировать и какие из известных типовых процессов можно рассмотреть как наиболее подходящие для автоматизации.

📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если кто-то еще в начале пути БА, то статья может пригодиться.

📍Канбан Метод: не магия, а логика. Наводим порядок в хаосе По итогам одного из эфиров известного спикера автор записал и раскрасил картинками комментарии к мифам о Канбан. Может быть полезным, если вы считаете, что Канбан только про ИТ и про техподдержку.

#что_почитать

Юбилейное

Меня время от времени спрашивают зачем этот канал? Вспомнилось вместе с фактом, что этому уютному каналу уже 1.5 года. Хочу поделиться парой вещей, которых я не понимала пока не попробовала выглянуть на просторы экспертного контента.

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

🔅Подготовка контента – это тоже продукт. Делать экспертный контент и немного рассказывать о себе – интересная творческая работа. Чем не тренировка продуктового мышления: выбрать тему, собрать материал, проверить, сформулировать, а потом оценивать зашло или нет? 🤔

🔅Обнаружилось, что контент живет долго, гораздо дольше, чем время на его подготовку. Почти два года назад сделала пару статей и по ним до сих пор есть прочтения и переходы в этот канал. У этого есть и минусы – поверхностные, некачественные тексты тоже могут напомнить о себе, когда о них почти забыто 🙈

В продолжение темы поделюсь парой ссылок на давние статьи о наболевшем:
🔸О паре заблуждений в работе аналитика
🔸3 мифа о бизнес-аналитиках в ИТ
🔸Об ошибках в работе аналитика

#мысливслух #что_почитать

Event Sourcing: требования и впечатления

Наверняка вы уже слышали об этом паттерне. Коротко говоря, в Event Sourcing состояние приложения определяется последовательностью событий (events), а не просто текущим состоянием данных. Каждое изменение сохраняется как неизменяемое событие. Можно восстановить экземпляр процесса, получить информацию о поведении системы, восстановить данные, если отследить или выполнить связанные события.

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

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

С точки зрения состава требований понадобятся:
📍структура события – состав атрибутов, обязательность, порядок заполнения;
📍типы событий – сама модель того, что должно сохраняться (OrderCreated, OrderCompleted и пр.);
📍место и политики хранения (где и как долго хранить. Этот и следующий пункт больше к СА или архитектору);
📍механизмы доставки и воспроизведения.

В части структуры и типов в моем случае сложным оказалось перекладывание бизнес-понимания шагов процесса на события в системе. За шагом вида "подать заявку" прячутся десятки взаимодействий между сервисами: для валидации данных, проверок дубликатов, обработки исключений и пр. Это связать с процессом особенно непросто, когда сам процесс не представлен в формате автономных задач с понятными входом и выходом. Здесь как раз вспомнился BPMN c его токенами. Звучит занудно, но не могу удержаться 🙈 Адекватную модель процесса гораздо проще переложить на архитектурное решение, чем наоборот – подстраивать одно под другое.

📚По традиции делюсь материалами:
Гайд по эвент-сорсингу
Знакомимся с Event Sourcing

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

Как из меня не получилось звезды учебного ролика

Давно не писала — то времени нет, то слов 😊 Пятница располагает рассказывать истории. Расскажу о своем новом опыте.

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

«Просто будь собой» Я готовилась серьёзно: составила скрипт рассказа, отрепетировала, записала себя на диктофон и оценила хронометраж. Составить текст на три минуты рассказа, чтобы передать суть и при этом не раскрыть весь материал дословно – это задача гораздо сложнее, чем написать длинное сочинение. Хорошая тренировка, чтобы излагать мысли коротко.
Как настоящий эксперт в пользовательских исследованиях, я решила проверить впечатления от новой фичи на собственном сыне-студенте. Более релевантных представителей целевой аудитории не оказалось рядом в 22:00 воскресенья. Он выдал:"Ты только не обижайся, но ты слишком стараешься. Звучишь как диктор в языковом упражнении "повторите за спикером""
А не стараться оказалось ужасно сложно 🤷‍♀️

Аллергия и клаустрофобия Это что-то про «эргономику рабочего места». Я должна была стоять в студийном помещении в заданной точке перед микрофоном, камерой и пустым теле-суфлером, потому что я решила не готовить для него текст. С моей близорукостью все равно ничего толком не видно.
Грим раздражает пудрой и непривычными запахами, вокруг серые звукоизолированные стены, двойные двери плотно закрыты. За дверьми режиссер, который дает команды и рекомендации через динамик. У вас никогда не было приступа аллергии и клаустрофобии одновременно?
В итоге не получилось ни быть собой, ни соблюдать хронометраж – я протараторила свой скрипт почти на треть времени быстрее.

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

Теперь жду что получилось. Кинодивой я не стала, но зато узнала чего стоит производство контента и получила новую забавную историю 🎥

#истории

Распаковка рюкзака с конференции

Выходные заняла поездка на конференцию Merge в Иннополис. Когда начала записывать, получилась целая серия заметок, я их назвала "распаковка рюкзака". Сегодня первая часть распаковки 👇

Распаковка рюкзака с конференции 2. Коллективное лидерство

В рюкзаке нашлись еще заметки о докладах. Сейчас про доклад под названием "Коллективное лидерство: как сделать ответственность желанной, а ценность постоянной" (программа тут)

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

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

Обсудили саму природу лидерства. Имелось в виду не формально назначенное лидерство, а именно сформированное в команде, когда она признает в ком-то вожака. От такого лидера ожидается:
📍Наставничество;
📍Поддержание атмосферы;
📍Медиация, как функция третейского судьи в случае конфликтов;
📍Объективность;
📍Этический ориентир, бывает, что кто-то задает тон коммуникаций и производительности в команде. "Если лидер не спешит, то почему всем остальным нужно" и наоборот, "а у него отлично получается и я так хочу".

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

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

Как вам такой подход? Мне показался интересным, я бы к этому добавила еще совет почитать книгу Дейва Пинка "Драйв" в продолжение темы мотивации.

Где-то на дне рюкзака осталось еще пара заметок, скоро вернусь со следующей распаковкой 🎒

#конференции #инструменты #agile

Распаковка рюкзака с конференции 3. Закон Миллера, Монте-Карло и dogfooding

Еще порция заметок с недавней Merge.

Большинство аналитиков неправильно используют требования и их классификацию. А ты? Рассказ о подходах к классификации требований и ее целях. Доклад в программе.
По закону Миллера кратковременная память человека оперирует количеством элементов от 5 до 9. Как только вы пытаетесь впихнуть в границы анализа больше, получается каша, которую сложно обработать. Мозг пытается сгруппировать увиденное и свести к посильному количеству знакомых объектов, так за деталями теряются цели и "дорисовываются" объекты.
Принципы ООП тоже работают для требований, помогают сократить количество объектов. Абстрагирование — выделение только значимых элементов. Инкапсуляция - скрывание деталей системы и фокус на её взаимодействии с внешним миром.
Классификация помогает выделить уровни информации и на каждом оперировать только теми объектами, что для него значимы. Плохо работает "верхнеуровневое БТ", где вперемешку указаны цели доработки, требования к решению, куски архитектуры и json-схемы.
📌Классификация требований не для обозначения уровней детализации, а для снижения сложности
📌Требования задают контракт: зоны ответственности и компетенций
📌Формулировать системные требования нужно так, чтобы оставить проработку деталей реализации другим компетенциям. За деталями теряется целое и возникают лишние ограничения
📌Не следует подменять работу с требованиями полным проектирование системы.

Тут вспомнила доклад Юрия Куприянова на Flow, что требования плотно связаны с решением, что описание требований свелось к придумыванию решения вместе с заказчиком. Есть и такое мнение.

От покера до футболок, выбор метода оценки ИТ задач. Доклад в программе. Советы по методам оценки задач. Метод важно выбрать соответственно ситуации. Если 10 специалистов час сидят на встрече по планированию задач, это суммарно10 часов рабочего времени потрачено. У каждого метода свои условия применения и своя чувствительность к неопределенности, зависимостям, сложности. Речь шла о таких методах:
📌Scrum покер, когда используются карты с цифрой оценки и участники одновременно открывают свои карты. Подходит для небольших команд и хорош вовлечением участников, требует опыта и времени на обсуждение.
📌Метод футболок, когда оценка дается буквой S,M,L. Подходит для небольших команд, простой и понятный, но не точный.
📌Три амиго, когда эксперты разных областей (DEV,BA/SA,QA) обсуждают задачу. Хорош для задач с высоким уровнем неопределенности, требует времени ключевых экспертов.
📌PERT, когда оцениваются сценарии оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Итоговую оценку подсчитывают как (O+4*R+P)\6. Учитывает неопределенность, подходит для сложных и долгосрочных проектов, но сложен и зависит от точности оценок.
📌Монте-Карло, статистический метод на основе данных о сроках выполнения задач из таск-трекера. Для начала нужны данные не менее, чем за 7 недель работы команды. Метод зависит от качества статистической модели, но хорошо визуализирует результаты расчетов и подходит для сложных проектов. Несколько слов о методе привозила с Dump в феврале тут.

Пока ждем записей докладов в общем доступе можно посмотреть в этом канале пост о техниках оценки задач.

Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна. Доклад в программе. Dogfooding – это использование сотрудниками компании продуктов этой же компании для анализа достоинств и недостатков. Название пришло от производителей собачьего корма, среди которых кто-то утверждал что готов съесть свой прекрасный продукт сам, а кто-то съел банку корма на собрании акционеров (подробнее в статье)
Доклад о том, как организован процесс. Смутили две вещи. 1) Процесс на добровольных началах и организаторы, и участники работают на добровольных началах вне основных задач. 2) По наблюдениям автора не более 50% собранных замечаний ложатся в бэклоги команд разработки, а остальное – дубли, уже известные идеи и пр.

На этом все распаковала. Всем прекрасных майских выходных 🔅

#конференции

BAST или мы так и не знаем чем занимается аналитик

Две недели назад коллега прислал файл с The Business Analysis Standard от IIBA. В некоторых статьях этот документ называют BAST. Добралась посмотреть. Интересно же, что нового придумали в IIBA, кроме BABOK, так и оставшегося в версии 3.0 от 2015 года?

BA Standard в первой версии появился под названием The Global Business Analysis Core Standard, сейчас доступна уже вторая его версия. Показательно, что ссылка на скачивание содержит название The-Standard, если дословно переводить, то можно сказать "единственный и уникальный". Сам материал на 58 страницах стандарта я бы не назвала принципиально новым. В предисловии так и сказано, что все 6 сфер знания и 30 аналитических задач остались неизменными.

В одном из экспертных чатов эту книгу назвали "выжимка из BABOK" и действительно выглядит именно так.
В BA Standard те же ключевые принципы бизнес-анализа, изложенных в BABOK Guide. Из нового: дополнены разделы о мышлении бизнес-аналитика (business analysis mindset), сделан акцент на зоны ответственности аналитика в рамках разных подходов к организации задач (approaches), они бывают каскадные (predictive), гибкие (agile) и гибридные.

Интереснее наблюдать за изменением общего подхода IIBA. Похоже, что подход меняется с учетом растущего количества очень разных аналитиков в очень разном контексте и делается попытка дать общий ответ на вопрос "чем же занимается аналитик?" В начале нулевых эта роль была новой и BABOK среди прочих стандартов помогал в ней разобраться, с тех пор аналитики разбрелись по разным направлениям и вопрос "чем же занимается аналитик?" очень актуален снова.

Новый документ ориентирован на более широкую аудиторию, включая руководителей организаций и специалистов разных ролей. Зачем он им? Чтобы объяснить роль аналитика и быть источником терминологии и стандартизированного словаря в области бизнес-анализа как его понимает IIBA😉 Предполагается BA Standard обновлять каждые полтора-два года. Это не просто краткая версия BABOK Guide, это ось для других публикаций IIBA и содержит на них ссылки:
📍BABOK Guide,
📍Agile Extension,
📍Business Data Analysis Guide,
📍Product Ownership Analysis Guide.

В отличие от прочих изданий BA Standard можно скачать свободно по ссылке, в обмен на ваши персональные данные 😊

Поиском по Хабру и по ТГ нашлось не слишком много статей. Поделюсь парой обзоров:

📚Сопоставление «The Business Analysis Standard» IIBA с профстандартом бизнес-аналитика РФ
📚(EN) Статья в блоге IIBA The BAST: The New Gravitational Centre of Business Analysis

#что_почитать #книжки

Про роль аналитика и переход из нее

В выходные разбирала всякое, что отложила посмотреть-почитать. Встретила пару публикаций, которые в очередной раз меня завели в мысли о ролях.

📌Как не скатиться в имитацию: о роли системного аналитика на проекте Это о системных аналитиках, но в том же ключе можно поговорить и о БА. Разве это редкость когда БА\СА неявно выполняют обязанности смежных ролей? или когда не удается выстроить общий процесс проектирования и аналитик превращается в разновидность то ли бюрократа, то ли наоборот человека-оркестра? В итоге может быть роль аналитика и не нужна в конкретном проекте, если нет необходимости детально проектирования, а отдельные функции уже выполняет кто-то другой?

В статье есть пара спорных моментов. Например, меня расстраивают формулировки вида «переводчик языка бизнеса в язык разработки» - традиционное упрощение большого объема работ по синтезу и анализу информации. Заглянула в BA Standard из предыдущего поста и он говорит о ролях и профессиях вполне созвучно со статьей.

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

📌Еще встретилось видео, где коллега делится опытом перехода из аналитиков в продакты здесь многое обсуждается: как состоялся переход, разница в работе продакта в B2B и B2C, роль продакта в заказной разработке, собеседования на позицию продакта. Но мне больше всего отозвался тезис о том, что переход в продакты должен быть связан с желанием большего влияния на продукт. Если вы не готовы взять на себя ответственность за решения по продукту и результаты этих решений, то работа станет в тягость. При этом деньги можно заработать и в роли эксперта 🌱

#мысливслух #что_почитать