Системный сдвиг

Нашел прекрасный шаблон PRD! Какой документ составляет бизнес-аналитик? Ну, BRD. Business Requirements Document. Но мне больше нравится PRD — Product Requirements Document, продуктовый требования. Я разделяю мнение, что ко всем современным ИТ-системам нужно подходить, как к продуктам, даже если они сугубо внутренние. Это только кажется, что у внутренних пользователей нет выбора. На самом деле он всегда есть: саботировать, отказываться (вплоть до ухода из вашей дурацкой организации), использовать альтернативы (мы тут в эксельке всё ведём, а потом в систему вносим), делегировать. Например, почти все электронные дневники и LMS настолько неудобны для преподавателей, что во многих организациях они сами их никогда не ведут — материалы и оценки туда вносят специальные люди — секретари, ассистенты, помощники. Преподаватель туда может и не заходить никогда, не сталкиваться с этим ужасом. А при найме крутого препода специально оговаривается, что LMS за вас будем сами вести, не переживайте. Поэтому я рекомендую подходить к каждой задаче, как к продуктовой. И начинать c PRD. А вот и шаблон для него (англ.), на примере гипотетической фичи "Эмодзи-реакции на сообщения в Твиттере". Что в шаблоне: ⭐️Ссылки на питч док (документ-основание, ага), технические спецификации для бэкенда и фронтенда, спецификации дизайна, план QA. (Самих ссылок нет, подразумевается, что они в виде отдельных документов разрабатываются, как ТЗ и ЧТЗ, или ТЗ и техпроект). ⭐️ Описание фичи одним предложением ⭐️Обоснование, почему стоит делать эту фичу: 👉Почему именно в этой функциональной области: — эта функциональная область продукта достаточно востребована (10% DAU) — по данным анализа данных, использование этой функциональной области на 40% увеличивает краткосрочное удержание (STR 7 дней) — рост этой метрики (STR7DAY) включен в OKR как цель 👉Почему именно эту фичу: — 14% всех сообщений — это эмодзи — 10% ответов на сообщения являются эмодзи — 5% ответов являются одной из трех эмодзи (👍, 😂, ❤️) — По данным опроса, реакция на сообщения — вторая среди запрашиваемых фич — По результатам фокус-группы, реакции на сообщения названы must-have фичей — 20% всех тикетов (обращения в поддержку, упоминания в соц.сетях, отзывы в сторах) упоминают реакции — Конкуренты внедрили эту фичу более года назад и она активно используется (25% пользователей по данным группы исследования конкурентов) (Естественно, на источники всех данных приведены ссылки) ⭐️Почему сейчас стоит делать именно эту фичу, а не другую? (ссылки на дорожную карту, анализ альтернативных элементов бэклога, таблицу с расчетом приоритетов) ⭐️Перечень основных пользовательских историй (буквально 4 штуки) ⭐️Цели реализации фичи ⭐️Метрики успеха (целевые значения метрик использования и метрики продукта, которую улучшаем — в данном случае STR) ⭐️Метрики отслеживания (тут метрики успеха, и связанные метрики — например те, значения которых могут снизиться или перестать быть релевантными из-за изменения логики расчета) ⭐️Список принятых решений и матрица информирования DACI (Driver-Approver-Contributors-Informed) ⭐️Продуктовые требования с приоритетами, этапами и статусами готовности ⭐️Макеты интерфейсов и пути пользователей ⭐️План информирования и обучения пользователей ⭐️Что не входит в рамки проекта ⭐️Настраиваемость (где и как можно включать/отключать фичу) ⭐️Открытые вопросы ⭐️Ссылки на протоколы совещаний по проекту Мне кажется, очень классный шаблон! Я был бы рад, если бы мои аналитики/продакты мне такое приносили (+на одну страницу краткое резюме). И это то, что может и должен делать бизнес-аналитик. Для сложных внутренних доработок ещё стоит добавить модель бизнес-процесса (если он есть), для сложных интеграций — предполагаемую верхнеуровневую архитектуру. И на этом, по моему мнению, фокусироваться. А вот конкретные требования к фронту, бэку и интеграциям — это уже работа системного аналитика. Шаблон взят из блога Manas J. Saloi, у него тут целый набор на разные случаи.

Сформулировал мысль в одной дискуссии: раньше дизайн интерфейса нарисовать было сложно и трудоемко и поэтому перед дизайнером работало несколько специалистов — аналитики, проектировщики — чтобы не пришлось переделывать такой сложный продукт. Поэтому разрабатывались сценарии, создавались черно-белые прототипы, они даже иногда тестировались заранее, чтобы точно убедиться, что труд дизайнера не пропадет зря. Была такая отдельная роль — проектировщик интерфейсов, результатом работы которой был прототип, который потом отдавали дизайнеру для отрисовки в Фотошопе. Например, об этом упоминается в статье про анализ вакансий (2013, и её продолжение через 10 лет — проектировщики интерфейсов и умение создавать прототипы исчезли полностью), а в этой статье Ярослава Перевалова (2012) разбирается, какие роли участвуют в процессе дизайна и как они взаимодействуют (там вообще отдельно проектировщик, дизайнер и юзабилити-специалист, бизнес-аналитик и системный аналитик). Потом появилась Figma, и финальный дизайн стало рисовать очень просто (когда у тебя есть подготовленные компоненты) и быстро. И предварительные мокапы оказались не нужны. А вместе с ними и процессы анализа и проектирования. Поэтому все функции по проектированию из отдельной выделенной роли перешли к дизайнеру, но дизайнеры в массе их делать не умеют, ну и не делают. Зато красивые картинки очень быстро рисуются и выезжают в продакшн. Скорость увеличилась, менеджер доволен, руководство довольно, ещё и пару человек можно уволить/убрать из процесса. Только пользователи жалуются. И вот тут становится востребована новая роль — UX-исследователь! Который разбирается — что же этим пользователям нужно, что им там неудобно в этих интерфейсах, нарисованных без анализа и проектирования. А потом и рекомендации по исправлению можно выдать. Ну, то есть — быстро что-то делаем, а потом уже работающее улучшаем, этап анализа и проектирования после реализации. Ничего не напоминает? Да это же ситуация с вайб-кодингом! Сначала будем невероятно быстро писать код, а потом долго и скрупулезно исследовать — что же там не так работает и как исправить? Как это там называется, vibe coding cleanup specialist, да?

На Flow в этом году какой-то нереальный конкурс — ПК приходится отказывать даже очень классным (с моей точки зрения) докладам! Потому что есть ещё более классные. ИИ, архитектура и немного софт-скиллов — всё для развития аналитика. Но у JUG Ru Group осенью будет ещё несколько отличных конференций. (У Джугов вообще все конференции отличные, но в основном для программистов, для меня слишком глубоко). А вот на какие две я лично собираюсь, кроме Flow: InBetween — про оперативное управление. У нас не так много конференций для менеджеров, а искусству управлять толком нигде не учат и мало где обсуждают. Каждый учится на практике, набивая себе шишки и пересчитывая новые седые волосы. Поэтому новая конференция про управление давно уже напрашивалась, как площадка для обсуждений. Очень рассчитываю на умение JUG Ru собирать классных спикеров и поднимать актуальные темы! Кстати, онлайн-часть уже прошла и можно посмотреть доклады в записи (после регистрации). Уровень дискуссий повыше, чем в среднем на обычных конференциях! Ну и моё почтение за выбор названия — это же явная отсылка к австралийскому сериалу Mr. Inbetween, да?.. да?.. На русский его перевели как "Решала". Про эксперта в оперативном и тактическом управлении, так сказать. BiasConf — я, можно сказать, джва* года ждал такой конференции. Про философско-методологические и научные основы исследований в бизнесе — ну вы знаете, на что меня можно поймать. Вы, вероятно, заметили, что философские основания нашей деятельности меня очень интересуют (хотя, кажется, не всегда они интересуют читателей, судя по реакциям, а то я бы только о них и писал). Также меня интересуют эмпирические исследования процессов создания программных систем — мне кажется, многие теории и фреймворки оторваны от реальной практики "на земле". Ну а вторая часть конференции — про исследование и принятие решений на основе данных — уже более практическая. Обе конференции пройдут в Москве, InBetween — 8 сентября (когда же ещё обсуждать управление, как не в понедельник); BiasConf — 6 сентября (в субботу самое правильное поговорить о философии). Если кто-то тоже соберется — буду рад увидеться! Я пока без докладов, посмотрю, как там что, и возможно подамся на следующий год. * Не опечатка! Отсылка к старинному текстовому мему "я джва года хочу эту игру [в которой можно грабить корованы]"

Вопросы дизайна и проектирования сильнее связаны с проектированием API, чем мы привыкли думать. В конце концов, и то, и другое — это интерфейсы и взаимодействие. Проектировщик интерфейсов строит диаграмму переходов между экранами, и, как правило, на одном экране есть какое-то главное действие (+ несколько второстепенных). Изменение экранов, их состояний, переходы с одного экрана на другой — это и есть смена тех самых состояний, которые упоминаются в принципе stateless. Less — это из на сервере нет, а на клиенте они как раз есть, от них всё и проектируется. Изменяется экран — изменяется и состояние. Каждый переход — вызов API. Один и тот же артефакт служит основой и для работы дизайнера, и для работы проектировщика API. Но и это не всё. Каждый дизайнер знает про аффорданс — свойство вещи "предлагать" или "подсказывать" способ её использования. Вы возьмете молоток за рукоятку, а не за головку, потому что самой своей формой она "предлагает" вам это. В интерфейсах аффорданс играет большую роль, акцентируя внимание пользователя на элементах взаимодействия и предлагая определенные действия. Например, подчеркивание ссылок в гипертексте как бы предлагает вам нажать на них. Такое же "предложение" справедливо и для API. И — вы не поверите — называется HATEOAS, о котором писал Рой Филдинг! Почему-то на русском практически не встречается статей на эту тему, а для англоязычной аудитории это почти что общее место. Аффордансы в API — это предложения следующих действий с предоставленным ресурсом: следующий шаг в процессе, изменение свойств и состояний, удаление, в конце концов. Майк Амундсен называет проектирование вокруг аффордансов высшей точкой зрелости API. Ну а что они такое, конкретно? Да это же ссылки на действия с ресурсом из HATEOAS! Как это может выглядеть в коде: { "user_id": "12345", "username": "johndoe", "email": "[email protected]", "_links": { "self": { "href": "/users/12345", "methods": ["GET", "PUT", "DELETE"] }, "update_profile": { "href": "/users/12345/profile", "methods": ["PUT"], "expected_fields": ["first_name", "last_name", "address"] }, "change_password": { "href": "/users/12345/password", "methods": ["PUT"], "expected_fields": ["old_password", "new_password"] } } } Так мы можем работать практически без документации! Идея пришла из простого следования HTML: там же сразу есть гиперссылки, и человек может нажимать на них, не запрашивая дополнительной информации и не обращаясь к документации. Вот бы и в API так делать! Ничего не вышло, т.к. c API работает программа, которую создает программист, и ей не требуются все эти ссылки, она сама не принимает решения ходить по ним. Это должен сделать программист. А дополнительный трафик они жрут порядочно. Но теперь у нас есть кому ходить по ссылкам — ИИ-агентам. В этой связи я бы ожидал возврата интереса к HATEOAS, но пока мы его не видим. Те же MCP и A2A построены совсем на других принципах. Возможно, эта ветка технологического развития так и не реализуется, как и многие другие перспективные, но не получившие массового применения технологии.

Зацепила статья про Human Centered Design от Дона Нормана (автора книги "Дизайн привычных вещей" и, собственно, изобретателя термина UX, "пользовательский опыт"). Это статья из серии "considered harmful", в данном случае — это самый человеко-ориентированный дизайн должен быть признан небезопасным. Почему? Тем более что у нас есть целый стандарт ISO 9241-210 (и ГОСТ Р ИСО 9241-210-2016 "Человеко-ориентированное проектирование интерактивных систем"). И что он предлагает взамен? В статье я увидел четыре концепции: 1) Не всегда нужно ориентироваться на человека. Расписывать его портрет, персону и социально-демографические характеристики. Это не очень помогает спроектировать интерфейс. Не так важно — кто именно пользуется вашим продуктом, гораздо важнее — что они делают, какая деятельность происходит в этом продукте. Тут Норман излагает в нескольких фразах теорию деятельности Леонтьева (не называя его, он говорит просто об early Russian research): у человека есть цели и задачи, им соответствует деятельность, действия и операции. И анализировать нужно именно деятельность и действия, а не личность человека. От HCD нужно перейти к ACD — Activity Centered Design. 2) Не всегда стоит игнорировать инструмент. Подход HCD говорит, что лучший интерфейс — это отсутствие интерфейса. Но есть много примеров, когда интерфейс имеет значение и никуда не исчезает: часы, автомобили, музыкальные инструменты, да даже письменность. Это не концепция исчезновения интерфейса, а концепция взаимной адаптации человека и интерфейса. Где-то интерфейс поменяется, а где-то человек привыкнет. Поэтому часто смена интерфейса на более модный и вроде бы удобный ломает работу пользователей, привыкших к старым интерфейсам (впервые я столкнулся с таким, когда нужно было перевести старых банковский софт под DOS на Windows: например, оказалось что плотность и различимость текста в интерфейсах типа Нортон-коммандера самая лучшая — в GUI элементы тоньше, пространства больше, а информации вмешается меньше). Тут сразу вспоминаются работы В.Ф.Венды по взаимоадаптации человека и машины, но их Норман видимо уже не читал. Идея в том, что адаптация взаимна — человек, в конце концов, очень хорошо учится, и на это можно рассчитывать. 3) Почти никогда интерфейс не является набором статических изображений. Когда человек действует, интерфейс для него — это динамический поток, изменяющийся и реагирующий на действия и изменение состояний. Поэтому худшее, что можно придумать — демонстрировать интерфейс в виде отдельных статических изображений, а не в процессе деятельности. Как пишет Норман, многие системы отлично проходят тесты на "визуальный осмотр" и даже юзабилити-ревью, но пользоваться ими потом крайне неудобно. 4) Почти всегда нужен авторитарный дизайнер. HCD рекомендует слушать пользователей и делать, как они говорят. Но великие продукты создавались яркими авторами, типа Джони Айва. Я тут уже писал, что это математически обусловлено. И всё это дает фору аналитикам при проектировании интерфейсов! Мы же умеем (должны уметь!) выявлять и моделировать деятельность людей — через бизнес-процессы или сценарии. Вот и нужно на этом фокусироваться. Какая деятельность выполняется? (процессы/сценарии) Из каких действий она состоит? (шаги сценария/частные сценарии) Какие операции может выполнить пользователь? (Это уже уровень отдельных компонент интерфейса, можем выбрать по табличке). Фокус на деятельности отражен даже в способе записи требований: job stories против user stories. Ну или их объединение — User Story Map. Правда, кажется, зачастую анализ деятельности пропускают — сразу перепрыгивают от бизнес-процессов к отдельным операциям. Но тогда целостный сценарий из действий не соберется.

Вы ещё не забыли про конкурс постов от Systems.Education? Там есть очень интересные! Искать по тегу #продолжи_мысль_SE Не буду ставить прямые ссылки, чтобы не создавать искусственное преимущество участникам (во втором туре учитывается количество цитирований), но отмечу новые каналы, которые мне понравились и их посты: https://t.me/cool_analyst , посты про промпты для аналитика. Полезная польза! https://t.me/parawriter , канал технического писателя, пост про типографическую раскладку. Люблю хорошо оформленные тексты! Правда, говорят, теперь это считается признаком ИИ-генерации и нужно наоборот делать максимально неряшливо: никаких кавычек-ёлочек, длинных тире и прочей красоты. Да ну их всех, не буду отказываться от эстетического удовольствия. https://t.me/vne_efira , пост про кофе и подход к критике продукта, но и вообще канал интересный и поднимающий неочевидные темы. https://t.me/kozlovaabout , пост про требования к UI. Очень правильные мысли! Вообще вижу, что аналитикам зачастую сложно формулировать требования к интерфейсам, а уж проектировать хорошие совсем сложно. Не знаю, почему так — вроде вполне системно и почти формально можно к этому подойти, а не получается. https://t.me/system_analysis_max , пост про транзакции и их откат. Скажу честно — точное попадание в тематику: понятное объяснение сложной темы. https://t.me/analyticagain , пост про харденинг. Узнал новое слово! https://t.me/analitics_way , пост про транзакции. Дались вам эти транзакции! Но авторы находят разные ракурсы, и это интересно. https://t.me/business_analysis_team , пост о SWOT-анализе, а также его родственниках и знакомых. Не люблю карточки, но может вам зайдет. А также совершенно неожиданные находки! Как вам ментор по системному анализу с 13-летним опытом работы в МВД? (https://t.me/solo_teach) Не говорите теперь, что в ИТ сложно перейти. У меня, кстати, был сотрудник, долго работавший судебным экспертом и перешедший в аналитики. Вот у кого не было никаких проблем с написанием документов и логикой изложения! Вот такие у нас участники, все очень классные. Если кого-то не упомянул, простите. Смотрите больше каналов по тегу!

Про типизацию в разных схемах я тут уже писал, а вот вам про null-ы. С ними вообще чудеса: каждый подходит со своей логикой. Вообще, можно найти довольно много статей под заголовком "Null considered harmful", Гугл сходу выдает штук 10. Страниц выдачи. Сам Чарльз Энтони Ричард Хоар, изобретатель null reference, говорит, что это его "ошибка на миллиард долларов". Говорит, невозможно было удержаться, но "this has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years". В чем проблема с Null? Основная проблема в том, что это семантическая черная дыра. Что конкретно означает Null каждый раз, когда он появляется, непонятно. То ли это ошибка, то ли это пропущенное значение (например, при объединении двух таблиц), то ли пустое значение, то ли элемента нет в списке, то ли есть элемент с пустым значением, и т.д. Наличие в языке значения Null подрывает всю идею статической типизации — когда мы можем проверить типы без исполнения программы. Теперь не можем, потому что всё может быть Null. Это приводит к защитному стилю программирования — каждый раз нам нужно проверять значение на Null. В некоторых языках ещё и на пустое значение, потому что они разные. Получаются конструкции типа string.IsNullOrEmpty(str). Пустое или Null. Бинарная логика становится тернарной: True, False и Null. Или даже 4-арной (я не знаю, как это читается): True, False, Null и Empty (Undefined). Во многих случаях нам нужно это различать: аватар пользователя Null потому, что мы не можем его прямо сейчас извлечь из хранилища/кэша, или пользователь его не установил (Empty) и нужно показать дефолтный? В случае интеграций всё ещё больше запутывается, когда мы используем разные языки (в некоторых null == 0, в некоторых нет, а со сравнениями вообще чудеса происходят). Удивительно, что каждый формат решает это по-своему. В XML никаких Null'ов нет, зато есть вариант с пустым тегом (<avatar/>) или просто исключение тега, когда его нет в документе. Что какая семантика означает — решать вам! Будет пустой тег пустой строкой или Null'ом? Когда как. Я видел дичь, когда <string></string> дает пустую строку, а <string/> — Empty. Впрочем, у пустого тега можно ещё поставить атрибут xsi:nil="true", но некоторые парсеры на этом ломаются. В JSON всё ещё хуже: есть отдельное значение null, и получается 6 вариантов: null, "", 0, [], {}, пропущенное значение. Все они разные и не равны друг другу. Зато в Protobuf вообще нет Null! Вот я понимаю — концептуальная целостность! Выкручивайтесь как хотите. Зато там есть значения по умолчанию для типов (0, "", false), и механизм для явного указания пропущенных полей. Помним, что protobuf бинарный и стремится к уменьшению размера сообщения, а для передачи null нужно было бы накручивать дополнительную семантику. А вот в Avro есть отдельный тип null, который ни с каким другим типом не совместим, так что нужно его в схеме явно указывать: это поле может иметь два типа — int и null. Зато в GraphQL Null'ы резвятся вовсю: все типы по умолчанию nullable, и нужно специально указывать, если вы хотите это отключить. Null в GraphQL — в первую очередь признак ошибки (значение этого поля по какой-то причине не удалось предоставить). Потому что GraphQL пытается отправить хоть какую-то информацию, пусть даже неполную. Это же позволяет гибко управлять доступом (вернем null в тех полях, которые недоступны этому клиенту) и допускает эволюцию схемы без изменения старых клиентов (мы выкинули какое-то поле, а клиент его запрашивает? Ну просто вернем ему null!). Кстати, вопрос про эволюцию схемы данных можно смело задавать на собеседовании, ещё один в копилочку :) Ну а про null'ы — если нужно зачем-то кандидата засыпать 🥴

Ну что, можно признать, что более чем в половине компаний ИИ активно и целенаправлено внедряется. Интересно, что в опросе в канале ЛАФа 61% ответов — "пущено на самотек". Видимо, разная аудитория у нас всё же. А можете чуть подробнее рассказать — что ваша компания делает? Есть инструменты с ИИ, типа Cursor или Copilot? Какие KPI введены? Что требуют от сотрудников? Как проверяют владение инструментами ИИ на собеседованиях? Как обеспечивают безопасность? Как изменилась ваша работа, как аналитика, с этими нововведениями? Напишите в комментах, ужасно интересно!

Ооо, какая штука! Каталог паттернов работы с легаси-системами: https://legacy-modernization.io/ Вытащил из сообщества архитекторов Russian Association of Software Architects Удушение, миграция, параллельная работа. В связи и импортозамещением (не всё ещё заместили?..) очень актуально. Как обычно, многие паттерны — это просто здравый смысл, но хорошо, что они названы и собраны в одном месте. Каталог разбит на 4 части: — миграция с легаси-системами — синхронизация данных — организационные паттерны + не паттерны, а перечень типовых проблем и мотивов перехода со старых систем. Паттерны интеграции: — "душитель" (по-английски он фикус-душитель, Strangler Fig): откусываем от легаси-системы по одному юскейсу — ставим на входящем потоке роутер, который перенаправляет некоторые частные случаи в новую систему. Сначала единичные, потом всё больше и больше, потом все. — "пузырь": развитие идеи anti-corruption level — внешние системы и пользователи работают с новой моделью (и функций, и операций), а он преобразует и сохраняет данные в легаси-системах. Постепенно он всё меньше и меньше зависит от легаси-систем, а потом они совсем отключаются — пузырь "лопнул". "Автономный пузырь" — изначально со своим хранилищем данных. "Обратный пузырь" — когда ставим его после легаси-системы, и отправляем в него запросы для обработки, то есть легаси как интерфейс, а в пузыре новая бизнес-логика с новой доменной моделью. — можно прикрутить к легаси новое API или UI, или отлавливать и публиковать события из неё. — дальше разные стратегии миграции: пишем в легаси, читаем из новой системы/читаем из легаси, пишем в новую систему. Или делим по сегментам пользователей (по странам, клиентам, юскейсам). — параллельная эксплуатация. Любимое развлечение, однажды полгода этим занимались. Паттерны синхронизации данных: — CDC, чтобы гонять только изменения — Sync and Backfill — когда у нас два отдельных процесса на синхронизацию новых данных (в реальном времени) и подгрузке исторических (асинхронно) — Двойная запись (пишем одновременно в старую и новую систему) — Общая БД Обратите внимание: миграция требует практически тех же подходов, что и интеграция! Организационные паттерны: — AMET (Architecture Modernization Enabling Team) — вот это крутая идея! Временная команда, выделенная на фасилитацию перехода: помогает спроектировать новую архитектуру, не давать угасать импульсу, добавлять экспертизу там, где она нужна. Вот тут подробная статья про AMET https://livebook.manning.com/book/architecture-modernization/chapter-15, из книги Jean-Georges Perrin и Nick Tune 'Architecture Modernization: Socio-technical Alignment of Software, Strategy, and Structure' (на русском вроде её нет) Добавлю от себя, что хорошо ещё иметь техническую команду для различных подпорок и строительных лесов: скриптов миграции, роутеров, синхронизаторов, контролеров расхождений с всякого такого добра. Его нужно писать много, и не всё из этого одноразовое — вам точно придётся запускать эти скрипты несколько раз, и обязательно предусмотрите детальный лог! — Inner-Sourced Client Migration: команда со стороны сервиса берется за переписывание кода в клиентских системах (эффективно, но только для тех клиентов, кто готов пустить в свою кодовую базу). Да мы уже сами вам всё перепишем, только перейдите уже на новую версию! — Dual Track — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией. Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.

Участники тренинга рассказали про вопрос на собеседовании: как браузер узнает, в какую именно вкладку пришел ответ от сервера, если в двух вкладках открыта одна и та же страница. Гугловский ИИ, кстати, выдает отменную чушь — мол, если открыта одна и та же страница в двух вкладках, то они обновятся обе. Вопрос достаточно простой (на каждое новое соединение открывается собственный сокет, то есть отличаться они будут локальным портом), так что даже начинаешь подозревать какой-то подвох. Ну, можно ещё рассказать про различие между HTTP/1.1 и HTTP/2 (в последнем будет удерживаться одно TCP-соединение, а запросы и ответы для разных вкладках будут передаваться в разных потоках). Но, конечно, фантазия интервьюеров меня огорчает. Не могли что-нибудь интересное спросить. Если уж спрашивать какую-то абстрактную чушь, то пусть это будут действительно странные вопросы, а не чем отличается REST от SOAP и что происходит, когда вы набираете адрес в браузере (это в деталях описано вот тут , начиная с описания генерации скан-кода нажатой клавиши и опроса клавиатуры контроллером USB). Я вот подумал и накидал десяток вопросов. Пользуйтесь, если вы любите такое. Заодно можем обсудить правильные ответы. Итак, странные вопросы для собеседования: 1. В какой интеграции нет очередей: RabbitMQ, gRPC, Kafka? 2. Как устроена пагинация в GraphQL? 3. Есть ли в MCP HATEOAS? 4. Какой самый простой способ организации Service Discovery? 5. Что лучше с точки зрения безопасности — JSON или XML? 6. В каких версиях HTTP можно передавать потоки данных с сервера на клиент по инициативе сервера? 7. Что передается в методе PATCH по стандарту? 8. Каким методом HTTP нужно создавать ресурс на сервере? 9. Чем ограничивается число входящих сетевых подключений на сервере? 10. Какими функциями должна обладать система, чтобы её можно было считать полноценной шиной?

Мы вместе с NextWay и Flow проводим независимое исследование рынка системных и бизнес-аналитиков. В виде опроса: Как мы уже с вами выяснили, здесь собралась не совсем обычная аудитория — например, по уровню внедрения ИИ в своих организациях вы явно более продвинуты, чем другие аналитики. Поэтому ваши свидетельства очень важны. Опрос займет у вас примерно 15 минут, а в результате мы будем с большой достоверностью знать — чем дышат аналитики, какие технологии и знания востребованы, что вообще происходит еа рынке. Результаты везде опубликуем. Ссылка на опрос

К чему я, собственно, это пишу. Слышу во многих обсуждениях сомнения в функциях системного/бизнес-аналитика. Мол, то ли всех заменит ИИ, то ли всех уволят из-за перехода на agile, то ли ещё что. Да и куда расти непонятно: то ли в архитекторы, то ли в продакты (рост ли это?), то ли в стратегию/CIO, то ли ещё куда. Вот один из вариантов — если вы любите операционку и кайфуете от налаживания процессов. Вариант, кстати, вполне реальный: у меня как-то раз именно в операционное подразделение сманили лучшего бизнес-аналитика — там задачи интереснее и рост понятнее.