Yet another SA

Вспомнил, что яжепродакт, и завел канал для всякого продуктового. Будут собирать интересные ссылочки, рассуждать про финтех, около-образование, экспериментировать с иишечкой. Все как здесь 4 года назад. https://t.me/fake_product

Хардкорный разбор работы протокола HTTP/2 на уровне обмена сообщениями фреймами. Написано классно и интересно. Но зачем вам это, я не знаю

🧪 Секция System analysis 🔹 Олеся Пахомова расскажет об архитекторе решений: что это, чем отличается от других видов архитектур и причём здесь бизнес-анализ. 🔹 Андрей Шапиро поделится авторским методом схематизации процесса и пользовательского опыта. 🔹 Кирилл Кашин и Сергей Хованов продемонстрируют, как можно перепроектировать системы с помощью ТРИЗ и извлекать максимум из ограниченных ресурсов. 🔹 С Андреем Бураковым обсудим, как требования и ограничения влияют на выбор технологии интеграции. 🔹 С Анной Вичуговой поговорим про инженерию данных и важность для системных аналитиков. 🔹 Роман Селезнёв разложит по полочкам тему выбора средств визуализации информации и почему это важно при разработке информационных систем. 🔹 С Викторией Лузиной обсудим проблему некорректной документации, роли технического писателя и как выглядит документация, за которую не стыдно. Вся программа 👉 https://14.codefest.ru/program #спикеры_CodeFest14

Через неделю еду в Сибирь релизить и молиться. И вы заходите - там секция по анализу вернулась.

Designing High-Performance APIs - с одной стороны поверхностная и капитанская статья, с другой - полезные вопросы на подумать при проектировании API. Можно пробежаться и покопать незнакомые темы. #API

Реквием по интеграции У меня в около-образовании тоже своя история. В 2020 году мы запустили в ComPractice курс по самым основам интеграции систем, тогда он назывался “Проектирование Web-сервисов”. На сколько помню, это был первый открытый курс по интеграции для аналитиков. А для меня это был первый опыт разработки и проведения коммерческого обучения, до это только внутри компании делал что-то. Тут большое спасибо Ирине за то, что втянула в эту тему. Не знаю, связался бы я с обучением без того предложения. И отдельное спасибо Ане за то, что терпит меня все эти годы)) За четыре года курс пережил 6 сезонов, обновился примерно на 50%, впитал в себя немного архитектуры и продвинутых тем. Теперь это полноценное погружение в тему на middle+ уровне. Одна беда - сил и времени проводить его больше нет. Поэтому в начале лета провожу последний поток курса, больше в таком формате проводить не буду. Старт 30 мая, описание тут. Главные особенности: ◽️Все темы отрабатываем на практике в группах и индивидуально. Просто видео не продаем. Покупать курс, чтобы посмотреть занятия тоже бесполезно - лучше выберите другой. ◽️“Иммерсивное обучение” (участник придумал название) - мы встречаемся с проблемой, и вместе ищем решение. “Повторяйте за мной” будет минимально. ◽️Правильных решений не существует, мы учимся думать и создавать подходящие. Что дальше будем делать не знаю, но точно не хочу переходить в формат видосики-задания. 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. Хронология или причинно-следственные связи в вашей версии реальности могут отличаться, поделитесь же ими.

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? Насколько часто, и что именно из него?

Чек-лист отличная штука. Если сделал ее сам Когда обсуждают выбор типа хранилищ, брокеров, способа интеграции регулярно слышу вопрос: “А что лучше использовать для XXX?” Рассказываешь об особенностях технологии, сильных и слабых сторонах, известных кейсах применения… а в ответ: “Нет, ты пальцем покажи: здесь нужно использовать FOO, а здесь BAR”. После короткого диалога собеседник просит какой-нибудь чек-лист, таблицу с критериями принятия решений или что-то подобное. 🤦‍♂️ Если вы узнали себя, то у меня плохие новости. ◽️Во-первых, инет завален всевозможными чек-листами и сравнениями на любую тему. Пора научиться гуглить нужную информацию, в том числе с помощью ChatGPT и ей подобных. Неумение добывать инфу можно относить к одному из смертных грехов. ◽️Во-вторых, большая часть подобных материалов поверхностна, создана не на основе опыта автора, а является выжимкой из аналогичных источников. ◽️В-третьих, глубокие материалы с серьезным анализом могут оказаться как бесполезны, так и вредны для вас. Но почему? При проектировании системы хороший инженер фокусируется на тех ограничениях и контексте, которые важны для его задачи. Основываясь на них, он составляет список значимых критериев и уже по ним выбирает подходящие технологии. Со временем, он может сформировать чек-лист, в котором соберет критерии и условия их применимости. Однажды он оформит его в статью и выложит в сеть. Есть проблема - это критерии, которые имели значение в его задачах. Нет никакой гарантии, что все критерии значимы для вас. Нет никакой гарантии, что все значимые для вас критерии есть в списке. Нет даже гарантии, что сам автор не разочаруется в своем подходе через пару лет. Тогда что делать? 1️⃣Погружаться в контекст вашей задачи. В большинстве случаев он шире зоны ответственности аналитика или разработчика. Например, я писал о проблемах выбора способа интеграции 2️⃣Изучать технологии по первоисточникам, а не обзорным статьям. Благо, сейчас проблем с оригинальной документацией нет 3️⃣Самостоятельно выявлять значимые критерии принятия решений и валидировать их с командой Последний пункт самый важный. Выявление критериев - серьезная творческая задача, которая требует глубокого понимания контекста и технического кругозора. Выбор технологии на основе списка критериев - элементарная задача для систем принятия решений, которая успешно решалась еще в прошлом веке. А при наличии LLM вообще внимания не стоит. Мораль проста: занимайтесь творческими задачами, которые пока недоступны моделькам. Всю рутину неизбежно сметут LLM, причем это уже не вопрос возможностей, а внедрения и безопасности. ❗️Работающий чек-лист - это тот, который вы сделали сами. На все остальное есть GPT.

Этапы взросления менеджера: - Не догадывается, что существует чат без него, но где есть все его подчиненные. - Расстраивается, что существует чат без него, но где есть все его подчиненные. - Радуется, что наконец создали чат без него, но где есть все его подчиненные. - Делаем вид, что не заметил, когда добавили в очередной новый чат.