Промпт для генерации BPMN — удивительно, но оказалось сложно найти хороший. Я сам не очень часто создаю диаграммы процессов, но как-то думал, что уж эта проблема давно решена. Но нет, из коробки только топовые модели — ChatGPT, Claude+ — могут сгенерить нормально, остальные сбиваются:
— то забудут диаграмму нарисовать (в XML-формате нужно же отдельно процесс описать, и отдельно диаграмму),
— то в диаграмме пишут совсем другие id,
— то стрелки вразнобой лепят.
Во многих инструментах уже генераторы встроены. Но не у всех они есть, у многих плагин в Confluence, и всё.
Но я всё-таки нашел и немного переделал промпт, вот, держите: https://github.com/yksi12/prompts/blob/main/generate-bpmn-prompt.md
Очень интересна обратная связь, расскажите, как у вас получилось. Ну или если вы пользуетесь чем-то другим для генерации BPMN-диаграмм, и оно хорошо работает — поделитесь в комментах!
— то забудут диаграмму нарисовать (в XML-формате нужно же отдельно процесс описать, и отдельно диаграмму),
— то в диаграмме пишут совсем другие id,
— то стрелки вразнобой лепят.
Во многих инструментах уже генераторы встроены. Но не у всех они есть, у многих плагин в Confluence, и всё.
Но я всё-таки нашел и немного переделал промпт, вот, держите: https://github.com/yksi12/prompts/blob/main/generate-bpmn-prompt.md
Очень интересна обратная связь, расскажите, как у вас получилось. Ну или если вы пользуетесь чем-то другим для генерации BPMN-диаграмм, и оно хорошо работает — поделитесь в комментах!
GitHub
prompts/generate-bpmn-prompt.md at main · yksi12/prompts
Сборник промптов для системного анализа, проектирования систем и создания промптов - yksi12/prompts
👍38❤3
Ну что, нужно искать запасной аэродром, резервную площадку. Пока создал канал в Сетке, мне она наиболее симпатична: https://setka.ru/communities/019ce261-eb50-7e61-82e0-8950e9a1de7e
Подписывайтесь, если вы там есть.
А так — выбирать вообще не из чего, "там скука, там обман иль бред, в том совести, в том смысла нет". В ВК пробовал писать, у меня там давно аккаунт, но вообще нет просмотров. В Max не хочу, в Дзен тоже как-то не очень. Что у нас ещё есть? Где вы кого читаете, кроме телеграма?
Из телеги, если что, уходить не собираюсь, пока будет техническая возможность.
Подписывайтесь, если вы там есть.
А так — выбирать вообще не из чего, "там скука, там обман иль бред, в том совести, в том смысла нет". В ВК пробовал писать, у меня там давно аккаунт, но вообще нет просмотров. В Max не хочу, в Дзен тоже как-то не очень. Что у нас ещё есть? Где вы кого читаете, кроме телеграма?
Из телеги, если что, уходить не собираюсь, пока будет техническая возможность.
Сетка
Системный сдвиг. Канал в Сетке
Записки о нетривиальных темах в системном анализе, архитектуре систем и управлении продуктами
❤26👍11👎9🤨8
Object Management Group (OMG) — международный консорциум, поддерживающий, в числе прочего, такие стандарты, как UML, BPMN и Essence — официально объявил, что в современных условиях о моделировании процессов не может идти речи, т.к. реально (по эмпирическим данным) никакие процессы не выполняются, даже если они формально замоделированы.
Поэтому OMG анонсировал разработку новой нотации: OMG ChTO? 1.0 (Chaos Towards Orientation)
Обоснование OMG: предыдущие стандарты основаны на логике различных модальностях, а в современных условиях никакой логики ни в проектах, ни в деятельности, ни в управлении не наблюдается, что требует новых инструментов моделирования.
Особенности нотации, о которых уже известно:
👉 В качестве стартового события будет использоваться иконка 🔥 с подписью "Всё горит" или просто "АААААА!!!"
👉 Шлюзы будут изображаться в виде дайса (кубика) D20 🎲 , все ветвления определяются случайным образом со сложной системой модификаторов (на данный момент в разработке).
👉 Названия шагов будут автоматически размываться при отображении и печати диаграммы, это обязательное требование к инструментам моделирования. При сохранении в XML названия шагов будут хэшироваться с неразглашаемой солью.
👉 Соединительные линии отображаются, как клубок запутанных ниток➿, причем при добавлении соединения шаг также автоматически связывается со всеми предыдущими шагами, обеспечивая положительную обратную связь и принципиальную разбалансировку системы.
👉 Также обязательным элементом любой диаграммы будет "черная дыра слива ресурсов", когда процесс преобразует входные ресурсы и управление в обогрев окружающей среды, и на выходе не получается никакого более-менее осязаемого результата.
Теория хаоса не является чем-то новым в моделировании, например, известна классическая статья Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1, DOI: 10.1145/225907.225914, на которую так или иначе опираются многие agile-методы. Ну а с точки зрения физики и философии это описано ещё раньше, в работах Пригожина и Стенгерс.
И вот теперь, через 30 лет, у нас наконец появится нотация, позволяющая адекватно описывать реальность!
Крупнейшие поставщики средств моделирования и исполнения, такие как Camunda, Draw.io и Bizagi уже объявили о поддержке нотации в режиме закрытого альфа-тестирования.
ВАЖНО: пока ни одна из известных LLM-моделей не может составить адекватную модель OMG ChTO? по текстовому описанию или расшифровкам интервью, так что эта зона в ближайшем будущем точно останется за человеком. Работать с нотацией ИИ-моделям не позволяет архитектура: многочисленные инструменты балансировки "креативность-надежность" (штрафы за повторения, температура, отсечения Top-k и Top-p) подгоняют энтропию результата к ожидаемой для среднего "разумного" текста, но это оказывается очень далеко от реально происходящих процессов в компаниях.
В экспериментах для генерации требуется установка сверхвысоких значений температуры (T>0.95) и понижения жесткости отсечения, но даже в этих условиях вывод чрезмерно стабилен.
Вот так, никакой машиной не заменишь человека, готового лицом к лицу встретиться с реальным хаосом.
Поэтому OMG анонсировал разработку новой нотации: OMG ChTO? 1.0 (Chaos Towards Orientation)
Обоснование OMG: предыдущие стандарты основаны на логике различных модальностях, а в современных условиях никакой логики ни в проектах, ни в деятельности, ни в управлении не наблюдается, что требует новых инструментов моделирования.
Особенности нотации, о которых уже известно:
Теория хаоса не является чем-то новым в моделировании, например, известна классическая статья Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1, DOI: 10.1145/225907.225914, на которую так или иначе опираются многие agile-методы. Ну а с точки зрения физики и философии это описано ещё раньше, в работах Пригожина и Стенгерс.
И вот теперь, через 30 лет, у нас наконец появится нотация, позволяющая адекватно описывать реальность!
Крупнейшие поставщики средств моделирования и исполнения, такие как Camunda, Draw.io и Bizagi уже объявили о поддержке нотации в режиме закрытого альфа-тестирования.
ВАЖНО: пока ни одна из известных LLM-моделей не может составить адекватную модель OMG ChTO? по текстовому описанию или расшифровкам интервью, так что эта зона в ближайшем будущем точно останется за человеком. Работать с нотацией ИИ-моделям не позволяет архитектура: многочисленные инструменты балансировки "креативность-надежность" (штрафы за повторения, температура, отсечения Top-k и Top-p) подгоняют энтропию результата к ожидаемой для среднего "разумного" текста, но это оказывается очень далеко от реально происходящих процессов в компаниях.
В экспериментах для генерации требуется установка сверхвысоких значений температуры (T>0.95) и понижения жесткости отсечения, но даже в этих условиях вывод чрезмерно стабилен.
Вот так, никакой машиной не заменишь человека, готового лицом к лицу встретиться с реальным хаосом.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁80👍18🤡11🔥7❤5
Пригласили меня тут в жюри школьного проектного конкурса, и вот что хочу сказать: мало кто может сформулировать проблему.
А точнее — отличить проблему от факта.
В основном авторы проекта в качестве проблемы формулируют некий факт. "Школьники стали реже заниматься спортом". "Мало кто знает историю своего района". "В школе часто меняется расписание".
Это не проблемы, это факты. Их можно проверить. С ними ничего не происходит, это просто замеры, констатация. Возможно, это симптом или причина проблемы. Если вас это почему-то беспокоит, можно покопать и докопаться до проблемы, к которой эти факты приводят. К каждому такому факту можно задать вопрос "ну и что?", это будет шагом к определению проблемы.
Мы не можем "решить" факт. Можем как-то изменить реальность, чтобы изменились факты (произошел импакт). Но чтобы понять, в какую сторону менять — нужно сформулировать проблему.
Для школьников это нормально, они ещё учатся. Но то же самое происходит и в рабочей практике! И у аналитиков, когда они берутся за разбор какой-то темы или запроса от пользователей. "Медленно работает запрос". "У пользователей нет возможности скачивать документ с предыдущими изменениями".
Тут мы видим ещё один частый антипаттерн: формулировка через отсутствие. "Не внедрена CRM". "Отсутствует возможность сделать ...", "У школьников нет понимания ...", "Задачи по математике не привязаны к реальной жизни" и т.д. Это тоже факт. Ну да, чего-то нет. Почему это проблема? А оно вообще нужно? А почему? А кому? А зачем?
Следующая частая ошибка — формулировка не проблемы, а задачи. "Требуется реализовать возможность проверки действительности паспорта". "Сделать импорт ФИО студентов из файла". Если вы думаете, что такую фразу сложно представить, как проблему, то нет: "Проблема: оказание помощи отстающим ученикам". "Проблема: уменьшение числа заявок, введенных с ошибками".
Ну в чем проблема — возьмите, да окажите. И делайте меньше ошибок.
Проблема отличается от задачи как раз отсутствием понятного решения. Мы видим некоторый разрыв, но что с ним делать — непонятно. Если перед нами задача — нам не нужен аналитик.
Собственно, аналитик нужен, чтобы превратить проблему в набор задач.
(А продакт — чтобы понять, какие проблемы стоит решать)
Что должно быть в формулировке проблемы? Там должен быть разрыв.
"Наблюдается [X], а должно быть [Y], поэтому происходит [Z]"
X — это как раз наш факт. Ему обычно не хватает Y — а как должно быть? И Z — что плохого из-за этого случается?
"Школьники стали реже заниматься подвижными играми на переменах [тут должны быть данные, как раньше, и как сейчас], поэтому на последних уроках им тяжелее концентрироваться"
Тут должно быть обоснование этой связки "подвижные игры — концентрация", потому что дело может быть в чем-о другом, например, в перенасыщенности CO2 в классах.
Причины потери концентрации требуют отдельного исследования, которое в реальной жизни мало кто делает. Ну вспомните, давно ли вы рисовали причинно-следственную диаграмму? Да ещё с опорой на данные, а не потому, что так всем кажется?
Следующий вопрос — чья это проблема? Кто страдает? Школьники, учителя, родители? Администрация школы, которой дадут по шапке за низкие результаты?
Итого, получается несколько проверок на формулировку проблемы:
1. В формулировке есть разрыв (можно сформулировать конструкцию XYZ,описанную выше)
2. Есть "владелец боли". Ясно, кто страдает, и понятен негативный эффект.
3. От боли нельзя отмахнуться. Понятно, что если ничего не сделать сейчас — ситуация будет ухудшаться, возникнут риски.
4. Формулировка не содержит упоминания конкретного способа решения. При прочтении непонятно, что делать.
5. В формулировке нет субъективных оценок (медленно, неудобно, сложно, непонятно, плохо).
6. Формулировка не содержит отрицания, не упоминает отсутствие чего-либо.
7. Сформулирована ровно одна проблема (нет и/или/запятых).
Зачем вообще выявлять и формулировать проблему? Почему не сразу брать в работу? Чтобы деятельность была осмысленной; чтобы решать проблемы, а не пилить задачи. Чтобы обоснованно выбирать, что делать.
А точнее — отличить проблему от факта.
В основном авторы проекта в качестве проблемы формулируют некий факт. "Школьники стали реже заниматься спортом". "Мало кто знает историю своего района". "В школе часто меняется расписание".
Это не проблемы, это факты. Их можно проверить. С ними ничего не происходит, это просто замеры, констатация. Возможно, это симптом или причина проблемы. Если вас это почему-то беспокоит, можно покопать и докопаться до проблемы, к которой эти факты приводят. К каждому такому факту можно задать вопрос "ну и что?", это будет шагом к определению проблемы.
Мы не можем "решить" факт. Можем как-то изменить реальность, чтобы изменились факты (произошел импакт). Но чтобы понять, в какую сторону менять — нужно сформулировать проблему.
Для школьников это нормально, они ещё учатся. Но то же самое происходит и в рабочей практике! И у аналитиков, когда они берутся за разбор какой-то темы или запроса от пользователей. "Медленно работает запрос". "У пользователей нет возможности скачивать документ с предыдущими изменениями".
Тут мы видим ещё один частый антипаттерн: формулировка через отсутствие. "Не внедрена CRM". "Отсутствует возможность сделать ...", "У школьников нет понимания ...", "Задачи по математике не привязаны к реальной жизни" и т.д. Это тоже факт. Ну да, чего-то нет. Почему это проблема? А оно вообще нужно? А почему? А кому? А зачем?
Следующая частая ошибка — формулировка не проблемы, а задачи. "Требуется реализовать возможность проверки действительности паспорта". "Сделать импорт ФИО студентов из файла". Если вы думаете, что такую фразу сложно представить, как проблему, то нет: "Проблема: оказание помощи отстающим ученикам". "Проблема: уменьшение числа заявок, введенных с ошибками".
Ну в чем проблема — возьмите, да окажите. И делайте меньше ошибок.
Проблема отличается от задачи как раз отсутствием понятного решения. Мы видим некоторый разрыв, но что с ним делать — непонятно. Если перед нами задача — нам не нужен аналитик.
Собственно, аналитик нужен, чтобы превратить проблему в набор задач.
(А продакт — чтобы понять, какие проблемы стоит решать)
Что должно быть в формулировке проблемы? Там должен быть разрыв.
"Наблюдается [X], а должно быть [Y], поэтому происходит [Z]"
X — это как раз наш факт. Ему обычно не хватает Y — а как должно быть? И Z — что плохого из-за этого случается?
"Школьники стали реже заниматься подвижными играми на переменах [тут должны быть данные, как раньше, и как сейчас], поэтому на последних уроках им тяжелее концентрироваться"
Тут должно быть обоснование этой связки "подвижные игры — концентрация", потому что дело может быть в чем-о другом, например, в перенасыщенности CO2 в классах.
Причины потери концентрации требуют отдельного исследования, которое в реальной жизни мало кто делает. Ну вспомните, давно ли вы рисовали причинно-следственную диаграмму? Да ещё с опорой на данные, а не потому, что так всем кажется?
Следующий вопрос — чья это проблема? Кто страдает? Школьники, учителя, родители? Администрация школы, которой дадут по шапке за низкие результаты?
Итого, получается несколько проверок на формулировку проблемы:
1. В формулировке есть разрыв (можно сформулировать конструкцию XYZ,описанную выше)
2. Есть "владелец боли". Ясно, кто страдает, и понятен негативный эффект.
3. От боли нельзя отмахнуться. Понятно, что если ничего не сделать сейчас — ситуация будет ухудшаться, возникнут риски.
4. Формулировка не содержит упоминания конкретного способа решения. При прочтении непонятно, что делать.
5. В формулировке нет субъективных оценок (медленно, неудобно, сложно, непонятно, плохо).
6. Формулировка не содержит отрицания, не упоминает отсутствие чего-либо.
7. Сформулирована ровно одна проблема (нет и/или/запятых).
Зачем вообще выявлять и формулировать проблему? Почему не сразу брать в работу? Чтобы деятельность была осмысленной; чтобы решать проблемы, а не пилить задачи. Чтобы обоснованно выбирать, что делать.
❤39👍31🔥20💯9👌1
Агентство NewHR выпустило исследование рынка аналитиков. Как типичные HR-ы, они не стали разбираться в разных видах аналитиков, поэтому свалили в кучу вообще всех — бизнес-, системных, дата-, и даже маркетинговых с финансовыми.
Можно пойти дальше, и проанализировать вообще все профессии на букву "А", ну а что? Есть же у них что-то общее! Например, все они люди и все где-то работают.
Но даже из этой каши можно вытащить крупицы смысла.
Например, с точки зрения эйджизма лучше всех себя чувствуют как раз системные и бизнес-аналитики: 19 и 17% соответственно старше 40 лет, при том что младше 26 — только 11 и 7%. Работа аналитика требует опыта, оказывается! Рынок подтверждает. Круче только аналитики данных, у которых аж 22% старше 40! (Но такой разброс в 4-5% может быть обусловлен просто особенностями выборки, критерии статистической значимости в отчете не приведены, а дата-аналитиков в выборке просто втрое больше)
Среди бизнес-аналитиков больше всего женщин, 65% (в среднем 46.5).
В грейдах авторы обнаружили 4.2% principal аналитиков! Значит, бывают и такие! То есть, очень крутой, но не руководитель. Не ясно, правда, какие именно это аналитики.
Системные аналитики в основном имеют больше опыта — 54% работают в этой роли 3 года и более.
Любимые задачи у системных аналитиков — проектирование и согласование архитектуры решения (53%) и
работа с интеграциями (51%). Тоже ожидаемо, но теперь мы имеем конкретные числа. Больше половыны системных аналитиков целятся в архитекторы!
Почти 25% респондентов живут не в РФ, при этом интересно распределение: 38% из всех бизнес-аналитиков находятся за границей, а вот системные аналитики почти все в России (79%). Ещё один аргумент к наблюдению, что за пределами РФ про системных аналитиков мало кто знает.
Переезжать тоже мало кто собирается — из системных аналитиков только 7%. А вот бизнес-аналитики вдвое больше склонны к релокации.
Больше половины аналитиков работает удаленно (52.8%), ещё 33,4% — гибридно. И в офис почти никто не хочет! (5.6%)
А вот зарплаты у системных аналитиков не растут (выросли только у 49% респондентов, а у бизнес-аналитиков, например, — у 61!) Причем это в основном либо за счет роста грейда, либо индексация. Смена компании, как причина роста, снизилась на 12% по сравнению с 2024 годом! История "перейти в другую компанию на большие деньги" сдувается, вот так. А вот потерять в деньгах при переходе можно в 54% случаев.
Грейды для системных аналитиков:
Джун — 70-130
Миддл — 190-250 (в пике до 300)
Сеньор, принципал — 250-400 (в пике до 500)
Тимлид — 350-400
Что влияет: экспертиза из нескольких доменов (но это для консалинга/аутстаффа), понимание бизнеса (то, что мы называем "фулл-стек") и умение закрывать задачи по анализу данных. Знание интеграций и архитектуры не влияет!
Для справки: CDO могут давать до миллиона, но это уровень определения стратегии работы с данными и их анализа на уровне компании. Это, в общем, про продажу самой идеи, что анализ помогает бизнесу достигать лучших результатов. Но это для всех справедливо, вроде как: чем у тебя лучше поставлен "бизнесовый майндсет", тем больше готовы платить.
Переход из других профессий тоже подтверждается: в 65% случаев люди приходят на роль бизнес-аналитика, а потом уже переходят на системного (41.7%). При этом 22.9% приходят в системный анализ из анализа данных, вот это удивительно! А 34% системных аналитиков хотят наоборот перейти в аналитики данных, вот такое взаимное перетекание.
По привлекательным отраслям всё уже давно известно: финтех, e-commerce, банки. Удивительна следующая тройка: HealthTech, BioTech, крипта(!). А потом — Travel, роботы, edTech/IoT (тут поровну). Прагматика, а потом романтика.
Интересен рейтинг компаний, но без отделения системных аналитиков, трудно оценить. А так выглядит забавно.
Ну и отдельно — за кем следят и кого читают аналитики, тут интересная отдельная база, там, кажется, почти все упомянуты.
Можно пойти дальше, и проанализировать вообще все профессии на букву "А", ну а что? Есть же у них что-то общее! Например, все они люди и все где-то работают.
Но даже из этой каши можно вытащить крупицы смысла.
Например, с точки зрения эйджизма лучше всех себя чувствуют как раз системные и бизнес-аналитики: 19 и 17% соответственно старше 40 лет, при том что младше 26 — только 11 и 7%. Работа аналитика требует опыта, оказывается! Рынок подтверждает. Круче только аналитики данных, у которых аж 22% старше 40! (Но такой разброс в 4-5% может быть обусловлен просто особенностями выборки, критерии статистической значимости в отчете не приведены, а дата-аналитиков в выборке просто втрое больше)
Среди бизнес-аналитиков больше всего женщин, 65% (в среднем 46.5).
В грейдах авторы обнаружили 4.2% principal аналитиков! Значит, бывают и такие! То есть, очень крутой, но не руководитель. Не ясно, правда, какие именно это аналитики.
Системные аналитики в основном имеют больше опыта — 54% работают в этой роли 3 года и более.
Любимые задачи у системных аналитиков — проектирование и согласование архитектуры решения (53%) и
работа с интеграциями (51%). Тоже ожидаемо, но теперь мы имеем конкретные числа. Больше половыны системных аналитиков целятся в архитекторы!
Почти 25% респондентов живут не в РФ, при этом интересно распределение: 38% из всех бизнес-аналитиков находятся за границей, а вот системные аналитики почти все в России (79%). Ещё один аргумент к наблюдению, что за пределами РФ про системных аналитиков мало кто знает.
Переезжать тоже мало кто собирается — из системных аналитиков только 7%. А вот бизнес-аналитики вдвое больше склонны к релокации.
Больше половины аналитиков работает удаленно (52.8%), ещё 33,4% — гибридно. И в офис почти никто не хочет! (5.6%)
А вот зарплаты у системных аналитиков не растут (выросли только у 49% респондентов, а у бизнес-аналитиков, например, — у 61!) Причем это в основном либо за счет роста грейда, либо индексация. Смена компании, как причина роста, снизилась на 12% по сравнению с 2024 годом! История "перейти в другую компанию на большие деньги" сдувается, вот так. А вот потерять в деньгах при переходе можно в 54% случаев.
Грейды для системных аналитиков:
Джун — 70-130
Миддл — 190-250 (в пике до 300)
Сеньор, принципал — 250-400 (в пике до 500)
Тимлид — 350-400
Что влияет: экспертиза из нескольких доменов (но это для консалинга/аутстаффа), понимание бизнеса (то, что мы называем "фулл-стек") и умение закрывать задачи по анализу данных. Знание интеграций и архитектуры не влияет!
Для справки: CDO могут давать до миллиона, но это уровень определения стратегии работы с данными и их анализа на уровне компании. Это, в общем, про продажу самой идеи, что анализ помогает бизнесу достигать лучших результатов. Но это для всех справедливо, вроде как: чем у тебя лучше поставлен "бизнесовый майндсет", тем больше готовы платить.
Переход из других профессий тоже подтверждается: в 65% случаев люди приходят на роль бизнес-аналитика, а потом уже переходят на системного (41.7%). При этом 22.9% приходят в системный анализ из анализа данных, вот это удивительно! А 34% системных аналитиков хотят наоборот перейти в аналитики данных, вот такое взаимное перетекание.
По привлекательным отраслям всё уже давно известно: финтех, e-commerce, банки. Удивительна следующая тройка: HealthTech, BioTech, крипта(!). А потом — Travel, роботы, edTech/IoT (тут поровну). Прагматика, а потом романтика.
Интересен рейтинг компаний, но без отделения системных аналитиков, трудно оценить. А так выглядит забавно.
Ну и отдельно — за кем следят и кого читают аналитики, тут интересная отдельная база, там, кажется, почти все упомянуты.
1❤24👍3👌1
Вы удивитесь, но статья Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1 из первоапрельского поста на самом деле существует! Про неё даже в Википедии написано.
L.B.S. — это сокращение от Laughing But Serious, по-русски что-то вроде "смех смехом, но серьезно"). Raccoon, я думаю, понятно.
Так вот что пишет этот енот: каждая строка кода соответствует всему проекту. Поэтому методика скорее не про хаос, а про фракталы, т.к. на каждом уровне повторяется один и тот же цикл работ.
У нас есть 4 уровня:
* вся система,
* отдельный компонент архитектуры,
* отдельная функция
* отдельная строка кода.
Все уровни связаны между собой. Смежные уровни влияют друг на друга очень сильно, отдаленные — слабо. Но тут как раз и возникает связь с теорией хаоса в математическом смысле, когда минимальные изменения (одна строка кода) приводят к принципиально разным — и непредсказуемым — результатам в макро-масштабе. То есть система находится в очень далеком от стабильного состоянии.
Собственно, стабилизация системы на каждом уровне — это и есть конечная цель. Линейные модели, согласно автору, рассматривают систему, как стабильную, до возникновения новой задачи. После успешной реализации задачи (пройдя стадии определения проблемы, разработки решения и интеграции его в существующую систему) достигается новое стабильное состояние.
В хаотической модели система ни в какой момент не находится в стабильном состоянии, а стадии фрактально отражаются на каждом уровне. В линейной модели сначала вы определяете проблему на уровне всей системы ("собираете требования"), потом "декомпозируете" её на более низкие уровни, дожидаетесь решения и проверяете его. В хаотической — определяете проблему на уровне системы, декомпозируете на низкие уровни, сталкиваетесь там с новыми проблемами, определяете их (вероятно, уже не в терминах требований, а в большей степени в виде сочетания требований и ограничений), пытаетесь решать, переходите на более низкий уровень, сталкиваетесь там с новыми проблемами, и так далее, вплоть до отдельной строки кода. А потом в обратную сторону — реализовать, проверить, интегрировать, проверить систему после интеграции.
Разработчик при этом находится между двух огней, они как раз видны на картинке: внешние требования к системе (требования пользователей и ограничения) сверху и возможности архитектуры/инструментов снизу. И вот где-то между ними, в попытке придумать решение с учетом и того, и другого, и находится большая часть работы.
При этом, как отмечает автор, для такой работы нет инструментов. Нижний уровень описывается интерфейсами библиотек и классов, верхний — сценариями использования, UI и внешними API. Их связка не описывается и не моделируется ничем (на 1995 год). 30 лет спустя мы называем это "архитектурой приложений" и "дизайном системы", но сильно легче, честно говоря, не стало.
Интересно, что разработчик идёт в эту историю один, без сопровождения. Аналитик может проработать определение проблемы на верхнем уровне, выявить проблемы, с которыми столкнется пользователь или смежная системы. А вот с какими проблемами столкнется разработчик, пытаясь это реализовать внутри, аналитик обычно даже не представляет. Но разработчику придется делать то же самое — анализировать требования и ограничения, вырабатывать решение, реализовывать и проверять его. Поэтому разработчики часто скептически смотрят на аналитиков — ну да, мы это всё каждый день делаем, только не называем громкими словами. А ещё у нас всё детерминировано, хорошо бы на входе тоже все было определено, а не эти непонятные люди, которые сами не знают, чего хотят.
Ну и поэтому решение всегда влияет на дизайн, причем очень часто заранее непредсказуемым образом — ведь о проблемах и ограничениях низкого уровня мы узнаем, только когда начнем пытаться это делать. И влияние движется не только сверху вниз, но и снизу вверх — ограничения решения могут заставить пользователей перестроить свою деятельность. Впрочем, неожиданные возможности тоже — риски бывают и положительными.
L.B.S. — это сокращение от Laughing But Serious, по-русски что-то вроде "смех смехом, но серьезно"). Raccoon, я думаю, понятно.
Так вот что пишет этот енот: каждая строка кода соответствует всему проекту. Поэтому методика скорее не про хаос, а про фракталы, т.к. на каждом уровне повторяется один и тот же цикл работ.
У нас есть 4 уровня:
* вся система,
* отдельный компонент архитектуры,
* отдельная функция
* отдельная строка кода.
Все уровни связаны между собой. Смежные уровни влияют друг на друга очень сильно, отдаленные — слабо. Но тут как раз и возникает связь с теорией хаоса в математическом смысле, когда минимальные изменения (одна строка кода) приводят к принципиально разным — и непредсказуемым — результатам в макро-масштабе. То есть система находится в очень далеком от стабильного состоянии.
Собственно, стабилизация системы на каждом уровне — это и есть конечная цель. Линейные модели, согласно автору, рассматривают систему, как стабильную, до возникновения новой задачи. После успешной реализации задачи (пройдя стадии определения проблемы, разработки решения и интеграции его в существующую систему) достигается новое стабильное состояние.
В хаотической модели система ни в какой момент не находится в стабильном состоянии, а стадии фрактально отражаются на каждом уровне. В линейной модели сначала вы определяете проблему на уровне всей системы ("собираете требования"), потом "декомпозируете" её на более низкие уровни, дожидаетесь решения и проверяете его. В хаотической — определяете проблему на уровне системы, декомпозируете на низкие уровни, сталкиваетесь там с новыми проблемами, определяете их (вероятно, уже не в терминах требований, а в большей степени в виде сочетания требований и ограничений), пытаетесь решать, переходите на более низкий уровень, сталкиваетесь там с новыми проблемами, и так далее, вплоть до отдельной строки кода. А потом в обратную сторону — реализовать, проверить, интегрировать, проверить систему после интеграции.
Разработчик при этом находится между двух огней, они как раз видны на картинке: внешние требования к системе (требования пользователей и ограничения) сверху и возможности архитектуры/инструментов снизу. И вот где-то между ними, в попытке придумать решение с учетом и того, и другого, и находится большая часть работы.
При этом, как отмечает автор, для такой работы нет инструментов. Нижний уровень описывается интерфейсами библиотек и классов, верхний — сценариями использования, UI и внешними API. Их связка не описывается и не моделируется ничем (на 1995 год). 30 лет спустя мы называем это "архитектурой приложений" и "дизайном системы", но сильно легче, честно говоря, не стало.
Интересно, что разработчик идёт в эту историю один, без сопровождения. Аналитик может проработать определение проблемы на верхнем уровне, выявить проблемы, с которыми столкнется пользователь или смежная системы. А вот с какими проблемами столкнется разработчик, пытаясь это реализовать внутри, аналитик обычно даже не представляет. Но разработчику придется делать то же самое — анализировать требования и ограничения, вырабатывать решение, реализовывать и проверять его. Поэтому разработчики часто скептически смотрят на аналитиков — ну да, мы это всё каждый день делаем, только не называем громкими словами. А ещё у нас всё детерминировано, хорошо бы на входе тоже все было определено, а не эти непонятные люди, которые сами не знают, чего хотят.
Ну и поэтому решение всегда влияет на дизайн, причем очень часто заранее непредсказуемым образом — ведь о проблемах и ограничениях низкого уровня мы узнаем, только когда начнем пытаться это делать. И влияние движется не только сверху вниз, но и снизу вверх — ограничения решения могут заставить пользователей перестроить свою деятельность. Впрочем, неожиданные возможности тоже — риски бывают и положительными.
👍10❤1
Event Storming Guide.pdf
2.3 MB
Удивительно, но на русском языке нет инструкции по Event Storming. Кажется, даже книга Брандолини не переведена (буду рад ошибиться).
Мне понадобилось для одного проекта описание техники на русском, и я не смог его найти. Пришлось сделать самому. Ну как сделать, я перевел описание с сайта https://www.qlerify.com/post/event-storming-the-complete-guide
Мне показалось, это может быть полезно для сообщества, поэтому поделюсь с вами. Надеюсь, я не очень сильно нарушаю авторские права, будем считать, что это всё в учебных целях.
Пользуйтесь!
Мне понадобилось для одного проекта описание техники на русском, и я не смог его найти. Пришлось сделать самому. Ну как сделать, я перевел описание с сайта https://www.qlerify.com/post/event-storming-the-complete-guide
Мне показалось, это может быть полезно для сообщества, поэтому поделюсь с вами. Надеюсь, я не очень сильно нарушаю авторские права, будем считать, что это всё в учебных целях.
Пользуйтесь!
2🔥40❤15👍3
Вдогонку к предыдущему посту: у многих аналитиков техника Event Storming вызывает... ну, почти что отторжение, а между тем это же всё очень похоже на юскейсы.
Вот смотрите:
🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать.
Когда мы изучаем юскейсы, я всем советую составлять отдельный перечень всех событий, собирая их из предусловий/постусловий. Кто хоть раз составлял такой перечень и отслеживал его актуальность? А в штурме событий он занимает центральное место!
🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время?
Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована")
Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает").
А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев.
Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события).
Акторы, они везде акторы (хотя в ES — и 🟥 системы тоже).
Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит.
Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов.
Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.
Вот смотрите:
🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать.
Когда мы изучаем юскейсы, я всем советую составлять отдельный перечень всех событий, собирая их из предусловий/постусловий. Кто хоть раз составлял такой перечень и отслеживал его актуальность? А в штурме событий он занимает центральное место!
🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время?
Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована")
Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает").
А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев.
Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события).
Акторы, они везде акторы (хотя в ES — и 🟥 системы тоже).
Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит.
Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов.
Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.
👌6❤5😢1
Извините, будет пост про бизнес-анализ, а не системный. Причем бизнес-анализ именно в смысле организационного консультирования, а не сбора требований к информационной системе. Ну, какими проектами занимаюсь, про то и пишу. Сейчас вот так.
И что хочу сказать: очень большое упущение в образовании бизнес-аналитиков — практически полное игнорирование теорий менеджмента! Если мы посмотрим на BABoK, он не основан ни на какой теории, это просто сборник некоторых практик "из полей".
Взять, хотя бы, модель организации. Есть такая книга, аж 1986 года, "Образы организаций" канадского профессора Гэрета Моргана. Он говорит, что любая модель организации следует какой-то метафоре, и приводит их 8:
1. Машина, механизм, состоящий из соединенных деталей.
2. Организм, пытающийся выживать и адаптироваться к меняющейся окружающей среде.
3. Мозг, постоянно получающий и обрабатывающий информацию, принимающий решения.
4. Культура, общество в миниатюре. Со своими суб-культурами, ценностями, нормами, верованиями, ритуалами.
5. Политическая система. Организация — это игра, борьба разных акторов за влияние и власть.
6. Психическая тюрьма. Организация — это набор мифов и историй, ограничивающих мысли, идеи и действия людей.
7. Инструмент доминирования. Организации нужны, чтобы подавлять и эксплуатировать людей.
8. Непрерывный поток трансформаций. Организация постоянно должна находиться в поиске и постоянно меняться в ответ на вызовы.
А теперь думаем: как аналитики, мы с какой метафорой работаем?
Важно, что это не типология организаций, а метафоры — как мы смотрим. Это значит, что на каждую организацию можно посмотреть через любую оптику. У вас гибкая обучающаяся бирюзовая организация? Или ваш миф настолько силен, что это уже выглядит, как секта?
Мы думаем, что мы работаем с внедрением автоматизированных систем. Но на самом деле мы работаем с изменениями.
Системы не было, система появилась. Это изменение.
Оно меняет:
- способ осуществления деятельности, структуру механизма организации (очевидно)
- возможности организации к адаптации (то, что делали руками, можно быстро поменять, а вот то, что зашито в программную систему...)
- распределение мест хранения и способов распространения информации
- соответственно, распределение власти. Та информация, которую раньше я раздавал порционно и в нужном мне ключе, теперь доступна всем. Ой-ой, я потерял рычаг манипуляций. И какие-то там итшники, у которых и бизнес-целей нет, стали вдруг очень важны — ведь без них ничего не будет работать.
- культуру. У нас была культура взаимных одолжений, а теперь в вашей системе нужно всё делать в срок и одинаково для всех. Нарастает отчуждение, разрушаются неформальные связи. Или наоборот, возникают тайные практики противодействия и фальсификации данных.
- ограничения. Ура, мы теперь можем ограничивать сотрудников так, как раньше и подумать не могли!
- гибкость. У нас не было никаких процессов, мы были супер-гибкими, каждый проект могли делать индивидуально. А в вашей системе нужно делать всё одинаково, слишком узкие рамки.
Мне кажется, мы чаще всего смотрим из метафоры машины, где вся деятельность выглядит, как набор бизнес-процессов, а шаги бизнес-процесса всегда выполняются четко, в рамках регламента, и, в общем, неважно кем — лучше бы роботами, конечно.
В связи с этим вопрос: какая метафора лучше всего подходит, если мы собираемся внедрять в организацию ИИ? Или, того хуже, перестраивать организацию по принципу AI-first?
И что хочу сказать: очень большое упущение в образовании бизнес-аналитиков — практически полное игнорирование теорий менеджмента! Если мы посмотрим на BABoK, он не основан ни на какой теории, это просто сборник некоторых практик "из полей".
Взять, хотя бы, модель организации. Есть такая книга, аж 1986 года, "Образы организаций" канадского профессора Гэрета Моргана. Он говорит, что любая модель организации следует какой-то метафоре, и приводит их 8:
1. Машина, механизм, состоящий из соединенных деталей.
2. Организм, пытающийся выживать и адаптироваться к меняющейся окружающей среде.
3. Мозг, постоянно получающий и обрабатывающий информацию, принимающий решения.
4. Культура, общество в миниатюре. Со своими суб-культурами, ценностями, нормами, верованиями, ритуалами.
5. Политическая система. Организация — это игра, борьба разных акторов за влияние и власть.
6. Психическая тюрьма. Организация — это набор мифов и историй, ограничивающих мысли, идеи и действия людей.
7. Инструмент доминирования. Организации нужны, чтобы подавлять и эксплуатировать людей.
8. Непрерывный поток трансформаций. Организация постоянно должна находиться в поиске и постоянно меняться в ответ на вызовы.
А теперь думаем: как аналитики, мы с какой метафорой работаем?
Важно, что это не типология организаций, а метафоры — как мы смотрим. Это значит, что на каждую организацию можно посмотреть через любую оптику. У вас гибкая обучающаяся бирюзовая организация? Или ваш миф настолько силен, что это уже выглядит, как секта?
Мы думаем, что мы работаем с внедрением автоматизированных систем. Но на самом деле мы работаем с изменениями.
Системы не было, система появилась. Это изменение.
Оно меняет:
- способ осуществления деятельности, структуру механизма организации (очевидно)
- возможности организации к адаптации (то, что делали руками, можно быстро поменять, а вот то, что зашито в программную систему...)
- распределение мест хранения и способов распространения информации
- соответственно, распределение власти. Та информация, которую раньше я раздавал порционно и в нужном мне ключе, теперь доступна всем. Ой-ой, я потерял рычаг манипуляций. И какие-то там итшники, у которых и бизнес-целей нет, стали вдруг очень важны — ведь без них ничего не будет работать.
- культуру. У нас была культура взаимных одолжений, а теперь в вашей системе нужно всё делать в срок и одинаково для всех. Нарастает отчуждение, разрушаются неформальные связи. Или наоборот, возникают тайные практики противодействия и фальсификации данных.
- ограничения. Ура, мы теперь можем ограничивать сотрудников так, как раньше и подумать не могли!
- гибкость. У нас не было никаких процессов, мы были супер-гибкими, каждый проект могли делать индивидуально. А в вашей системе нужно делать всё одинаково, слишком узкие рамки.
Мне кажется, мы чаще всего смотрим из метафоры машины, где вся деятельность выглядит, как набор бизнес-процессов, а шаги бизнес-процесса всегда выполняются четко, в рамках регламента, и, в общем, неважно кем — лучше бы роботами, конечно.
В связи с этим вопрос: какая метафора лучше всего подходит, если мы собираемся внедрять в организацию ИИ? Или, того хуже, перестраивать организацию по принципу AI-first?
❤20👍11👏2🤔2👎1