Залез в mermaid.js по какой-то надобности, а он теперь mermaid.ai, весь такой ИИ-интегрированный.
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
1🔥7❤6👍1
Я в последнее время в связи с использованием ИИ заметил вот что: можно, конечно, загонять в него формальные промпты по какой-то структуре (многие из которых упомянуты тут), но вообще он итак неплохо работает, в режиме обычного человеческого диалога, а не вот этих формальных рамок.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
1❤26👍14🔥3👎1
Если вы думаете, что ИИ победно шествует по рынку труда, то нет. Свежий анализ Anthropic показывает, что ещё толком ничего не началось.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
1👍18🤔5
8 марта я традиционно пишу про великих женщин в ИТ.
И сегодня, чем дольше я изучал материалы о героине поста, тем чаще у меня в голове вертелись фразы: "Офигеть!", "Так не бывает!" и, наконец: "Возможно всё!"
Итак, знакомьтесь: Каринэ Назарян. Или Джоанна Хоффман, на западный манер.
Родилась в 1955 году в Польше, в семье режиссера Ежи Гоффмана, и с 9 месяцев жила с матерью в Армении (родители познакомились в Москве). Родственники Каринэ работали в кино, например, с Параджановым — в доме висели раскадровки его фильмов. Но киношные люди казались ей слишком суматошными, и она с детства мечтала стать физиком, вдохновляясь двоюродным братом-астрономом.
С 10 до 13 лет жила в Польше у дедушки с бабушкой, а потом переехала в США к матери, которая уехала чуть раньше (это отдельная трагическая история — как это, эмигрировать из Советского Союза в США в конце 60-х? Оказывается, Сталин после войны приглашал армян со всего мира приезжать в СССР, вот только места в советской Армении для всех не хватило, поэтому большинство репатриантов отправили... в Сибирь. Вернуться обратно в свои страны им удалось лишь при Хрущеве).
США оказались не таким клёвым местом, как виделось из СССР, ещё и язык нужно было учить, но Джоанну после двух месяцев в американской школе в бедном районе перевели сначала в из 7 в 8 класс, ещё через два месяца — в 9, а потом посоветовали пойти в частную школу и готовиться к поступлению в колледж. Джоанна учила английский, а бабушка из Польши присылала ей советские учебники по математике.
В итоге она попала в MIT на свою любимую физику, и обнаружила себя полностью в своей среде. Однако к концу обучения поняла, что физика всё-таки слишком сложная, и науки о людях её интересуют не в меньшей степени. В поисках области, совмещающей эти два направления, она занялась археологией и древней историей, но с точки зрения технологий обработки и изготовления материалов — идеальное сочетание физики и гуманитарных наук!
В качестве объекта исследований выбрала Урарту — древнее государство между современными Арменией, Турцией и Ираном. По туристической визе въехала в СССР, пошла к Борису Пиотровскому — директору Эрмитажа, академику и крупнейшему специалисту по Урарту, и договорилась с ним об исследованиях. Он поддержал американку и направил её на раскопки в Армению. 9 месяцев в Джоанна жила в СССР с просроченной визой, притворялась 15-летним подростком без паспорта и занималась археологией.
По возвращении в США она защитила диссертацию и поехала в Иран, чтобы продолжить исследования, но по дороге заехала к бабушке в Польшу, а в Иране в это время как раз началась исламская революция. Так что Джоанне пришлось вернуться в США и думать, что делать дальше.
Ещё в MIT она тусила с ребятами из BBN (компания, которую называли "третьим университетом" в Кембридже, после MIT и Гарварда), дружила с дочерью "отца искусственного интеллекта" Марвина Минского и Синтией Соломон — создательницей обучающего языка Logo (вместе с Сеймуром Пейпертом). Кто-то из них позвал её в Xerox PARC, подработать тестировщиком интерфейсов их компьютера Alto — первого компьютера с GUI.
На семинаре в PARC она вскоре познакомилась с Джефом Раскиным, и долго обсуждала принципы и способы применения персональных компьютеров. В результате он позвал её в свой новый проект Apple Macintosh, 5-м участником. Приходилось делать все понемногу, даже паять, но в основном Джоана работала над интерфейсами в широком смысле — от клавиатуры до GUI, и составила первую версию Macintosh User Interface Guidelines — инструкцию, заложившую основные принципы построения интерфейсов приложений на Маках.
А потом как-то раз в офис команды зашел Стив Джобс, и сказал — ты кто? Будешь заниматься маркетингом. С тех пор Джоана Хоффман известна, как руководитель маркетинговой команды Macintosh, NeXT, "правая рука" Стива Джобса и единственный человек, который мог "выстоять перед Стивом и вразумить его".
Вот такая история великой женщины. С праздником! Помните: возможно всё!🌷 🌷 🌷
И сегодня, чем дольше я изучал материалы о героине поста, тем чаще у меня в голове вертелись фразы: "Офигеть!", "Так не бывает!" и, наконец: "Возможно всё!"
Итак, знакомьтесь: Каринэ Назарян. Или Джоанна Хоффман, на западный манер.
Родилась в 1955 году в Польше, в семье режиссера Ежи Гоффмана, и с 9 месяцев жила с матерью в Армении (родители познакомились в Москве). Родственники Каринэ работали в кино, например, с Параджановым — в доме висели раскадровки его фильмов. Но киношные люди казались ей слишком суматошными, и она с детства мечтала стать физиком, вдохновляясь двоюродным братом-астрономом.
С 10 до 13 лет жила в Польше у дедушки с бабушкой, а потом переехала в США к матери, которая уехала чуть раньше (это отдельная трагическая история — как это, эмигрировать из Советского Союза в США в конце 60-х? Оказывается, Сталин после войны приглашал армян со всего мира приезжать в СССР, вот только места в советской Армении для всех не хватило, поэтому большинство репатриантов отправили... в Сибирь. Вернуться обратно в свои страны им удалось лишь при Хрущеве).
США оказались не таким клёвым местом, как виделось из СССР, ещё и язык нужно было учить, но Джоанну после двух месяцев в американской школе в бедном районе перевели сначала в из 7 в 8 класс, ещё через два месяца — в 9, а потом посоветовали пойти в частную школу и готовиться к поступлению в колледж. Джоанна учила английский, а бабушка из Польши присылала ей советские учебники по математике.
В итоге она попала в MIT на свою любимую физику, и обнаружила себя полностью в своей среде. Однако к концу обучения поняла, что физика всё-таки слишком сложная, и науки о людях её интересуют не в меньшей степени. В поисках области, совмещающей эти два направления, она занялась археологией и древней историей, но с точки зрения технологий обработки и изготовления материалов — идеальное сочетание физики и гуманитарных наук!
В качестве объекта исследований выбрала Урарту — древнее государство между современными Арменией, Турцией и Ираном. По туристической визе въехала в СССР, пошла к Борису Пиотровскому — директору Эрмитажа, академику и крупнейшему специалисту по Урарту, и договорилась с ним об исследованиях. Он поддержал американку и направил её на раскопки в Армению. 9 месяцев в Джоанна жила в СССР с просроченной визой, притворялась 15-летним подростком без паспорта и занималась археологией.
По возвращении в США она защитила диссертацию и поехала в Иран, чтобы продолжить исследования, но по дороге заехала к бабушке в Польшу, а в Иране в это время как раз началась исламская революция. Так что Джоанне пришлось вернуться в США и думать, что делать дальше.
Ещё в MIT она тусила с ребятами из BBN (компания, которую называли "третьим университетом" в Кембридже, после MIT и Гарварда), дружила с дочерью "отца искусственного интеллекта" Марвина Минского и Синтией Соломон — создательницей обучающего языка Logo (вместе с Сеймуром Пейпертом). Кто-то из них позвал её в Xerox PARC, подработать тестировщиком интерфейсов их компьютера Alto — первого компьютера с GUI.
На семинаре в PARC она вскоре познакомилась с Джефом Раскиным, и долго обсуждала принципы и способы применения персональных компьютеров. В результате он позвал её в свой новый проект Apple Macintosh, 5-м участником. Приходилось делать все понемногу, даже паять, но в основном Джоана работала над интерфейсами в широком смысле — от клавиатуры до GUI, и составила первую версию Macintosh User Interface Guidelines — инструкцию, заложившую основные принципы построения интерфейсов приложений на Маках.
А потом как-то раз в офис команды зашел Стив Джобс, и сказал — ты кто? Будешь заниматься маркетингом. С тех пор Джоана Хоффман известна, как руководитель маркетинговой команды Macintosh, NeXT, "правая рука" Стива Джобса и единственный человек, который мог "выстоять перед Стивом и вразумить его".
Вот такая история великой женщины. С праздником! Помните: возможно всё!
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉66🔥38❤21👏4🤩3
Systems.Education закрывается. 15 лет учили аналитиков!
Можно сказать, сформировали этот рынок и, хочется верить, оказали определённое влияние.
Очень жаль. Такие дела.
Можно сказать, сформировали этот рынок и, хочется верить, оказали определённое влияние.
Очень жаль. Такие дела.
😭34🤯3🥱1
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Школа Systems Education закрывается
Спасибо, что были с нами: приходили на обучение, оставляли отзывы, читали наш канал и статьи на сайте, смотрели вебинары и участвовали в конференциях. Вместе с вами мы развивали индустрию и повышали уровень проектирования систем.
До конца марта на этом канале вас ждут интересные посты, которые подготовили наш маркетолог Алёна Кудрявцева, карьерный коуч Кристина Годовых и авторы, с которыми мы сотрудничаем.
Поддержите нас: прямо сейчас оплатите участие на курсе, воркшопе или лабораторной. Тем более что они будут последние. Мы проводим учебные потоки до начала июня — и на этом всё. Это позволит нам выплатить зарплаты и закрыть школу без долгов.
Перейти в расписание
Перешлите, пожалуйста, друзьям, коллегам и в свои блоги
Денис Бесков, Основатель, Владелец
Спасибо, что были с нами: приходили на обучение, оставляли отзывы, читали наш канал и статьи на сайте, смотрели вебинары и участвовали в конференциях. Вместе с вами мы развивали индустрию и повышали уровень проектирования систем.
До конца марта на этом канале вас ждут интересные посты, которые подготовили наш маркетолог Алёна Кудрявцева, карьерный коуч Кристина Годовых и авторы, с которыми мы сотрудничаем.
Поддержите нас: прямо сейчас оплатите участие на курсе, воркшопе или лабораторной. Тем более что они будут последние. Мы проводим учебные потоки до начала июня — и на этом всё. Это позволит нам выплатить зарплаты и закрыть школу без долгов.
Перейти в расписание
Перешлите, пожалуйста, друзьям, коллегам и в свои блоги
Денис Бесков, Основатель, Владелец
systems.education
Школа системного анализа и проектирования информационных систем Systems.Education
Более 14 лет обучаем проектированию информационных систем. Бизнес-анализ, инженерия требований, системный анализ и проектирование для разработки и интеграции информационных систем, веб-сервисов и мобильных приложений. Мы авторы профстандартов системного аналитика…
💔58😭30😢8😱4👀2
Собираетесь ли вы в этом году проходить обучение?
Anonymous Poll
21%
Да, на курсах за свои деньги
5%
Да, с ментором за свои деньги
9%
Да, компания оплачивает внешние курсы
13%
Да, на внутренних курсах компании
52%
Собираюсь учиться самостоятельно по статьям, книгам, видео
40%
Собираюсь учиться самостоятельно с помощью ИИ
16%
Нет, в этом году учиться не планирую
Этот день в истории:
12 марта 1455 года — будущий Папа Пий II в письме упоминает Библию Гуттенберга — первую печатную книгу. Это первое свидетельство о существовании такой диковины.
12 марта 1989 года — Тим Бернерс-Ли представил проект WWW ("день рождения Интернета, как мы его знаем").
12 марта 2006 года — организация "▒▒▒▒▒▒▒▒▒ без ▒▒▒▒▒▒" (объявлена нежелательной организацией в РФ) объявила этот день Днем протеста против ▒▒▒▒▒-▒▒▒▒▒▒▒.
В общем, всё одно к одному, всё про свободный обмен информацией и распространение знаний.
12 марта 2026 года — у меня сегодня день рождения, надеюсь, я в русле этого движения, и приношу вам новую интересную информацию!
12 марта 1455 года — будущий Папа Пий II в письме упоминает Библию Гуттенберга — первую печатную книгу. Это первое свидетельство о существовании такой диковины.
12 марта 1989 года — Тим Бернерс-Ли представил проект WWW ("день рождения Интернета, как мы его знаем").
12 марта 2006 года — организация "▒▒▒▒▒▒▒▒▒ без ▒▒▒▒▒▒" (объявлена нежелательной организацией в РФ) объявила этот день Днем протеста против ▒▒▒▒▒-▒▒▒▒▒▒▒.
В общем, всё одно к одному, всё про свободный обмен информацией и распространение знаний.
12 марта 2026 года — у меня сегодня день рождения, надеюсь, я в русле этого движения, и приношу вам новую интересную информацию!
3🔥38🍾33❤18🎉8👍1
Наблюдаю интересный дрейф в функциях аналитиков. Уже в нескольких крупных компаниях вижу, что бизнес-аналитиков всё больше и больше нагружают техническими деталями: спецификацией данных, описанием исключений и краевых случаев, обработки ошибок. Ну потому что системный аналитик не может сказать, что нужно делать при возникновении такой ошибки. Бизнесу-то как нужно? Вы расскажите. И дайте примеры данных в виде json.
Задачи системных аналитиков при этом тоже смещаются в сторону техники: описания интеграций, структур и форматов данных — как для транспорта, так и для хранения, стратегии надежности обмена и повторных вызовов.
В результате такой работы у системного аналитика получается техническая спецификация, практически непригодная для чтения обычным человеком — формальные спеки API, схемы данных.
Но и у бизнес-аналитиков получается не лучше — в деталях теряется общая картина, и, например, тестировщики уже перестают понимать — а как и для чего оно должно работать? При такой степени проработки теряется описание бизнес-возможности и потребностей. А схемы бизнес-процессов, которые ещё где-то сохраняются как форма, по содержанию отражают скорее взаимодействие систем при интеграции.
Поэтому описание потребностей бизнеса всё чаще возлагают... на сам бизнес. А так как они этого никогда не делали и не владеют инструментами, получается, ну, так. С помощью ИИ даже ещё смешнее — объем большой, а акценты расставлены почти случайно. За что стат.модель зацепилась, о том и говорит. Проконтролировать это у бизнес-заказчиков не хватает квалификации и понимания, что эти слова вообще-то должны что-то означать и для чего-то в дальнейшем использоваться. Возникает синдром студента: "а мы думали, вам просто какой-то текст по теме нужен, ну вот ИИ какой-то сгенерил, разве это не подходит?"
Так как с потребностями бизнеса всё-таки нужно разбираться (ну, хотя бы иногда), БА на это уже не способны, а СА вообще к людям не пускают, эта задача отъезжает к... UX-исследователям.
Ну правда, им же по роли положено разговаривать с пользователями!
Вот пусть и расскажут, что этим пользователям, в конце концов, нужно.
Поэтому процесс становится примерно таким:
* СА находит в постановке непрописанный вариант, просит БА его описать.
* БА идёт к UX-ресерчеру и спрашивает — как пользователям будет удобно в этом случае, что им нужно? Ну ты же с ними говорила уже, выясни этот момент тоже. И дай сразу макет интерфейса, я вставлю в документ.
* UX действительно говорил с пользователями, но совершенно по другим вопросам и по рандомизированной выборке. А делать ещё одно исследование из-за такого мелкого вопроса довольно накладно. Кроме того, переворачивается ответственность: БА просит принести уже готовый макет (принятое решение), который нужно сделать совместно с дизайнером. То есть, не дизайнер получает постановку задачи от БА, а наоборот — БА хочет готовое решение, которое откуда-то извне возьмется, а он только зафиксирует.
В этой ситуации функция управления и координации фактически перекладывается на UX-исследователя, который вообще говоря исследователь, а не менеджер. Иногда в этой цепочке всё-таки возникает какой-то младший продакт (если такая роль вообще есть), фактически — фича-оунер.
Но если нет — ситуация решается случайным образом. Так как фичу кто-то всё же должен дотащить до прода, но никто не хочет принимать решения, всё превращается в игру "горячая картошка" с перебрасыванием ответственности друг-другу до первого, кто сдастся и возьмет функцию ситуационного лидера на себя. Это может быть кто угодно — UX, БА, дизайнер, кто-то из менеджеров, иногда даже тестировщик. Я даже видел лида поддержки в этой роли.
Или же фича так и останется бесхозной, и в каком-то виде доедет до прода без хозяина. Решения в этой ситуации, скорее всего, будут приняты случайными людьми и без надежных оснований. Оценку решений получит опять же либо поддержка, либо UX в ходе очередного скрининга.
Такой вот процесс, сталкивались с таким? И что делать, если в команде не предусмотрен UX?
Задачи системных аналитиков при этом тоже смещаются в сторону техники: описания интеграций, структур и форматов данных — как для транспорта, так и для хранения, стратегии надежности обмена и повторных вызовов.
В результате такой работы у системного аналитика получается техническая спецификация, практически непригодная для чтения обычным человеком — формальные спеки API, схемы данных.
Но и у бизнес-аналитиков получается не лучше — в деталях теряется общая картина, и, например, тестировщики уже перестают понимать — а как и для чего оно должно работать? При такой степени проработки теряется описание бизнес-возможности и потребностей. А схемы бизнес-процессов, которые ещё где-то сохраняются как форма, по содержанию отражают скорее взаимодействие систем при интеграции.
Поэтому описание потребностей бизнеса всё чаще возлагают... на сам бизнес. А так как они этого никогда не делали и не владеют инструментами, получается, ну, так. С помощью ИИ даже ещё смешнее — объем большой, а акценты расставлены почти случайно. За что стат.модель зацепилась, о том и говорит. Проконтролировать это у бизнес-заказчиков не хватает квалификации и понимания, что эти слова вообще-то должны что-то означать и для чего-то в дальнейшем использоваться. Возникает синдром студента: "а мы думали, вам просто какой-то текст по теме нужен, ну вот ИИ какой-то сгенерил, разве это не подходит?"
Так как с потребностями бизнеса всё-таки нужно разбираться (ну, хотя бы иногда), БА на это уже не способны, а СА вообще к людям не пускают, эта задача отъезжает к... UX-исследователям.
Ну правда, им же по роли положено разговаривать с пользователями!
Вот пусть и расскажут, что этим пользователям, в конце концов, нужно.
Поэтому процесс становится примерно таким:
* СА находит в постановке непрописанный вариант, просит БА его описать.
* БА идёт к UX-ресерчеру и спрашивает — как пользователям будет удобно в этом случае, что им нужно? Ну ты же с ними говорила уже, выясни этот момент тоже. И дай сразу макет интерфейса, я вставлю в документ.
* UX действительно говорил с пользователями, но совершенно по другим вопросам и по рандомизированной выборке. А делать ещё одно исследование из-за такого мелкого вопроса довольно накладно. Кроме того, переворачивается ответственность: БА просит принести уже готовый макет (принятое решение), который нужно сделать совместно с дизайнером. То есть, не дизайнер получает постановку задачи от БА, а наоборот — БА хочет готовое решение, которое откуда-то извне возьмется, а он только зафиксирует.
В этой ситуации функция управления и координации фактически перекладывается на UX-исследователя, который вообще говоря исследователь, а не менеджер. Иногда в этой цепочке всё-таки возникает какой-то младший продакт (если такая роль вообще есть), фактически — фича-оунер.
Но если нет — ситуация решается случайным образом. Так как фичу кто-то всё же должен дотащить до прода, но никто не хочет принимать решения, всё превращается в игру "горячая картошка" с перебрасыванием ответственности друг-другу до первого, кто сдастся и возьмет функцию ситуационного лидера на себя. Это может быть кто угодно — UX, БА, дизайнер, кто-то из менеджеров, иногда даже тестировщик. Я даже видел лида поддержки в этой роли.
Или же фича так и останется бесхозной, и в каком-то виде доедет до прода без хозяина. Решения в этой ситуации, скорее всего, будут приняты случайными людьми и без надежных оснований. Оценку решений получит опять же либо поддержка, либо UX в ходе очередного скрининга.
Такой вот процесс, сталкивались с таким? И что делать, если в команде не предусмотрен UX?
🤯20💯14🤔9🔥6👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Знаете ли вы, что в qwen (ну и в других LLM-сервисах тоже) можно сгенерировать эмуляцию какого-нибудь процесса и поиграться с его параметрами?
Вот, например, модель элементарного системного дизайна с одним балансировщиком и несколькими воркерами. Можно подвигать разные настройки и посмотреть, что будет.
Я тут не сильно заморачивался с промптом, буквально написал вот так:
Чтобы создать именно модель, нужно в "плюсике" слева от строки запроса выбрать "артефакты".
Там же можно и любые другие эмуляции создавать или быстрые макеты.
Имитационное моделирование становится доступным прямо на кончиках пальцев!
Вот, например, модель элементарного системного дизайна с одним балансировщиком и несколькими воркерами. Можно подвигать разные настройки и посмотреть, что будет.
Я тут не сильно заморачивался с промптом, буквально написал вот так:
Can you create a model of system with web interface, mobile, several server workers, db and balancer, and show simulation with adjustable parameters
(можно и на русском: Можешь создать модель системы с веб-интерфейсом, мобильным приложением, несколькими серверными воркерами, базой данных и балансировщиком нагрузки, и предусмотреть настраиваемые параметры нагрузки, масштабирования и уровня ошибок)
Чтобы создать именно модель, нужно в "плюсике" слева от строки запроса выбрать "артефакты".
Там же можно и любые другие эмуляции создавать или быстрые макеты.
Имитационное моделирование становится доступным прямо на кончиках пальцев!
2👍23🔥15🤯3❤2
Хотите оценить свою карьерную перспективу в мире всепобеждающего ИИ?
Мой знакомый Алекс Ильин сделал сервис, анализирующий резюме и дающих рекомендации, исходя из трех сценариев:
1. Эволюционный сценарий. ИИ в качестве помощника, но всем по-прежнему управляют люди.
2. Радикальные изменения. ИИ заменяет целиком профессии, миллионы людей ищут работу.
3. Новый мир. Большая часть интеллектуального труда отдана ИИ. Общество ищет новый смысл жизни.
Мне, например, предсказывает следующее:
1. Собственная школа
Вы используете сэкономленные ИИ часы, чтобы наконец создать собственную независимую компанию по обучению. Вы проводите дни, обучая аналитиков и менеджеров по продуктам системному мышлению, потому что ИИ может делать только то, что ему говорят. Вы занимаетесь любимым делом – преподаванием, строите бизнес, который полностью принадлежит вам, и поддерживаете свою финансовую стабильность, продавая высококлассные экспертные услуги профессионалам, которые отчаянно стремятся понять общую картину.
2. Архитектор-одиночка
Вы перестаёте управлять шестьюдесятью сотрудниками. Вместо этого вы садитесь за стол переговоров с клиентом, у которого сложная и запутанная проблема в образовании. Вы оцениваете ситуацию, понимаете, что им действительно нужно, прежде чем они смогут это сформулировать, а затем, работая наедине с мощными агентами искусственного интеллекта, за неделю создаёте именно ту платформу, которая им необходима. Вы защищаете свой доход, контролируя весь процесс от начала до конца, превращая свои глубокие знания систем в готовые продукты.
3. Создатель смысла
Ваши дни проходят в непосредственной работе с молодежью и сообществами. Вы не учите их пользоваться компьютерами. Вы учите их видеть картину в целом, принимать сложные решения и понимать друг друга. Вы используете свой дар упрощать сложные вещи, чтобы помочь людям ориентироваться в мире, который кажется невероятно быстрым. Вы зарабатываете на жизнь глубоким, незаменимым человеческим наставничеством.
На самом деле, в направлении вариантов 1 и 2 я уже работаю, тут мы совпадаем. Зачем выбирать, когда всё такое вкусное.
(Вы замечали, кстати, как сложно генеративный ИИ заставить давать мрачные прогнозы? Всё ужасно позитивно, у всех всё хорошо и прекрасно. Где апокалипсис и мировые войны за электрогенерирующие мощности и пресную воду, а? А?!).
В общем, если хотите поиграться, то вот: https://alexilin.com/aifuture/ (там на английском, но переводчик в браузере справляется).
Делитесь, а что вам ИИ предсказывает?
Мой знакомый Алекс Ильин сделал сервис, анализирующий резюме и дающих рекомендации, исходя из трех сценариев:
1. Эволюционный сценарий. ИИ в качестве помощника, но всем по-прежнему управляют люди.
2. Радикальные изменения. ИИ заменяет целиком профессии, миллионы людей ищут работу.
3. Новый мир. Большая часть интеллектуального труда отдана ИИ. Общество ищет новый смысл жизни.
Мне, например, предсказывает следующее:
1. Собственная школа
Вы используете сэкономленные ИИ часы, чтобы наконец создать собственную независимую компанию по обучению. Вы проводите дни, обучая аналитиков и менеджеров по продуктам системному мышлению, потому что ИИ может делать только то, что ему говорят. Вы занимаетесь любимым делом – преподаванием, строите бизнес, который полностью принадлежит вам, и поддерживаете свою финансовую стабильность, продавая высококлассные экспертные услуги профессионалам, которые отчаянно стремятся понять общую картину.
2. Архитектор-одиночка
Вы перестаёте управлять шестьюдесятью сотрудниками. Вместо этого вы садитесь за стол переговоров с клиентом, у которого сложная и запутанная проблема в образовании. Вы оцениваете ситуацию, понимаете, что им действительно нужно, прежде чем они смогут это сформулировать, а затем, работая наедине с мощными агентами искусственного интеллекта, за неделю создаёте именно ту платформу, которая им необходима. Вы защищаете свой доход, контролируя весь процесс от начала до конца, превращая свои глубокие знания систем в готовые продукты.
3. Создатель смысла
Ваши дни проходят в непосредственной работе с молодежью и сообществами. Вы не учите их пользоваться компьютерами. Вы учите их видеть картину в целом, принимать сложные решения и понимать друг друга. Вы используете свой дар упрощать сложные вещи, чтобы помочь людям ориентироваться в мире, который кажется невероятно быстрым. Вы зарабатываете на жизнь глубоким, незаменимым человеческим наставничеством.
На самом деле, в направлении вариантов 1 и 2 я уже работаю, тут мы совпадаем. Зачем выбирать, когда всё такое вкусное.
(Вы замечали, кстати, как сложно генеративный ИИ заставить давать мрачные прогнозы? Всё ужасно позитивно, у всех всё хорошо и прекрасно. Где апокалипсис и мировые войны за электрогенерирующие мощности и пресную воду, а? А?!).
В общем, если хотите поиграться, то вот: https://alexilin.com/aifuture/ (там на английском, но переводчик в браузере справляется).
Делитесь, а что вам ИИ предсказывает?
👍10🗿3
Промпт для генерации 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