Системный анализ | Ольга Пономарева

Когда анализа уже достаточно?

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

Команда читает и спорит

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

"Лучше проработать все мелочи"
Подробная спецификация снижает неопределённость. Разработчику не приходится додумывать, что делать в редких сценариях, а бизнесу проще заранее увидеть, как будет вести себя система. Лучше потратить время на анализ сейчас, чем обнаружить неоднозначность уже после реализации

А вы до какой степени детализируете свое описание? Где для вас проходит граница между "хорошо проработал" и "переработал"?

Так выглядит

"Нужно просто добавить одно поле"

😏

Иногда это действительно небольшая доработка. А иногда после этой фразы аналитик начинает выяснять:

🥰 откуда берётся значение поля
🥰 обязательное оно или нет
🥰 что делать со старыми записями
🥰 как его воспримут старые версии клиентов
🥰 в какие смежные системы его нужно передать
🥰 кто и по каким правилам будет его заполнять

И внезапно одно поле затрагивает базу данных, API, фронтенд, миграции, тесты и документацию

Было у вас такое, что скрывалось за «маленькой доработкой»?
Рассказывайте самые эпичные случаи в комментариях 👇

Я не всегда делюсь на этом канале своим личным, но про визу в Великобританию не могла обойти стороной! 😅

Пишите рекомендации по UK в комментариях)

А если хотите больше видеть моей жизни, то велком на канал "Сегодня с Олей". Скоро полечу в Японию и Корею - буду делиться)

И кстати!
Мне выдали визу в Великобританию на полгода. Да уж, мои мечты полететь в нее на свое др 5 августа не оправдались, придется лететь в самую ужасную осеннюю или зимнюю погоду😊

Принимаю рекомендации по UK в комментариях)

Что делать, если один и тот же файл нужен всем ❓

💬 Немного контекста задачи: на образовательной платформе автор загружает видео, презентации и дополнительные материалы к курсу. Сейчас файлы хранятся на серверах приложения, но платформа начинает разростаться:
- одновременно курс могут проходить до 20 000 студентов, что влечет за собой просмотр одного видео тысячами пользователей одновременно;
- автор может заменить файл, пока студенты продолжают пользоваться курсом;
- файлы нельзя делать публичными по прямой ссылке.
Команда обсуждает архитектуру хранения.

Что выберете? И самое главное, почему? Пишите в комментариях 👇

Уже завтра прозвенит звонок на первые уроки курса "Архитектура систем. База"

Для тех, кто еще принимает решение, хочу сообщить, что осталось 4 места на текущий поток!

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

📱 Смотреть обзор на YouTube
📱 Смотреть обзор на VK Видео

А еще важно уточнить, что домашки на наших курсах - дело серьезное. В них и есть основная ценность обучения. Но, естественно, заставить делать их не можем

Тут делились реакцией ученика на домашку и общее мнение о воркшопах прошлого потока!

Успевайте принять участие и придти на первые уроки уже завтра:
https://systemanalyst.life/architecture

Реальная домашка ученика. Найдёте ошибку?

Наши эксперты проверяли домашку на курсе «Архитектура. База» и решили принести нам один реальный кейс. Задание было следующее: разбить образовательную платформу на DDD-поддомены и определить тип каждого поддомена. Фрагмент ответа представлен в фото

Задача
В этом ответе есть 2 технические ошибки по DDD. Попробуйте найти их в комментариях. Спойлер: ошибки не в названиях поддоменов, а в логике определения их типа.

Первые, кто найдёт обе ошибки и объяснит почему, наш почет и уважение ❤️
А для кого было трудно - ждем на курсе "Архитектура.База" уже в понедельник

Кстати, в тему завтрашнего воркшопа и как ИИ разгружает рутину, не только рабочую, но и помогает в жизни!

Я планирую путешествие в Японию, и не могла не воспользоваться тем, что как раз будет на воркшопе: я выгрузила из тг-канала блогера места по японии, попросила сформировать локации (бары, шопинг, парки и т.д.) прям на гугл-карту

получилась просто супер крутая гид-карта

так что применять можно навыки с воркшопа не только в работе!

А вообще считаю, что я капец лайфхакер по путешествиям! Обращайтесь 😅

⚡⚡ ХАБР ВСЁ

Виктор Шариков, админ нашего чата по ИИ и автор воркшопа "Вайбкодинг для аналитика", создал базу знаний на основе самых топовых телеграм каналов по системному анализу!

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

🚀 ВЫ СМОЖЕТЕ ДЕЛАТЬ ТАКЖЕ, если посетите воркшоп, который стартует уже завтра

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

За два практических дня обработаем переписку с помощью ИИ, выделим полезные темы и решения, соберём базу знаний и превратим её в сайт с поиском, навигацией и авторизацией

Зачем мне делать тоже самое, если могу просто воспользоваться готовым?

Навык можно применить у себя в работе, где много неструктурированной информации или в чате много обсуждений. Можно монетизировать навык и получать доп доход вне работы. Да или просто научиться вайбкодить, понять принцип и механику, чтобы выделяться в компании (тут писали об этом)

📅 5 и 12 сентября, с 12:00 до 17:00 МСК

➡️ Посмотреть программу и присоединиться

Привет, сообщество!

Лето — это прекрасно, но давайте будем честны: нам не хватало этих уютных посиделок и разговоров о насущном (и не очень). Осень — время новых встреч и теплых компаний, так почему бы не начать её правильно?

Завтрак! Уже в эту субботу!
Резко и дерзко записываемся, не откладываем!

5 сентября (суббота) в 10:00 мы снова соберемся в прекрасном и известном месте Сыроварня
Адрес: Лесная ул., 20, стр. 4

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

P.S. Обязательно дождитесь подтверждения регистрации. До 3 сентября всем напишем

P.S.P.S. Ресторан берет сервисный сбор 10%, предупреждаем заранее 🫶🏻

#АналитическиеЗавтраки

В эту сб проводим завтрак для аналитиков. Так что кто хотел увидится лично - приходите 🐱

У нас границы нигде не заканчиваются

Казалось бы, вроде и прав один из активных комментаторов на канале, что аналитик не такое уж и важное звено, но при этом только у нас (аналитиков) нигде не заканчиваются границы

То код напишем, то дизайн сделаем, то вот и с архитекторами постоянно мучаемся кто что должен 😊


На прошлых выходных как раз обсуждали с аналитиками холиварную тему: где все-таки заканчивается зона ответственности системного аналитика и начинается зона архитектора/разработчика?

Например, аналитик понимает, что для нового сценария лучше использовать асинхронную интеграцию. Он должен просто описать бизнес-требования и передать решение архитектору? Или он уже должен прийти с конкретным вариантом: Здесь нужен Kafka, потому что…

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

Я всё больше склоняюсь к тому, что сильный СА не может полностью отстраняться от технических решений. Но тогда где граница между СА и архитекторами/разработчиками?

Где она проходит у вас на проектах?

Почему нельзя просто увеличить timeout?

Однажды, прекрасным утром на проекте Х возникла следующая ситуация: один их сервисов стал отвечать 20 секунд. Заказчики предлагают:

Сейчас timeout 5 секунд. Давайте поставим 30 — и проблема исчезнет

Что должен проверить аналитик?

Системные аналитики, дневники на стол 😏

С Днём знаний! Ольга Андреевна подготовила расписание на сентябрь 👩‍🏫

5 и 12 сентября — Вайбкодинг для аналитиков

На реальном Telegram-архиве научимся обрабатывать большие объёмы информации с помощью ИИ, соберём базу знаний и превратим её в сайт с поиском, навигацией и авторизацией

7 сентября — Архитектура систем. База

Разберём НФТ, архитектурные стили, декомпозицию, API, очереди, вебхуки и System Design. В итоге спроектируем собственную систему

28 сентября — Архитектура систем. Хард

Пойдём глубже в C4, архитектурные слои, антипаттерны, индексы, репликацию, шардирование, кэширование и NoSQL

А ещё скоро — «Собесы с ИИ»

Готовим воркшоп-челлендж по подготовке к собеседованиям с помощью искусственного интеллекта. Формат — игра на выбывание 😈

Дату и подробности объявим немного позже

Не хотите ждать определённой даты?

У нас есть "факультативы", которые можно начать в любое время: ИИ для аналитика, AI-агенты в Cursor, брокеры сообщений, базы данных и SQL, REST API, Postman, Swagger, UX/UI и другие программы

👉 Посмотреть всё обучение

На какой урок записываетесь? 😏

Навайбкодили базу знаний для аналитиков 😏

Виктор Шариков, который ведёт наш чат по искусственному интеллекту, несколько месяцев собирал полезные материалы из Telegram-каналов в Obsidian

А потом превратил всё это в полноценный сайт: www.basahub.ru

Завтра выложим видео, в котором Виктор покажет BasaHub изнутри и расскажет, как всё работает!

А 5 и 12 сентября на воркшопе Виктор будет учить делать также, начиная от сбора данных до вайбкодинга сайта с авторизацией

👉 https://systemanalyst.life/vibe

Выгодная стоимость только до завтра (включительно)

"Вайбкодинг - это для разработчиков, мне это не нужно"

😏😏😏

Что аналитик может сделать с помощью вайбкодинга?

1️⃣ Собрать прототип до постановки задачи разработчикам

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

2️⃣Автоматизировать свою рутину

Например, сделать инструмент для проверки требований, обработки файлов, подготовки документации, сравнения версий или формирования отчётов

3️⃣Превратить проектные материалы в базу знаний

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

4️⃣ Проверить собственную продуктовую гипотезу

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

5️⃣ Получить дополнительный источник дохода

Небольшие внутренние сервисы, базы знаний, личные кабинеты и сайты с авторизацией нужны экспертам и небольшим командам. Аналитик уже умеет выяснять требования, раскладывать задачу и проверять логику. Остаётся научиться доводить это до работающего результата

🙂 Именно этому посвящён наш воркшоп: созданию реального продукта с помощью ИИ

За два занятия мы пройдём путь от исходных данных и требований до базы знаний и работающего сайта

➡️ Подробности и программа:
https://systemanalyst.life/vibe

Из-за меня упал прод!

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

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

Так что, решила написать этот пост как напоминание, что наша работа не только записать то, что рассказал заказчик. Наша работа — догадаться, о чём ещё нужно спросить. И, кажется, именно поэтому страх "я что-то упустил" никуда не исчезает даже с опытом

А у вас как? Или есть другие страхи?

Можно. И часть работы он действительно сделает: прочитает файл, найдёт несколько тем и подготовит краткое содержание

Тогда зачем этому посвящать два занятия по пять часов?

😊 Потому что один красивый ответ ChatGPT — ещё не база знаний 👇

Возьмём обычный проектный чат

В 2020 году один участник предложил решение. Через несколько сообщений его раскритиковали. В в другой раз вернулись и выбрали другой вариант. А через n времени выяснилось, что реализация вообще работает иначе

Если просто попросить нейросеть «выделить главное», она может собрать все эти сообщения в одно убедительное резюме. Только какое из решений в нём окажется финальным?

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

Результат ещё нужно:

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

Поэтому на воркшопе мы не будем искать один «секретный промпт». Мы соберём целый процесс:

Telegram-архив → подготовленные данные → темы и решения → поиск по базе → сайт с авторизацией

➡️ Пройдя этот путь один раз, вы сможете повторять его с проектными чатами, документацией, профессиональными каналами, материалами для собеседований и другими источниками (все секретики расскажем на воркшопе)

😏 То есть результатом будет не просто страница, которую однажды сгенерировал ChatGPT, а понятная и воспроизводимая механика создания подобных продуктов

Программа воркшопа и примеры применения:
https://systemanalyst.life/vibe

До 31 августа участие доступно по ранней стоимости. С 1 сентября цена изменится