🏫 Снова в школу?
Сейчас тот период, когда взрослые идут в школу, чтобы посетить так называемые линейки своих детей. Сегодня я был тоже в школе, но в другой и по другому поводу.
Я был в Школе 21 в Новосибирске. Если кто не знает, Школа 21 — это образовательное заведение от Сбера, в котором можно получить IT-профессию 👩🏻💻.
Целью моего визита было чтение лекции на тему "Системный аналитик: профессия соединять идеи и технологии". Я простыми словами на житейских примерах рассказал слушателям, кто такой системный аналитик, чем он занимается, почему он главный "почемучка" на проекте и пр. Надеюсь, всё прошло хорошо и те, кто только присматриваются к выбору будущей профессии, смогут сделать выбор (каким бы он ни был) более осознанно.
Теперь о впечатлениях. Они только положительные 🔥! Было здорово выступить перед столь заинтересованной аудиторией. Вопросов было много, в том числе онлайн от слушателей из кампусов Школы 21 из других городов 💪. Время пролетело незаметно.
#выступления #события #сбер
Сейчас тот период, когда взрослые идут в школу, чтобы посетить так называемые линейки своих детей. Сегодня я был тоже в школе, но в другой и по другому поводу.
Я был в Школе 21 в Новосибирске. Если кто не знает, Школа 21 — это образовательное заведение от Сбера, в котором можно получить IT-профессию 👩🏻💻.
Целью моего визита было чтение лекции на тему "Системный аналитик: профессия соединять идеи и технологии". Я простыми словами на житейских примерах рассказал слушателям, кто такой системный аналитик, чем он занимается, почему он главный "почемучка" на проекте и пр. Надеюсь, всё прошло хорошо и те, кто только присматриваются к выбору будущей профессии, смогут сделать выбор (каким бы он ни был) более осознанно.
Теперь о впечатлениях. Они только положительные 🔥! Было здорово выступить перед столь заинтересованной аудиторией. Вопросов было много, в том числе онлайн от слушателей из кампусов Школы 21 из других городов 💪. Время пролетело незаметно.
#выступления #события #сбер
🔥7👍4
преза_школа21.pdf
2.1 MB
Во вложении презентация с сегодняшнего мероприятия в Школе 21 (см. пост выше 👆).
👍7🙏1
🌟 if pow (аналитик, 2) == архитектор
Часто замечаю, что в обсуждениях нет-нет да и возникает вопрос: куда расти аналитику? И, что примечательно, довольно популярной ответ – в архитектора решений.
Но стоит ли аналитику в действительности грезить карьерой solution-архитектора? Или эти две роли настолько разные, что одна из другой никак не вырастает?
Я рассуждаю так.
Системный аналитик – это как опытный следопыт🕵🏻♂️, шаг за шагом исследующий лес проблем заказчика и клиентов. Он знает каждую тропинку, ловушку и даже растяжку, старательно установленную смежниками😉 на пути. Но каким бы аналитик ни был выносливым, возможность прочесать весь лес всё же малореальна.
А вот архитектор решений – это как Маша из сказки "Маша и мелведь". Он высоко сидит и далеко глядит. 🔭 Его задача – увидеть общую архитектуру проекта, функциональной области или даже компании в целом, учесть риски и планы по трансформации ИТ-ландшафта. Поэтому архитектор с высоты физически может не видеть всех "тропинок", а некоторые из них просто сливаются в одну большую трассу.
Так что с того? Ответ, как мне предоставляется, таков: обе профессии важны и нужны, но они разные. Это всё равно что отоларинголог из вашей поликлиники мечтал бы вырасти до терапевта (или наоборот). Звучит странно? Вот то-то и оно! Потенциально возможно? Конечно! Если инвестировать время в приобретение соответствующих знаний, то любой переход становится возможным, если, конечно, есть такое желание.
Согласны ли вы с моей логикой? Делитесь мыслями в комментариях!✨
Часто замечаю, что в обсуждениях нет-нет да и возникает вопрос: куда расти аналитику? И, что примечательно, довольно популярной ответ – в архитектора решений.
Но стоит ли аналитику в действительности грезить карьерой solution-архитектора? Или эти две роли настолько разные, что одна из другой никак не вырастает?
Я рассуждаю так.
Системный аналитик – это как опытный следопыт🕵🏻♂️, шаг за шагом исследующий лес проблем заказчика и клиентов. Он знает каждую тропинку, ловушку и даже растяжку, старательно установленную смежниками😉 на пути. Но каким бы аналитик ни был выносливым, возможность прочесать весь лес всё же малореальна.
А вот архитектор решений – это как Маша из сказки "Маша и мелведь". Он высоко сидит и далеко глядит. 🔭 Его задача – увидеть общую архитектуру проекта, функциональной области или даже компании в целом, учесть риски и планы по трансформации ИТ-ландшафта. Поэтому архитектор с высоты физически может не видеть всех "тропинок", а некоторые из них просто сливаются в одну большую трассу.
Так что с того? Ответ, как мне предоставляется, таков: обе профессии важны и нужны, но они разные. Это всё равно что отоларинголог из вашей поликлиники мечтал бы вырасти до терапевта (или наоборот). Звучит странно? Вот то-то и оно! Потенциально возможно? Конечно! Если инвестировать время в приобретение соответствующих знаний, то любой переход становится возможным, если, конечно, есть такое желание.
Согласны ли вы с моей логикой? Делитесь мыслями в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍3🔥1
⚖ Сравнение SOA и MSA
Время от времени в различных ситуациях возникает вопрос, чем отличается сервис-ориентированная архитектура (SOA) от микросервисной (MSA).
Кто-то говорит, что MSA это частный случай SOA. Иные убеждены, что вопрос только в размере интегрируемых систем или сервисов.
Можно также встретить мнение, что SOA стремится к максимальной унификации моделей данных и переиспользованию сервисов, в то время как в MSA принимается разнородность данных и логики, а сложность локализуется на уровне контекстов и сервисов.
Не смотря на то, что последняя позиция мне кажется концептуально более верной, предлагаю обратиться к книге Криса Ричардсона "Микросервисы. Паттерны разработки и рефакторинга" (см. обзор) как к авторитетному источнику. В ней приводится следующее сравнение.
🟣 Межсервисное взаимодействие
⚙️ SOA: Умные каналы, такие как сервисная шина предприятия (ESB), с использованием тяжеловесных протоколов вроде SOAP и других веб-сервисных стандартов
☸ MSA: Примитивные каналы, такие как брокер сообщений, или прямое взаимодействие между сервисами с помощью легковесных протоколов наподобие REST или gRPC
🟣 Данные
⚙️ SOA: Глобальная модель данных и общие базы данных
☸ MSA: Отдельные модель данных и база данных для каждого сервиса
🟣 Типовой сервис
⚙️ SOA: Крупное монолитное приложение
☸ MSA: Небольшой сервис
#архитектура #интеграции #сервисы
Время от времени в различных ситуациях возникает вопрос, чем отличается сервис-ориентированная архитектура (SOA) от микросервисной (MSA).
Кто-то говорит, что MSA это частный случай SOA. Иные убеждены, что вопрос только в размере интегрируемых систем или сервисов.
Можно также встретить мнение, что SOA стремится к максимальной унификации моделей данных и переиспользованию сервисов, в то время как в MSA принимается разнородность данных и логики, а сложность локализуется на уровне контекстов и сервисов.
Не смотря на то, что последняя позиция мне кажется концептуально более верной, предлагаю обратиться к книге Криса Ричардсона "Микросервисы. Паттерны разработки и рефакторинга" (см. обзор) как к авторитетному источнику. В ней приводится следующее сравнение.
⚙️ SOA: Умные каналы, такие как сервисная шина предприятия (ESB), с использованием тяжеловесных протоколов вроде SOAP и других веб-сервисных стандартов
☸ MSA: Примитивные каналы, такие как брокер сообщений, или прямое взаимодействие между сервисами с помощью легковесных протоколов наподобие REST или gRPC
⚙️ SOA: Глобальная модель данных и общие базы данных
☸ MSA: Отдельные модель данных и база данных для каждого сервиса
⚙️ SOA: Крупное монолитное приложение
☸ MSA: Небольшой сервис
#архитектура #интеграции #сервисы
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5
🧊 Куб масштабирования
Куб масштабирования (Scale Cube) — модель, которая указывает три принципиально возможных направления (аспекта) для масштабирования IT-систем.
Модель была разработана Мартином Фаулером и Джеймсом Льюисом, хотя одним из основных её популяризаторов по праву считается небезызвестный Крис Ричардсон. Экскурс в историю закончен, теперь перейдём к сути.
Модель куба масштабирования включает три типа масштабирования: по осям X, Y и Z.
🔤 Масштабирование по оси X
Запускается несколько одинаковых экземпляров приложения за балансировщиком нагрузки. Недостатки: увеличенное потребление памяти и отсутствие решения проблем, обусловленных сложностью приложения.
🔤 Масштабирование по оси Y
Приложение делится на отдельные независимые сервисы, каждый из которых отвечает за свою область функциональности. Возможны разные подходы к декомпозиции: на основе действий ("глаголы") или объектов ("существительные"). Недостатки: сложность управления множеством сервисов и рост зависимости от сетевой инфраструктуры.
🔤 Масштабирование по оси Z
Каждому серверу выделяется своя часть данных (разделение может выполняться по географическому признаку, по идентификационным номерам клиентов и т.д.), запросы автоматически направляются на нужный сервер. Недостатком является сложность реализации маршрутизации и потенциальная неравномерность распределения нагрузки.
Более подробно про плюсы и минусы каждого подхода можно прочитать в статье К. Ричардсона, доступной по ссылке.
💡 При этом важно отметить, что на практике масштабирование крупных систем часто выполняется сразу по нескольким осям.
#архитектура #интеграции #сервисы
Куб масштабирования (Scale Cube) — модель, которая указывает три принципиально возможных направления (аспекта) для масштабирования IT-систем.
Модель была разработана Мартином Фаулером и Джеймсом Льюисом, хотя одним из основных её популяризаторов по праву считается небезызвестный Крис Ричардсон. Экскурс в историю закончен, теперь перейдём к сути.
Модель куба масштабирования включает три типа масштабирования: по осям X, Y и Z.
Запускается несколько одинаковых экземпляров приложения за балансировщиком нагрузки. Недостатки: увеличенное потребление памяти и отсутствие решения проблем, обусловленных сложностью приложения.
Приложение делится на отдельные независимые сервисы, каждый из которых отвечает за свою область функциональности. Возможны разные подходы к декомпозиции: на основе действий ("глаголы") или объектов ("существительные"). Недостатки: сложность управления множеством сервисов и рост зависимости от сетевой инфраструктуры.
Каждому серверу выделяется своя часть данных (разделение может выполняться по географическому признаку, по идентификационным номерам клиентов и т.д.), запросы автоматически направляются на нужный сервер. Недостатком является сложность реализации маршрутизации и потенциальная неравномерность распределения нагрузки.
Более подробно про плюсы и минусы каждого подхода можно прочитать в статье К. Ричардсона, доступной по ссылке.
#архитектура #интеграции #сервисы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
🚀 Северная столица: про людей и будущее
Несколько часов назад вернулся со стратегической сессии кластера, проходившей в Санкт-Петербурге.
Для тех, кто не знает, это такое мероприятие, на которое съезжаются участники кластера (группы смежных команд разработки, объединëнных вокруг большой общей бизнес-цели) со всей страны, чтобы синхронизироваться по планам, провести ретроспективу, поштормить и, конечно, вживую увидеть друг друга.
В качестве площадки был выбран Технохаб Сбера, расположенный в реконструтированном комплексе заводских зданий на Васильевском острове, что добавляло колорит: снаружи красивая кирипичная кладка, внутри — современное рабочее пространство с нотками космоса.
Программа была насыщенной, притом я тоже внёс свою лепту в её насыщение, выступив перед всеми со специально подготовленным докладом на тему построения архитектуры AI-агентов 🦾. В своём выступлении рассказал об используемой платформе для разработки агентов, генезисе используемого техстека, текущем проекте и дальнейших шагах.
👉 Что стоит сказать. Встреча прошла плодотворно. А помимо изначально запланированного доклада мне довелось выступить ещё дважды, но уже с целью презентации нашей суперкоманды (команда, действительно, особенная, я говорю это искренне!) и дизрапт-идеи, которая "созрела" в ходе работы на сессии.
Если к сказанному ещё добавить ежедневно преодолеваемые километры питерских улиц, душевные посиделки с коллегами и перманентный недосып, то примерно сложится картина этих нескольких потрясающих дней. Было🤘
#выступления #события #сбер #ai
Несколько часов назад вернулся со стратегической сессии кластера, проходившей в Санкт-Петербурге.
Для тех, кто не знает, это такое мероприятие, на которое съезжаются участники кластера (группы смежных команд разработки, объединëнных вокруг большой общей бизнес-цели) со всей страны, чтобы синхронизироваться по планам, провести ретроспективу, поштормить и, конечно, вживую увидеть друг друга.
В качестве площадки был выбран Технохаб Сбера, расположенный в реконструтированном комплексе заводских зданий на Васильевском острове, что добавляло колорит: снаружи красивая кирипичная кладка, внутри — современное рабочее пространство с нотками космоса.
Программа была насыщенной, притом я тоже внёс свою лепту в её насыщение, выступив перед всеми со специально подготовленным докладом на тему построения архитектуры AI-агентов 🦾. В своём выступлении рассказал об используемой платформе для разработки агентов, генезисе используемого техстека, текущем проекте и дальнейших шагах.
👉 Что стоит сказать. Встреча прошла плодотворно. А помимо изначально запланированного доклада мне довелось выступить ещё дважды, но уже с целью презентации нашей суперкоманды (команда, действительно, особенная, я говорю это искренне!) и дизрапт-идеи, которая "созрела" в ходе работы на сессии.
Если к сказанному ещё добавить ежедневно преодолеваемые километры питерских улиц, душевные посиделки с коллегами и перманентный недосып, то примерно сложится картина этих нескольких потрясающих дней. Было🤘
#выступления #события #сбер #ai
🔥4👍2
📖 "Agentic Design Patterns: Практическое руководство по созданию интеллектуальных систем" Антонио Гулли
Сегодня хочу поделиться появившемся переводом на русский язык книги А. Гулли, эксперта в области AI и ML.
🌟 Содержание. Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems — это фундаментальное руководство по проектированию и разработке агентных AI-систем. Книга представляет собой практическое пособие для разработчиков, архитекторов и исследователей, работающих в области искусственного интеллекта.
☝Особенность. Книга переведена отечественным энтузиастом, а результат в электронном виде размещён на гитхабе. Ссылка: 🔗.
🧠 Ремарка. Тема разработки систем на базе ИИ сейчас крайне актуальная, кто-то может даже сказать — хайповая. Поэтому, получив несколько лестных отзывов об этой книге от коллег, решил не ждать, пока прочитаю её сам, и сразу поделиться с вами.
#книги #ai
Сегодня хочу поделиться появившемся переводом на русский язык книги А. Гулли, эксперта в области AI и ML.
🌟 Содержание. Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems — это фундаментальное руководство по проектированию и разработке агентных AI-систем. Книга представляет собой практическое пособие для разработчиков, архитекторов и исследователей, работающих в области искусственного интеллекта.
☝Особенность. Книга переведена отечественным энтузиастом, а результат в электронном виде размещён на гитхабе. Ссылка: 🔗.
🧠 Ремарка. Тема разработки систем на базе ИИ сейчас крайне актуальная, кто-то может даже сказать — хайповая. Поэтому, получив несколько лестных отзывов об этой книге от коллег, решил не ждать, пока прочитаю её сам, и сразу поделиться с вами.
#книги #ai
🔥4
Друзья, поздравляю всех с Днём системного аналитика! 🎂
Желаю, чтобы у вас полными были не только требования, но и банковские счета. Чтобы баги обходили стороной код вашей команды, а дедлайны становились такими же мягкими, как уютный диван после тяжёлого трудового дня.
Пусть каждый день приносит радость первооткрывателя. И пусть ваша зарплата растёт быстрее, чем список изменений в пожеланиях заказчиков!
Желаю, чтобы у вас полными были не только требования, но и банковские счета. Чтобы баги обходили стороной код вашей команды, а дедлайны становились такими же мягкими, как уютный диван после тяжёлого трудового дня.
Пусть каждый день приносит радость первооткрывателя. И пусть ваша зарплата растёт быстрее, чем список изменений в пожеланиях заказчиков!
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾6🔥1
🔥 Залипательная Kafka
Читали про Apache Kafka, но в голове всё равно трудно представить, как она работает? Не беда! В открытом доступе есть средство для визуального моделирования работы с этим брокером. https://softwaremill.com/kafka-visualisation/
Пройдя по этой ссылке, вы можете самостоятельно крутить-вертеть параметры, как душе угодно. Однако, если вы пока слабо представляете себе работу с Кафка, то могу рекомендовать воспользоваться следующим алгоритмом.
👇
0️⃣ Стоит начать с выставления самого медленного режима анимации – это 5s.
1️⃣ Далее выставляем число партиций – 1шт, число брокеров – 1шт, фактор репликации – 1 (то есть без репликации). Для начала пусть будет 1 продюсер и 1 консьюмер. Запускаем и следим за анимацией: это самая простая ситуация, при которой сообщение перекладывается через Кафку в единственного консьюмера.
2️⃣ Добавляем второго консьюмера, указав ту же консьюмер-группу "A", что и у первого. Будет видно, что новый консьюмер (потребитель) ничего не потребляет. Вывод: число потребителей не должно превосходить число партиций Кафки.
3️⃣ Далее стоит привязать второго консьюмера к новой группе "B". Станет видно, что теперь оба консьюмера стали независимо потреблять сообщения из единственной партиции. Таким образом у нас имеется 2 независимых потребителя данных.
4️⃣ После этого выставляем число партиций в значение 2 и перепривязать второго консьюмера снова к той же консьюмер-группе "A". Будет видно, что при равенстве числа партиций и консьюмеров, состоящих в одной консьюмер-группе, каждый консьюмер вычитывает сообщения строго из одного топика.
5️⃣ Добавляем третью партицию и видим, что эта патриция теперь вычитывается первым консьюмером. Причина: каждая добавляемая партиция распределяется между имеющимися потребителями.
6️⃣ Теперь стоит сделать небольшую диверсию, удалив второго консьюмера. После этого все партиции переназначаются на оставшегося единственного потребителя.
7️⃣ Если установить число партиций в значение 2 и число брокеров – тоже в 2, то будет видно, как независимо работают 2 брокера Kafka, а их сообщения потребляются единственным "выжившим" консьюмером.
8️⃣ Но, поскольку брокеры должны быть надёжными, то выставим фактор репликации в значение 2. После этого будет видно, что у каждого брокера стало по 2 партиции: ярким цветом показана партиция-лидер, блёклым – партиция с репликами сообщений от другого брокера.
9️⃣ Если после этого нажать синюю кнопку питания у брокера 1, то он "потухнет". После этого брокер 2 возьмёт на себя хранение всех сообщений продюсера.
🔟 Если снова нажать кнопку питания у брокера 1, то брокер вернётся в строй и довольно быстро будет навёрстано отставание от брокера 2. Брокер 1 продолжит работу.
🔢 Далее можно продолжать экспериментировать, играя всеми доступными параметрами и рассматривая получающиеся при этом результаты.
☝ Меняя параметры, не забывайте нажимать на кнопку "Apply Setup", чтобы применить все изменения. А если захотите провести эксперимент с выставленными параметрами с чистого листа, то просто нажмите в правом верхнем углу кнопку "Restart".
Удачных экспериментов!
#интеграции #брокеры #анимация
Читали про Apache Kafka, но в голове всё равно трудно представить, как она работает? Не беда! В открытом доступе есть средство для визуального моделирования работы с этим брокером. https://softwaremill.com/kafka-visualisation/
Пройдя по этой ссылке, вы можете самостоятельно крутить-вертеть параметры, как душе угодно. Однако, если вы пока слабо представляете себе работу с Кафка, то могу рекомендовать воспользоваться следующим алгоритмом.
👇
0️⃣ Стоит начать с выставления самого медленного режима анимации – это 5s.
1️⃣ Далее выставляем число партиций – 1шт, число брокеров – 1шт, фактор репликации – 1 (то есть без репликации). Для начала пусть будет 1 продюсер и 1 консьюмер. Запускаем и следим за анимацией: это самая простая ситуация, при которой сообщение перекладывается через Кафку в единственного консьюмера.
2️⃣ Добавляем второго консьюмера, указав ту же консьюмер-группу "A", что и у первого. Будет видно, что новый консьюмер (потребитель) ничего не потребляет. Вывод: число потребителей не должно превосходить число партиций Кафки.
3️⃣ Далее стоит привязать второго консьюмера к новой группе "B". Станет видно, что теперь оба консьюмера стали независимо потреблять сообщения из единственной партиции. Таким образом у нас имеется 2 независимых потребителя данных.
4️⃣ После этого выставляем число партиций в значение 2 и перепривязать второго консьюмера снова к той же консьюмер-группе "A". Будет видно, что при равенстве числа партиций и консьюмеров, состоящих в одной консьюмер-группе, каждый консьюмер вычитывает сообщения строго из одного топика.
5️⃣ Добавляем третью партицию и видим, что эта патриция теперь вычитывается первым консьюмером. Причина: каждая добавляемая партиция распределяется между имеющимися потребителями.
6️⃣ Теперь стоит сделать небольшую диверсию, удалив второго консьюмера. После этого все партиции переназначаются на оставшегося единственного потребителя.
7️⃣ Если установить число партиций в значение 2 и число брокеров – тоже в 2, то будет видно, как независимо работают 2 брокера Kafka, а их сообщения потребляются единственным "выжившим" консьюмером.
8️⃣ Но, поскольку брокеры должны быть надёжными, то выставим фактор репликации в значение 2. После этого будет видно, что у каждого брокера стало по 2 партиции: ярким цветом показана партиция-лидер, блёклым – партиция с репликами сообщений от другого брокера.
9️⃣ Если после этого нажать синюю кнопку питания у брокера 1, то он "потухнет". После этого брокер 2 возьмёт на себя хранение всех сообщений продюсера.
🔟 Если снова нажать кнопку питания у брокера 1, то брокер вернётся в строй и довольно быстро будет навёрстано отставание от брокера 2. Брокер 1 продолжит работу.
🔢 Далее можно продолжать экспериментировать, играя всеми доступными параметрами и рассматривая получающиеся при этом результаты.
☝ Меняя параметры, не забывайте нажимать на кнопку "Apply Setup", чтобы применить все изменения. А если захотите провести эксперимент с выставленными параметрами с чистого листа, то просто нажмите в правом верхнем углу кнопку "Restart".
Удачных экспериментов!
#интеграции #брокеры #анимация
🔥2🙏1
📖 "Пятая дисциплина. Искусство и практика обучающейся организации" Питера Сенге
В этот раз хочу поделиться впечатлением о другой классической работе.
💡 Содержание. Книга посвящена концепции организации как "обучающейся системы". Автор утверждает, что успешная компания должна стать организацией, способной постоянно учиться и адаптироваться к изменениям. Сенге выделяет пять ключевых дисциплин, формирующих такую систему:
1. Системное мышление — умение видеть взаимосвязи между элементами и понимать динамику сложных ситуаций.
2. Личная мастерская — развитие личностных качеств сотрудников для повышения эффективности.
3. Интеллектуальные модели — осознание и изменение ментальных моделей, влияющих на поведение и принятие решений.
4. Общее видение — создание общей цели и миссии, объединяющих коллектив.
5. Командное обучение — формирование командного духа и способности решать проблемы совместно.
🔍 Что внутри. Могу порекомендовать ознакомиться с "Пивной игрой" из главы 3. Она довольно любопытна, даже если не играть в неё, а проследить динамику и её результаты, глядя на это со стороны — со стороны читателя книги. Помимо этого в книге есть и другие интересные моменты. Вот, например, такая мысль (процитирую):
На страницах книги читатели также узнают, что:
🍬 увеличение продолжительности рабочего дня для решения срочных задач быстро становится неэффективным.
🍬 когда самые опытные специалисты вынуждены тратить часть своего времени на решение управленческих вопросов, процессы разработки замедляются.
🍬 по мере расширения компании возможности для карьерного и профессионального роста сужаются, а взаимное недовольство и напряжённость — возрастают.
Поскольку большинство из нас является наёмными работниками, то примеры будут полезным и нам.
🍯 Ложка дёгтя. Начиная с 3 главы материал становится сложнее. Плюс довольно часто автор для убеждения в верности своей философии начинает приводить цитаты других людей и накладывать на них свои мысли. Как итог, растекается по древу, что существенно усложняет восприятие и так непростой книги. Я точно не смог вникнуть во многие содержащиеся в ней смыслы.
💡 Выводы. Эту книгу есть смысл читать после "Искусства системного мышления", чтобы, с одной стороны, повторить ряд концепций, и, с другой стороны, чтобы материал дался легче.
Второй момент: "Пятая дисциплина" адресована в большей степени управленцам, притом не менеджерам проекта или продукта, а скорее руководителям верхнего уровня. Наверное, стартаперам тоже подойдёт, хотя Сенге в явном виде их не упоминает.
В то же время для системных аналитиков книга может быть полезна в части философского взгляда на работу в команде, но этот философский характер временами постичь будет непросто. Как следствие, рекомендовать этот труд для прочтения сложно (стоит хорошенько подумать☝🏻). Но, если и читать, то только вдумчиво и на свежую голову.
😱 Забавный факт. Если послушать произношение фамилии автора книги, то окажется, что он Сэ́нджи.
#книги #системныйподход #менеджмент
В этот раз хочу поделиться впечатлением о другой классической работе.
💡 Содержание. Книга посвящена концепции организации как "обучающейся системы". Автор утверждает, что успешная компания должна стать организацией, способной постоянно учиться и адаптироваться к изменениям. Сенге выделяет пять ключевых дисциплин, формирующих такую систему:
1. Системное мышление — умение видеть взаимосвязи между элементами и понимать динамику сложных ситуаций.
2. Личная мастерская — развитие личностных качеств сотрудников для повышения эффективности.
3. Интеллектуальные модели — осознание и изменение ментальных моделей, влияющих на поведение и принятие решений.
4. Общее видение — создание общей цели и миссии, объединяющих коллектив.
5. Командное обучение — формирование командного духа и способности решать проблемы совместно.
🔍 Что внутри. Могу порекомендовать ознакомиться с "Пивной игрой" из главы 3. Она довольно любопытна, даже если не играть в неё, а проследить динамику и её результаты, глядя на это со стороны — со стороны читателя книги. Помимо этого в книге есть и другие интересные моменты. Вот, например, такая мысль (процитирую):
Например, менеджеры под давлением финансовых проблем часто идут на сокращение персонала ради снижения расходов, но в конце концов обнаруживают, что оставшиеся работники перегружены и что расходы сократить не удалось, поскольку приходится либо привлекать консультантов, либо платить сверхурочные. Сокращение расходов оказывается временным, потому что у системы есть собственные цели. Эти неявные, не сформулированные цели очень реальны. В данном случае такая цель — считающаяся приемлемой рабочая нагрузка.В главе 5, рассматривая эффект задержки на примере регулирования температуры воды, автор приходит к заключению, как будто написанному для всё той же пивной игры (да, системы имеют общие черты):
Это важный урок: если система обратной связи работает с задержкой, то чрезмерно энергичные действия дают эффект, обратный ожидаемому. Вместо того чтобы быстро достичь цели, вы получаете нестабильность и колебания.
На страницах книги читатели также узнают, что:
🍬 увеличение продолжительности рабочего дня для решения срочных задач быстро становится неэффективным.
🍬 когда самые опытные специалисты вынуждены тратить часть своего времени на решение управленческих вопросов, процессы разработки замедляются.
🍬 по мере расширения компании возможности для карьерного и профессионального роста сужаются, а взаимное недовольство и напряжённость — возрастают.
Поскольку большинство из нас является наёмными работниками, то примеры будут полезным и нам.
🍯 Ложка дёгтя. Начиная с 3 главы материал становится сложнее. Плюс довольно часто автор для убеждения в верности своей философии начинает приводить цитаты других людей и накладывать на них свои мысли. Как итог, растекается по древу, что существенно усложняет восприятие и так непростой книги. Я точно не смог вникнуть во многие содержащиеся в ней смыслы.
💡 Выводы. Эту книгу есть смысл читать после "Искусства системного мышления", чтобы, с одной стороны, повторить ряд концепций, и, с другой стороны, чтобы материал дался легче.
Второй момент: "Пятая дисциплина" адресована в большей степени управленцам, притом не менеджерам проекта или продукта, а скорее руководителям верхнего уровня. Наверное, стартаперам тоже подойдёт, хотя Сенге в явном виде их не упоминает.
В то же время для системных аналитиков книга может быть полезна в части философского взгляда на работу в команде, но этот философский характер временами постичь будет непросто. Как следствие, рекомендовать этот труд для прочтения сложно (стоит хорошенько подумать☝🏻). Но, если и читать, то только вдумчиво и на свежую голову.
😱 Забавный факт. Если послушать произношение фамилии автора книги, то окажется, что он Сэ́нджи.
#книги #системныйподход #менеджмент
🔥2👍1
#codefestru #видео
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1🙏1
Forwarded from CodeFest'16 | 30–31 мая 2026
Ясно? Доклады, полезные для системных аналитиков (и не только!). Смотрите, что бы прокачаться в поиске решений:
✨ Дмитрий Уткин. Пять направлений повышения зрелости архитектуры →
YouTube | RuTube | VK Video
✨ Анастасия Севостьянова. Docs as Code. Когда документация становится частью кода, а не пыткой →
YouTube | RuTube | VK Video
✨ Лев Немировский. Применение архитектурных стилей в проектировании сложных систем →
YouTube | RuTube | VK Video
✨ Любовь Вайгель. Особенности СА в разных предметных областях →
YouTube | RuTube | VK Video
✨ Наталья Новикова, Роман Бушняков. Строительство моста вебсокетов →
YouTube | RuTube | VK Video
✨ Андрей Бураков. Всё есть состояние. CAP в теории и реальности →
YouTube | RuTube | VK Video
✨ Анна Курманова. Не просто курсы: как мы сделали школу аналитиков точкой роста и стратегическим активом →
YouTube | RuTube | VK Video
✨ Александра Клименко. Навыки на вырост: как получать удовольствие от работы сейчас, расти в профессии или менять её без потерь →
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
YouTube | RuTube | VK Video
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
⚡ Друзья, спешу поделиться.
The Association of Information Technology Experts (AITEX) оказала мне честь, пригласив меня принять участие в AITEX Summit Fall 2025: From Intelligence to Impact в качестве судьи.
Участники этого хакатона представят проекты в таких областях, как ИИ во благо, ИИ для бизнеса, креативный ИИ и открытые инновации, а я с радостью оценю их вклад в формирование будущих технологических инноваций.
#достижения #события #судейства #ai
The Association of Information Technology Experts (AITEX) оказала мне честь, пригласив меня принять участие в AITEX Summit Fall 2025: From Intelligence to Impact в качестве судьи.
Участники этого хакатона представят проекты в таких областях, как ИИ во благо, ИИ для бизнеса, креативный ИИ и открытые инновации, а я с радостью оценю их вклад в формирование будущих технологических инноваций.
#достижения #события #судейства #ai
Aitexsummit
AITEX Summit Fall 2025
AITEX Summit Fall 2025: 2-day AI event where developers and IT professionals transform industries, drive innovation, and compete for prizes.
🔥7
🛠 Техдолг... как много в этом звуке...
Представьте себе такую ситуацию. Вы купили новую квартиру в строящемся доме, продав свою старую жилплощадь. Строительство вашего нового жилья близко к завершению, но настаëт срок освобождения старого жилища и передачи ключей новым собственникам.
🤷♂ Возникает парадоксальная ситуация: новая квартира ещё непригодна для проживания, а старую в скором времени придётся освобождать. Вам предстоит срочно договариваться с застройщиком, чтобы получать доступ к объекту, далее пригласить бригаду рабочих для ремонта и наконец-то переехать. Однако дефицит времени вынуждает вас принять решение: отдельные этапы работ придётся отложить до лучших времён. Конечно, ваша цель — сделать всё качественно, но временные рамки неумолимы.
💻 Такая же картина наблюдается и в процессе разработки программного обеспечения. Мы называем это техническим долгом. Так что же это?
Техдолг — это совокупность компромиссных решений, принятых командой разработки, как правило, в условиях жёстких сроков сдачи проекта. Иногда приходится отказываться от детальной проработки архитектурных элементов, глубокого анализа граничных условий или полноценного покрытия функционала тестами. Всё это делается вынужденно, исходя из ограничений времени и ресурсов.
❌ Негативные последствия накапливаемого технического долга очевидны. Если игнорировать их существование, решение рискует превратиться в нечто нестабильное и хрупкое; в решение, которое сложно поддерживать и развивать дальше. И рано или поздно команде потребуется вернуться к старым проблемам, чтобы довести всё до ума.
💡 Однако есть аспект в контексте этого вопроса, который редко принимается во внимание. Даже если релиз успешно проходит все предусмотренные вашим релизным процессом проверки и отправляется в продакшн, оставшийся технический долг становится моральным бременем для самой команды.
Члены команды понимают, что существуют недоработанные участки, в которых могли затаиться потенциальные риски и неудобства. От этого понимания ответственные специалисты испытывают чувство дискомфорта и внутреннего недовольства качеством проделанной работы, ведь они хотят гордиться результатом своего труда, а не оставлять за собой хвост нерешённых проблем.
💎 Да, так или иначе все мы работаем ради денег, но удовлетворённость и гордость за труд — это то, что нельзя недооценивать. Качество продукта и эмоциональная составляющая его создателей всегда идут рука об руку. Это факт.
Представьте себе такую ситуацию. Вы купили новую квартиру в строящемся доме, продав свою старую жилплощадь. Строительство вашего нового жилья близко к завершению, но настаëт срок освобождения старого жилища и передачи ключей новым собственникам.
🤷♂ Возникает парадоксальная ситуация: новая квартира ещё непригодна для проживания, а старую в скором времени придётся освобождать. Вам предстоит срочно договариваться с застройщиком, чтобы получать доступ к объекту, далее пригласить бригаду рабочих для ремонта и наконец-то переехать. Однако дефицит времени вынуждает вас принять решение: отдельные этапы работ придётся отложить до лучших времён. Конечно, ваша цель — сделать всё качественно, но временные рамки неумолимы.
Техдолг — это совокупность компромиссных решений, принятых командой разработки, как правило, в условиях жёстких сроков сдачи проекта. Иногда приходится отказываться от детальной проработки архитектурных элементов, глубокого анализа граничных условий или полноценного покрытия функционала тестами. Всё это делается вынужденно, исходя из ограничений времени и ресурсов.
Члены команды понимают, что существуют недоработанные участки, в которых могли затаиться потенциальные риски и неудобства. От этого понимания ответственные специалисты испытывают чувство дискомфорта и внутреннего недовольства качеством проделанной работы, ведь они хотят гордиться результатом своего труда, а не оставлять за собой хвост нерешённых проблем.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🙏2