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

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

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

Сохраняйте, чтобы не потерять!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постепенно буду рассказывать подробнее о фичах моего сайта 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. Ищите несоответствия. Обращайте внимание на места, где документ расходится с реальностью или противоречит сам себе. Это золотая жила для уточняющих вопросов на интервью.

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

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

Spec Driven Development

После того, как появился вайбкодинг, энтузиасты обнаружили, что просто промпт “сделай хорошо” для сложных задач не работает. А если после первой версии попросить модельку что-то доработать или поправить, то она начинает ломать старый код.

Так родилась идея, что на вход нужно давать более конкретные описания, а после контролировать действия агента. В итоге пришли к флоу:

Описываем хотелки —> Проектируем —> Декомпозируем —> Реализуем

Что-то знакомое? Почти как с людьми, только с агентами. Назвали подход Spec Driven Development.
Пока это лишь общая концепция, а не что-то конкретное. Нет единой терминологии, общих правил, принятых практик.

Наиболее популярные инструменты:
• SpecKit — от гитхаба
• Kiro — от амазона
• OpenSpec — опенсорс

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

Про реализацию SDD в SpecKitl: часть 1, часть 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Немного о реальной оценке сроков 😁

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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