Прекрасное про стили организации работы и времени.
- У вас есть планы на 5, 10 лет? Кем вы видите себя через это время?
- Идите нафиг со своим планированием. Оно мне всю радость жизни портит.
Авторы противопоставляют рациональное и иррациональное отношение к работе и планированию времени, по аналогии с совами и жаворонками. Мне не очень нравится формулировка вида иррационал-рационал, но главную мысль статья передает: не все могут эффективно жить-работать в условиях строгого планирования, жесткого тайм-менеджмента, формализованных процессов и т.п.
И это нормально, Карл!
Нужно сделать лишь одну вещь:
1. Представителям порядка принять, что люди разные, устроены они по-разному, и использовать их нужно по-разному.
2. Представителям хаоса принять свою природу, и перестать себя мучать успехосоветами и магиями утра, максимально делегировать рутину и создать вокруг себя подходящую среду для работы.
Познай себя, “человек-иррационал”.
- У вас есть планы на 5, 10 лет? Кем вы видите себя через это время?
- Идите нафиг со своим планированием. Оно мне всю радость жизни портит.
Авторы противопоставляют рациональное и иррациональное отношение к работе и планированию времени, по аналогии с совами и жаворонками. Мне не очень нравится формулировка вида иррационал-рационал, но главную мысль статья передает: не все могут эффективно жить-работать в условиях строгого планирования, жесткого тайм-менеджмента, формализованных процессов и т.п.
И это нормально, Карл!
Нужно сделать лишь одну вещь:
1. Представителям порядка принять, что люди разные, устроены они по-разному, и использовать их нужно по-разному.
2. Представителям хаоса принять свою природу, и перестать себя мучать успехосоветами и магиями утра, максимально делегировать рутину и создать вокруг себя подходящую среду для работы.
Познай себя, “человек-иррационал”.
Telegraph
Тайм-менеджмент для разгильдяев
- У вас есть планы на 5, 10 лет? Кем вы видите себя через это время? - Идите нафиг со своим планированием. Оно мне всю радость жизни портит. Этот текст посвящен разгильдяям... Тем, чья жизнь меняется постоянно. Тем, кто не может работать монотонно и пошагово.…
🔥13👍10❤4
Я несколько раз писал, что аналитик не может всерьез выбирать технологии интеграции, в том числе из-за нехватки знаний о сетях.
Поэтому держите небольшую шпаргалку-введение в работу и устройство сетей. Если интересно занырнуть глубже HTTP, но не готовы к Таненбауму.
Еще у подолдки интересные подкасты были:
https://podlodka.io/239 - часть 1, про интернет
https://podlodka.io/249 - часть 2, больше про железо
Поэтому держите небольшую шпаргалку-введение в работу и устройство сетей. Если интересно занырнуть глубже HTTP, но не готовы к Таненбауму.
Еще у подолдки интересные подкасты были:
https://podlodka.io/239 - часть 1, про интернет
https://podlodka.io/249 - часть 2, больше про железо
linkmeup.gitbook.io
Сети для самых маленьких | Сети Для Самых Маленьких
👍35🔥20❤5
#манагерское
О вечном противостоянии «бизнеса» и «техники»
За счет того, что в каждом из отделов совершенно разная культура, люди начинают самоидентифицироваться не как сотрудники всей компании, а как сотрудники «последнего оплота „нормальности”» в компании — в то время как «эти раздолбаи из соседнего отдела» неделями двигают свои маленькие задачки / вкидывают в бэклог какой-то непоследовательный бред (ненужное зачеркнуть)
О вечном противостоянии «бизнеса» и «техники»
За счет того, что в каждом из отделов совершенно разная культура, люди начинают самоидентифицироваться не как сотрудники всей компании, а как сотрудники «последнего оплота „нормальности”» в компании — в то время как «эти раздолбаи из соседнего отдела» неделями двигают свои маленькие задачки / вкидывают в бэклог какой-то непоследовательный бред (ненужное зачеркнуть)
Блог ProductSense
Мотивация команды с точки зрения базовых потребностей (взгляд с необычного ракурса на OKR и KPI)
Нередко конфликты возникают не из-за локальных проблем в коммуникациях или ошибок конкретного сотрудника, а из-за серьезных культурных различный или различий в мотивации на уровне команд. Как возни…
🔥7👍5❤2
#архитектура
Заметка о моделях консистентности и способах ее обеспечения. Для быстрого знакомства.
https://systemdesign.one/consistency-patterns/
Заметка о моделях консистентности и способах ее обеспечения. Для быстрого знакомства.
https://systemdesign.one/consistency-patterns/
System Design
Consistency Patterns
popular consistency models in distributed systems
👍10
#архитектура
System Design. Основы проектирования высоконагруженных систем
Два года назад мы попробовали запустить большой курс по архитектуре, но звезды оказались против. В этот раз решили двигаться мелкими шагами и подготовили двухдневный тренинг по проектированию системной архитектуры или System Design, как это модно сейчас называть.
Пилот прошел отлично, поэтому приглашаем через неделю на открытый тренинг спроектировать вместе систему бронирования.
Как это будет:
⁃ Делимся на три команды, каждая из которых проектирует свой микросеврис
⁃ Определяем требования к системе и ключевые метрики
⁃ Проектируем API, модель данных, выбираем тип хранилища, способы масштабирования, инфраструктурные элементы
⁃ Интегрируем сервисы команд, чтобы получить цельную систему
Соотношение теории и практики примерно 50/50.
Даша Колесова в роли автора и ведущего вызывает особый восторг - еще не видел, чтобы так органично получалось связать все шаги проектирования от продуктовых метрик до выбора конкретных технических паттернов.
Кого ждем:
⁃ Опытных системных аналитиков
⁃ Разработчкиов
⁃ Технических менеджеров
📆 Встречаемся 3 и 4 февраля в 10:00 - 14:00 мск
🔗 Регаемся тут
System Design. Основы проектирования высоконагруженных систем
Два года назад мы попробовали запустить большой курс по архитектуре, но звезды оказались против. В этот раз решили двигаться мелкими шагами и подготовили двухдневный тренинг по проектированию системной архитектуры или System Design, как это модно сейчас называть.
Пилот прошел отлично, поэтому приглашаем через неделю на открытый тренинг спроектировать вместе систему бронирования.
Как это будет:
⁃ Делимся на три команды, каждая из которых проектирует свой микросеврис
⁃ Определяем требования к системе и ключевые метрики
⁃ Проектируем API, модель данных, выбираем тип хранилища, способы масштабирования, инфраструктурные элементы
⁃ Интегрируем сервисы команд, чтобы получить цельную систему
Соотношение теории и практики примерно 50/50.
Даша Колесова в роли автора и ведущего вызывает особый восторг - еще не видел, чтобы так органично получалось связать все шаги проектирования от продуктовых метрик до выбора конкретных технических паттернов.
Кого ждем:
⁃ Опытных системных аналитиков
⁃ Разработчкиов
⁃ Технических менеджеров
📆 Встречаемся 3 и 4 февраля в 10:00 - 14:00 мск
🔗 Регаемся тут
nextway.pro
System Design. Основы проектирования архитектуры систем
Ключевые принципы построения систем для системных аналитиков и разработчиков
👍14🔥6
Don't worry about what is or isn't REST; focus on building pragmatic, useful APIs.
Статья о практических нюансах проектирования REST-like API. Есть моменты, где можно похоливарить, но всяко лучше чем очередная дискуссия “Как правильно делать REST API”.
Например, почему:
• не стоит везде использовать вложенные ресурсы
• не стоит использовать map-структуры
• не стоит возвращать 404, если ресурс не найден - интересный кейс внутри, посмотрите обязательно
• id лучше дополнять префиксом-указателем на тип сущности и представлять в виде стрингов
#API
Статья о практических нюансах проектирования REST-like API. Есть моменты, где можно похоливарить, но всяко лучше чем очередная дискуссия “Как правильно делать REST API”.
Например, почему:
• не стоит везде использовать вложенные ресурсы
• не стоит использовать map-структуры
• не стоит возвращать 404, если ресурс не найден - интересный кейс внутри, посмотрите обязательно
• id лучше дополнять префиксом-указателем на тип сущности и представлять в виде стрингов
#API
GitHub
How to (and how not to) design REST APIs
Jeff Schnitzer's Blog. Contribute to stickfigure/blog development by creating an account on GitHub.
🔥14👍6❤2🤝1
Архитектурная подборка для тех, кто еще умеет читать книги.
Внутри не только классические труды о проектировании систем, но и о построении коммуникаций, организации работы со стейкхолдерами, оценке качества архитектуры, способах принятия решений.
#архитектура
Внутри не только классические труды о проектировании систем, но и о построении коммуникаций, организации работы со стейкхолдерами, оценке качества архитектуры, способах принятия решений.
#архитектура
❤31🔥6🥰3👍1😱1
Архитектурная зарисовка на тему проектирования процесса обработки платежей для абстрактного цифрового сервиса. Нужен VPN
#архитектура
#архитектура
Medium
Processing Payments in a Distributed System
Explained through a real-world example
Верните анализ в аналитиков
На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят.
Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.
Когда заходит речь о том, что же нужно пользователю, в каких процессах участвует система, какие из функций критичны для бизнеса и как посчитать пиковую нагрузку - пусть бизнес-аналитики с продуктами разбираются, у нас лапки архитектура.
Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.
Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4
2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.
3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.
4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.
Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Сомнительно.
На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят.
Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.
Когда заходит речь о том, что же нужно пользователю, в каких процессах участвует система, какие из функций критичны для бизнеса и как посчитать пиковую нагрузку - пусть бизнес-аналитики с продуктами разбираются, у нас лапки архитектура.
Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.
Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4
2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.
3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.
4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.
Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Сомнительно.
🔥94👍5🤔2
#конфа
Flow. Spring 2024
Во вторник провел на воркшоп о влиянии НФТ на выбор технологий интеграции. Судя по отзывам участников, получилось хорошо, но совсем не так, как планировал.
Дополнительные материалы, которые обещал
Модель зрелости REST-сервисов https://martinfowler.com/articles/richardsonMaturityModel.html
Спецификация JSON-RPC 2.0 https://www.jsonrpc.org
Инструмент для документирования JSON-RPC https://news.1rj.ru/str/another_sa/78
Краткий обзор GraphQL с хорошими ссылками: https://habr.com/ru/post/326986/
Стрим об особенностях использования GraphQL: https://youtu.be/gfSYKLo0P5E?si=4OluWLZVg61ACAA1
Просто о Websockets: https://mcs.mail.ru/blog/websocket-kogda-sleduet-ispolzovat-i-preimushhestva
Сравнение WebSockets и gRPC: https://dev.by/blogs/godel-technologies-europe/articles/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket
Большая база материалов по интеграции систем: https://systems.wiki/integration
Сравнение REST и RPC стилей API
В защиту REST: https://habr.com/ru/post/476576
В защиту JSON-RPC: https://habr.com/en/post/441854
Стрим REST vs RPC https://youtu.be/JS96oEB4bWc?si=6TaOXjq1K96r3P-z
Flow. Spring 2024
Во вторник провел на воркшоп о влиянии НФТ на выбор технологий интеграции. Судя по отзывам участников, получилось хорошо, но совсем не так, как планировал.
Дополнительные материалы, которые обещал
Модель зрелости REST-сервисов https://martinfowler.com/articles/richardsonMaturityModel.html
Спецификация JSON-RPC 2.0 https://www.jsonrpc.org
Инструмент для документирования JSON-RPC https://news.1rj.ru/str/another_sa/78
Краткий обзор GraphQL с хорошими ссылками: https://habr.com/ru/post/326986/
Стрим об особенностях использования GraphQL: https://youtu.be/gfSYKLo0P5E?si=4OluWLZVg61ACAA1
Просто о Websockets: https://mcs.mail.ru/blog/websocket-kogda-sleduet-ispolzovat-i-preimushhestva
Сравнение WebSockets и gRPC: https://dev.by/blogs/godel-technologies-europe/articles/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket
Большая база материалов по интеграции систем: https://systems.wiki/integration
Сравнение REST и RPC стилей API
В защиту REST: https://habr.com/ru/post/476576
В защиту JSON-RPC: https://habr.com/en/post/441854
Стрим REST vs RPC https://youtu.be/JS96oEB4bWc?si=6TaOXjq1K96r3P-z
🔥27👍12❤2
Идея поиска работы
За последнее время прилетало несколько запросов на консультацию по продвижению в карьере. Обычно речь идет про переходы миддл - сениор, сениор - тимлид, сениор - архитектор. Чаще проблема заключается в заниженной самооценке и умении продать себя.
Вспомнил, как несколько лет назад искал мидлов в компанию, и мне написало в личку два кандидата в формате: “Я не прохожу под все требования, но есть такой-то опыт, давай попробуем поговорить”. Поговорить согласился, просто потому что не засцали написать.
В итоге наняли обоих, и успешно работали несколько лет.
К чему это? Мне регулярно пишут с предложениями разместить рекламу в канале, иногда сами покупаем рекламу курсов. Пост в каналах на 3-5к подписчиков может стоить около 5.000р. На 10-15к подписчиков около 10.000р.
Что мешает сделать классное резюме, подготовить короткий яркий пост с самопрезентаций и опубликовать в канале для аналитиков? Сходу могу вспомнить четыре таких канала, где сидит по 7-10к подписчиков. Причем среди них лиды и нанимающие менеджеры. Даже если таких 1% получим аудиторию в 70-150 лидов, к которым мы обратимся напрямую без HR и SMS. Если на них конверсия будет в 10%, то имеем 7-15 контактов для дальнейшего диалога.
Выглядит неплохо. Правда, это больше для специалистов middle и выше, которые уже могут рассказать про какие-то результаты. И главное - не сцать.
Если интересно попробовать - маякните в комментах, готов помочь с авантюрой.
За последнее время прилетало несколько запросов на консультацию по продвижению в карьере. Обычно речь идет про переходы миддл - сениор, сениор - тимлид, сениор - архитектор. Чаще проблема заключается в заниженной самооценке и умении продать себя.
Вспомнил, как несколько лет назад искал мидлов в компанию, и мне написало в личку два кандидата в формате: “Я не прохожу под все требования, но есть такой-то опыт, давай попробуем поговорить”. Поговорить согласился, просто потому что не засцали написать.
В итоге наняли обоих, и успешно работали несколько лет.
К чему это? Мне регулярно пишут с предложениями разместить рекламу в канале, иногда сами покупаем рекламу курсов. Пост в каналах на 3-5к подписчиков может стоить около 5.000р. На 10-15к подписчиков около 10.000р.
Что мешает сделать классное резюме, подготовить короткий яркий пост с самопрезентаций и опубликовать в канале для аналитиков? Сходу могу вспомнить четыре таких канала, где сидит по 7-10к подписчиков. Причем среди них лиды и нанимающие менеджеры. Даже если таких 1% получим аудиторию в 70-150 лидов, к которым мы обратимся напрямую без HR и SMS. Если на них конверсия будет в 10%, то имеем 7-15 контактов для дальнейшего диалога.
Выглядит неплохо. Правда, это больше для специалистов middle и выше, которые уже могут рассказать про какие-то результаты. И главное - не сцать.
Если интересно попробовать - маякните в комментах, готов помочь с авантюрой.
👍26🔥9😁4❤2
Forwarded from Chief Philosophy Officer
Этапы взросления менеджера:
- Не догадывается, что существует чат без него, но где есть все его подчиненные.
- Расстраивается, что существует чат без него, но где есть все его подчиненные.
- Радуется, что наконец создали чат без него, но где есть все его подчиненные.
- Делаем вид, что не заметил, когда добавили в очередной новый чат.
- Не догадывается, что существует чат без него, но где есть все его подчиненные.
- Расстраивается, что существует чат без него, но где есть все его подчиненные.
- Радуется, что наконец создали чат без него, но где есть все его подчиненные.
- Делаем вид, что не заметил, когда добавили в очередной новый чат.
😁67🐳4👎3🤮3❤1💩1
Чек-лист - отличная штука. Если сделал его сам
Когда обсуждают выбор типа хранилищ, брокеров, способа интеграции регулярно слышу вопрос: “А что лучше использовать для XXX?”
Рассказываешь об особенностях технологии, сильных и слабых сторонах, известных кейсах применения… а в ответ: “Нет, ты пальцем покажи: здесь нужно использовать FOO, а здесь BAR”. После короткого диалога собеседник просит какой-нибудь чек-лист, таблицу с критериями принятия решений или что-то подобное.
🤦♂️ Если вы узнали себя, то у меня плохие новости.
◽️ Во-первых, инет завален всевозможными чек-листами и сравнениями на любую тему. Пора научиться гуглить нужную информацию, в том числе с помощью ChatGPT и ей подобных. Неумение добывать инфу можно относить к одному из смертных грехов.
◽️ Во-вторых, большая часть подобных материалов поверхностна, создана не на основе опыта автора, а является выжимкой из аналогичных источников.
◽️ В-третьих, глубокие материалы с серьезным анализом могут оказаться как бесполезны, так и вредны для вас.
Но почему?
При проектировании системы хороший инженер фокусируется на тех ограничениях и контексте, которые важны для его задачи. Основываясь на них, он составляет список значимых критериев и уже по ним выбирает подходящие технологии. Со временем, он может сформировать чек-лист, в котором соберет критерии и условия их применимости.
Однажды он оформит его в статью и выложит в сеть.
Есть проблема - это критерии, которые имели значение в его задачах. Нет никакой гарантии, что все критерии значимы для вас. Нет никакой гарантии, что все значимые для вас критерии есть в списке. Нет даже гарантии, что сам автор не разочаруется в своем подходе через пару лет.
Тогда что делать?
1️⃣ Погружаться в контекст вашей задачи. В большинстве случаев он шире зоны ответственности аналитика или разработчика. Например, я писал о проблемах выбора способа интеграции
2️⃣ Изучать технологии по первоисточникам, а не обзорным статьям. Благо, сейчас проблем с оригинальной документацией нет
3️⃣ Самостоятельно выявлять значимые критерии принятия решений и валидировать их с командой
Последний пункт самый важный. Выявление критериев - серьезная творческая задача, которая требует глубокого понимания контекста и технического кругозора. Выбор технологии на основе списка критериев - элементарная задача для систем принятия решений, которая успешно решалась еще в прошлом веке. А при наличии LLM вообще внимания не стоит.
Мораль проста: занимайтесь творческими задачами, которые пока недоступны моделькам. Всю рутину неизбежно сметут LLM, причем это уже не вопрос возможностей, а внедрения и безопасности.
❗️ Работающий чек-лист - это тот, который вы сделали сами. На все остальное есть GPT.
Когда обсуждают выбор типа хранилищ, брокеров, способа интеграции регулярно слышу вопрос: “А что лучше использовать для XXX?”
Рассказываешь об особенностях технологии, сильных и слабых сторонах, известных кейсах применения… а в ответ: “Нет, ты пальцем покажи: здесь нужно использовать FOO, а здесь BAR”. После короткого диалога собеседник просит какой-нибудь чек-лист, таблицу с критериями принятия решений или что-то подобное.
🤦♂️ Если вы узнали себя, то у меня плохие новости.
Но почему?
При проектировании системы хороший инженер фокусируется на тех ограничениях и контексте, которые важны для его задачи. Основываясь на них, он составляет список значимых критериев и уже по ним выбирает подходящие технологии. Со временем, он может сформировать чек-лист, в котором соберет критерии и условия их применимости.
Однажды он оформит его в статью и выложит в сеть.
Есть проблема - это критерии, которые имели значение в его задачах. Нет никакой гарантии, что все критерии значимы для вас. Нет никакой гарантии, что все значимые для вас критерии есть в списке. Нет даже гарантии, что сам автор не разочаруется в своем подходе через пару лет.
Тогда что делать?
Последний пункт самый важный. Выявление критериев - серьезная творческая задача, которая требует глубокого понимания контекста и технического кругозора. Выбор технологии на основе списка критериев - элементарная задача для систем принятия решений, которая успешно решалась еще в прошлом веке. А при наличии LLM вообще внимания не стоит.
Мораль проста: занимайтесь творческими задачами, которые пока недоступны моделькам. Всю рутину неизбежно сметут LLM, причем это уже не вопрос возможностей, а внедрения и безопасности.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22👍10🤡1
Forwarded from Системный сдвиг
UML умер, но никто этого не заметил?
Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.
Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)
Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.
Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.
Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".
Интересными мне показались два поинта в статье:
1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.
2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.
Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.
В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.
UML каждая команда может использовать внутри себя, если захочет. А может использовать любой другой способ записи идей на салфетках, главное, чтобы работало.
А вы применяете UML? Насколько часто, и что именно из него?
Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.
Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)
Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.
Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.
Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".
Интересными мне показались два поинта в статье:
1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.
2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.
Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.
В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.
UML каждая команда может использовать внутри себя, если захочет. А может использовать любой другой способ записи идей на салфетках, главное, чтобы работало.
А вы применяете UML? Насколько часто, и что именно из него?
🔥26🤔15👎12❤3😁3👍1
Околообразование для аналитиков
Интересно наблюдать за развитием инфобиза в аналитической тусе. Как это было для меня.
2012-2019. Тишь да Вигерс
Из открытого обучения есть базовый курс ШСА и 2-3 коротких тренинга, плюс несколько центров корп обучения при крупных интеграторах. В основном все фокусируются на базовых техниках работы с требованиями: ФТ, НФТ, Use Cases и вот это все.
2020-2021. Интеграция расправляет плечи
Стартуют первые курсы по интеграции систем для аналитиков у ШСА и Com-Practice. Фокус смещается на “технику”, в основном на HTTP-based сервисы и SOAP, народ задорно обсуждает что такое REST, и как его правильно готовить.
2021. Вторжение титанов
На волне роста онлайн-образования в тему SA/BA заходят гиганты эдтеха в духе БрикФактори и им подобных. Многие закидывают их камнями и помидорами, ибо качество вызывает вопросы.
Но важно другое - они массово начали закупать рекламу в тематических тг-каналах. Сходу вспомнил 6 каналов, которые появились тогда чтобы репостить контент и размещать рекламу.
Хозяйке на заметку: сегодня пост в канале на ~10к подписчиков стоит 10-15к рублей. По моим наблюдениям канал может приносить 50-200к в месяц в зависимости от сезона. И не нужно заморачиваться с курсом.
А с открытыми LLM это реально автоматизировать.
2021-2023. Образовательная лихорадка
Не только лишь каждый аналитик запустил свой инди-курс в одном и популярных форматов: от записи на степике, которая приносит небольшую копеечку, до живых когортных курсов с активным маркетингом. Ибо собрать и продать курс стало значительно проще, чем до ковида.
За это время качество локального бутикового (Денис, спасибо за термин, каждый раз ржу) образования сблизилось с большими игроками: брикфактори подтянули качество, а в андергрунде появились курсы по архитектуре от аналитиков с 3-5 летним стажем.
2023-2024. Пост-пост, мета-мета
Курсы плодятся, запускать легко, но нужно продавать - много конкурентов.
Появляются курсы вида “как пройти собеседование на SA”, “как найти работу аналитиком”, “как построить карьеру в IT” и т.п.
Подход мегаразумный - продать техническое обучение куда сложнее, чем продать буст карьеры. Участники тратят меньше времени на обучение, а результат намного понятнее и проще измерять. Тем более брикфактори и другие стабильно поставляют клиентов - специалистов с завышенными ожиданиями.
Есть даже курс по подготовке IT-спикеров. Не знаю, как продается, имхо рынок слишком маленький - по конференциям кочует всего несколько сотен спикеров.
Среди каналов случился первый эксперимент с платной подпиской. Контент классный, но не особо летит. Возможно, народ привык к халявному контенту.
2024 - …
Вангую тренд на мета-скиллы и обучение-без-курсов будет развиваться, а начинающим авторам будет проще запрыгнуть в них, чем в стандартные технические курсы.
P.S. Хронология или причинно-следственные связи в вашей версии реальности могут отличаться, поделитесь же ими.
Интересно наблюдать за развитием инфобиза в аналитической тусе. Как это было для меня.
2012-2019. Тишь да Вигерс
Из открытого обучения есть базовый курс ШСА и 2-3 коротких тренинга, плюс несколько центров корп обучения при крупных интеграторах. В основном все фокусируются на базовых техниках работы с требованиями: ФТ, НФТ, Use Cases и вот это все.
2020-2021. Интеграция расправляет плечи
Стартуют первые курсы по интеграции систем для аналитиков у ШСА и Com-Practice. Фокус смещается на “технику”, в основном на HTTP-based сервисы и SOAP, народ задорно обсуждает что такое REST, и как его правильно готовить.
2021. Вторжение титанов
На волне роста онлайн-образования в тему SA/BA заходят гиганты эдтеха в духе БрикФактори и им подобных. Многие закидывают их камнями и помидорами, ибо качество вызывает вопросы.
Но важно другое - они массово начали закупать рекламу в тематических тг-каналах. Сходу вспомнил 6 каналов, которые появились тогда чтобы репостить контент и размещать рекламу.
Хозяйке на заметку: сегодня пост в канале на ~10к подписчиков стоит 10-15к рублей. По моим наблюдениям канал может приносить 50-200к в месяц в зависимости от сезона. И не нужно заморачиваться с курсом.
А с открытыми LLM это реально автоматизировать.
2021-2023. Образовательная лихорадка
Не только лишь каждый аналитик запустил свой инди-курс в одном и популярных форматов: от записи на степике, которая приносит небольшую копеечку, до живых когортных курсов с активным маркетингом. Ибо собрать и продать курс стало значительно проще, чем до ковида.
За это время качество локального бутикового (Денис, спасибо за термин, каждый раз ржу) образования сблизилось с большими игроками: брикфактори подтянули качество, а в андергрунде появились курсы по архитектуре от аналитиков с 3-5 летним стажем.
2023-2024. Пост-пост, мета-мета
Курсы плодятся, запускать легко, но нужно продавать - много конкурентов.
Появляются курсы вида “как пройти собеседование на SA”, “как найти работу аналитиком”, “как построить карьеру в IT” и т.п.
Подход мегаразумный - продать техническое обучение куда сложнее, чем продать буст карьеры. Участники тратят меньше времени на обучение, а результат намного понятнее и проще измерять. Тем более брикфактори и другие стабильно поставляют клиентов - специалистов с завышенными ожиданиями.
Есть даже курс по подготовке IT-спикеров. Не знаю, как продается, имхо рынок слишком маленький - по конференциям кочует всего несколько сотен спикеров.
Среди каналов случился первый эксперимент с платной подпиской. Контент классный, но не особо летит. Возможно, народ привык к халявному контенту.
2024 - …
Вангую тренд на мета-скиллы и обучение-без-курсов будет развиваться, а начинающим авторам будет проще запрыгнуть в них, чем в стандартные технические курсы.
P.S. Хронология или причинно-следственные связи в вашей версии реальности могут отличаться, поделитесь же ими.
😁28👍11🔥6
Реквием по интеграции
У меня в около-образовании тоже своя история. В 2020 году мы запустили в ComPractice курс по самым основам интеграции систем, тогда он назывался “Проектирование Web-сервисов”. На сколько помню, это был первый открытый курс по интеграции для аналитиков. А для меня это был первый опыт разработки и проведения коммерческого обучения, до это только внутри компании делал что-то.
Тут большое спасибо Ирине за то, что втянула в эту тему. Не знаю, связался бы я с обучением без того предложения.
И отдельное спасибо Ане за то, что терпит меня все эти годы))
За четыре года курс пережил 6 сезонов, обновился примерно на 50%, впитал в себя немного архитектуры и продвинутых тем. Теперь это полноценное погружение в тему на middle+ уровне.
Одна беда - сил и времени проводить его больше нет. Поэтому в начале лета провожу последний поток курса, больше в таком формате проводить не буду. Старт 30 мая, описание тут.
Главные особенности:
◽️ Все темы отрабатываем на практике в группах и индивидуально. Просто видео не продаем. Покупать курс, чтобы посмотреть занятия тоже бесполезно - лучше выберите другой.
◽️ “Иммерсивное обучение” (участник придумал название) - мы встречаемся с проблемой, и вместе ищем решение. “Повторяйте за мной” будет минимально.
◽️ Правильных решений не существует, мы учимся думать и создавать подходящие.
Что дальше будем делать не знаю, но точно не хочу переходить в формат видосики-задания.
P.S. Если у тебя, дорогой читатель, есть желание попробовать себя в роли автора и ведущего курса в теме интеграции или проектирования - дай знать в комментах, нам будет о чем поговорить ;)
У меня в около-образовании тоже своя история. В 2020 году мы запустили в ComPractice курс по самым основам интеграции систем, тогда он назывался “Проектирование Web-сервисов”. На сколько помню, это был первый открытый курс по интеграции для аналитиков. А для меня это был первый опыт разработки и проведения коммерческого обучения, до это только внутри компании делал что-то.
Тут большое спасибо Ирине за то, что втянула в эту тему. Не знаю, связался бы я с обучением без того предложения.
И отдельное спасибо Ане за то, что терпит меня все эти годы))
За четыре года курс пережил 6 сезонов, обновился примерно на 50%, впитал в себя немного архитектуры и продвинутых тем. Теперь это полноценное погружение в тему на middle+ уровне.
Одна беда - сил и времени проводить его больше нет. Поэтому в начале лета провожу последний поток курса, больше в таком формате проводить не буду. Старт 30 мая, описание тут.
Главные особенности:
Что дальше будем делать не знаю, но точно не хочу переходить в формат видосики-задания.
P.S. Если у тебя, дорогой читатель, есть желание попробовать себя в роли автора и ведущего курса в теме интеграции или проектирования - дай знать в комментах, нам будет о чем поговорить ;)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤5👌1
Designing High-Performance APIs - с одной стороны поверхностная и капитанская статья, с другой - полезные вопросы на подумать при проектировании API. Можно пробежаться и покопать незнакомые темы.
#API
#API
DZone
Designing High-Performance APIs
Learn API design principles for optimal performance and scalability. Create high-performance APIs for great user experiences and workload management.
👍7
Через неделю еду в Сибирь релизить и молиться.
И вы заходите - там секция по анализу вернулась.
И вы заходите - там секция по анализу вернулась.
Forwarded from CodeFest'16 | 30–31 мая 2026
🧪 Секция System analysis
🔹 Олеся Пахомова расскажет об архитекторе решений: что это, чем отличается от других видов архитектур и причём здесь бизнес-анализ.
🔹 Андрей Шапиро поделится авторским методом схематизации процесса и пользовательского опыта.
🔹 Кирилл Кашин и Сергей Хованов продемонстрируют, как можно перепроектировать системы с помощью ТРИЗ и извлекать максимум из ограниченных ресурсов.
🔹 С Андреем Бураковым обсудим, как требования и ограничения влияют на выбор технологии интеграции.
🔹 С Анной Вичуговой поговорим про инженерию данных и важность для системных аналитиков.
🔹 Роман Селезнёв разложит по полочкам тему выбора средств визуализации информации и почему это важно при разработке информационных систем.
🔹 С Викторией Лузиной обсудим проблему некорректной документации, роли технического писателя и как выглядит документация, за которую не стыдно.
Вся программа 👉 https://14.codefest.ru/program
#спикеры_CodeFest14
🔹 Олеся Пахомова расскажет об архитекторе решений: что это, чем отличается от других видов архитектур и причём здесь бизнес-анализ.
🔹 Андрей Шапиро поделится авторским методом схематизации процесса и пользовательского опыта.
🔹 Кирилл Кашин и Сергей Хованов продемонстрируют, как можно перепроектировать системы с помощью ТРИЗ и извлекать максимум из ограниченных ресурсов.
🔹 С Андреем Бураковым обсудим, как требования и ограничения влияют на выбор технологии интеграции.
🔹 С Анной Вичуговой поговорим про инженерию данных и важность для системных аналитиков.
🔹 Роман Селезнёв разложит по полочкам тему выбора средств визуализации информации и почему это важно при разработке информационных систем.
🔹 С Викторией Лузиной обсудим проблему некорректной документации, роли технического писателя и как выглядит документация, за которую не стыдно.
Вся программа 👉 https://14.codefest.ru/program
#спикеры_CodeFest14
❤7👍4
Хардкорный разбор работы протокола HTTP/2 на уровне обмена сообщениями фреймами.
Написано классно и интересно.Но зачем вам это, я не знаю
Написано классно и интересно.
Хабр
Разбираем HTTP/2 по байтам
Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие: GET / HTTP/1.1 Host: localhost HTTP/1.1 200 OK Date: Sat, 09 Oct 2010...
❤16