Функциональная декомпозиция

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

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

Вот такая рекомендация есть в книге "Принципы работы с требованиями к программному обеспечению" Дина Леффингуэлла и Дона Уидрига

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

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

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

Было бы нечестно промолчать про ограничения:
▫️За декомпозиций функций можно упустить другие важные вещи: потоки данных или взаимодействие пользователей. Узкий взгляд именно на функции приводит к потере других важных составляющих системы. Я здесь под "системой" имею в виду именно совокупность взаимодействующих объектов, не обязательно автоматизацию.
▫️Декомпозиция часто основана на предположениях о процессах и связях между функциями. Предположения могут быть ошибочными, в результате вместо прозрачности и упрощения привести к путанице и непониманию.
▫️При функциональной декомпозиции остаются без внимания нефункциональные требования, о которых важно не забыть.

Каждый сложный объект допускает несколько альтернативных декомпозиций. Исследование всех альтернатив может быть сложной и трудоемкой задачей, тогда как выбор единственной альтернативы может игнорировать важные возможности и привести к неоптимальному решению (Из BABOK 3.0)

▫️Для сложных систем иерархия функций может оказаться многоуровневой и содержать непростые зависимости между разными уровнями. Обратите внимание, на картинке дерево функций (Feature tree) из статьи К. Вигерса Using Feature Trees To Depict Scope. Здесь всего три уровня, но выглядит ли картина простой?

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

P.S. В этом контексте вспомнила давний обзор статьи о масштабируемой структуре требований, там есть пример декомпозиции в формате mind map.

#инструменты

3 статьи про коммуникации. Подборка

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

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

📍Эффективное управление отношениями со стейкхолдерами Это перевод статьи из блога Miro, похоже на инструкцию, где перечислены основные инструменты управления заинтересованными сторонами

📍Берем ответственность за вопросы: как задавать их правильно Статья о роли вопросов в коммуникации, еще в ней есть описание методов "5 почему" и "Score+", может быть интересно, если еще не сталкивались с этими методами

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

ИТ инсайды

Собрались вместе с другими авторами в папку "ИТ инсайды". В ней 9 каналов.

Ребята рассказывают очень ярко и эмоционально про свою работу, про тренды в ИТ, про PR, безу и менеджмент.
А еще, про СА и БА, GO, фронтенд и, конечно, AI. И, периодически, делают обзоры с крупнейших ИТ конференций.

Перейти к папке "ИТ инсайды"

Аналитики и их диаграммы. Второй день Flow

Вчера завершилась Flow, а вместе с ней и моя поездка, в которой я так и не увидела в Петербурге ничего, кроме пробки у Московского вокзала 🤷‍♀️

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

📌BPMN — стандарт, но все всё равно рисуют ерунду. Что делать? Доклад Дениса Котова о противоречиях в формальном стандарте BPMN от компании Object Management Group (OMG) и в том числе об использовании дорожек (любимое противоречие автора), которые применяют для выделения ролей в процессе, что совершенно не обязательно и не указано в стандарте, он рекомендует исполнителей прописывать в каждой задаче. Стандарт не решает задачу единого языка для аналитиков. Речь пошла о том, что можно заключить новое общее соглашение о моделировании, чтобы дать общее понимание стандартов BPMN и улучшить работу с диаграммами. Улучшить предлагается среди прочего за счет отказа от редких типов диаграмм (conversation diagram), комплексных шлюзов, некоторых типов задач (global task, script task) и событий (cancel event, multiply event, parallel event), а еще двусмысленных приемов для ленивых аналитиков (ad hoc process).
📌Проекты оптимизации бизнес-процессов — как с ними жить? Здесь был рассказ об опыте спикера в обследовании процессов и внедрении изменений. На основе собственных ошибок и достижений спикер предложила несколько правил. 1) Анализировать данные параллельно с обследованием процесса, чтобы не пропустить важных сценариев, о которых могут не рассказать на обследовании; 2) изучать причины хейта и внимательно работать в первую очередь с основными недоброжелателями изменений; 3) нужно просить примеры, документы, результаты выполненных задач; 4) больше времени выделять на первичное исследование. Мне запомнился слайд, где предлагалась разбивка времени проекта: 40% на первичный анализ, 10% – согласование, 40% разработка, 10% – приемка и кастомизация.
На дискуссии после доклада зазвучали общие для всех боли "как довести требование до разработчика", "как договориться, чтобы выделили столько времени на первичный анализ" 🌱
📌UML и другие графические нотации: что актуально в 2024 году? Исследование, мнения, практика Доклад Юрия Куприянова, в котором он поделился результатами исследования с целью понять насколько UML актуален. Было опрошено 275 респондентов, из них больше половины – это СА и БА. Из сказанного для себя отметила: 1) порядка 80% участников создавали диаграммы хотя бы несколько месяцев назад и что-то использовали из UML, архитекторы и разработчики меньше, СА - больше; 2) на вопрос "зачем создавали" самый частый ответ "как часть документации"; 3) небольшая корреляция между размером компании, использованием Agile, возрастом аналитика и использованием UML. Еще обсудили какие еще нотации применяют коллеги и какие диаграммы UML чаще используют. А вы как думаете, какие?

Завершал конференцию доклад Александры Клименко о коммуникациях "Как расти в карьере, налаживать связи и двигать проект вперед, если ты аналитик?". Здесь можно было выходить к микрофонам и тренироваться в предложенных сценариях коммуникации. В этих сценариях нужно суметь правильно отреагировать на эмоции собеседника или обозначить свои границы, когда тебе говорят что-то вроде "Аналитики такие нежные пошли! " Сложно пересказывать интерактив, буду надеяться, что рано или поздно появятся записи и тогда смогу обратить ваше внимание на них 🔅

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

Осенний аналитический марафон

Сегодня я снова о конференции. На этот раз об Analyst Marathon #11, которая прошла 28 сентября. На улице с утра в субботу шел дождь, в моем фитнес-зале всю прошлую неделю шел ремонт, так почему бы не подключиться к душевной онлайн-конференции?

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

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

📍Системный аналитик в водовороте событий: проектируем метрики продукта Доклад Никиты Харичкина начался с того, как важно проследить путь от идеи фичи до понимания как она работает после внедрения. Затем определились термины "событие" – уникальный набор параметров в конкретный момент времени, "метрика" – конечные измеримые показатели, собираемые из события. Было много прикладной информации о том как собрать и вести каталог событий.

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

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

📌Пигмалион. Как воспитать стейкхолдера, доклад Ирины Гертовской. Это был развернутый рассказ о базовых техниках анализа заинтересованных сторон (луковичной диаграмме, карте стейкхолдеров) с небольшими комментариями из практического опыта и сценариями на примере персонажей пьесы Бернарда Шоу "Пигмалион".
Здесь я записала фразу "думай о клиенте своего клиента". Если идет работа над приложением для врачей, то "клиенты клиента" – это пациенты, у них могут быть свои интересы, связанные с системой.

📌Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях В этом докладе Михаил Максимов один вывод последовательно нанизывал на другой и в завершении привел разбор примера. Разговор шел о том, как выбрать нужный для конкретной задачи тип модели и нотацию. Важно понять для кого, какой целью, в какой срок строится модель. При выборе нужно подумать, какое представление и с каких точек зрения (организационной, действий и бизнес-процессов, функциональной или информационной структуры, информационных потоков, автоматизации операций) потребуется для решения задачи.

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

Две разные причины одинаковых неудач

За этот пост я принималась пять раз и пять раз откладывала. Угол темы какой-то коварный, но все равно хочу поделиться наблюдением.

В роли ментора у меня есть возможность наблюдать очень разных менти. Бывает, кто-то делает первые шаги в профессии после вуза. Бывает, после 15-20 лет работы с финансовыми отчетами кто-то хочет заняться проектированием ИТ-систем. Свои учебные цели и те и другие проваливают с одинаковым результатом, но интересно наблюдать какие разные причины.

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

🔅Оказалось, что люди с опытом тоже легко проваливают отработку навыков. Самое обидное, что в некоторых я неожиданно узнавала себя слов в слово. "У меня хорошее образование и большой опыт, я быстро освою эти ваши C4/Rest Api/Описания фич/что угодно еще." "Я 15 лет занимаюсь SAP, ну что я диаграмму последовательности не пойму что ли?" При этом мешают сосредоточиться уже не только дофамины с эндорфинами, но и груз ответственности: работа, родительские собрания в школе и ежедневный список из десятка дел. В общей суматохе бывает тяжело запомнить что такое "функциональные требования". И непонятно зачем запоминать, неужели "на месте не разберемся"? Результат тот же – навык не формируется даже на уровне тестовых заданий.

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

#мысливслух

С кем важно говорить о требованиях на самом деле?

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

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

Отношения
Как только в компании планируются изменения, у них сразу появляются друзья и враги.
Тот, кто заинтересован в результатах вашей задачи, может давать больше информации, активно загружать аналитика своими идеями. Жаль, что заинтересованность не обязательно совпадает с важной ролью и полномочиями в принятии решений.
Например, когда аналитик выбирается "в поля" пообщаться с конечными пользователями, то часто видит очень высокую заинтересованность. Это же те, кто каждый день спотыкается о наши поля и кнопки! У них много идей и требований. Вернувшись на рабочее место, аналитик обнаруживает, что полномочий принимать решения и высокого влияния у коллег "в полях" совсем немного.
Отношение к задаче может меняться со временем и это тоже приходится отслеживать. Например, если функция не внедряется вовремя, то и заинтересованность может снизиться.

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

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

#инструменты

Что здесь есть о BPMN?

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

🔅Сколько нужно времени, чтобы проснуться и выпить кофе?
🔅Вопросы для процессных аналитиков
🔅Разнообразие начальных событий в BPMN

#навигация

В царстве смекалки

Еще одна книга из библиотеки моих родителей. Конечно, в момент первой публикации в 1908 году еще и бабушек моих на свете не было, а вот издание 1982 года нашлось на полках.

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

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

Это из 1911 года, а как актуально звучит вопрос всяких машин и приспособлений, правда?

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

В  комнате четыре угла. В  каждом углу сидит кошка. Напротив каждой кошки по три кошки. На  хвосте каждой кошки по одной кошке. Сколько же всего кошек в комнате?

Ответ: 4 кошки

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

Мне досталось издание 2017 года, в нем решение задачи написано сразу под задачей и это сильно сбивает, особенно для простых задач решение видишь быстрее, чем саму задачу. Может быть так было и в 1908 году?

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

О других книгах с логическими задачками
Как же называется эта книга? Рэймонд М. Смаллиан
Считай, смекай, отгадывай! Труднев В.П.

#книжки

Подборка о работе с процессами

Вы помните, какой сегодня день недели? Или как и я начали день с полным ощущением понедельника?

Вчера, как бывает по воскресеньям, разбирала список для чтения. Еще и поэтому сложно вытряхнуть из головы понедельник 🤷‍♀️ Зато получилась подборка об управлении процессами.

📍Нюансы менеджмента процессов на примере процесса «Управление инцидентами ИТ» Эту статью оставила в закладках, чтобы еще раз перечитать. Здесь на конкретном примере показано управление процессом и почему сначала должен появиться управляемый процесс и уже после KPI.

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

📍Российское представительство ABPMP (Ассоциация профессионалов управления бизнес-процессами) опубликовало на Rutube свои материалы. Можно найти полезные видео о моделировании процессов и их оптимизации. И все это от настоящих мастеров.

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

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