ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА

ТАЙМ-АУТЫ. ЧЬЯ ЗОНА ОТВЕТСВЕННОСТИ? АНАЛИТИКА ИЛИ РАЗРАБА? Очень часто я встречаю ситуацию на ревью, да и просто при обсуждениях, когда пропускают тему таймаутов. Чаще всего их втыкают везде по умолчанию и тянут из конфига. Но бывают ситуации, когда просто отдать на откуп разрабу эту тему - не самая лучшая затея, потому что это может стоить вам кучи времени. Был у нас как-то кейс на мобильном проекте: UI обращался в мидл сервис, который в свою очередь тянул данные из внешнего бэка, а у них что БД, что бизнес-логика на хранимых процедурах. Понимаете, чем пахнет? Правильно! Лютыми тайм-аутами, так как при возрастании нагрузки, мы начинали ловить лютые лаги и UI начал отваливаться, потому что тайм-ауты на фронте были стандартные. И все бы ничего, но UI это не веб приложение, где можно накинуть быстро изменение, это мобилка, а все же знают, что чтобы релизнуть мобилку надо пройти 100 кругов ада и все равно где-то старые версии будут использоваться? Так вот. Когда появились таймауты разумеется кто негодяй? Правильно, наша команда. И поэтому нас удостоили чести решать этот вопрос 😂 В итоге, как в любой сказке есть 3 пути: ✔️ пойти по-длинному, но безопасному, ✔️ по-короткому, ✔️ по-среднему, но с танцами и потерей коней по дороге. Идеальный и длинный путь - это пойти и попросить команду доработать запросы, но они не быстрые - бэклог забит, на полгода вперед, и в целом функциональность-то работает, поэтому вы и решайте. Поэтому мы с командой решили идти по пути не очень правильному, но 100% рабочему. Подкручивали таймауты на разных уровнях цепочки, чтобы поведение было предсказуемым. Почему на разном уровне? Потому что на просто накинуть чуть времени на UI не достаточно, так как это не решит проблему отвала при доп нагрузке, а значит надо подкручивать и делать доп инструменты по пути: UI, Балансир, Твой сервис, внешний сервис. И только так можно получить какой-то качественный и устойчивый вариант. Так что после таких кейсов, даже если не надо продумывать таймауты, я все равно обращаю на них внимание, чтобы не отдавать это на откуп разработчику и значениям по умолчанию. ➖➖➖ На что важно обратить внимание в постановках? ✔️ Сколько ждать ответ В идеале не больше 3-5 секунд. Все что больше - уже не очень и надо продумывать другие механизмы, например, кэширование, перевод этапа в асинхрон или что-то еще выдумывать. Возможно чинить на других этапах. ✔️ Ретраить или нет Если операция отваливается по таймауту, то можно сделать повторный вызов, если операция идемпотентная, но если нет, то нужно продумывать работу с дублями. Обычно про это забывают. ➖➖➖ Так что, если вы думали, что таймауты - это мелочь и можно отдать это разрабам, то увы, нам с вами лучше поучаствовать в этом вопросе.

Time To Market за один день Был сегодня на встрече и там прозвучала мысль, о том, что надо стремится делать Delivery так, чтобы фичи появлялись за 1 день. Звучит здорово, однако у меня всегда в этом желании возникакет только один вопрос: а насколько это жизнеспособно внутри крупной компании, а не на слайде? Вообще с появлением ИИ-движухи эта идея может взлететь, однако это сейчас разбивается о то, что есть 2 лагеря сотрудников. Одни говорят - погнали внедрять ЫЫ, токины палить, а другие - считают, что этот ИИ дичь лютая. Только продуктивность роняет и ничего не дает. ➖➖➖ А я, сейчас в такой позиции, где-то между. С одной стороны, инструменты сейчас реально огонь, последние модели позволяют лепить такие прототипы, что даже школьник соберет что-то рабочее и будет счастлив. С другой - в энтерпрайзе все это вязнет. Архитектура слишком вязкая и громоздкая со своими нюансами + есть регуляторка + своя внутренняя кухня в компании. И ребятки, которые играют в политику на локальном уровене. Короче цирк с конями 😂 Поэтому вся эта красота точно за один день не взлетает. Но можно ли реально ужать time-to-market до дня? Наверное, да, я такие компании даже видел. Недавно слушал подкаст про одну компанию из Штатов - Manifest. Они автоматизируют работу юристов и выкупают самых дорогих инженеров по всему миру, не только в Долине. И, если верить владельцу, от запроса клиента до реализации у них уходит 2-6 часов на внедрение каких-то быстрых фичей. Но это компания стартап, поэтому там обвесов в виде легаси еще нет. Но для СА важно критически научиться работать с этими инструментами. Мне в проекте некоторые моменты ИИ-шка точно облегчает. Ну и ниже, слайдик из выступления на data day про агентов, который показывает, что в финтехе не везде надо делать TTM 1 день и доверятся агентам и ИИ в целом. Было полезно - ставь 🔥

Я как-то на конференции DUMP разговорился с Егором Марюшко - он рассказал, что решил запустить институт системного анализа и собирает под него базу знаний. Вот сегодня он написал, что у института появилась платформа с моделью знаний, умений и навыков. Платформа новая, и пока там не сильно много инфы, но по направлению СА уже есть скелет из 300+ разделов: от BPMN и трассировки требований до Swagger, SQL и event-driven архитектуры. Опубликованных вопросов пока немного, база только растет, но сама карта навыков уже стоящая, по ней видно, что вообще должен знать и уметь системный аналитик. Так что если вы хотите понять, какие навыки нужны и в целом поучаствовать в наполнении базы, то вот ссылочка

Вчера был на Data Day 2026, вся конфа посвещена самой важной теме к этому часу - кто и как юзает ИИ. Там выступали ребята из финтеха, ритейла и не других сфер. Короче было интересно. Но... Я поймал себя на мысли, что ребята рассказывают какие-то кейсы про ИИ очень бодро и задорно, сыпят кучей терминов, рассказывают как круто все работает. Но я или слабо понимаю о чем они, потому что много терминологии с которой я не работал и это чисто их локальная кухня или все презентуется так абстрактно, что хочется сказать: "так *лять... собрались и дали конкретный кейс по шагам, что делать" А то кейс прикольный, а как мне его применить непонятно. И таких докладов 90%. Очень интересные, а забрать практически нечего. Ладно, кое какие мысли я оттуда взял и принес вам 😉 И вот они: ✔️ Компании, которые поувольняли спецов заменив их на ИИ в 55% случаев жалеют об этом и возвращают квалифицированные кадры. ✔️ Агенты, которые сейчас есть, отлично покрывают рутинную работу среднего сотрудника, помогают ему обучиться за пару месяцев вместо пары лет, но не покрывают корнер кейсы. И в итоге у нас среднячки, которые не могут перформить. ✔️ Не во все дырки надо пихать ИИ. Кто бы сомневался И в большинстве кейсах нужен человек хотя бы, как смотрящий за тем, что выдает ЫЫ-шка. Так что ребят, качаемся в агентности, но не забываем про БАЗовые навыки, чтобы понимать, где у ИИ правда, а где она словила галюнов 😅

Как выбрать метод сбора требований, когда все запутано? Увидел недавно одно интересное обсуждение. Пишет аналитик: Я знаю кучу методик по сбору требований: воркшопы, карты стейкхолдеров, модели процессов, root cause, матрицы решений. Но есть проблемка, не знаю когда какой использовать. Не знаю, как вас, но на старте карьеры такое часто стреляет у аналитиков, потому что когда ты только изучаешь тему, навыки и познал сокральные знания, то инфы много, а практических навыков нет, так как не встречается так много всего на одном проекте. Так как же понять, когда какой способ сбора требований использовать? Все просто, надо понять, что у тебя сейчас за ситуация и чего не хватает, чтобы подвинуться дальше. И понять это можно только исходя из кейсов, которые мы можем получить на практике, или прочитать, или получить опыт из блогов, книг, статей. Вот давайте приведу парочку кейсов, чтобы было понятно, что делать и какой инструмент применять. ➖➖➖ Кейс 1️⃣ Представьте, что у вас 2 стекхолдера и каждый описывает процесс по-своему и возникает спор между ними, и тебя как аналитика затягивают. Какой инструмент можно применить? Поиск причинно следственных связей. Берем и рисуем AS-IS схему. Дальше совместно со стекхолдерами проходимся по схеме и на каждом этапе верифицируем всех стеков и находим противоречия и пересечения. ➖➖➖ Кейс 2️⃣ Размытый скоуп и нечеткие границы. Вам дали задачу, которая ну очень большая. Например, спроектировать функциональность торговли на криптобирже. Для вас, как аналитика, такая постановка может означать все, что угодно. Поэтому надо сужать скоуп и приводить все к какому-то более четкому знаменателю. Поэтому тут нужно будет делать несколько итераций. И начать с такого инструмента, как assumption mapping (карта гепотиз), то есть накидываете, что имелось ввиду, а уже потом обсуждаете со всеми, что можно реализовать из этого, что вообще не туда. ➖➖➖ Кейс 3️⃣ Несколько вариантов решения. Вам дали задачу спроектировать отображение торговых идей на бирже. Вы видите несколько вариантов решения, но не понимаете, а какой из них выбрать. Вот для такого кейса отлично подходит матрица принятия решений (decision matrix). Просто разбираете на плюсы/минусы, ограничения, возможности каждый из вариантов и потом груммите и обсуждаете с командой и стеками. ➖➖➖ Короче, если вы понимаете, что у вас есть набор инструментов, который вы не знаете куда применить и сомневаетесь в его использовании, то: во-первых, попробуйте поискать кейсы, где такое применимо; во-вторых, попробуйте к какой-то конкретной задаче, которая у вас есть сейчас, применить любой, кажущийся правильным. Поверьте, на собственной практике, вам через пару тройку задач станет понятно, где отлично работает research, где интервью, где матрицы или живое общение.

ОГНЕННОЕ ВИДЕО ПРО ТО, КАК РАБОТАЮТ ЯЗЫКОВЫЕ МОДЕЛИ Я думаю, что только ленивый не изучает сейчас ИИ, и я уверен, что среди вас есть те, кто хочет хочет понять, как это все работает. Потому что не понимая БАЗЫ, трудно делать какие-то более глобальные штуки правильно. Так вот, наткнулся на очень крутое видео с объяснением, как устроены большие языковые модели (LLM).  И мне очень зашло, так как моменты, которые были просто по умолчанию из разряда "просто так все делают и так говорят делать" - я понял зачем их применять. Например, что такое температура, как подбираются веса, зачем надо обязательно добавлять ролевую модель и как указание роли влияет на выбор и предсказание.  Короче, мне зашло и думаю вам тоже залетит.  Так что рекомендасьен 🔥 ➡️ ССЫЛКА НА ВИДЕО ➡️ ССЫЛКА НА ВИДЕО ➡️ ССЫЛКА НА ВИДЕО Ставьте 🔥, если тема ИИ заходит

КАК ЗАГРУЖАТЬ ФАЙЛЫ В API? Представьте, что вам надо сделать загрузку документов, например, сканы паспорта. Как правильно это сделать? Первое, что может прийти в голову - это воткнуть в JSON в формате base64, но так делать не надо! Потому что кодировка может очень сильно раздуть файл. - если это маленькая картиночка, то это еще терпимо, - если это pdf со сканами всех страниц документа, то это будет полная жесть. И ладно, что нам это надо отправить, но нам еще стороне API такое добро нужно обработать, а обработка такой дикой JSON-ины заставит сервер не то что задуматься, а дико затупить и подвиснуть. И есть риск, что результат будет плачевным 🥲 Поэтому давайте обсудим, как лучше грузить файлы? ➖➖➖ 1️⃣ Content-Type: Multipart/form-data. Отправка файла через ваш бэкенд. Это классический способ. Клиент отправляет файл на сервер, как multipart, вместе с метаданными в виде байтиков, а бэк принимает байты и кладёт их в хранилище. Пример, POST /documents Content-Type: multipart/form-data (file=скан.pdf, type=passport) Этот способ хорошо использовать, когда файл имеет небольшой размер, например, аватарка или один документ. Ну и тогда, когда не хочется заморачиваться, так как в этом случае у нас один запрос и валидация проходит прям на серваке, то есть никакой доп логики и усложнений. Однако, этот способ очень плох, когда у вас файлы много весят или их очень много, например, вы хотите передать не один документ, а пачку док разом. При использовании этого варианта в какой-то момент бэк может начать захлебываться и вальнется по таймауту, поэтому для этого используем способ 2. 2️⃣ Presigned URL При этом варианте мы отправляем файлы напрямую в хранилище, то есть API-шки у нас тут участвуют только в роли указателя, что сделать с файлом, но не передают его. При этом сервер выдает просто доступ к хранилищу и никак не взаимодействует с самим файлом. Как это выглядит: 1. Клиент дергает API и говорит: хочу загрузить файл. POST /uploads → { "uploadUrl": "https://storage/...&sig=...", "key": "docs/abc123", "expiresIn": 600 } 2. Клиент грузит файл НАПРЯМУЮ в хранилище по ссылкам при помощи PUT метода. 3. Клиент дергает бэк, чтобы проверить, что все загрузилось. Если загрузлось, то возвращается ключ, по которому можно работать с документами. POST /documents { "key": "docs/abc123", "type": "passport" } Главный жирный плюс такого подхода это то, что тяжёлую работу берёт на себя хранилище и этот подход легко масштабировать. Однако, в использовании такого подхода есть нюанс в сложности его проектирования. Например, надо учитывать типы данных, которые вы готовы отправлять и их максимальный размер. Еще, стоит продумывать проверку таких загруженных файлов на вирусы. И конечно же, надо продумывать правила доступа, кто может писать файлы напрямую, а кто нет. ➖➖➖ Подытожу Первый мы используем когда надо прокидываь низковесные файлы в единственном числе, загружать файлы на диск лучше, когда у вас большой скоуп или вес файлов. Было полезно - ставь 🔥

Я ЖИВОЙ, НЕ ТЕРЯЙТЕ 😄 Так, кажется, я на пару недель выпал из канала и меня даже кто-то успел потерять, но нет, не дождетесь 😎 Я все еще с вами)) А пропал я по хорошей причине. Последние 2 недели с головой ушёл в курс: собрался активный поток, я вёл ребят по этому пути, разбирал их работы, а вопросы сыпались нон-стоп. Признаюсь честно, выдавать такой объем вдумчивой обратной связи на каждую работу и каждому ученику - очень энергозатратно и съедает время подчистую. Потому что я убежден, что если делать что-то, то лучшим образом, поэтому на качественные посты сил не было, а выкладывать что-то на отъ*бись не хотелось. И вот поток уже почти завершен, я немного выдыхаю и возвращаюсь. Тем более, что накопилось много интересных тем, которые стоит разобрать. И первая тема, которой хочу с вами подробнее обсудить - это как правильно формировать ошибки. Очень часто на эту тему забивают и зря, потому что в зависимости от того, как вы проектируете негативный ответ - зависит очень много. Если статья полезна - ставьте 🔥 ➡️ ссылка на статью ➡️ ссылка на статью ➡️ ссылка на статью

Думаю, что уже только ленивый не посмотрел фильм про Platа 😉 Так вот, тут попался пост РО, который ищет к себе в команду джуников. Вдруг вам актуально ➡️ ссылка на пост

АЛЛО ЭТО МОШЕННИКИ? НЕТ, ЭТО HR ИЗ КОМПАНИИ N Последнее время заметил, что HRы и рекрутеры стали звонить просто на телефон, а не пишут в чат или на почту. Первый раз, когда меня так набрали, я признаюсь честно, сильно удивился, потому что с незнакомых номеров часто звонят или мошенники, или реклама. И вот я задумался, почему они вдруг решили звонить? Первая мысль, что они решили проверить не ИИ ли ты случаем. Думаю вы видели приколы, когда ИИ HR разговаривает с ИИ кандидатом 😄 Вторая мысль, возможно это из-за того, что не у всех работает телега, а ИТишники это последние люди, которые пойдут в ВК или MAX. Ну и третья, походу рынок начинает оживать и люди хотят быстрее всех закрыть вакансию. Например, мне вчера позвонила девушка, мы с ней пообщались и через 10 минут от другого рекрутера в чат прилетела та же вакансия. Разумеется я буду общаться с первым человеком. ➖➖➖ Ну и да, это все круто, но как на это реагировать? Первое и главное: не теряйтесь. Если неудобно говорить, то сами переведите на мессенджер, или попросите перезвонить в конкретное время. Мне ни разу не отказывали перейти в тележку. И держите наготове мини-рассказ на 60 секунд про себя, что ищете и на каких условиях.