Коллеги собрали папку каналов по системному анализу, как это сейчас модно. А вы какие каналы читаете по нашей теме?
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Подборка классных каналов про системный и бизнес-анализ
У телеграма появилась новая возможность поделиться несколькими каналами, чтобы можно было подписаться сразу на все.
Собрали для вас подборку каналов и групп, посвященных системному и бизнес-анализу от практиков и школ.
Можно подписаться сразу на все или выборочно. Каналы сложатся в отдельную папку SA. Потом можно отменить подписку или размьютить, как и с другими каналами, но мы рекомендуем следить за актуальными темами отрасли!
Папка с нашей подборкой классных каналов про системный и бизнес-анализ.
У телеграма появилась новая возможность поделиться несколькими каналами, чтобы можно было подписаться сразу на все.
Собрали для вас подборку каналов и групп, посвященных системному и бизнес-анализу от практиков и школ.
Можно подписаться сразу на все или выборочно. Каналы сложатся в отдельную папку SA. Потом можно отменить подписку или размьютить, как и с другими каналами, но мы рекомендуем следить за актуальными темами отрасли!
Папка с нашей подборкой классных каналов про системный и бизнес-анализ.
Telegram
SA folder
Systems Education invites you to add the folder “SA folder”, which includes 20 chats.
🔥7👍1
У Григория Добрякова классный (и очень холиварный, ух как у многих от него пригорело!) пост про шины и брокеры: как вы их используете — как шину данных, или как шину сообщений? Процитирую самую суть:
"Из-за мелких различий в трактовке паттерна в интернетах и литературе вы можете найти дюжину интерпретаций. Вот ета самая шина — ето што? В зависимости от личных симпатий команды это может быть, как минимум:
1. Событийный брокер (кафка, раббит) с честным потоком событий.
2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).
3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).
4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.
5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.
6. Какая-то абсолютная дичь в симбиозе http и событийного брокера, когда приходящее сообщение в кафке инициирует http-запрос в систему-получатель и фактически запихивает в него данные.
7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.
Но есть как минимум одно фундаментальное различие, которое морочит голову абсолютно всем: это использование шины событий как шины данных. И беда в том, что кафка это поощряет.
Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.
[...]
В программировании — то же самое. В идеальной ситуации достаточно обмениваться только дельтами, чтобы поддерживать в консистентности даже самую огромную систему. В реальной жизни, конечно, такая система моментально разъедется во всех данных.
Поэтому передают объекты целиком. "
Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.
Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).
"Из-за мелких различий в трактовке паттерна в интернетах и литературе вы можете найти дюжину интерпретаций. Вот ета самая шина — ето што? В зависимости от личных симпатий команды это может быть, как минимум:
1. Событийный брокер (кафка, раббит) с честным потоком событий.
2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).
3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).
4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.
5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.
6. Какая-то абсолютная дичь в симбиозе http и событийного брокера, когда приходящее сообщение в кафке инициирует http-запрос в систему-получатель и фактически запихивает в него данные.
7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.
Но есть как минимум одно фундаментальное различие, которое морочит голову абсолютно всем: это использование шины событий как шины данных. И беда в том, что кафка это поощряет.
Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.
[...]
В программировании — то же самое. В идеальной ситуации достаточно обмениваться только дельтами, чтобы поддерживать в консистентности даже самую огромную систему. В реальной жизни, конечно, такая система моментально разъедется во всех данных.
Поэтому передают объекты целиком. "
Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.
Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).
🔥12👍8❤3
Интересную тут штуку заметил и сформулировал: хотя у ChatGPT есть известная проблема с вычислениями (он трактует числа как текст, разбивая их так же "на слоги", токенизируя), он удивительно хорошо прикидывает.
Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.
Так же я пробовал спрашивать про оценку рынка — и по известным мне рынкам оценки от ChatGPT хорошо совпадают с отраслевыми отчётами. Возможно, он эти числа из этих же отчетов и берет :)
В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)
Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.
Так же я пробовал спрашивать про оценку рынка — и по известным мне рынкам оценки от ChatGPT хорошо совпадают с отраслевыми отчётами. Возможно, он эти числа из этих же отчетов и берет :)
В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)
👍17
Свежая статистика по зарплатам в вакансиях. Вчера как раз зарубились на эту тему на круглом столе на конференции "Анализ & Управление в ИТ проектах" – специализированная конференция 1С-аналитиков, куда меня позвали рассказать про ChatGPT. У 1С сейчас бум – во-первых, проекты стали сложнее, и запросов от бизнеса больше – и на интеграции, и на анализ данных, и на более дружелюбные интерфейсы; во-вторых – многие компании ищут замену SAP. При этом раньше массово такой роли, как аналитик, в 1С не было, а сейчас это очень горячая тема, и ребята активно осваивают все методы, существующие в других областях.
Вчера как раз был круглый стол на тему "откуда брать аналитиков" и чему их учить. Интересно, что разработчиков 1С сейчас гораздо больше, чем аналитиков, и спрос на них меньше, такой вот парадокс. Так что передайте своим знакомым 1С-программистам, пусть приходят к нам учиться методам системного и бизнес-анализа :)
Вчера как раз был круглый стол на тему "откуда брать аналитиков" и чему их учить. Интересно, что разработчиков 1С сейчас гораздо больше, чем аналитиков, и спрос на них меньше, такой вот парадокс. Так что передайте своим знакомым 1С-программистам, пусть приходят к нам учиться методам системного и бизнес-анализа :)
👍8
( Отдельно зафиксирую, что планка в 400 тыс. – это что-то новое, раньше такого вроде не было. Такие суммы обычно готовы платить архитекторам, а не аналитикам. Видимо, спрос на квалифицированные кадры продолжает расти)
👍5❤2
Послушал несколько дискуссий про роль аналитика на проекте, и, кажется, очень часто понимание работы (со стороны руководителей!) сводится к механическим вещам: сколько требований описано, насколько документация процессов или системы соответствует реальности, то есть, аналитик выступает таким механизмом для составления компактного описания системы — "модели" в классическом понимании, как "более простой системы, которая несёт информацию о более сложной системе".
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.
🔥21👍11
Оказывается, сервис, который я проектировал в Московской электронной школе — портфолио учащегося — получил Премию Рунета 2022. Это прямо признание. Теперь у меня один проект в 2016 в шортлисте — "Открытое образование", и один — лауреат. Приятно.
🔥44👏20❤3😱2
На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато наглядно показано, как сама техника работает, и почему очень важно найти и правильно сформулировать противоречие.
У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.
И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)
Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)
Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)
Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.
У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.
И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)
Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)
Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)
Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.
🔥30👍3👏2🆒1
Наша школа расширяется, и мы хотим сохранять практику, когда у нас преподают только опытные аналитики, поэтому сейчас ищем новых тренеров. С нас — обучение приемам ведения, методическое сопровождение, прокачка тренерских скиллов и личного бренда (мы активно записываем вебинары и статьи с нашими ведущими, помогаем с подготовкой выступлений на конференциях). Ну и достойная оплата, само собой, на тренерах мы не экономим. С вас — жгучее желание поделиться своим опытом с коллегами.
Я к объявлению добавлю, что мы развиваем направление интеграций, проектирования и архитектуры (systems design, UX), так что если вы чувствуете себя уверенно в этих областях — приходите делать новые курсы! Писать можно мне или Денису (по ссылке в объявлении).
Я к объявлению добавлю, что мы развиваем направление интеграций, проектирования и архитектуры (systems design, UX), так что если вы чувствуете себя уверенно в этих областях — приходите делать новые курсы! Писать можно мне или Денису (по ссылке в объявлении).
👍7🤔2
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Ищем тренеров по системному анализу и проектированию
на дистанционную работу
Ищем в команду школы опытных системных аналитиков, которым интересно собственное развитие через обучение других:
— проведение контактных групповых онлайн-занятий в малых группах (до 12-15 человек)
— проверка домашних работ
— разработка учебных материалов (по желанию)
Мы ждём, что вы хорошо знакомы c 3-4 профессиональными темами из:
— классическая инженерия требований
— проектирование взаимодействия в форматах use case и user story
— современные фасилитационные практики Event Storming, Impact Mapping, Story Mapping
— моделирование структур данных и применение SQL
— интеграция информационных систем и проектирование API
— проектирование пользовательских интерфейсов
учебные курсы, которые надо вести:
— Системный анализ и Разработка требований в ИТ-проектах
— Systems Analyst Bootcamp
— Проектирование интеграций через брокеры сообщений
основное время проведения занятий
— суббота и воскресенье с 10 до 14 мск
загрузка от 8 до 24 часов в месяц по договорённости
пишите о себе Денису @beskov
на дистанционную работу
Ищем в команду школы опытных системных аналитиков, которым интересно собственное развитие через обучение других:
— проведение контактных групповых онлайн-занятий в малых группах (до 12-15 человек)
— проверка домашних работ
— разработка учебных материалов (по желанию)
Мы ждём, что вы хорошо знакомы c 3-4 профессиональными темами из:
— классическая инженерия требований
— проектирование взаимодействия в форматах use case и user story
— современные фасилитационные практики Event Storming, Impact Mapping, Story Mapping
— моделирование структур данных и применение SQL
— интеграция информационных систем и проектирование API
— проектирование пользовательских интерфейсов
учебные курсы, которые надо вести:
— Системный анализ и Разработка требований в ИТ-проектах
— Systems Analyst Bootcamp
— Проектирование интеграций через брокеры сообщений
основное время проведения занятий
— суббота и воскресенье с 10 до 14 мск
загрузка от 8 до 24 часов в месяц по договорённости
пишите о себе Денису @beskov
По поводу одного из предыдущих постов возникла дискуссия про зрелость программной архитектуры, как инженерной дисциплины. Тема крайне дискуссионная и требует более подробного анализа, но вот что я вспомнил. Сейчас общее место для архитектуры - стили и паттерны. Мы говорим про тактические паттерны DDD, паттерны интеграций приложений, паттерны объектно-ориентированных языков. Даже популярная тема systems design обсуждается в виде типовых решений и шаблонов. Обычно разговор про паттерны возводят к книге Кристофера Александера "Язык шаблонов", но ещё немного раньше - в конце XVII - начале XVIII века - жил в Швеции гениальный механик и преподаватель Кристофер Полхем. Он для своего времени был пионером - например, спроектировал и построил фабрику, автоматически производившую несколько (!) видов товаров (это ещё до паровых двигателей, на воде, как мельница!). Его называли "северным Дедалом".
Так вот Полхем в образовательных целях собрал так называемый "Механический алфавит" - набор узлов, из которых можно собрать любой механизм. Сейчас бы это назвали "паттерны проектирования механизмов", но такого предмета в современных университетах нет, есть "теория машин и механизмов", разработанная и математически обоснованная на 100 лет позже, в середине XIX в., во многом стараниями русского учёного Чебышёва, который сам был как раз математиком. Так что у нас в проектировании систем пока уровень паттернов, "архитектурного алфавита", дисциплина ждёт своего Чебышёва.
А "Механический алфавит" можно увидеть в Национальном музее науки и технологий в Швеции, ну или на сайте: https://digitaltmuseum.se/search/?q=mekaniskt+alfabet
Это вам не книжка, это настоящие физические деревянные модели!
Так вот Полхем в образовательных целях собрал так называемый "Механический алфавит" - набор узлов, из которых можно собрать любой механизм. Сейчас бы это назвали "паттерны проектирования механизмов", но такого предмета в современных университетах нет, есть "теория машин и механизмов", разработанная и математически обоснованная на 100 лет позже, в середине XIX в., во многом стараниями русского учёного Чебышёва, который сам был как раз математиком. Так что у нас в проектировании систем пока уровень паттернов, "архитектурного алфавита", дисциплина ждёт своего Чебышёва.
А "Механический алфавит" можно увидеть в Национальном музее науки и технологий в Швеции, ну или на сайте: https://digitaltmuseum.se/search/?q=mekaniskt+alfabet
Это вам не книжка, это настоящие физические деревянные модели!
🔥15👍4
Элементы "Механического алфавита", Кристофер Полхем, эскизы моделей, паттерны организации пространства Кристофера Александера.
❤5👍3
Не смог в этом году поехать на ЛАФ, но пристально слежу за докладами (и читаю обзоры Макса Цепкова, большое ему спасибо!). Всегда очень интересно — про что говорит сообщество, какие темы актуальны.
Встретил упоминание доклада "Практические подходы к измерению KPI аналитиков на Agile-проектах", и тут у меня прямо всё встрепенулось! KPI и Agile в одном предложении! Тут, как говорится, или крестик снимите, или трусы наденьте. Из разных миров слова. Или уж KPI и прочие корпоративные радости, или agile с самоорганизующимися командами и самоулучшающимся процессом, уважением к способу работы команды и фокусом на поставке бизнес-ценности.
А работа по спринтам — это ещё не agile, это просто способ организации работ короткими итерациями, при чем тут agile. Из него, наоборот, ту ещё соковыжималку можно сделать при желании.
Интересно, конечно, будет сам доклад посмотреть — что там автор про KPI думает и про Agile. А у вас, дорогие читатели, какой опыт?
Встретил упоминание доклада "Практические подходы к измерению KPI аналитиков на Agile-проектах", и тут у меня прямо всё встрепенулось! KPI и Agile в одном предложении! Тут, как говорится, или крестик снимите, или трусы наденьте. Из разных миров слова. Или уж KPI и прочие корпоративные радости, или agile с самоорганизующимися командами и самоулучшающимся процессом, уважением к способу работы команды и фокусом на поставке бизнес-ценности.
А работа по спринтам — это ещё не agile, это просто способ организации работ короткими итерациями, при чем тут agile. Из него, наоборот, ту ещё соковыжималку можно сделать при желании.
Интересно, конечно, будет сам доклад посмотреть — что там автор про KPI думает и про Agile. А у вас, дорогие читатели, какой опыт?
👍6🔥2❤1