Вчера на вебинаре показывал промежуточные версии карты технологий интеграций, и внезапно одна из версий, которую я забраковал, вызвала интерес. Так что опубликую её тоже.
Здесь не так явно видна связь элементов друг с другом, только по расположению, зато видны направления дальнейшего возможного развития:
— от ETL идём в хранилища данных и BI
— от gRPC через HTTP/2 можно проложить путь к рассмотрению низкоуровневых протоколов (нужно ли аналитикам знать, чем друг от друга отличаются HTTP /1.0, /1.1, /2 и /3 ?)
— от транзакционной целостности можно дойти до паттерна Saga и микросервисов, а оттуда уже к рассмотрению архитектуры распределенных систем
— а от OpenAPI и смежных нотаций дальше идём к вопросам управления API
У карты четыре "центра кристаллизации" — всё те же стили из книги "Паттерны интеграций корпоративных приложений": обмен файлами, общая БД, удаленный вызов и обмен сообщениями. Вокруг группируются связанные технологии.
А ещё эта карта похожа на карту местности в какой-то стратегической игре — закрепились в одной части, построили укрепления, пошли разведывать новые области :) Надо будет туман по краям дорисовать, для антуражности.
Я показал эту версию ограниченному кругу, её очень ругали — мол, непонятная. Но на вебинаре она людям понравилась. Так что опубликую её тоже, а вы напишите в комментах — какую версию вы считаете более понятной и полезной.
Здесь не так явно видна связь элементов друг с другом, только по расположению, зато видны направления дальнейшего возможного развития:
— от ETL идём в хранилища данных и BI
— от gRPC через HTTP/2 можно проложить путь к рассмотрению низкоуровневых протоколов (нужно ли аналитикам знать, чем друг от друга отличаются HTTP /1.0, /1.1, /2 и /3 ?)
— от транзакционной целостности можно дойти до паттерна Saga и микросервисов, а оттуда уже к рассмотрению архитектуры распределенных систем
— а от OpenAPI и смежных нотаций дальше идём к вопросам управления API
У карты четыре "центра кристаллизации" — всё те же стили из книги "Паттерны интеграций корпоративных приложений": обмен файлами, общая БД, удаленный вызов и обмен сообщениями. Вокруг группируются связанные технологии.
А ещё эта карта похожа на карту местности в какой-то стратегической игре — закрепились в одной части, построили укрепления, пошли разведывать новые области :) Надо будет туман по краям дорисовать, для антуражности.
Я показал эту версию ограниченному кругу, её очень ругали — мол, непонятная. Но на вебинаре она людям понравилась. Так что опубликую её тоже, а вы напишите в комментах — какую версию вы считаете более понятной и полезной.
👍29🔥9❤5👎1👌1
А вот уже и запись вебинара по карте интеграций готова: https://youtu.be/27KmDUMkV6A
Смотрим, ставим лайки, задаем вопросы!
Upd.: Альтернатива на VK: https://m.vk.com/video-211773358_456239310
Смотрим, ставим лайки, задаем вопросы!
Upd.: Альтернатива на VK: https://m.vk.com/video-211773358_456239310
YouTube
Карта паттернов и технологий интеграции • Юрий Куприянов
Юрий Куприянов, эксперт школы Systems.Education, провёл вебинар, посвящённый Карте паттернов и технологий интеграций — уникальному инструменту ведущего, который поможет разобраться в сложном мире интеграционных технологий.
На вебинаре мы подробно разобрали…
На вебинаре мы подробно разобрали…
🔥34👍4
На канале Solvery поделился небольшой инструкцией по написанию документов требований с помощью ИИ.
В двух словах: не стоит ждать, что ИИ напишет сходу всё ТЗ или PRD. То есть, он конечно напишет, но результат может быть не совсем целостным. Поэтому нужно, во-первых, действовать последовательно — идти от верхнеуровнего описания или модели к деталям. Я начинаю с выявления ролей пользователей, основных юскейсов и контекстной диаграммы. Потом прошу выявить объекты и составить модель данных. А потом уже можно требования и интерфейсы описывать (всё — отдельными запросами).
Во-вторых, нужно проверить полноту документа через связи. Мы описываем одну систему с разных точек зрения, так ничего не должно "провисать" -- все части описания со всеми связаны. Это тоже может проверить ИИ.
В общем, смотрите карточки!
У ребят из Solvery на канале вообще интересный формат — многие эксперты делятся своим опытом. В основном про поиск работы и вход в ИТ — в разные профессии, не только в СА. Но есть и посты конкретно про аналитиков:
👉 прохождение собеса на аналитика в Т-банк
👉 подкаст про то, как джунам выжить на перегретом рынке IT
👉 и как упаковать профессиональный опыт, чтобы стартовать в системном анализе
В двух словах: не стоит ждать, что ИИ напишет сходу всё ТЗ или PRD. То есть, он конечно напишет, но результат может быть не совсем целостным. Поэтому нужно, во-первых, действовать последовательно — идти от верхнеуровнего описания или модели к деталям. Я начинаю с выявления ролей пользователей, основных юскейсов и контекстной диаграммы. Потом прошу выявить объекты и составить модель данных. А потом уже можно требования и интерфейсы описывать (всё — отдельными запросами).
Во-вторых, нужно проверить полноту документа через связи. Мы описываем одну систему с разных точек зрения, так ничего не должно "провисать" -- все части описания со всеми связаны. Это тоже может проверить ИИ.
В общем, смотрите карточки!
У ребят из Solvery на канале вообще интересный формат — многие эксперты делятся своим опытом. В основном про поиск работы и вход в ИТ — в разные профессии, не только в СА. Но есть и посты конкретно про аналитиков:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥2❤1
Forwarded from Solvery | Айтишники о карьере, росте и провалах
Как джуну в системном анализе использовать ИИ и не спалиться? 🔵
Поделился Юрий Куприянов - независимый эксперт и консультант в области системного анализа и архитектуры, ведущий тренер школы Systems.Education, автор канала "Системный сдвиг", программный директор конференции Winter Analytical Weekend.
⏩ Он также первым в России использовал ИИ для работы системных аналитиков и рассказал об этом на Хабре :)
▶️ Продолжает развивать эту тему в своем канале, где публикует также полезные материалы для аналитиков по проектированию интеграций и разработке требований.
Подписывайтесь, если хотите узнавать больше
Поделился Юрий Куприянов - независимый эксперт и консультант в области системного анализа и архитектуры, ведущий тренер школы Systems.Education, автор канала "Системный сдвиг", программный директор конференции Winter Analytical Weekend.
Юрий больше 25 лет проектирует и создает программные системы в разных ролях — разработчика, аналитика, архитектора и продакта. Создавал системы для крупнейших банков и в области образования (EdTech).
Постоянный докладчик на конференциях по системному анализу, автор лучших докладов на Analyst Days, ЛАФ и Flow.
Подписывайтесь, если хотите узнавать больше
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍7❤2👎2
Второй по счету WAW — Зимний аналитический уикенд — прошел. Я, честно говоря, очень переживал — такую высокую планку с точки зрения атмосферы и нетворкинга задал первый WAW. Когда в любое время проходишь по лобби отеля, и видишь, что везде тут и там сидят группками люди и общаются — это кайф! 💖 То есть, в основном же все на докладах и мастер-классах, но всегда кто-то активно тусит в кулуарах — огонь! 🔥 Кажется, это то, чего хотят все организаторы всех конференций.
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!😻 Так же до ночи сидели люди, что-то обсуждая, так же исписали весь флипчарт, установленный в фойе, так же тусили между и параллельно с докладами, перемешивались за обедом, танцевали на афтепати.
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥13👍2👏1
На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
🔥15❤9👍8🤔3🤯1
Вообще, когда начинаешь разбираться с сутью разговоров про стандартизацию процессов, часто выясняется, что всё дело в угадывании сроков. Только в этом, в основном.
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите🤷♂️
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
После уточнения вводных накинул ещё 30%:
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
Для системы средней сложности с базовым функционалом: 8-12 месяцев. При наличии готовых модулей (например, аутентификации) срок может сократиться до 6-9 месяцев.
После уточнения вводных накинул ещё 30%:
Этап Длительность Комментарий
Проектирование 5-8 недель Учёт новых интеграций (визы, календари)
Бэкенд-разработка 6-9 месяцев Особое внимание интеграциям с высокорисковыми системами
Фронтенд 4-6 месяцев Сложные интерфейсы для конструктора маршрутов и планировщика
Тестирование 10-12 недель Проверка сценариев мультивалютных операций и модерации
Общий срок: 12-16 месяцев
(увеличение на 30-40% к первоначальной оценке)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥8❤1