Завершил сегодня последний курс по основам проектирования интеграций в школе Systems.Education в весеннем сезоне. Следующие курсы — осенью, летом буду отдыхать.
Правда, отдых получается боевой:
20.06 заканчивается обучение очередного потока буткемпа по системному анализу, приду на финальное демо. Это очень крутая программа по освоению профессии, объединяющая в себе несколько наших курсов, и то, что не входит в отдельные курсы (например, практика сбора требований с заказчика). Я сейчас сам её не веду, но участвовал в разработке.
13-14 июля ЛАФ в Подмосковье. На правах члена ПК и почетного докладчика порассуждаю о развитии системного анализа и проектирования на примере истории развития и использования UML (некоторые мысли вы читали у канале, будет развитие темы). Где же ещё порассуждать, как не на фестивале.
Продолжается работа с отбором заявок на Flow 2024 Autumn — вообще, число заявок с каждым разом растёт, и ПК с каждым разом всё тяжелее отбирать самые лучшие доклады, двигающие вперёд индустрию.
И в промежутках между этими делами обещаю не бросать вас и радовать интересными и полезными постами, раскапывать неочевидные вещи и парадоксальные взгляды на знакомые предметы.
А также, надеюсь, к очередному бизнес-сезону, который у нас начинается осенью как раз примерно c дат проведения Flow (17 сентября в онлайне, 24-25 очно, хороший старт!), придумаю для вас новые интересные штуки.
Всем отличного лета!
Правда, отдых получается боевой:
20.06 заканчивается обучение очередного потока буткемпа по системному анализу, приду на финальное демо. Это очень крутая программа по освоению профессии, объединяющая в себе несколько наших курсов, и то, что не входит в отдельные курсы (например, практика сбора требований с заказчика). Я сейчас сам её не веду, но участвовал в разработке.
13-14 июля ЛАФ в Подмосковье. На правах члена ПК и почетного докладчика порассуждаю о развитии системного анализа и проектирования на примере истории развития и использования UML (некоторые мысли вы читали у канале, будет развитие темы). Где же ещё порассуждать, как не на фестивале.
Продолжается работа с отбором заявок на Flow 2024 Autumn — вообще, число заявок с каждым разом растёт, и ПК с каждым разом всё тяжелее отбирать самые лучшие доклады, двигающие вперёд индустрию.
И в промежутках между этими делами обещаю не бросать вас и радовать интересными и полезными постами, раскапывать неочевидные вещи и парадоксальные взгляды на знакомые предметы.
А также, надеюсь, к очередному бизнес-сезону, который у нас начинается осенью как раз примерно c дат проведения Flow (17 сентября в онлайне, 24-25 очно, хороший старт!), придумаю для вас новые интересные штуки.
Всем отличного лета!
systems.education
■ Systems Analyst Bootcamp — интенсивная онлайн-программа переподготовки. Системный аналитик
Интенсивная программа по проектированию информационных систем для действующих ИТ-специалистов и системных аналитиков
❤20👍3🔥2
Какую шикарную цитату нашел про системный анализ! Вот так он воспринимался в 1979:
Де Марко — один из авторов культовой книги "Peopleware", а также более поздних "The Deadline" и "Waltzing with Bears" и изобретатель структурного анализа. В упомянутой книге приведены описания диаграммы потоков данных (DFD) и словаря данных — мы этим методам и сейчас учим на курсах по интеграции и системному анализу.
В 1979 году я купил книгу Тома Де Марко "Structured Analysis and System Specifcation". К тому времени я работал около трех лет в качестве программиста, но имел амбиции стать системным аналитиком. Те, кто знал о моих амбициях, ясно намекали, что не каждый годится на роль системного аналитика. Весьма вероятно, что у меня нет "правильных наклонностей" — той специфической комбинации индивидуальности, интеллекта и взгляда на вещи, которые характеризуют системного аналитика. Короче говоря, бытовало мнение, что системный анализ близок к искусству и так же, как не каждый рождается,чтобы стать великим пианистом, не каждый может стать системным аналитиком.
После чтения книги Де Марко не было бы преувеличением сказать, что я избавился от шор. Попросту, я был ошеломлен! Большая тайна системного анализа была изложена совершенно открыто. Это не было искусством, во всяком случае не настолько искусством, это был метод, подход, техника. Хотя было бы диким упрощением сказать, что любой мог сделатъ это, конечно, это определенно не было уделом волшебников или гениев. Книга описывала метод, и если вы придерживались этого метода, вы выполняли системный анализ.
Системный анализ давно уже прекратил рядиться в мистические одежды, так что теперь нам, практикам программирования, пришлось найти другую черную магию, другую тайну, которая будет окутывать нас. Эта черная магия — руководство проектами, и вам достаточно посмотреть на статистику успехов проектов, чтобы понять, почему мир в целом воспринимает ее именно так.
Де Марко — один из авторов культовой книги "Peopleware", а также более поздних "The Deadline" и "Waltzing with Bears" и изобретатель структурного анализа. В упомянутой книге приведены описания диаграммы потоков данных (DFD) и словаря данных — мы этим методам и сейчас учим на курсах по интеграции и системному анализу.
👍33❤7
Формат OpenAPI, конечно, интересный и довольно мощный (например, вы знали, что там есть наследование и полиморфизм?..) Но он всё-таки сложный. И объемный. Назвать его компактным никак нельзя.
Но есть упрощение и для OpenAPI. Ну то есть, в каком смысле упрощение. По крайней мере, компактификация. Всё ближе к языку программирования, всё дальше от текстового описания. Это язык TypeSpec (https://typespec.io/)
Выглядит примерно так:
Что мы тут видим:
— целевая генерация будет в http api (а может быть ещё protobuf, тут замена уже совсем простая)
— заданы три модели: Pet, Store и Address; это вам не JSON-Schema, синтаксис проще и компактней.
— заданы два эндпоинта: /pets и /stores, для первого -- три метода (получить список с возможностью указать фильтр в параметрах запроса; создать, передав JSON в теле запроса; получить один экземпляр по id, переданному в эндпоинте после /), для второго — два.
На этом всё. Из этого кода генерится спека в OpenAPI (JSON-схема, .proto-файл), которую дальше уже можно использовать как обычно (а как обычно вы её используете? скорее всего, либо код из неё генерируете, либо для верификации написанного вручную кода в ходе автоматической проверки релиза). То есть, это такой DSL для OpenAPI.
Язык тоже мощный, всё, что есть в OpenAPI и http, он поддерживает.
Например, чтобы дописать тип аутентификации, нужно добавить строчку вроде
Чтобы добавить поля заголовка запроса и коды ответов, нужно описать операцию чуть подробнее:
Что ещё классного есть в TypeSpec — абстрактные паттерны. Например, вы можете определить паттерн фильтрации через параметры запроса для любого ресурса, и потом его использовать, меняя только модель:
Ну как вам? Смогли бы такой язык использовать? Или совсем жесть, и это только для программистов?
Но есть упрощение и для OpenAPI. Ну то есть, в каком смысле упрощение. По крайней мере, компактификация. Всё ближе к языку программирования, всё дальше от текстового описания. Это язык TypeSpec (https://typespec.io/)
Выглядит примерно так:
import "@typespec/http";
using TypeSpec.Http;
// Определение моделей
model Pet {
name: string;
age: int32;
}
model Store {
name: string;
address: Address;
}
model Address {
street: string;
city: string;
}
// Определение эндпоинтов
@route("/pets")
interface Pets {
list(@query filter: string): Pet[];
create(@body pet: Pet): Pet;
read(@path id: string): Pet;
}
@route("/stores")
interface Stores {
list(@query filter: string): Store[];
read(@path id: string): Store;
}
Что мы тут видим:
— целевая генерация будет в http api (а может быть ещё protobuf, тут замена уже совсем простая)
— заданы три модели: Pet, Store и Address; это вам не JSON-Schema, синтаксис проще и компактней.
— заданы два эндпоинта: /pets и /stores, для первого -- три метода (получить список с возможностью указать фильтр в параметрах запроса; создать, передав JSON в теле запроса; получить один экземпляр по id, переданному в эндпоинте после /), для второго — два.
На этом всё. Из этого кода генерится спека в OpenAPI (JSON-схема, .proto-файл), которую дальше уже можно использовать как обычно (а как обычно вы её используете? скорее всего, либо код из неё генерируете, либо для верификации написанного вручную кода в ходе автоматической проверки релиза). То есть, это такой DSL для OpenAPI.
Язык тоже мощный, всё, что есть в OpenAPI и http, он поддерживает.
Например, чтобы дописать тип аутентификации, нужно добавить строчку вроде
@useAuth(BasicAuth)
Чтобы добавить поля заголовка запроса и коды ответов, нужно описать операцию чуть подробнее:
op read(@path petId: int32, @header ifMatch?: string): {
@statusCode statusCode: 200;
@header eTag: string;
@body pet: Pet;
} | {
@statusCode statusCode: 404;
};Что ещё классного есть в TypeSpec — абстрактные паттерны. Например, вы можете определить паттерн фильтрации через параметры запроса для любого ресурса, и потом его использовать, меняя только модель:
// Define abstraction for resource lifecyle
op ResourceList<T>(@query filter: string): T[];
op ResourceRead<T>(@path id: string): T;
@post op ResourceCreate<T>(...T): T;
model Pet {
name: string;
age: int32;
}
@route("/pets")
interface Pets {
list is ResourceList<Pet>;
create is ResourceCreate<Pet>;
read is ResourceRead<Pet>;
}
Ну как вам? Смогли бы такой язык использовать? Или совсем жесть, и это только для программистов?
👍16🔥6😨6❤2
А вот интересный пост про качества лидеров. Я не так часто пишу на темы управления проектами, но все мы так или иначе работаем в проектах и кто-то в любом случае выполняет роль лидера.
На днях мне попалось интересное видео с TEDxBerlin от Мартина Гутманна: https://www.ted.com/talks/martin_gutmann_are_we_celebrating_the_wrong_leaders
В нём историк задается вопросом, почему мы выбираем в качестве лидеров людей по тому впечатлению, которое они производят, а не по их реальным результатам. И по тому, насколько они успешно решают кризисные ситуации, не учитывая, что они сами и были причиной этих кризисов. Наблюдение, безусловно, находит подтверждение — думаю, все могут вспомнить таких людей среди руководителей.
Однако в качестве примеров Гутманн приводит руководителей полярных экспедиций: Амундсена и Шеклтона. Это начало XX века, гонка за покорение Южного полюса. Странно, что он привел в пример Шеклтона, обычно вспоминают Скотта, погибшего на обратном пути с полюса. Так или иначе, все трое они штурмовали Антарктиду, но успешно достиг полюса и вернулся только Амундсен. Именно у него всё шло по плану и по графику, поэтому его очень любят в проектном менеджменте и бизнес-школах.
Но, если залезать в детали — далеко не всё так однозначно. Амундсен, конечно, умел хорошо подготовиться и всё тщательно рассчитать, а также собрать команду по хард-скиллам (у него все умели ходить на лыжах, многие были опытными каюрами, почти у всех был опыт полярных экспедиций). Однако стиль руководства у него был жесткий, почти военный, команда была плохо сработана, а сам Амундсен не терпел никаких возражений и конкуренции, вплоть до ссаживания несогласных в промежуточных портах.
В противоположность ему, Шеклтон при подборе команды опирался в первую очередь на софтскиллы, умение играть на музыкальных инструментах, общий настрой и дружелюбность. И бодрость духа в команде он ставил на первое место: в экспедиции издавался внутренний журнал, праздновались дни рождения и все праздники, все через одного были музыкантами или художниками. Собственно, Шеклтон сначала работал у Скотта, но они разошлись именно потому, что Шеклтон был неформальным лидером, и к Скотту люди уже переставали прислушиваться.
С другой стороны, Шеклтон при подготовке насовершал максимальное число промахов: он сам не умел ходить на лыжах, и в его команде тоже мало кто умел. Лыж вообще взяли буквально несколько штук. С собаками он тоже не очень ладил, поэтому собак в экспедиции тоже почти не было. Зато ему нравились лошадки (про которых было неизвестно, как они выдержат холод Антарктиды) и остромодная инновационная технология — автомобиль. Амундсен полагался на проверенных ездовых собак, у него всё судно было в собаках, больше сотни. На них ехали к полюсу, их же по дороге и ели, почти всех и съели, осталось 11. Скотт (и Шеклтон) такого допустить не могли по этическим соображениям и собак не использовали.
То же касалось и еды, и одежды, и судовых двигателей. Там, где Амундсен тщательно готовился, Шеклтон брал первые попавшиеся решения, без тестирования и серьезного анализа.
Зато Амундсен мог бросить своих спутников в буране и вернуться на базу. А Шеклтон возвращался в Антарктиду, пока не вывез всех участников экспедиции, остававшихся на зимовку (раза три он за ними возвращался). И отказаться от штурма полюса под угрозой гибели людей (до полюса он так и не дошел, и считал это своим лучшим решением, «живой осёл лучше мёртвого льва».
В общем, выбор вырисовывается такой: с одной стороны, расчетливый и циничный Амундсен, с полувоенной дисциплиной, но с отличными талантами в подготовке и планировании; с другой — душа компании Шеклтон, до последнего старающийся вытащить своих людей и сохранить бодрость духа, но довольно безалаберный в выборе технологий и подготовке.
И вот кого бы вы выбрали в качестве руководителя? С кем бы вам было комфортнее работать? На кого обычно были похожи ваши руководители?
На днях мне попалось интересное видео с TEDxBerlin от Мартина Гутманна: https://www.ted.com/talks/martin_gutmann_are_we_celebrating_the_wrong_leaders
В нём историк задается вопросом, почему мы выбираем в качестве лидеров людей по тому впечатлению, которое они производят, а не по их реальным результатам. И по тому, насколько они успешно решают кризисные ситуации, не учитывая, что они сами и были причиной этих кризисов. Наблюдение, безусловно, находит подтверждение — думаю, все могут вспомнить таких людей среди руководителей.
Однако в качестве примеров Гутманн приводит руководителей полярных экспедиций: Амундсена и Шеклтона. Это начало XX века, гонка за покорение Южного полюса. Странно, что он привел в пример Шеклтона, обычно вспоминают Скотта, погибшего на обратном пути с полюса. Так или иначе, все трое они штурмовали Антарктиду, но успешно достиг полюса и вернулся только Амундсен. Именно у него всё шло по плану и по графику, поэтому его очень любят в проектном менеджменте и бизнес-школах.
Но, если залезать в детали — далеко не всё так однозначно. Амундсен, конечно, умел хорошо подготовиться и всё тщательно рассчитать, а также собрать команду по хард-скиллам (у него все умели ходить на лыжах, многие были опытными каюрами, почти у всех был опыт полярных экспедиций). Однако стиль руководства у него был жесткий, почти военный, команда была плохо сработана, а сам Амундсен не терпел никаких возражений и конкуренции, вплоть до ссаживания несогласных в промежуточных портах.
В противоположность ему, Шеклтон при подборе команды опирался в первую очередь на софтскиллы, умение играть на музыкальных инструментах, общий настрой и дружелюбность. И бодрость духа в команде он ставил на первое место: в экспедиции издавался внутренний журнал, праздновались дни рождения и все праздники, все через одного были музыкантами или художниками. Собственно, Шеклтон сначала работал у Скотта, но они разошлись именно потому, что Шеклтон был неформальным лидером, и к Скотту люди уже переставали прислушиваться.
С другой стороны, Шеклтон при подготовке насовершал максимальное число промахов: он сам не умел ходить на лыжах, и в его команде тоже мало кто умел. Лыж вообще взяли буквально несколько штук. С собаками он тоже не очень ладил, поэтому собак в экспедиции тоже почти не было. Зато ему нравились лошадки (про которых было неизвестно, как они выдержат холод Антарктиды) и остромодная инновационная технология — автомобиль. Амундсен полагался на проверенных ездовых собак, у него всё судно было в собаках, больше сотни. На них ехали к полюсу, их же по дороге и ели, почти всех и съели, осталось 11. Скотт (и Шеклтон) такого допустить не могли по этическим соображениям и собак не использовали.
То же касалось и еды, и одежды, и судовых двигателей. Там, где Амундсен тщательно готовился, Шеклтон брал первые попавшиеся решения, без тестирования и серьезного анализа.
Зато Амундсен мог бросить своих спутников в буране и вернуться на базу. А Шеклтон возвращался в Антарктиду, пока не вывез всех участников экспедиции, остававшихся на зимовку (раза три он за ними возвращался). И отказаться от штурма полюса под угрозой гибели людей (до полюса он так и не дошел, и считал это своим лучшим решением, «живой осёл лучше мёртвого льва».
В общем, выбор вырисовывается такой: с одной стороны, расчетливый и циничный Амундсен, с полувоенной дисциплиной, но с отличными талантами в подготовке и планировании; с другой — душа компании Шеклтон, до последнего старающийся вытащить своих людей и сохранить бодрость духа, но довольно безалаберный в выборе технологий и подготовке.
И вот кого бы вы выбрали в качестве руководителя? С кем бы вам было комфортнее работать? На кого обычно были похожи ваши руководители?
Ted
Are we celebrating the wrong leaders?
We tend to celebrate leaders for their dramatic words and actions in times of crisis — but we often overlook truly great leaders who avoid the crisis to begin with. Historian Martin Gutmann challenges us to rethink what effective leadership actually looks…
👍24🔥4
(Понимаю, что если бы объединить тщательность планирования Амундсена с заботой о команде Шеклтона — получился бы идеальный руководитель. Но чаще мы видим объединение других черт: строгая дисциплина в сочетании с бардаком в планировании, выборе целей и выборе технологий).
🤝11😁8👍1
В канале ЛАФ прикольный конкурс — вспомните какую-то типовую фразу из общения аналитиков с заказчиками / разработчиками / менеджерами проектов, какую-то шутку из рабочего контекста — для размещения на мерче ЛАФа. Футболку или толстовку с какой фразой вы давно хотели иметь?
За лучшую идею дают скидки на билеты 15%, 10%, 5% или эксклюзивный мерч ЛАФ 2024!
Мои фавориты, конечно:
My IDE is Google Docs
и
— Морфеус, я знаю UML!
— Посмотрим
Но, боюсь, это слишком сложно :)
Конкурс продлится с 20 до 24 июня, так что переходите в канал прямо сейчас.
Ну и приезжайте на ЛАФ — вас ждут 40+ докладов, мастер-классов, дискуссий и игр с упором на практику и интерактив в атмосфере свободного общения и отдыха на природе.
Я там хочу рассказать про развитие и современное состояние визуальных инструментов проектирования и анализа, на базе результатов опроса, конечно, и изучения истории вопроса. И проследить историю развития и актуальное состояние системного анализа на этом примере. Опрос меня несколько обескуражил, честно говоря — в части целей составления диаграмм. Не такого я ожидал, и не так я вижу задачу аналитика. Но, видимо, это то, чего хочет от профессии рынок. Вот про это хочется поговорить, такой практически key-note.
Про результаты напишу в канале, конечно.
За лучшую идею дают скидки на билеты 15%, 10%, 5% или эксклюзивный мерч ЛАФ 2024!
Мои фавориты, конечно:
My IDE is Google Docs
и
— Морфеус, я знаю UML!
— Посмотрим
Но, боюсь, это слишком сложно :)
Конкурс продлится с 20 до 24 июня, так что переходите в канал прямо сейчас.
Ну и приезжайте на ЛАФ — вас ждут 40+ докладов, мастер-классов, дискуссий и игр с упором на практику и интерактив в атмосфере свободного общения и отдыха на природе.
Я там хочу рассказать про развитие и современное состояние визуальных инструментов проектирования и анализа, на базе результатов опроса, конечно, и изучения истории вопроса. И проследить историю развития и актуальное состояние системного анализа на этом примере. Опрос меня несколько обескуражил, честно говоря — в части целей составления диаграмм. Не такого я ожидал, и не так я вижу задачу аналитика. Но, видимо, это то, чего хочет от профессии рынок. Вот про это хочется поговорить, такой практически key-note.
Про результаты напишу в канале, конечно.
👍4🔥3❤1
Шикарная картинка про архитектуру современных систем, в целом отражает 😂
"Мы замучились придумывать осмысленные названия слоям архитектуры и теперь просто называем их в честь их архитекторов".
Фундаментальный закон программной инженерии, сформулированный ещё в 1972 году:
"Любую проблему в программной инженерии можно решить добавлением ещё одного уровня абстракции."
(в оригинале indirection — опосредованности)
Это мы повсюду наблюдаем: нельзя напрямую к таблицам в БД лезтьгрязными руками, нужно сделать views, над ними ORM в фреймворке, к нему API, потом BFF для клиентов, потом API Gateway для сборки BFF из разных сервисов, а перед ним балансировщик и CDN для статики!
И если вы думаете, что я шучу, то нет — ровно такую картинку видел на днях в одной статье. Разве что для слоев пока ещё хватило осмысленных имен.
"Мы замучились придумывать осмысленные названия слоям архитектуры и теперь просто называем их в честь их архитекторов".
Фундаментальный закон программной инженерии, сформулированный ещё в 1972 году:
"Любую проблему в программной инженерии можно решить добавлением ещё одного уровня абстракции."
(в оригинале indirection — опосредованности)
Это мы повсюду наблюдаем: нельзя напрямую к таблицам в БД лезть
И если вы думаете, что я шучу, то нет — ровно такую картинку видел на днях в одной статье. Разве что для слоев пока ещё хватило осмысленных имен.
😁22👍4
Во всех курсах по интеграциям при рассказе про REST повторяется тезис: ключевая особенность архитектуры REST — взаимодействие по принципу "клиент-сервер".
И слушатели такие — ну да, ну да, клиент-сервер. А почему, собственно, это важно? И что это значит? И можно ли как-то по-другому?
С чем боролись-то?
Вы знаете ответ?
И слушатели такие — ну да, ну да, клиент-сервер. А почему, собственно, это важно? И что это значит? И можно ли как-то по-другому?
С чем боролись-то?
Вы знаете ответ?
Ответ на вчерашнюю загадку: мы-то сейчас уже не знаем и не помним, но 1990-е — это время, когда архитектура клиент-сервер победила архитектуру мейнфреймов. Филдинг понятно, про мейнфреймы в своей диссертации не пишет, она у него посвящена архитектуре сетевых программных систем, то есть заведомо не централизованных.
Упоминание разных архитектур есть в главе 2, где Филдинг разделяет архитектуры на централизованные, распределенные и сетевые.
Централизованные — это как раз мейнфреймы. Такая здоровенная железка, реально шкаф, с сотней+ процессоров, дисковыми (а когда-то и ленточными) накопителями, со специальной ОС, специальными СУБД, очень хорошо заточенными на конкретное железо.
Помните книгу "Мифический человеко-месяц"? Они там как раз и разрабатывали OS/360 — операционную систему для IBM-овских мейнфреймов System/360. Это самый дорогостоящий проект создания ПО в истории. Начальная стоимость разработки ОС оценивалась в 30-40 млн. долларов, в итоге превратившихся в 500 млн. Общая стоимость вместе с железом — 5 млрд. в ценах 60-х годов. Это дороже Манхэттенского проекта и на втором месте после программы "Аполлон".
В итоге IBM владел 90% рынка мейнфреймов, и почти весь бизнес использовал именно их.
Мейнфрейм имеет централизованную архитектуру: всё происходит внутри него. Терминалы, при помощи которых к нему подключаются — не клиенты, это вообще не компьютеры, это только устройства ввода и вывода. Вычисления, память — всё внутри мейнфрейма. Так были устроены все корпоративные системы до 90-х годов.
Развитие сетевых технологий шло принципиально другим путем: в сети изначально все узлы равны, и все "умные". Впрочем всё это было не очень важно, пока компьютеры (а не терминалы) появились на каждом столе в офисе. Это были "микрокомпьютеры", или персоналки — от Apple, Commodore и опять IBM (тут они не пропустили тренд). А такие же компьютеры, но чуть мощнее и в другом корпусе — стали серверами. Только стоили они на десятичные порядки дешевле мейнфреймов — те вообще часто не покупали, а брали в аренду, настолько они были дорогими. В 90-х полупроводниковая база стала достаточно мощной для решения интересных задач.
Если поднять статьи 90-х годов, мы увидим много обсуждений "клиент-сервер vs мейнфрейм" (вот, например, из 1995 года)
То есть, в 90-е постулат использования архитектуры клиент-сервер был ещё не совсем очевиден. Всё ещё кипело и бурлило. Даже есть взять децентрализованные системы — не все они обязательно являются клиент-серверными. Может быть, они ведут себя, как единый компьютер, размещенный на нескольких физических устройствах (например, распределенные файловые системы).
Филдинг в диссертации рассматривает и анализирует несколько видов архитектур:
➡️ pipe-and-filter (актуален и сейчас, особенно для обработки потоков данных);
➡️ репликация и кэширование (системы, которые эмулируют для пользователя централизованную обработку — суперактуальны сейчас, практически в каждом проекте);
➡️ разнообразные версии клиент-серверной и многослойной архитектуры: с передачей состояния и без передачи состояния, с кэшированием и без, с комбинациями типа "Layered-Client-Cache-Stateless-Server".
Пример клиент-серверного взаимодействия с передачей состояния — удаленные сессии, когда соединение поддерживается и состояние соединения — а часто и состояние выполняемого приложения — хранится на сервере. Сюда же относится удаленный доступ к данным (помните, в мейнфреймах СУБД были встроены прямо в ОС, ничего удаленного не требовалось!) — по типу SQL-запросов. На сервере хранится состояние транзакции для каждого клиента.
➡️ виртуальные машины (тоже архитектурный стиль!)
➡️ p2p взаимодействия
➡️ событийно-ориентированные взаимодействия (привет, event sourcing!), к которым Филдинг относит, неожиданно, Model-View-Controller (!)
➡️ распределенные объекты (слышали что-то про стандарт CORBA? я тоже почти нет)
Упоминание разных архитектур есть в главе 2, где Филдинг разделяет архитектуры на централизованные, распределенные и сетевые.
Централизованные — это как раз мейнфреймы. Такая здоровенная железка, реально шкаф, с сотней+ процессоров, дисковыми (а когда-то и ленточными) накопителями, со специальной ОС, специальными СУБД, очень хорошо заточенными на конкретное железо.
Помните книгу "Мифический человеко-месяц"? Они там как раз и разрабатывали OS/360 — операционную систему для IBM-овских мейнфреймов System/360. Это самый дорогостоящий проект создания ПО в истории. Начальная стоимость разработки ОС оценивалась в 30-40 млн. долларов, в итоге превратившихся в 500 млн. Общая стоимость вместе с железом — 5 млрд. в ценах 60-х годов. Это дороже Манхэттенского проекта и на втором месте после программы "Аполлон".
В итоге IBM владел 90% рынка мейнфреймов, и почти весь бизнес использовал именно их.
Мейнфрейм имеет централизованную архитектуру: всё происходит внутри него. Терминалы, при помощи которых к нему подключаются — не клиенты, это вообще не компьютеры, это только устройства ввода и вывода. Вычисления, память — всё внутри мейнфрейма. Так были устроены все корпоративные системы до 90-х годов.
Развитие сетевых технологий шло принципиально другим путем: в сети изначально все узлы равны, и все "умные". Впрочем всё это было не очень важно, пока компьютеры (а не терминалы) появились на каждом столе в офисе. Это были "микрокомпьютеры", или персоналки — от Apple, Commodore и опять IBM (тут они не пропустили тренд). А такие же компьютеры, но чуть мощнее и в другом корпусе — стали серверами. Только стоили они на десятичные порядки дешевле мейнфреймов — те вообще часто не покупали, а брали в аренду, настолько они были дорогими. В 90-х полупроводниковая база стала достаточно мощной для решения интересных задач.
Если поднять статьи 90-х годов, мы увидим много обсуждений "клиент-сервер vs мейнфрейм" (вот, например, из 1995 года)
То есть, в 90-е постулат использования архитектуры клиент-сервер был ещё не совсем очевиден. Всё ещё кипело и бурлило. Даже есть взять децентрализованные системы — не все они обязательно являются клиент-серверными. Может быть, они ведут себя, как единый компьютер, размещенный на нескольких физических устройствах (например, распределенные файловые системы).
Филдинг в диссертации рассматривает и анализирует несколько видов архитектур:
Пример клиент-серверного взаимодействия с передачей состояния — удаленные сессии, когда соединение поддерживается и состояние соединения — а часто и состояние выполняемого приложения — хранится на сервере. Сюда же относится удаленный доступ к данным (помните, в мейнфреймах СУБД были встроены прямо в ОС, ничего удаленного не требовалось!) — по типу SQL-запросов. На сервере хранится состояние транзакции для каждого клиента.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥6🤣1
Вот как много разных вариантов архитектур! все они так или иначе живы и сейчас — та же CORBA — это SOA, то есть шина, то есть микросервисы.
p2p — крипта и торренты.
Ну а что мейнфреймы? Да тоже живы, IBM их до сих пор продает на миллиарды долларов в год. А какой-нибудь гигант типа Sabre (это крупнейший сервис онлайн-бронирования авиабилетов) каждый год рапортует, что уже почти ушли с мейнфреймов, да, вот уже уже почти совсем ушли, угу, последние отключаем. Начиная с 2001 года, угу. Последнюю новость про 90% операций, перенесенных с мейнфреймов, я нашел в их корп. блоге от 30 января 2024.
Так выглядит мир ИТ, в котором мы живем.
p2p — крипта и торренты.
Ну а что мейнфреймы? Да тоже живы, IBM их до сих пор продает на миллиарды долларов в год. А какой-нибудь гигант типа Sabre (это крупнейший сервис онлайн-бронирования авиабилетов) каждый год рапортует, что уже почти ушли с мейнфреймов, да, вот уже уже почти совсем ушли, угу, последние отключаем. Начиная с 2001 года, угу. Последнюю новость про 90% операций, перенесенных с мейнфреймов, я нашел в их корп. блоге от 30 января 2024.
Так выглядит мир ИТ, в котором мы живем.
👍20
В группе конференции Analyst Days зашла речь про "идеальные" бизнес-требования, и к слову опять пришлись действия, которые аналитик должен выполнять рефлекторно, на автомате. Как оса, которая жалит, даже когда уже мертва.
На мой взгляд, к рефлекторным движениям аналитика можно отнести такие:
➡️ Поиск нормативки. Всегда есть какая-нибудь нормативка. Регламенты, договоры, стандарты, требования регуляторов. Человеческая деятельность почти всегда регулируется юридическими документами.
➡️ Выявление полноты операций: данные откуда-то должны появиться, кому-то быть предъявлены, в какой-то момент изменены или удалены. При этом данные не просто "есть", их обычно откуда-то нужно взять, об этом часто забывают.
➡️ Продумывание обеспечения, мониторинга и обслуживания. Что нужно для выполнения деятельности? Что нужно настроить, какие данные и шаблоны подготовить, кто это будет делать? Какие действия нужно регулярно делать в системе? (чистить мусор, архивировать старые данные, проталкивать вручную застрявшие операции и т.п.). За чем нужно следить и кто это должен делать?
➡️ Выяснение численных показателей. Когда аналитик рисует процесс или сценарий— он рисует его так, как будто в системе есть только один пользователь, один экземпляр процесса и один сотрудник, который этот процесс обрабатывает. Из-за этого пропускают полномочия, распределение, захват объектов на обработку, гонки и конкурирующие процессы, да и параллельную обработку в целом.
➡️ Выявление возможных комбинаций данных, состояний, и особенно пропущенных данных и ошибок в данных. Причем сочетания иногда могут быть совершенно диковинные: казалось бы, такого быть не может, а оно есть.
Вот буквально на днях видел выгрузку сделок, в которых коды товаров одинаковые, а наименование и цены — разные. Хотя казалось бы, как это может быть возможно?
То есть, безусловный рефлекс аналитика — всё ставить под сомнение. Да, коды уникальные. А точно уникальные? Ну, могут иногда повторяться. Формат артикула вот такой. Точно такой? Ну, иногда мы добавляем туда ещё вот такие символы, но это очень редко бывает. Выгрузку из системы делаем каждый день. Точно каждый день? Ну, когда не забываем. Все врут.
А вы как считаете, что ещё должен делать аналитик на автомате?
На мой взгляд, к рефлекторным движениям аналитика можно отнести такие:
Вот буквально на днях видел выгрузку сделок, в которых коды товаров одинаковые, а наименование и цены — разные. Хотя казалось бы, как это может быть возможно?
То есть, безусловный рефлекс аналитика — всё ставить под сомнение. Да, коды уникальные. А точно уникальные? Ну, могут иногда повторяться. Формат артикула вот такой. Точно такой? Ну, иногда мы добавляем туда ещё вот такие символы, но это очень редко бывает. Выгрузку из системы делаем каждый день. Точно каждый день? Ну, когда не забываем. Все врут.
А вы как считаете, что ещё должен делать аналитик на автомате?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36💯4❤1
На ЛАФ меня позвали на круглый стол про моделирование процессов.
Рискованный шаг, нужно сказать, потому что я совсем не фанат моделирования БП, особенно тщательного, особенно вот этих всяких BPMN, EPC и т.д.
Очень часто я видел "бинзес-процессы", нарисованные просто потому, что "это у нас по процессу разработки так положено" и "в BRS есть такой раздел". Получаются бизнес-процесс проведения урока, бизнес-процесс простановки оценки, бизнес-процесс просмотра логов, бизнес-процесс отправки письма.
В документе есть такой раздел — да, давайте мучаться теперь. Опишем бизнес-процесс работы Шерлока Холмса. Или БП пилота в процессе полета (почему-то не видел таких, только табличные инструкции и чек-листы; а вот для авиакомпаний моделей много, в чем же разница?)
И, конечно, всякие чудные прекрасные фразы: "у нас БП в виде CJM", "замоделируем сценарии в виде БП", "БП для интеграции" и так далее.
А вы используете моделирование БП? Когда? Для чего? Всё ли вас устраивает, с какими сложностями сталкиваетесь? Бывает ли, что деятельность ну никак в бизнес-процесс не укладывается?
Рискованный шаг, нужно сказать, потому что я совсем не фанат моделирования БП, особенно тщательного, особенно вот этих всяких BPMN, EPC и т.д.
Очень часто я видел "бинзес-процессы", нарисованные просто потому, что "это у нас по процессу разработки так положено" и "в BRS есть такой раздел". Получаются бизнес-процесс проведения урока, бизнес-процесс простановки оценки, бизнес-процесс просмотра логов, бизнес-процесс отправки письма.
В документе есть такой раздел — да, давайте мучаться теперь. Опишем бизнес-процесс работы Шерлока Холмса. Или БП пилота в процессе полета (почему-то не видел таких, только табличные инструкции и чек-листы; а вот для авиакомпаний моделей много, в чем же разница?)
И, конечно, всякие чудные прекрасные фразы: "у нас БП в виде CJM", "замоделируем сценарии в виде БП", "БП для интеграции" и так далее.
А вы используете моделирование БП? Когда? Для чего? Всё ли вас устраивает, с какими сложностями сталкиваетесь? Бывает ли, что деятельность ну никак в бизнес-процесс не укладывается?
👍5❤3
Если вы в принципе описываете деятельность в виде последовательных шагов — в виде BPMN, EPC или UML Activity Diagram, а особенно если учите этому стажеров или начинающих аналитиков — вам будет полезна эта классификация ошибок в таких диаграммах.
(из статьи "Identifying common and persistent errors made by novice analysts when modeling business processes using UML
activity diagram: utilizing a hierarchical error classifcation", https://doi.org/10.1007/s11219-023-09628-2)
Авторы рассматривают Activity Diagram, а не BPMN, как наиболее простую в освоении нотацию. Но классификация ошибок в том числе опирается на более ранние классифиакции, учитывающие BPMN. В Activity Diagram нет событий, для BPMN их нужно добавить, думаю, понятно, как.
Интересен анализ частоты ошибок и их повторяемости. Чаще всего новички ошибаются в семантике, то есть используют один элемент вместо другого (ожидаемо), в полноте узлов (не хватает узлов соединения и разветвления, в терминах BPMN — шлюзов) и в избыточности действий (то есть, на диаграмме появляются лишние действия, не имеющие отношения к описываемому процессу).
Этот анализ в очередной раз говорит о сложности концепций для моделирования: чем отличается событие от действия? А действие от узла принятия решения? А конечное состояние от действия? Всё очень запутано.
Целый ряд ошибок связан с плохими навыками абстрагирования — обобщения описания процесса на типовую ситуацию, а не описание конкретной ситуации (использование имени актора вместо роли, например). Ещё одна типовая ошибка связана с неумением отличить важное от неважного — в примере было описание действий медсестры на приеме пациентов, и для неё не было важно — как именно пациент добрался до больницы, но эти действия тоже тащили на диаграмму.
При этом исследование показывает, что семантике можно довольно быстро научиться, полноте тоже, и даже навыком генерализации можно овладеть, а вот что трудно поддается улучшению — это способность отделять важное от неважного, и правильно разделять деятельность на отдельные действия, это развивается медленнее всего.
(из статьи "Identifying common and persistent errors made by novice analysts when modeling business processes using UML
activity diagram: utilizing a hierarchical error classifcation", https://doi.org/10.1007/s11219-023-09628-2)
Авторы рассматривают Activity Diagram, а не BPMN, как наиболее простую в освоении нотацию. Но классификация ошибок в том числе опирается на более ранние классифиакции, учитывающие BPMN. В Activity Diagram нет событий, для BPMN их нужно добавить, думаю, понятно, как.
Интересен анализ частоты ошибок и их повторяемости. Чаще всего новички ошибаются в семантике, то есть используют один элемент вместо другого (ожидаемо), в полноте узлов (не хватает узлов соединения и разветвления, в терминах BPMN — шлюзов) и в избыточности действий (то есть, на диаграмме появляются лишние действия, не имеющие отношения к описываемому процессу).
Этот анализ в очередной раз говорит о сложности концепций для моделирования: чем отличается событие от действия? А действие от узла принятия решения? А конечное состояние от действия? Всё очень запутано.
Целый ряд ошибок связан с плохими навыками абстрагирования — обобщения описания процесса на типовую ситуацию, а не описание конкретной ситуации (использование имени актора вместо роли, например). Ещё одна типовая ошибка связана с неумением отличить важное от неважного — в примере было описание действий медсестры на приеме пациентов, и для неё не было важно — как именно пациент добрался до больницы, но эти действия тоже тащили на диаграмму.
При этом исследование показывает, что семантике можно довольно быстро научиться, полноте тоже, и даже навыком генерализации можно овладеть, а вот что трудно поддается улучшению — это способность отделять важное от неважного, и правильно разделять деятельность на отдельные действия, это развивается медленнее всего.
🔥14👍3
В обсуждении к предыдущему посту начались обсуждения — как отличить важное от неважного, тут лучше на примере. Вот задание из статьи, можете проверить себя:
Задание:
Текст:
В оригинале это задание на час и результат предполагается на одну страницу в виде диаграммы активности. Можно и в виде BPMN записать.
И вот тут можно потренировать и навыки обобщения, и отделения важного от неважного, и правильного отображения последовательности действий, и узлов слияния / разветвления. В принципе, ничего сложного, но начинающий аналитик, наверное, может и запутаться.
Upd: Закинул это задание ChatGPT, он красиво насажал все ошибки, которые перечислены в статье, как настоящий новичок!
Задание:
Следующий текст рассказывает историю Ребекки. В тексте описаны два процесса, которые вы должны смоделировать. Эти процессы включают:
1. Административный приём в больницу
2. Медсестринский приём в отделении неотложной помощи (ER)
Текст:
Ребекка, 75-летняя женщина, была доставлена на машине скорой помощи в отделение неотложной помощи ближайшей больницы, так как ей стало плохо. Она прибыла в больницу в сопровождении дочери в полном сознании, и жаловалась на ощущение давления в груди. Она кричала, что ей не хватает воздуха, и ей очень трудно дышать. Казалось, что с каждым вдохом в легких у нее возникают спазмы. Она также жаловалась на слабость в ногах и тошноту.
Когда она поступила в отделение неотложной помощи, ее дочь попросили пройти в приемный покой для оформления госпитализации её матери, которая с трудом говорила и ходила. Сначала администратор в приемной запросила данные пациентки (в соответствии с ее идентификационным номером) в базах данных больницы. Поскольку это ее первый визит в больницу, история госпитализации пациентки не была найдена. Поэтому администратор открыла новую медицинскую карту Ребекки. После этого дочери нужно было заполнить полный бланк заявления о приеме, который включал информацию о медицинской страховке и краткую справку о состоянии здоровья. Администратор проверила детали формы вместе с дочерью и спросила, подключена ли её мать к сенсору тревоги дома. Наконец, администратор выдала стикер с именем пациентки и её номером удостоверения личности, приклеила его на бумажную папку и передала дочери, которая вернулась с ней в отделение неотложной помощи.
В это время, в связи с тяжелым состоянием матери, медсестра отделения неотложной помощи уже начала сестринское обследование. Сначала медсестра проверила следующие показатели: температуру тела (термометр), пульс и кровяное давление, а также насыщение крови кислородом (сатурацию) с помощью оптического считывателя, подключенного к сканеру. Эти тесты дают непосредственную и первоначальную картину состояния сердечно-сосудистой системы, которая включает в себя функции сердца, легких и кровеносных сосудов. Эти тесты позволяют врачу, среди прочего, определить, насколько стабильно состояние пациента и требуется ли неотложная медицинская помощь. Медсестра также провела оценку уровня боли.
После того, как медсестра выполнила все необходимые измерения, в медицинскую карту пациентки (это можно сделать только при наличии медицинской карты в системе). Когда дочь вернулась из приёмного отделения, медсестра попросила её рассказать краткую медицинскую историю матери, а также уточнить, какие лекарства мать принимает регулярно и по какой причине. Медсестра также поинтересовалась образом жизни матери. Дочь сообщила, что мать живёт одна, работает самостоятельно и курит не менее одной пачки сигарет в день. Дочь добавила, что мать оставалась у неё на выходные и уточнила, что в прошлом месяце мать была госпитализирована в другую больницу возле её дома из-за острой пневмонии. Медсестра спросила, есть ли у неё результаты недавних лабораторных тестов, рентгеновских снимков грудной клетки или заключений КТ или МРТ. Расстроенная дочь ответила, что, к сожалению, у неё нет этой информации, и так как сегодня суббота, она не сможет связаться с семейным врачом, чтобы выяснить это. По завершении опроса медсестра внесла жалобы пациентки и затем установила медсестринский диагноз в соответствии с предоставленными данными.
В оригинале это задание на час и результат предполагается на одну страницу в виде диаграммы активности. Можно и в виде BPMN записать.
И вот тут можно потренировать и навыки обобщения, и отделения важного от неважного, и правильного отображения последовательности действий, и узлов слияния / разветвления. В принципе, ничего сложного, но начинающий аналитик, наверное, может и запутаться.
Upd: Закинул это задание ChatGPT, он красиво насажал все ошибки, которые перечислены в статье, как настоящий новичок!
🔥8👍4❤2
Вот что выдает ChatGPT-4o с "ванильным" промптом (буквально, "построй activity diagram по тексту). Очевидно, тут много ошибок:
— лишние, несущественные действия ("прибыл в госпиталь", "сопровожден в отделение неотложной помощи", "возвращение из приёмного отделения");
— начало процесса не на месте: процесс явно должен начинать регистратор, а не пациент;
— название процесса вместо актора;
— недостаток абстракции: "спросить дочь", "отдать папку дочери", "спросить про тревожную кнопку", "Дочь Ребекки", возможно — перечисление тестов тоже слишком конкретно, в другой ситуации будет иным;
— перепутан порядок действий (заполнение формы после проверки полей этой формы);
— действия, порядок которых неважен, отображены как последовательные (это на сестринском осмотре);
— действие названо как объект данных;
— лишние, несущественные действия ("прибыл в госпиталь", "сопровожден в отделение неотложной помощи", "возвращение из приёмного отделения");
— начало процесса не на месте: процесс явно должен начинать регистратор, а не пациент;
— название процесса вместо актора;
— недостаток абстракции: "спросить дочь", "отдать папку дочери", "спросить про тревожную кнопку", "Дочь Ребекки", возможно — перечисление тестов тоже слишком конкретно, в другой ситуации будет иным;
— перепутан порядок действий (заполнение формы после проверки полей этой формы);
— действия, порядок которых неважен, отображены как последовательные (это на сестринском осмотре);
— действие названо как объект данных;
👍4👎3🤔1
А вот Claude 3.5 — другая LLM, в некоторых случаях срабатывает лучше, чем ChatGPT, даже 4o.
Промпт такой же, но посмотрите на результат:
— есть обобщение до "пациента" и "родственника";
— действия, порядок которых не важен, нарисованы как параллельные (не все, я бы опрос тоже распараллелил);
— есть заход на обобщение тестов ("измерение жизненных показателей");
— нет вопроса про тревожную кнопку;
— правда, нет и условия про проверку наличия карты, но тут вопрос — может, оно и правда не очень принципиально, нужно подумать;
В общем, мне результат Claude понравился больше. Сравнить выдачу разных моделей можно на https://llmarena.ru/, я рекомендую выбирать именно GPT 4o и Claude 3.5 Sonnet — они сейчас лучшие. Остальное так себе — например, ГигаЧат мне вместо кода начал пытаться генерировать картинку, да так и не смог.
Промпт такой же, но посмотрите на результат:
— есть обобщение до "пациента" и "родственника";
— действия, порядок которых не важен, нарисованы как параллельные (не все, я бы опрос тоже распараллелил);
— есть заход на обобщение тестов ("измерение жизненных показателей");
— нет вопроса про тревожную кнопку;
— правда, нет и условия про проверку наличия карты, но тут вопрос — может, оно и правда не очень принципиально, нужно подумать;
В общем, мне результат Claude понравился больше. Сравнить выдачу разных моделей можно на https://llmarena.ru/, я рекомендую выбирать именно GPT 4o и Claude 3.5 Sonnet — они сейчас лучшие. Остальное так себе — например, ГигаЧат мне вместо кода начал пытаться генерировать картинку, да так и не смог.
👍10❤1🔥1
Ладно, последний пост про моделирование деятельности. Слева — картинка с эталонным решением (по мнению авторов статьи). Как видите, довольно абстрактный процесс.
А справа — решение от Claude 3.5 Sonnet. Пока это лучший вариант, который мне удалось получить за один промпт. ChatGPT можно заставить выдать нечто похожее, но путем нескольких приближений — с абстрагированием и отделением важного от неважного у него хуже, чем у Claude.
В итоговом промпте я использовал несколько известных приемов промпт-инжиниринга, про которые известно, что они работают: выдал роль, давил на жалость и важность задачи, явно указал ошибки, которые могли бы встретиться. Нужно понимать, что результат всё равно нестабилен и немного плавает, даже Claude иногда сбивается при повторных запросах.
Итоговый промпт:
А справа — решение от Claude 3.5 Sonnet. Пока это лучший вариант, который мне удалось получить за один промпт. ChatGPT можно заставить выдать нечто похожее, но путем нескольких приближений — с абстрагированием и отделением важного от неважного у него хуже, чем у Claude.
В итоговом промпте я использовал несколько известных приемов промпт-инжиниринга, про которые известно, что они работают: выдал роль, давил на жалость и важность задачи, явно указал ошибки, которые могли бы встретиться. Нужно понимать, что результат всё равно нестабилен и немного плавает, даже Claude иногда сбивается при повторных запросах.
Итоговый промпт:
Представь, что ты опытный бизнес-аналитик с отличными навыками моделирования бизнес-процессов. Помоги мне с составлением Activity Diagram для описания процесса по тексту, который я дам тебе ниже. Диаграмму нужно представить в виде кода для PlantUML. При составлении диаграммы нужно абстрагироваться от конкретных действующих лиц и их частных действий, и перейти на более высокий уровень абстракции, то есть описать обобщенный процесс, не углубляясь в конкретику. При этом нужно учесть, что порядок некоторых действий в конкретном случае, описанном в тексте, может быть другим в других ситуациях, такие действия следует изобразить в виде параллельных. К частым ошибкам при построении такой диаграммы относятся: неполнота (не учтены все необходимые действия, роли и разветвления), избыточность (обратная ошибка - лишние действия, роли, разветвления, которых не должно быть на этом уровне абстракции), семантические ошибки: недостаточное абстрагирование (конкретные имена и действия, относящиеся именно к этому частному случаю), излишнее абстрагирование, неправильный порядок следования действий. При построении диаграммы нужно избежать этих ошибок.
В тексте описано два процесса:
1. Оформления пациента
2. Медсестринского приема
Мне нужна помощь со вторым процессом (прием медсестры). Это задание очень важно для меня, это тестовое задание и от него зависит моя будущая карьера. Пожалуйста, помоги мне выполнить это задание наилучшим образом.
Текст кейса:<>
🔥18❤3
Заметки с ЛАФ. Очень интересное наблюдение Николая Новика: много лишних знаний и владение разнообразными инструментами у аналитиков мешают им работать.
На курсах давали много всего, нужно же теперь работодателю показать всё, что знаешь. И получается документ, в котором есть всё разнообразие диаграмм, форматов описаний, кэнвасов и карт, но утерян смысл.
С точки зрения же работодателя, меньше = лучше. Есть конкретная задача, нужно её решить. Ничего больше, ничего меньше. JBGE — Just barely good enough, минимально достаточный артефакт.
И вот этот навык отделения важного от неважного очень сложно нарабатывается. Да, у тебя есть репертуар техник и инструментов, какие выбрать для решения именно этой задачи? И в какой последовательности их выстроить, как одно следует из другого? И этому не очень-то учат.
(Я учу, приходите ко мне)
На курсах давали много всего, нужно же теперь работодателю показать всё, что знаешь. И получается документ, в котором есть всё разнообразие диаграмм, форматов описаний, кэнвасов и карт, но утерян смысл.
С точки зрения же работодателя, меньше = лучше. Есть конкретная задача, нужно её решить. Ничего больше, ничего меньше. JBGE — Just barely good enough, минимально достаточный артефакт.
И вот этот навык отделения важного от неважного очень сложно нарабатывается. Да, у тебя есть репертуар техник и инструментов, какие выбрать для решения именно этой задачи? И в какой последовательности их выстроить, как одно следует из другого? И этому не очень-то учат.
(Я учу, приходите ко мне)
❤22👍8🔥6😁3🤡3
Андрей Дмитриев из JUG Ru Group на ЛАФ проводил сессию PESTEL-анализа. Это анализ значимых трендов и факторов в области политики (P), экономики (E), социальной сферы (S), Технологий (T), экологии (E) и права (L). Естественно, рассматривались факторы, которые могут повлиять на сферу ИТ и SA/BA.
Что назвали участники, по степени влияния (комментарии в скобках мои):
Сильное влияние:
- импортозамещение (почти все отметили)
- электронный документооборот (откуда? зачем?)
- усиление гос. регулирования (тоже у многих встречается)
- тотальная цифровизация
- рост киберпреступности
- забота о здоровье (как это связано с системным анализом?)
- рост гос.расходов на ИТ (мечты, мечты!)
- дефицит кадров (да!)
- рост возможностей для удаленной работы
Среднее влияние:
- демографическая яма (и, как следствие — дефицит кадров)
- сокращение горизонтов планирования
- глобализация логистики (куда уж глобальнее? скорее говорят об угрозе разрушении глобального мира)
- рост населения развивающихся стран
- рост миграционных потоков
- экономические войны, санкции
- повсеместное внедрение ИИ
- переход на облачную инфраструктуру (видимо, в РФ, т.к. вне её уже все там)
- "клиповое мышление" (нет такого феномена)
- онлайн-обучение
- частая смена работ
Слабое влияние:
- повышение экологической осознанности, "зеленые ИТ" (у нас традиционно не очень про это думают, а в мире тема острая)
- цифровая валюта
- цифровая медицина
Набор трендов интересный, можно дальше поштурмить, но было всего два часа. Если бы это был какой-нибудь rapid foresight, дальше бы можно было ещё раз уточнить значимость и оценить силу этих трендов; погенерить технологии и политики, разгоняющие или тормозящие тренды, составляющие в комбинации пакеты, резко ускоряющие тренд; дописать угрозы и возможности, своё отношение к этим трендам, и, наконец, сформировать инициативы и проекты, которые могут негативные тренды погасить, а положительные усилить (и дать возможность на них заработать). Но на это нужно полноценных два дня, а не два часа.
Что заметил: большинство трендов скорее негативные, люди видят угрозы и думают, как их преодолеть. Хочется, конечно, больше увидеть возможностей, но, наверное, это не к аналитикам — специфика профессии.
Что назвали участники, по степени влияния (комментарии в скобках мои):
Сильное влияние:
- импортозамещение (почти все отметили)
- электронный документооборот (откуда? зачем?)
- усиление гос. регулирования (тоже у многих встречается)
- тотальная цифровизация
- рост киберпреступности
- забота о здоровье (как это связано с системным анализом?)
- рост гос.расходов на ИТ (мечты, мечты!)
- дефицит кадров (да!)
- рост возможностей для удаленной работы
Среднее влияние:
- демографическая яма (и, как следствие — дефицит кадров)
- сокращение горизонтов планирования
- глобализация логистики (куда уж глобальнее? скорее говорят об угрозе разрушении глобального мира)
- рост населения развивающихся стран
- рост миграционных потоков
- экономические войны, санкции
- повсеместное внедрение ИИ
- переход на облачную инфраструктуру (видимо, в РФ, т.к. вне её уже все там)
- "клиповое мышление" (нет такого феномена)
- онлайн-обучение
- частая смена работ
Слабое влияние:
- повышение экологической осознанности, "зеленые ИТ" (у нас традиционно не очень про это думают, а в мире тема острая)
- цифровая валюта
- цифровая медицина
Набор трендов интересный, можно дальше поштурмить, но было всего два часа. Если бы это был какой-нибудь rapid foresight, дальше бы можно было ещё раз уточнить значимость и оценить силу этих трендов; погенерить технологии и политики, разгоняющие или тормозящие тренды, составляющие в комбинации пакеты, резко ускоряющие тренд; дописать угрозы и возможности, своё отношение к этим трендам, и, наконец, сформировать инициативы и проекты, которые могут негативные тренды погасить, а положительные усилить (и дать возможность на них заработать). Но на это нужно полноценных два дня, а не два часа.
Что заметил: большинство трендов скорее негативные, люди видят угрозы и думают, как их преодолеть. Хочется, конечно, больше увидеть возможностей, но, наверное, это не к аналитикам — специфика профессии.
🔥14👍2