Analyst Quick

Мы разбирали, какие вопросы аналитик должен задать до проектирования отмены заказа.

Теперь давайте зафиксируем один конкретный сценарий, чтобы не пытаться уместить в одну диаграмму вообще всё.

Допустим, мы договорились о таких правилах:

— пользователь может отменить заказ, пока он не передан в доставку;
— отменяем весь заказ целиком;
— если заказ уже оплачен — нужно сделать возврат денег;
— после этого надо снять резерв со склада;
— в конце пользователь должен увидеть, что заказ отменён.

То есть сценарий уже не выглядит как:

«нажал кнопку → заказ отменён»

На самом деле между нажатием кнопки и финальным статусом происходит несколько шагов.

Участники процесса:

User → Order Service → Payment Service → Warehouse Service → Notification Service

Логика примерно такая:

1. Пользователь нажимает «Отменить заказ».
2. Order Service проверяет, можно ли ещё отменить заказ.
3. Если можно — вызывает Payment Service для возврата денег.
4. После успешного возврата вызывает Warehouse Service, чтобы снять резерв.
5. Затем меняет статус заказа на CANCELLED.
6. И отправляет уведомление пользователю.

Вот здесь и появляется смысл sequence diagram.

Она полезна не потому, что «так принято у аналитиков».

Она полезна потому, что сразу показывает:
— кто у нас инициатор;
— кто за что отвечает;
— в каком порядке идут вызовы;
— где есть точки отказа.

Например, очень быстро возникает вопрос:

А что делать, если деньги уже вернули, а склад не ответил?

И вот это уже нормальный аналитический разговор.

Не про кнопку.
А про бизнес-процесс, статусы и консистентность между сервисами.

Ниже — пример такой диаграммы.

Вчера разбирали задачу:

«Нужно просто добавить кнопку “Отменить заказ”».

Сегодня — что я бы спросил у продакта до того, как открывать Swagger, рисовать Sequence Diagram и думать про API.

Первый вопрос вообще не технический:

1. В какой момент заказ ещё можно отменить?

Пока он создан?
Пока не оплачен?
Пока не собран?
Пока не передан в доставку?

Потому что «отмена заказа» на разных этапах — это уже несколько разных сценариев.

Дальше:

2. Что происходит с оплатой?

Если заказ уже оплачен — мы делаем автоматический refund?

Сразу?
После подтверждения отмены?
А если платёжный сервис не ответил?

3. Можно отменить весь заказ или отдельный товар?

Потому что частичная отмена сразу делает задачу интереснее.

4. Что происходит с товаром на складе?

Если товар уже зарезервирован — снимаем резерв.

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

5. Кто вообще может отменить заказ?

Покупатель?
Продавец?
Поддержка?
Администратор?

И одинаковые ли у них правила?

6. Что увидит пользователь после отмены?

Просто статус CANCELLED?

Или ещё:

— причину отмены;
— информацию о возврате денег;
— срок возврата;
— уведомление.

И один из моих любимых вопросов:

7. А что должно произойти, если что-то пошло не так?

Например:

Order Service отменил заказ.

А Payment Service не смог вернуть деньги.

Какой статус заказа показываем пользователю?

Вот здесь обычно и заканчивается история про «просто кнопку».

---

У меня есть простое правило:

сначала разбираемся с бизнес-сценарием и исключениями, и только потом проектируем API.

Иначе очень легко красиво спроектировать не то.

Завтра попробуем из этих требований собрать сам процесс отмены заказа и нарисовать Sequence Diagram.

— Нужно добавить кнопку «Отменить заказ». Там ничего сложного.

Фраза, после которой системный аналитик обычно понимает, что простого как раз ничего не будет.
Допустим, у нас маркетплейс.
Пользователь оформил заказ и теперь хочет иметь возможность его отменить.

На первый взгляд задача выглядит так:

Заказ → нажали «Отменить» → заказ отменён.

Можно расходиться.

Но потом начинаются вопросы.

А если заказ уже передали в доставку? А если товар уже списан со склада? А если пользователь оплатил заказ картой — когда возвращаем деньги? А если в заказе несколько товаров и отменить нужно только один? А если пользователь два раза нажал на кнопку? А если Payment подтвердил возврат, а Order Service упал? А продавец может запретить отмену?

И вот «добавить кнопку» постепенно превращается в несколько сервисов, статусы, интеграции и пачку пограничных сценариев.

Давайте разберём этот кейс на неделе.

Начнём с самого важного.

Представьте, что такую задачу вам принёс продакт. Какие 3 вопроса вы зададите ему первыми?

Пишите в комментариях. Завтра соберу свой список вопросов, которые я бы уточнил до того, как вообще начинать рисовать схемы и проектировать API.

Аудит ваших навыков: конкуренция выросла, зарплаты замерли.

Всё. Рынок IT в 2026 году окончательно перешел от кандидатов к работодателям. По данным hh. ru, за год количество IT-вакансий в России сократилось на 22%, а число резюме, наоборот, возросло на 23%... Конкуренция? Да, есть. Но не там, где вы думаете.

Спокойно! Задайте три честных вопроса самому себе:

1️⃣ Какие навыки уже стали обязательными на хорошие позиции?
ИИ-агенты, брокеры сообщений (Kafka/RabbitMQ), продвинутый SQL, OpenAPI. Это не "будет плюсом", это спрашивают на собесах в 2026. Если у вас это в списке "знаю, но плаваю" - срочно на прокачку.

2️⃣ Где я реально применяю знания, а не просто галочку поставил?
Теория без проекта = ноль. Компании теперь проверяют не список технологий, а умение решить задачу. Ваш pet-проект или учебный кейс с брокером или OpenAPI весит больше, чем очередной сертификат.

3️⃣ Какой один навык из топ-2026 я выведу из "фронтенда" в "бэкенд" за этот месяц?
Не пытайтесь объять необъятное: выберите Kafka или OpenAPI, или ИИ-агентов - один. И сделайте с ним конкретный мини-проект. Результат: строчка в резюме, которую проверят.

Чек-лист (то, что реально ищут):

✔️API/REST/OpenAPI: встречается в 59% вакансий для джуниоров

✔️Брокеры сообщений: стандарт микросервисов, дефицит понимающих

✔️ИИ-грамотность (агенты, интеграция в бизнес-процессы): уже норма

✔️Платформенность вместо набора инструментов

Всё. Только три вопроса и один фокус.

Как не допустить хаоса на проекте. Часть 2.

После того, как вам кажется, что вы разобрались зачем делается проект, наверняка появится такой коллега, который скажет, что "Мы не согласны".

Уверен, многие из вас сталкивались с этим. Причина этого - неучтенный стейкхолдер.

В этом посте мы рассмотрим, что такое "Карта влияния" и как она сэкономит вам время на проекте.

1. Рисуем в центре листа круг (наш проект).

Вокруг — четыре сектора:
• Решает: Те, кто говорит «Да» или «Нет». Ресурсы, приоритеты.
• Влияет: Те, чьё мнение будет учтено при принятии решений. Эксперты, архитекторы
• Делает : Те, кто непосредственно создаёт результат (разработка, дизайн, тестирование). Важно: здесь же — вы, как аналитик.
• Интересуется (interested): Те, кого нужно ставить в копию, чтобы не было сюрпризов. Смежные команды, поддержка, конечные пользователи, безопасность

Быстрое заполнение:
К кому вы пойдёте за ресурсами? (Решает). Чьё техническое мнение будет ключевым? (Влияет). Кто будет воплощать? (Делает). Кого нужно держать в курсе? (Интересуется). Записываете роли/имена в соответствующие сектора.

Для чего все это делать?

Предотвращение саботажа.

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

Чёткая коммуникация. Вы сразу понимаете:
• С кем согласовывать цели и планы (Решает + Влияет).
• Кого глубоко погружать в детали (Делает).
• Кому отправлять краткие протоколы и заметки (Интересуется).

Экономия времени. Больше не нужно отправлять объемные документы «всеключевым» участникам, половина которых даже не откроет письмо. Фокус — на ключевых персонах.

Этот шаг кажется достаточно очевидным, но его системное применение отличает проактивного аналитика от того, кто постоянно тушит пожары.

Вы не просто фиксируете требования — вы управляете социальной структурой проекта.

Как не допустить хаоса на проекте. Часть 1.

Уверен, у каждого было такое, что к вам обращается продакт или заказчик, говорят вам: "нужно сделать это, это, это и тут добавьте кпопку и надо сделать это за неделю".

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

Задача любого аналитика отсеять шум и хаос и найти в нем смысл.

Самый главный вопрос, который должен задавать аналитик - "Зачем?".

Этот вопрос поможет отсеять вам большую часть лишних задач. Вы спрашиваете "Какую проблему мы решаем", "Как мы поймем, что проект успешен".

Давайте рассмотрим конкретные примеры:

1. Вам несут "готовое решение"
Что говорят: «Хотим добавить в CRM ИИ-чат-бота для менеджеров».
Что спрашиваете вы: «Отлично, а что должно измениться после этого?».
Что может выясниться: Настоящая боль в том, что менеджеры тратят время на поиск истории общения с клиентом в трёх разных системах. Бот здесь не поможет — нужна просто единая карточка клиента с агрегированной историей.

2. Требования противоречивы
Контекст: Маркетинг хочет, чтобы регистрация была в один клик через соцсети, служба безопасности настаивает на обязательной двухфакторной аутентификации.
Ваш вопрос: «Что для нас важнее на этом этапе — максимальная конверсия в регистрацию или минимизация риска мошеннических аккаунтов?»
Результат: Приоритет становится явным, и часто находится компромисс: быстрая регистрация для новых пользователей плюс 2FA, которая включается позже — при первой финансовой операции.

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

Как проводить свою ретроспективу

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

Перед тем, как приступить к новой задаче, советую отрывать вам базу знаний в любом редакторе (notion, obsidian и т.п.) и отвечать на три следующих вопроса:

1️⃣ Что сработало хорошо?

LLM сгенерировала PlantUML с 1 раза, значит сохраняем шаблон промта.
У разработчика не возникло вопросов по документации API , значит используем шаблон документа в следующих задачах.

2️⃣Что пошло не так и как исправлю в следующий раз?

Не сразу учли, что склад не умеет отдавать статус по одному заказу, значит добавляю вопрос стейкхолдерам "Какие эндпоинты уже есть?"

3️⃣ Какую одну практику заберу с собой?

Всегда рисовать Sequence Diagram до контракта — иначе команды путаются в ответственных

Обязательно добавлять обязательные поля в OpenAPI, чтобы не получать сюрпризы от бэка

Что получается в итоге:

После такого 15-минутного разбора у вас появляется живой шаблон, который вы дополнянте от проекта к проекту.

Теперь, берясь за новую интеграцию, вы открываете этот чек-лист и не наступаю на старые грабли.

Run-деятельность

Сегодня разбираем термин Run-деятельность.
Это все те задачи, которыми мы с вами занимаемся между крупными проектами, но не придаем им особого значения.

📊 Ключевые признаки Run-задачи:

• занимает немного времени

• по итогу задачи: система вернулась к норме или вопрос закрыт

• не меняет архитектуру, не добавляет больших фич

Для БА — это уточнить требование у заказчика, объяснить реализацию команде, скорректировать описание в BRD, поправить метрики бизнеса

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

Как генерировать BPMN диаграммы и редактировать их без XML

Одной из фишек последнего времени является генерация ответа нейронки в виде html-файла. Чтобы не копировать какой-то код, вставлять его в IDE, сейчас можно просить ИИ давать ответ в виде html.

Теперь мы можем генерировать красивую и интерактивную документацию на любую тему.

В случае BPMN мы можем сгенерировать не только диаграмму, но и страницу со встроенным редактором.

Как мы знаем, в выдаче LLM могут быть мелкие недочеты, которые проще поправить руками, чем убедить переделать ИИ. Поэтому строим такой воркфлоу: ИИ делает диаграмму, показывает нам сразу в редакторе и с кнопкой "Сохранить". Мы немного меняет диаграмму, как нам нужно, и сохраняем в файл .bpmn

Возможно, так и будут выглядеть интерфейсы будущего, когда редактор генерируется сразу под формат редактируемых данных.

Причем, что удивительно, качество кода самой диаграммы становится лучше — возможно, это связано с внутренней проверкой кода, а может, просьба сгенерировать код активирует какие-то слои нейросети, позволяющие лучше работать и с файлами XML.

Запрос при этом используется самый примитивный:

Опиши процесс согласования документов в крупной организации, организованной иерархически (управления, отделы, руководители и т.п.). Результат представь в виде модели бизнес-процесса в BPMN, размещенного на html-странице. Используй библиотеку bpmn.js

Результат, наконец-то, выглядит довольно прилично. А мелкие детали можно быстро поправить вручную.

Умеет ли LLM работать с бизнес-процессами?

Интересные материалы на темы: автоматизация бизнес-процессов и генерация BPMN-диаграмм через ИИ.

📍Внедрение ИИ в бизнес: где он реально окупается и как автоматизировать бизнес-процессы Прикладная статья с систематизацией сценариев, где ИИ работает успешно и где не стоит спешить с его применением.

📍Сравнение LLM по навыку анализа бизнес-процессов Статья с результатами исследования, которое автор делал для того чтобы выбрать "лучшую" LLM для конкретной коммерческой платформы и в итоге решил опубликовать. Есть интересная сравнительная таблица разных инструментов.

📍Говорят ли LLM на языке BPMN? Оценка их возможностей моделирования процессов на основе качественных метрик Большая переводная статья с результатами исследования. В исследовании представлена систематическая оценка пяти инструментов на основе LLM, предназначенных для генерации моделей BPMN из текстовых описаний процессов. Читается сложно, написано в академическом стиле, но может быть интересно тем, кто в поиске инструмента для генерации диаграмм.

📍Пост в канале “Системный сдвиг”, где автор поделился промптом для генерации BPMN.

📍Подборка о работе с процессами Еще одна подборка об управлении процессами в этом канале, может быть полезна, если вам интересна эта тема.

​​📑 Требования в Agile: полный гайд с работающими практиками

Автор- Сергей Прощаев, Tech Lead и руководитель направления Java | Kotlin разработки в FinTech:

"Сегодня хочу поговорить о теме, которая, казалось бы, лежит на поверхности, но именно в ней чаще всего тонут проекты и страдает разработка. О работе с требованиями. Точнее — о том, почему их нельзя «собрать» раз и навсегда и почему Agile‑требования ничем принципиально не отличаются от любых других, как бы их ни называли."

Читать статью

Пять советов, которые помогут не утонуть в документах и выжать из них максимум:

1. Составьте список источников заранее. До того, как открыть первый документ, определите, что именно вы ищете. Запросите у заказчика перечень материалов с кратким описанием каждого.

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

3. Фиксируйте выдержки и гипотезы. Заводите рабочий документ или таблицу, куда выписываете ключевые требования, термины, противоречия и вопросы. Это станет основой для дальнейшего обсуждения с экспертами.

4. Ищите несоответствия. Обращайте внимание на места, где документ расходится с реальностью или противоречит сам себе. Это золотая жила для уточняющих вопросов на интервью.

5. Проверяйте актуальность. Смотрите на даты, версии, отметки о введении в действие. Если документ старый, отметьте его как «требующий валидации» и проверьте информацию у экспертов.

Итог: Анализ документации - фундамент, на котором строится понимание проекта. Этот метод редко работает в одиночку, но без него любое интервью или воркшоп рискуют превратиться в обсуждение того, что уже давно написано в забытых регламентах.

Постепенно буду рассказывать подробнее о фичах моего сайта analystquick.tech, чтобы вы понимали, какие плюсы вы можете получить, покупая подписку за 650 рублей в месяц.

Сегодня хочу продемонстрировать, как можно создавать гайды или целые курсы по интересующим вас темам всего за один незамысловатый промпт

Для примера решил взять UML Sequence диаграмму, которая используется повсеместно.

Промпт был следующий: "Создай мне гайд на тему UML Sequence диаграммы с учетом того, что мои знания в UML на уровне новичка"

Ссылка на гайд от ИИ Analyst Quick по теме UML Sequence

Что касается курса, ИИ сделал курс, состоящий из трех модулей:

Модуль 1: Введение в мир UML и визуализации взаимодействий
1. Что такое UML и зачем он аналитику?
2. Sequence диаграмма: Суть и аналогии из жизни
3. Базовые элементы диаграммы: Акторы, Линии жизни, Сообщения
4. Инструменты для рисования: от простых до профессиональных

Модуль 2: Строим первый сценарий взаимодействия
1. Простой поток: Успешная авторизация пользователя
2. Ветвление логики: Операция с проверкой условий (Alt/Opt)
3. Циклы и повторения: Загрузка списка товаров с пагинацией
4. Асинхронное взаимодействие и таймауты

Модуль 3: Sequence диаграммы в контексте современного IT
1. Моделирование REST API вызова
2. Диаграмма для событийной архитектуры (Kafka-like)
3. Паттерн BFF (Backend For Frontend) на Sequence диаграмме
4. Взаимодействие с внешними системами и ошибки

Модуль 4: От диаграммы к требованиям и дизайну
1. Реверс-инжиниринг: Составление диаграммы по описанию бизнес-процесса
2. Sequence диаграмма как часть спецификации API
3. Выявление нефункциональных требований через диаграмму
4. Оптимизация дизайна системы на основе диаграммы
5. Итоговый проект: Диаграмма для микросервисного сценария

По каждой теме ИИ генерирует подробные статьи, на основании которых вы можете изучать теоретические материалы, которые затем сможете закрепить, выполняя практические задания, которых сейчас на сайте около 20 (и постоянно пополняется)

Хочется отметить, что аналогичные курсы по UML стоят от 5-6 тысяч рублей, а на analystquick.tech покупая подписку всего за 650 рублей вы получаете ВСЕ доступные материалы.

В сегодняшнем посте рассмотрим то, как происходит взаимодействие аналитика с разработкой.

Эту информацию всегда спрашивают на собеседовании и в целом она будет полезна и начинающим аналитикам

При взаимодействии с разработчиками важно:

1️⃣ Описать требования понятно и качественно

2️⃣Собраться с разработкой на обсуждение требований

3️⃣Получить от них обратную связь и внести правки, если возникли какие-то уточнения в процессе обсуждения

4️⃣В процессе разработки быть на связи, отвечать на уточняющие вопросы, если такие будут.

Важно уметь расположить команду к себе, чтобы к вам спокойно могли подходить с вопросами

Конкретно на собеседовании важно рассказать следующее:

1️⃣Сколько разработчиков в команде и каких

2️⃣Какие артефакты готовили для разработчиков

3️⃣В каком виде ставили задачи

4️⃣Как обсуждали и оценивали задачи с разработчиками

5️⃣Как контролировали выполнение и консультировали в процессе

6️⃣Как осуществляли приемку

Курсы по системной аналитике по цене двух чашек кофе — analystquick.tech