System Design: проектируем систему бронирования билетов

⏳ 27 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Почему не стоит вытаскивать требования из законов и НПА с помощью ИИ через голый Zero Shot

⏳ 8 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

В комментариях к опросу возник один вопрос по пояснению, что я имею в виду, когда пишу “AI-агенты», небольшое пояснение:

Когда я говорю “AI-агент” — я имею в виду не просто чат с нейросеткой. Это система, которая работает иначе чем обычный ИИ.

Вот три ключевых отличия:

1. Цикл действий — агент не просто отвечает, а действует: планирует → выполняет → проверяет результат → корректирует → повторяет. Это loop, а не одноразовый ответ.

2. Инструменты — агент умеет делать что-то в реальном мире: запускать код, читать файлы, искать в интернете, вызывать API. Он не ограничен текстом.

3. Автономность — вы ставите цель, не инструкцию. Как именно её достичь — агент решает сам.

Грубо говоря: обычный ChatGPT — это умный собеседник. AI-агент — это исполнитель, которому можно делегировать задачу и отойти.

Примеры которые я имею в виду: Claude Code, Cursor, Devin, автономные пайплайны где LLM сам принимает решения.

Не агенты: ChatGPT в браузере без инструментов, обычные чат-боты.

Граница размытая — один и тот же инструмент может работать и как агент, и как обычный чат, в зависимости от того, как вы его используете.

Если есть ещё вопросы — пишите в комментарии, разберём.​​​​​​​​​​​​​​​​

💙 BA|SA | 💬 BA|SA

Салют! Сегодня начну серию постов про AI-агенты✍🏻

Часть 1:

«AI-агенты — это не про чат»

Большинство людей используют ИИ как умный поиск: спросил — получил ответ. Скопировал, вставил, поправил руками. Это полезно, но это не агент.

Агент работает иначе. Вы даёте ему цель, а не инструкцию. Дальше он сам: планирует шаги, вызывает инструменты, проверяет результат, корректирует и идёт дальше. Без вашего участия на каждом шаге.

📝 Как это выглядит на практике

✔️ Я системный аналитик. Даю агенту задачу: проанализируй три версии технического задания, найди противоречия между ними, выдели требования которые изменились, сформулируй вопросы к заказчику.

Агент сам читает документы, сопоставляет, возвращает структурированный результат.
Раньше это занимало полдня внимательного чтения и заметок. Сейчас — 15 минут на то чтобы проверить что он нашёл и добавить своё.

✔️ Или другой пример — мониторинг рынка.

Агент сам обходит несколько источников, собирает данные по заданным критериям, сравнивает и возвращает саммари с выводами. Не идеально — иногда пропускает нюансы, иногда интерпретирует данные слишком буквально. Но 80% работы уже сделано.

🆘 Где агенты реально помогают аналитику или где помогли мне (на начальном этапе)

— Анализ больших документов на противоречия и gaps
— Сравнение нескольких версий требований
— Исследование рынка и конкурентов по заданным параметрам
— Генерация первого черновика процессов и user stories
— Подготовка вопросов к стейкхолдерам на основе документов
— Саммари встреч и выделение договорённостей

Мои советы если только начинаете

1. Начните с задачи которая вас раздражает
Не с самой важной. С той, которую делаете регулярно и которая кажется тупой тратой времени. Эффект почувствуете быстрее всего именно там.

2. Давайте контекст, а не команды
Плохо: “напиши требования к системе”.
Хорошо: “вот описание бизнеса, вот проблема, вот ограничения — напиши требования и задай уточняющие вопросы”. Чем больше контекста, тем лучше результат.

3. Не ждите идеального результата
Агент даёт хороший черновик, а не финальный документ. Иногда ошибается, иногда интерпретирует слишком буквально. Ваша работа — направлять и проверять, а не переделывать с нуля.

4. Встройте в процесс, а не используйте разово
Самый большой эффект — когда агент становится частью рабочего процесса. Найдите одну задачу, автоматизируйте полностью, потом следующую.

5. Контролируйте результат
Ваша экспертиза никуда не девается — она нужна чтобы оценить то, что агент сделал. Особенно на специфичных доменных задачах он ошибается. Доверяй, но проверяй.

Главный сдвиг не в технологии. А в том, что вы начинаете делегировать задачи, а не запросы — и высвобождаете время на то, что реально требует вашей головы.​​​​​​​​​​​​​​​

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Методология «Модель систем»

⏳ 15 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как перестать использовать ИИ как чат-бота и начать автоматизировать рабочие процессы (Workflows)

⏳ 4 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Сегодня хочу напомнить, что у меня выходили посты с вопросами, которые любят задавать на собеседованиях.

Часть 1
Часть 2

В сумме вышло 50 вопросов, с их разбором, также собрала все вопросы в pdf формате, можно скачать, будет полезно))

Готовится вторая часть таких вопросов уже с уклоном на ИИ, покажу, что изменилось и какие сейчас дополнительные вопросы задают на собесах 🧐

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия

⏳ 5 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Где на самом деле лежит правда в работе с требованиями? (Спойлер: не в Agile и не в Waterfall)

⏳ 8 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

«Невидимые требования» — главная причина провала проектов

Салют! Сегодня хочу поговорить о проблеме, с которой может столкнуться каждый аналитик — вне зависимости от домена, компании и стека. Про требования, которые никто не записал. Не потому что забыли. А потому что считали: это и так понятно. Я сама сталкивалась с такой ситуацией и не раз 🥲

Большинство проектных провалов связаны не с техническими проблемами, а с плохо собранными или неполными требованиями. Но когда начинаешь разбираться в таком проекте — почти никогда не находишь явной халтуры.
Люди работали. Митинги проводились. Документы писались. Вроде все гуд, все работали!

‼️ Проблема в другом. Есть целый класс требований, которые не попадают ни в один документ — потому что в момент разговора обе стороны искренне убеждены, что понимают друг друга.

✔️ Заказчик не договаривает детали — он уверен, что они очевидны.
✔️ Аналитик не уточняет — боится выглядеть некомпетентно.
✔️ Разработчик молчит — думает, что аналитик разберётся.

Так рождается иллюзия согласия. Все кивают на митинге. Все расходятся с ощущением, что договорились. А потом, на приёмке, выясняется, что каждый имел в виду своё.

Я называю такие требования - «невидимыми».

Они не злонамеренные и не случайные — они системные. И появляются по трём предсказуемым причинам:

1️⃣ Разрыв контекстов. Заказчик живёт внутри своего процесса годами — для него многое фоновое знание, которое он физически не умеет передать словами. Он не скрывает, он просто не видит, что скрывает.

2️⃣ Разница уровней абстракции. Бизнес думает результатами и процессами. Аналитик — сущностями и логикой. Разработчик — данными и структурами. Одно и то же слово на каждом уровне означает разное.

3️⃣ Социальная динамика. Задавать уточняющие вопросы неловко — кажется, что ставишь под сомнение компетентность собеседника или собственную. Молчание воспринимается как понимание, хотя на самом деле это просто вежливость.

Всё это вместе создаёт среду, в которой невидимые требования не просто появляются — они неизбежны, если аналитик не выстраивает процесс их намеренного извлечения.

Именно об этом хочу написать несколько постов с моими примерами. Не о том, как правильно заполнять шаблоны требований. А о том, как вытаскивать то, что люди не говорят вслух, — методично, без конфликта и без лишних митингов🧐

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Почему я перестала доверять «очевидным» требованиям

Есть одна фраза, от которой у меня теперь непроизвольно сжимается желудок🤨. Звучит она так: «Ну это же понятно, зачем это писать».

За несколько лет в аналитике я слышала её десятки раз — от бизнеса, от заказчиков, от коллег. И почти каждый раз за этой фразой прятался баг. Не в коде. В голове у людей, которые были уверены, что думают об одном и том же.

Расскажу один конкретный случай из своей практики в финтехе.

Мы работали над внутренним порталом для операционного отдела. На установочном митинге руководитель направления сказал:

«Нам нужна кнопка выгрузки отчёта по клиентам»

Коротко. Чётко. Все кивнули — и я в том числе. Требование ушло в бэклог.

Через пять недель разработчики показали готовую выгрузку: все поля на месте, данные корректные, формат .xlsx, скачивается за секунду.

Я проверила — полное соответствие тому, что обсуждали. Передаю на приёмку. Через час приходит сообщение:

«Это не тот отчёт. Нам нужна выгрузка строго по форме № ОП-7 из нашего внутреннего регламента — с группировкой по менеджерам, подитогами по продуктам и отдельной вкладкой для просроченных клиентов».

Про форму № ОП-7 на митинге не было сказано ни слова. Потому что «это же очевидно» 🤯

Две недели переделок. Недовольный заказчик. Разбор полётов с тимлидом. И главное — ощущение, что я подвела команду, хотя сделала ровно то, о чём договорились.

После этого случая я изменила подход к сбору требований. Теперь любое упоминание слов «отчёт», «выгрузка», «уведомление», «форма», «статус» — это для меня стоп-сигнал. Я не иду дальше, пока не получу ответ на три вопроса:

1️⃣ Как это выглядит прямо сейчас? Покажи файл, скриншот, распечатку — что угодно реальное.
2️⃣ Кто это использует и когда? Конкретный человек, конкретная ситуация.
3️⃣ Что произойдёт, если этого не будет? Это помогает понять реальный приоритет и критичность.

Эти три вопроса кажутся простыми — но именно они вскрывают всё скрытое. Форму № ОП-7. Макросы. Регламенты безопасности. Согласования со смежниками. То, что заказчик считает само собой разумеющимся и поэтому не говорит вслух.

Самое неприятное в «очевидных» требованиях — они не выглядят как проблема. Никто не молчит намеренно. Люди просто не умеют видеть границу между тем, что знают они, и тем, что знаешь ты. Это не злой умысел — это разрыв контекстов. И устранять этот разрыв — наша работа, а не заказчика.

Вывод: Документируй не то, что кажется сложным, — а то, что кажется очевидным. Именно там живут самые дорогие ошибки. Один уточняющий вопрос на старте стоит дешевле двух недель переделок на финише. Я убедилась в этом на собственном опыте — и теперь не киваю молча никогда!

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Оживляем диаграммы последовательности: PlantUML и немного кода

⏳ 18 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Проектируем сервис HTTP-запросов: Kafka, PostgreSQL, Redis-очередь и миллионы логических партиций

⏳ 11 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Человек-команда в роли Эйса Вентуры: как с помощью no-code и ИИ собрать простую заявочную систему

⏳ 5 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Story points — прошлый век?

⏳ 8 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Хочу продолжить тему невидимых / очевидных требований, и поделиться еще одной историей с моей рабочей жизни))

‼️ «Сделайте нам заявку» — и два цеха три месяца не могли договориться

До финтеха я работала аналитиком в крупной нефтепереработке — участвовала в проектах автоматизации производственных процессов на заводе. Это совсем другой мир: здесь заказчики — не продакты в кроссовках, а начальники цехов с тридцатилетним стажем, которые привыкли работать в Excel, журналах и телефонных звонках.

Один из проектов — автоматизация подачи заявок на ремонт оборудования. Звучит просто.

Бизнес-заказчик — главный механик — сформулировал задачу так:

«Нам нужно, чтобы заявки на ремонт подавались в системе, а не на бумаге».

Все кивнули. Я записала. Пошли проектировать.

Первое интервью — начальник механического цеха. Рассказывает, как подаёт заявку: звонит мастеру, тот записывает в журнал, передаёт в плановый отдел, те согласовывают с главным механиком. Я рисую флоу, кажется, всё понятно.

Второе интервью — начальник технологического цеха. И тут я понимаю, что он описывает совершенно другой процесс 🤯

У них заявка не на ремонт как таковой, а на вывод оборудования из работы — это требует согласования с диспетчером, технологом и службой безопасности, потому что остановка установки влияет на всю цепочку производства.

Оба называли это словом «заявка на ремонт». Но за этим словом скрывались два принципиально разных процесса: в одном случае — административное поручение внутри цеха, в другом — межведомственное согласование с остановкой производственной установки и рисками для безопасности.

Если бы мы спроектировали одну форму под оба сценария — она не подошла бы ни одному.

Я остановила проектирование и провела ещё четыре интервью — с диспетчером, технологом, сотрудником службы промышленной безопасности и плановым отделом. Попросила каждого показать мне реальный случай: вот конкретная заявка из прошлого месяца — как она шла, кто что делал, где могло застрять.

В итоге оказалось, что под «заявкой на ремонт» на заводе существовало пять разных сценариев с разными маршрутами согласования, разными сроками, разными уровнями критичности и разными ответственными. Некоторые из них пересекались, некоторые — нет.

Я собрала это в карту процессов с разветвлениями по типу оборудования и категории работ. Когда вынесла на общий митинг — начальники цехов впервые увидели процессы друг друга.

Главный механик сказал:

«Я не знал, что у технологов это работает вот так».

‼️ Что этот проект закрепил для меня навсегда:

✅ На производстве слова особенно обманчивы — один термин может означать разное в зависимости от цеха, должности и стажа собеседника.
✅ Всегда проси показать реальный документ или журнал: бумажный процесс честнее любого описания на словах — в нём видны все обходные пути и неформальные договорённости.
✅ Интервью только с «главным заказчиком» — это половина картины. Истина живёт на уровне исполнителей и смежников.
✅ Карта процессов как артефакт работает лучше любого ТЗ на старте — люди узнают себя и сами начинают уточнять и исправлять.

В финтехе за неправильно понятое требование платишь переделкой функции. На производстве цена ошибки — это остановка установки, нарушение регламента безопасности или срыв ремонтной кампании. Ставки другие. Но болезнь та же: «очевидное» требование, которое никто не потрудился проверить.

Вывод: Чем сложнее домен — тем опаснее простые формулировки. Когда опытный заводчанин говорит «ну это понятно» — это сигнал остановиться и спросить ещё раз, но по-другому: «Покажи мне конкретный случай из прошлого месяца». Именно там, в реальном примере, прячется настоящее требование.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA