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

ТЕСТОВОЕ ЗАДАНИЕ БОЛЬШЕ НИЧЕГО НЕ ДОКАЗЫВАЕТ Раньше тестовое было самым дешевым фильтром на найме. Схема простая: даешь кандидату кейс, например, у тебя есть две системы и ему надо описать интеграцию, наикдать методы API, нарисовать sequence. Что еще не маловажно - это еще и скоростной способ проверки. Можно просмотреть десять работ за час и в среднем троих позвать дальше на разговор. Что происходит сейчас? Приходит десять одинаково приличных работ. Очень похожие user story, грамотные формулировки и все как под копирку. А почему? Потому что ИИ сломал этот фильтр, так как любой худо-бедно прошаренный кандидат пользуется ИИ-шкой. И это не хорошо и не плохо, но теперь, если ты нанимаешь аналитика, то такой отбор ну вообще ничего не показывает. А что делать? 1️⃣ Давать такие задания, но вычислять ИИ-шные ответы от обычных. Например, по кавычкам-елочкам, длинным тире и "важно отметить". Но к сожалению, такой подход тоже не работает. Потому что если слегка поправить текст или явно прописать, чтобы ИИ-шка не писала эти маркеры и руками поправить текст, то ни один детектор, включая человеческий не отличит текст. Это, кстати, подтверждают ребята из штатов, которые в Университете Мэриленда провели такой эксперимент. Поэтому, зарубежные компании уже внедряют другой подход и думаю наши тоже скоро подтянутся. 2️⃣ Они просто начинают на техническом интервью просить кандидата показать, как он через ИИ, будет решать задачку. Например, просят запустить Copilot, Cursor, Claude и погнали. Логика у них простая - кандидаты итак делают это скрытно, а без ИИ не видно, как человек реально работает, а если сразу начать работать через ИИ-шку, то можно понять ход мысли и как человек умеет работать и с инструментом, и как он критически мыслит, как формулирует задачи и так далее. Еще читал, что в Shopify вообще пошли дальше и просят сразу показать инструменты, которыми пользуется человек. Какие у него есть скиллы, как он с ними работает. Ну и конечно, начинают возвращать очное общение в офисе, как в старые добрые, чтобы увидеть реального человека без всяких обвесов. Так что теперь думаю не стоит удивляться, если вас позовут в офис на какой-нибудь из раундов, потому что просто артефакт, сделанный без наблюдения, больше ничего не значит. Как это было раньше. ➖➖➖ И ключевое Если раньше закрывали глаза и спрашивали типовые кейсы, то теперь смотрят и копают вглубь, что бы понимать, как думаете и что реально имеете в виде практического опыта. Нанимать так дороже. Несколько минут чтения тестового превратились в час живого разговора с каждым, но других вариантов я пока не вижу. Поэтому, если вы готовитесь к собеседованию, то знайте, что теперь ценят умение объяснить каждое свое и не свое решение: почему так реализовали, где ИИ ошибался и что вы за ним поправили. Было полезно - ставь 🔥 ➖➖➖ Подписывайся на резервный канал, чтобы не потерять 💙 я в ВК | 🇷🇺 я в Макс

Ну что? Сегодня уже пятница и вот я возвращаюсь с постом на тему - что можно прокачать, чтобы быть в теме AI first и чтобы вы были не просто пользователи АИ-шки, а вообще понимали, что вы делаете и на какие навыки смотрят люди. В основном, конечно, это разбито за рубежом, а вот у нас, наверное, еще не так, но хотя всякие большие финтехи, типа Сбера и того же Райфа, уже рассматривают эту тему. В целом, все скиллы, которые вам нужны для того, чтобы быть AI-Native, можно посмотреть на картинке к этому посту и из них нужно понимать и знать хотя бы 3-4, но чем больше, тем лучше. ➖➖➖ Основное большинство пользователей обычно зависает на двух топовых: Claude и ChatGPT, а какие-то альтернативы не рассматривают: тот же QWEN, тот же Kimi и другие LLM-ки, которые можно использовать в работе. Дальше Вы умеете создавать и использовать скиллы, не только Claude, вообще скиллы, и понимаете, вообще что это такое и на что они влияют. Крутая штука с которой я до сих пор борюсь и прокачиваюсь - второй мозг. Тут можно почитать про GBrains и Obsidian. Следующая штука, которая очень важная на мой взгляд, написана вот так: «Вы ведете и обновляете CLAUDE.MD». Понятное дело, что у Codex это его AGENT.MD, но то, с чем мы столкнулись для того, чтобы не жрать токены, приходится прям хорошо работать с этим файлом, чтобы ничего лишнего туда не попало. Ну и, конечно же, куда же без наших интеграций. Обычно, если раньше у нас все требовали умения работать с API, подключать их, то здесь нам важно уметь не только работать с самим API, но еще и уметь работать с MCP: • уметь их подключать, • настраивать, • понимать вообще, что такое токенизация, • как это все работает. А остальное уже по мелочи. То есть уметь управлять контекстом, например, не писать, как я в прошлом посте писал, все в одном окне, создавать проекты, уметь создавать различные рутинсы, подключать различные коннекторы, которые вы можете. Ну и последнее, что самое важное, наверное, будет в будущем, это все-таки умение экономить токены, потому что сейчас я думаю, вы слышали миллионы вообще историй уже про то, как чуваки спалили токены очень-очень быстро и потратили там бюджет годовой за один месяц. Вот такие вот 9 основных навыков, которые хочет видеть рынок. Поэтому прокачивайтесь вообще, смотрите, чекайте, что вы знаете, что не знаете, и развивайтесь в этой теме. Скорее всего, как бы мы ни хотели, это в той, либо иной части, к нам точно придет. И про себя могу отметить, что уже навыки, работа с таким набором вещей мне помогают достаточно хорошо ускорить мою работу. Ну и вопрос, конечно же, к вам Кто этим пользуется, не пользуется? Вы сколько уже навыков из этого используете в работе?

5 ОТВЕТОВ, КОТОРЫЕ ВЫДАЮТ, ЧТО ВЫ НЕ ШАРИТЕ ЗА ИИ, А ПРОСТО ОБЫЧНЫЙ ПОЛЬЗОВАТЕЛЬ Недавно был на вебинаре у Ai-First агенства. Ребята делают крутые штуки. Например, парсят linkedIn и HH и вообще все, что только можно для того, чтобы закрывать вакансии, где требуются крутые спецы. Так вот, понравился комментарий владелицы про то, что AI прошареным чувакам готовы платить больше, чем обычным спецам процентов на 20-30, нооооо при этом часто такие люди валятся на простых рассказах о том, как они используют ИИ в работе. И вот они 1. Пользуется только веб-чатом; 2. Один огромный диалог на все; 3. Вставляют секретные ключи прямо в чат; 4. AI все сделает за меня; 5. Бесплатной версии достаточно. Звучит банально, но блин, реально. Очень многие мои знакомые действительно так и делают. Просто юзают GPT и скидывают туда все. При этом это очень крутые ИТ профи. Поэтому, не делайте так 😉 Кстати, интересно узнать на что стоит сделать упор, чтобы прокачать себя в ИИшности? Тоже в этой презе было. Ставь 🔥, если да

🔥 СРОЧНЫЕ НОВОСТИ 🔥 Друзья, расскажу, какие планы у меня по запуску курсов в этом году ➡️ ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API 21 сентября стартует последний поток этого года. Если планируете учиться — самое время определяться, особенно, если хотите пройти обучение через работодателя, потому что процесс оформления документов небыстрый, так что инициировать его лучше уже сейчас. ➡️ БД (базы данных и основы SQL) Курс, который традиционно запускался раз в год, в конце октября. В этом году решение такое: набора для всех не будет. На БД смогут попасть только те, кто прошёл интеграции — у вас уже есть контекст и понимание концепции, без этого разобраться в БД будет сложнее. Новых курсов пока не планирую. Хочу сосредоточиться на том, чтобы: — улучшить текущий курс по интеграциям; — проработать тему с ИИ — сейчас это требуется почти везде, AI First компании ждут, что вы понимаете, как работать с ИИ. Хочу, чтобы вы могли этому научиться. Что можно сделать прямо сейчас? ✔️ Хотите на курс по интеграциям? Записывайтесь в лист ожидания на сайте курса. Те, кто в листе, получают лучшие условия. Старт продаж — середина августа. ✔️ Планируете оплату через юрлицо? Ждем запрос от работодателя на почту info@proanalitika.ru ✔️ Хотите на курс по БД? Предложение пришлю в чате учеников в ближайшие 2 недели

Очень часто вижу новости о том, что свершилось чудо и в HTTP протоколе появился новый метод - QUERY. Если так подумать, то это не сильная революция, но она сможет снять головную боль в кейсах, когда вам надо было сделать гигантские фильтры. ➡️ Почитать про метод можно тут Интересно, как быстро его начнут внедрять в проекты, что думаете?

Вчера наткнулся на классичейский кейс, который любят давать продакты на интервью, после технички. Звучит так: "Хочу, чтобы каждое утро у меня на столе лежал бутерброд. Как ты это реализуешь?" Кому попадался такой кейс - ставьте 🔥 Что обычно делает аналитик? Правильно, идет копать эту тему и начинает мучать продакта. - Какой хлеб, - какая начинка, - во сколько положить, - кто готовит, - что с бутиком делать в выходные. Ну вы поняли, то есть начинает собирать контекст. Однако, это типичная ситуация на которой вы завалитесь, потому что не надо сразу бежать и крафтить бутики, пока не поймете, а ЗАЧЕМ он хочет его получить. ➖➖➖ Что нам надо выяснить в самом начале? Почему бутерброд? Это можно делать через пять ПОЧЕМУ. Исходя из ответов, уже будет понятно, что с этим делать. Действительно нужен бутер или может быть нужен комплексный завтрак, а может быть нужно альтернативное решение и вообще надо такси заказать и в рестик отвезти. Ну вы поняли 😉 Когда понятно стало зачем, допустим, хочет сытно завтракать, начинаем углубляться и выяснять глубинные потребности: ✔️ Какая цель? Что он этим завтраком хочет получить? Взбодрится, отвлечься, что-то еще. ✔️ Что для него "сытный завтрак"? ✔️ Есть аллергии, ограничения, рекомендации врача? ✔️ Во сколько он в офисе и обязательно ли еда должна ждать на столе? ✔️ Кто это готовит, заказывает и оплачивает? Поняв ответы на все вопросы, в итоге у вас вряд ли по итогу окажется бутерброд 😁 У вас будет совершенно другое решение. ➖➖➖ Подытожу 2 мыслями: ✔️ Если вам задают такие абстрактные вопросы на собесе, то не бегите вперед паравоза и не сразу решайте задачу, а повыясняйте. ✔️ Когда мы работаем в проектах, очень часто при интеграциях всплывают такие хотелки заказчика. Только они не выглядят, как бутик, а просто заказчик приходит не с потребностью, а с готовым решением, например, "сделай мне выгрузку в Excel", "прикрути вебхук", "добавь поле status". При этом часто, то что он себе придумал делать - ну вообще не надо и это так не работает. Поэтому не тащите в разработку первое, что озвучил клиент, а отделить его решение от настоящей потребности.

Всем спасибо за участие 🔥 Вы капитальные красавчики и красавицы! [Условия задачи здесь] Поехали 🚀 Что мне понравилось из ваших ответов: 1. Почти все нашли бесконечный цикл на схеме; 2. Дубль задачи "Проверить оплату"; 3. Неподписанные ветки у шлюза "Оплата есть?"; 4. Менеджер запустил процесс, а ответного действия у него нет. В целом, это закрывает практически все. Но я чуть-чуть дополню мысли. ➖➖➖ Был комментарий, что с точки зрения логики все ок, а вот с точки зрения схемы - нет. Если нас просят разробрать на собеседовании именно схему, то обычно хотят понять: ✔️ понимание поведения, ✔️увидеть понимаете ли вы ошибки на самой схеме или нет. ✔️ шарите ли вы за BPMN, в целом, но если вы еще найдете ошибку в логике, то это будет супер 🔥 Теперь к схеме. ✖️ Первое, что мне не нравится на ней, в целом нейминг: "Нужно проверить факт оплаты." Это бантик, но лучше писать: «Проверка оплаты». Или вообще, это вынести в название схемы. ✖️ Дальше, самая главная ошибка, бесконечный цикл, в случае, если оплаты нет. В ветке с таймером. Если клиент вообще не делал оплату, то и бухгалтер устанет проверять, и менеджер будет в неведении и будет слать повторные запросы. Поэтому тут нам нужно сделать или поток со счетчиком (сколько мы можем сделать проверок, и после нескольких ретраев уведомлять менеджера, что оплаты нет). Либо, я бы вообще убрал такой цикл и просто проверял бы есть оплата или нет и отдавал сразу ответ менеджеру без доп проверок. И вообще убрал этот не нужный цикл. Понятное дело, что для того, чтобы сделать финальное решение, надо понимать еще бизнес-контекст, зачем тут таймер. Но все же, люблю процессы с наименьшим сопротивлением. Поехали дальше. ✖️ Еще одна из ошибок - это то, что у процесса всегда есть только один конец процесса. То есть пока мы оплату не получим - процесс не завершится. Тут стоит добавить еще выход в случае, если оплата не получена. В принципе это вытекает само собой из предыдущего пункта. ✖️ Еще один глобальный косячек состоит в том, что задачу инициирует Менеджер, но закрытие процесса происходит на уровне Бухгалтера, а при этом менеджер остается в неведении. По -хорошему, нужно добавить действие на уровень Менеджер. Например, "Обработка ответа от Бухгалтера" и уже на его уровне сделать, если оплатил, то закрыть процесс, если не оплатил, то завершить процесс с негативным сценарием или отправить повторный запрос. ➖➖➖ Дальше будут чисто визуальные мелочи, но на собесе за них могут зацепиться. ✖️ Ветки шлюза не подписаны. Там где стоит IF на вопрос Оплата есть, нет подписи да/нет. ✖️ Две одинаковые "Проверить оплату" В идеале цикл должен возвращаться к существующей задаче, а не к копии, но если схема сложная и громосткая, то такое допустимо. ✖️ Название действий немного длинные. "Запросить у бухгалтера проверить оплату" можно заменить на "Запросить проверку оплаты". На этом пожалуй все. Было полезно - ставьте 🔥 и я разберу еще какую-нибудь задачку.

Давненько у нас с вами не было задач 😉 Последнее время мне часто попадаются задачки на BPMN на собесах у СА. Честно, не знаю с чем связано, возможно у всех CAMUNDA завезли, но все же, давайте покрутим задачку 🔥 Ваша задача - найти, что не так с этой схемой Погнали 🚀

Почему 6 TCP-соединений, а не 4? В посте про HTTP/1.1 и HTTP/2 прилетел классный вопрос: почему на схеме HTTP/1.1 стоит 6 TCP-соединений, а не 4, если запросов всего 4? Давайте разбираться ➖➖➖ Начну с того, что цифры 4 и 6 на картине - это про разные вещи. Цифра 4 - это сколько запросов шлет страница в примере из поста. 6 - это лимит браузера, т.е. сколько параллельных TCP соединений он готов открыть К ОДНОМУ ХОСТУ. В Chrome и Firefox по умолчанию их как раз 6. И тут пожалуй надо дать пояснение, ЗАЧЕМ вообще открывать несколько соединений? Помните, что когда я приводил примеры, то я сказал что в HTTP/1.1 одно соединение - это одна однополосная дорога, где машины едут строго друг за другом, один запрос за раз. Теперь представьте, что нам нужно передать данные параллельно. В этом случае браузер откроет несколько TCP соединений. И максимальное количество будет равно 6 на один хост, то есть фактически у нас есть 6 дорог. А что будет, если запросов будет 20? То в этом случае у нас откроется 6 соединений, а остальные 14 будут ждать на обочине, пока освободится любая из дорог. Надеюсь с аналогией стало понятно? Если по схеме остались вопросы - кидайте в комменты, разберем.

Люблю элегантные решения на экранах ошибки и на видео одно из них 😉 Это в мобильном приложении Дом от ГосУслуг такая милая идея. Единственное, когда я первый раз увидел этот экран, то знатно завис, потому что на экране не работали стандартные паттерны, например, скрол вниз. Поэтому, когда проектируете какие-то экраны, то не забывайте про поведение пользователя 😉 Кстати, как вам такая идея и чтобы вы, как СА добавили, чтобы улучшить UX для пользователя?

5 КНИГ, КОТОРЫЕ Я ХОЧУ ПРОЧИТАТЬ В 2026 ГОДУ ПО СИСТЕМНОМУ АНАЛИЗУ Если бы меня спросили еще год назад, что почитать, чтобы прокачать себя в теме СА, то я смело бы назвал неизменную классику: 1. Software Requirements — Карл Вигерс, Джой Битти 2. Writing Effective Use Cases — Алистер Коберн 3. User Story Mapping — Джефф Паттон 4. Clean Architecture — Роберт Мартин 5. И что-нибудь вроде паттернов проектирования. Но не в этом году С учетом того, что у нас все больше становится популярен подход, когда мы используем ИИ, работаем с Event-Driven Архитектурой, уже надо классику знать, а читать что-то новенькое. Вот открыл для себя такую подборку: 1. AI Engineering. Chip Huyen (2025) Как устроены системы на LLM: RAG, агенты, оценка моделей. 2. Designing Machine Learning Systems. Chip Huyen (2022) Полный цикл ML в продакшене: фичи, пайплайны, дрейф, мониторинг. 3. Software Architecture: The Hard Parts. Ford, Richards, Sadalage, Dehghani (2021) Про сложные компромиссы в распределённых системах. 4. Team Topologies. Skelton, Pais (2019) Книга про фреймворк организации команд, предназначенный для улучшения производительности и достижения более высокой гибкости в разработке и внедрении продуктов и услуг. 5. Building Event-Driven Microservices. Bellemare (2020) Кто хочет понять асинхронщину вариант отличный. Я пока на 3-ей книге, 5-ую читал. А вы что сейчас изучаете? Что почитываете? Посматриваете? Поделитесь в комментариях, плиз. Ну и если было полезно, то ставим огонецкий 🔥

ТАЙМ-АУТЫ. ЧЬЯ ЗОНА ОТВЕТСВЕННОСТИ? АНАЛИТИКА ИЛИ РАЗРАБА? Очень часто я встречаю ситуацию на ревью, да и просто при обсуждениях, когда пропускают тему таймаутов. Чаще всего их втыкают везде по умолчанию и тянут из конфига. Но бывают ситуации, когда просто отдать на откуп разрабу эту тему - не самая лучшая затея, потому что это может стоить вам кучи времени. Был у нас как-то кейс на мобильном проекте: 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а 😉 Так вот, тут попался пост РО, который ищет к себе в команду джуников. Вдруг вам актуально ➡️ ссылка на пост