Системный аналитик

Постновогодняя распродажа 🎄 Если откладывали покупку Базы знаний по системному анализу — вот он, знак. 🔥 ВЕЧНЫЙ доступ за 3 000 ₽ вместо 5 000 ₽ ⏰ Акция всего 3 дня — до 10:00 22 января (МСК) Если думали, покупать ли, то сейчас самое время

Постновогодняя распродажа 🎄 Если откладывали покупку Базы знаний — вот он, знак. 🔥 ВЕЧНЫЙ доступ за 3 000 ₽ вместо 5 000 ₽ ⏰ Акция всего 3 дня — до 10:00 22 января (МСК) Если думали, покупать ли, то сейчас самое время

😎 Менторство от создателя канала Если вдруг вы задумывались о менторе, самое время рассмотреть мою кандидатуру. Изучить условия и оставить заявку можно тут

🔼 Слоистая архитектура Слоистая архитектура — подход, при котором система разделяется на логические слои 💚Каждый отвечает за строго определённую группу задач и взаимодействует с другими слоями по правилам Базовые принципы 💚 Разделение ответственности Каждый слой решает 1 категорию задач: 💚взаимодействие с пользователем/внешними клиентами 💚управление бизнес-процессами 💚бизнес-правила 💚работа с данными и внешними системами Слой не должен брать на себя задачи вне его зоны ответственности 💚 Однонаправленные зависимости Зависимости направлены сверху вниз: 💚верхние слои используют нижние 💚нижние не знают о верхних Снижает связанность и упрощает изменение системы 💚 Контракты между слоями Контракт слоя — формальное описание: 💚какие данные слой принимает 💚какие данные возвращает 💚какие ошибки и ограничения возможны ⭕контракт важнее реализации ⭕верхний слой знает контракт, но не реализацию ⭕реализацию можно заменить (другая БД, другой внешний сервис), не меняя вызывающий слой 💚 Изоляция изменений Изменения в одном слое не должны затрагивать другие, если контракт сохранён Пример: 📍смена БД не требует изменений в бизнес-логике 📍смена UI не влияет на доменные правила Типовая структура ⏩ Презентационный слой (Presentation Layer) 🟡принять запрос 🟡проверить формат данных 🟡вернуть результат пользователю или клиенту Включает: ⭕UI (веб, мобильный, desktop) ⭕REST / GraphQL контроллеры ⭕валидацию формата данных Не должно быть: ✖ бизнес-логики, ✖ прямой работы с БД ⏩ Слой приложения (Application / Service Layer) 🟡управлять сценариями использования (use cases) 🟡определять последовательность шагов 🟡управлять транзакциями и безопасностью Включает: ⭕сервисы приложений ⭕оркестрация логики ⭕обработку ошибок сценариев Отвечает на вопрос «что именно нужно сделать», но не содержит бизнес-правил ⏩ Бизнес слой (Domain / Business Layer) 🟡реализация бизнес-правил и ограничений 🟡хранение данных предметной области Включает: ⭕сущности ⭕доменные сервисы ⭕бизнес-инварианты Ключевой слой, ради которого существует система Не должно быть: ✖ логики UI ✖ SQL, HTTP-вызовов ✖ технических деталей хранения данных ⏩ Инфраструктурный слой (Infrastructure Layer) 🟡реализация технических деталей 🟡работа с БД 🟡интеграции с внешними системами 🟡файловые хранилища, очереди, API, кэш Включает: ⭕репозитории ⭕ORM ⭕HTTP-клиенты Типовой поток запроса 1. Presentation Layer принимает запрос 2. Application Layer запускает сценарий 3. Domain Layer выполняет бизнес-логику 4. Infrastructure Layer читает или сохраняет данные 5. Результат возвращается вверх Другие слои 🟡Integration — изоляция внешних API и интеграций 🟡Security — авторизация, аутентификация, ACL 🟡Caching — работа с кэшем (Redis и аналоги) 🟡Messaging / Event — очереди, события, асинхронное взаимодействие Это не обязательные слои Их выделяют, если появляется отдельная ответственность Лишние слои усложняют систему Когда использовать ✅ есть нетривиальная бизнес-логика ✅ система будет развиваться ✅ в проекте несколько команд ✖ система одноразовая ✖ минимальная логика ✖ критична каждая миллисекунда задержки 📎 Материалы 1. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя 2. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика 3. Слоистая архитектура 4. Архитектура приложения: что это, какие есть виды и как проектировать 📚 Книги 1. Архитектура ПО. Руководство для обучающихся архитектурному мышлению - Ганди Раджу, Ричардс Марк, Форд Нил 2. Идеальная архитектура. Ведущие специалисты о красоте программных архитектур - Диомидис Спинеллис, Георгиос Гусиос 3. Архитектура программного обеспечения на практике - Л. Басс, П. Клементс, Р. Кацман 4. Александр Швец. Погружение в Паттерны Проектирования #архитектура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🚨Выжить среди хаоса информации или где системному аналитику узнавать первым про актуальные инструменты и навыки в 2026 году? Наши преподаватели-практики ответят! 🔥Записывайтесь на 3 бесплатных вебинара курса «Системный аналитик. Advanced» ✅ Вебинар 1: «Шпаргалка по проектированию REST API» ⏰14 января в 20:00 мск Программа вебинара: 1. Что такое REST и чем он отличается от других подходов 2. Как правильно проектировать ресурсы и эндпоинты 3. Использование HTTP-методов и кодов ответа 4. Стандарты оформления ошибок и валидации данных 5. Версионирование API и управление изменениями 6 Лучшие практики по безопасности, логированию и документации (OpenAPI/Swagger) ✅ Вебинар 2: «Пользовательские сценарии (Use Cases): как превратить бизнес-требования заказчика в задачи на разработку» ⏰20 января в 18:00 мск Программа вебинара: 1. Введение в пользовательские истории (User Stories): основы и принципы 2. Работа с бизнес-требованиями: как превратить запросы заказчика в конкретные истории 3. Формулировка User Stories: примеры из практики и подходы 4. Постановка задач в разработку ✅ Вебинар 3: «Что делает системный аналитик когда собирает требования?» ⏰26 января в 20:00 мск Программа вебинара: 1. Требования: понятия, классификация, процесс выявления 2. Когда и как мы работаем с требованиями 3. Несколько приемов работы со стейкхолдерами 4. Роль аналитика в работе с требованиями Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

❌ Баги аналитики Код написан, всё успешно протестировано, фича на проде, а бизнес в шоке... Знакомо? 💙Это то, что мы с вами не учли на этапе написания ТЗ Выявить, проанализировать, уточнить, согласовать требования, критически посмотреть на проблему, найти риски 💙Никто, кроме аналитиков, эту работу не проделает Баги от нас стоят дороже всего 💙Но их предотвращение — экономит деньги компании больше всего Антипаттерны аналитики 1️⃣ Не все требования фиксируются письменно Существуют на словах, "очевидно же" В итоге на прод попадает функционал, где клиент-иностранец может получить налоговый вычет 💙 Все требования фиксируем в артефакте 2️⃣ Не все требования согласовываются с бизнесом После релиза менеджер залетает с ноги и возмущается, почему не учли то-то. А это нигде не зафиксировано 💙 Обязательно получаем ОК от заказчика по требованиям перед тем, как писать детальное ТЗ 3️⃣ Лоскутное описание процессов Не продуман процесс целиком, нет e2e описания, как должно работать В итоге ни у кого нет понимания общей картины. Даже у аналитика 💙 Составлять верхнеуровневое описание процесса до написания ТЗ 4️⃣ Не обращать внимания на вариации и корнер-кейсы Один из самых частых и дорогих видов багов Например, не учесть, что отчество может отсутствовать, или что имя клиента может быть двойным 💙 Заполнять специальный артефакт, например, матрицу сценариев (пример шаблона см. в комментариях) 5️⃣ Неверный уровень детализации ТЗ 💙 Слишком подробные, кодоподобные ТЗ затрудняют чтение и требуют реверс-инжиринга Никто, кроме аналитика, ничего не поймёт 💙 Слишком поверхностные ТЗ упускают детали → ловим баги на проде 💙 Иметь шаблоны ТЗ под каждый тип задачи 6️⃣ Доверять документации Вообще, слово "доверять" не про аналитиков :) Руководствуемся критическим мышлением, слепо доверять мы не можем Например, при описании интеграции с внешним сервисом нельзя взять и скопипастить в своё ТЗ пример запроса и ответа. Нужно проверять вручную 💙 Критически относится к чужой документации. Всегда проверять всё, что можно проверить 7️⃣ Не закладывать идемпотентность и дедубликацию В той самой статье про Васю всё сказано, добавить нечего Бонусом в комментариях будет короткий DoR для самопроверки. ➿➿➿➿➿➿➿➿ ⬇️ Продолжение следует ... за Вами! Давайте добавим краудсорсинга в комментариях к этому посту — обменяемся своими факапами (админ первый) Соберём всё и выложим продолжение P.S. Если формат зайдёт, будем практивать и дальше. Примерно так: мы даём начало 💙 обмен опытом в комментах 💙 собираем в финальный пост. Ну и как всегда — выложим в базу знаний по системному анализу

📊 65% аналитиков заваливают техсобесы из-за пробелов в базовых знаниях. Ты среди них? 😓

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

Александр Нездемина — практикующий системный аналитик с 14-летним опытом — создал канал, где структурирует хаос технических знаний в понятную систему. Почему подписчики не могут оторваться от его контента? 🖇 Разборы РЕАЛЬНЫХ задач с собеседований — те самые, которые могут вызывать сложности в момент собеса 🖇Готовые шаблоны и чек-листы, которые можно сразу применять в работе 🖇 Никакой воды — только емко и структурно о самом важном для работы аналитика После изучения материалов канала, аналитики повышают зарплату и становятся востребованными спецами на рынке. Подписывайся на канал, переходи в закреп и начинай с разборов задач из собесов и реальной практики. Говорят, что после этих разборов начинают крутиться шестеренки в голове ⚙️ Хватит сомневаться. Действуй прямо сейчас! https://t.me/+IAifBUzdDtQwNjky

🧠 Brainstorm Брейншторм (мозговой штурм) — групповой метод генерации идей для решения задачи или поиска вариантов Это не обсуждение и не поиск лучшего решения 💙А способ найти варианты решений 🎯 Цель: получить максимально широкий набор идей за ограниченное время без их оценки на этапе генерации Проводится в два этапа: 💙 сначала — генерация идей 💙затем — анализ, отбор и принятие решений Роли участников ✨фасилитатор — управляет процессом, следит за правилами, не предлагает решения ✨участники — генерируют идеи, не критикуют, не оценивают ✨наблюдатель (опционально) — подключается на этапе анализа Зачем нужен ◾️задача открытая, без заранее известного решения ◾️есть риск застрять в очевидных или привычных решениях ◾️требуется быстро собрать идеи от разных ролей и точек зрения ◾️проекты на начальных, неопределенных стадиях Когда не нужен ➖ у задачи однозначное решение (например, по регламенту или стандарту) ➖ требуется точный расчет или экспертиза одного специалиста ➖ решение уже принято, нужна его реализация Пример 💙 Поиск корневой причины сбоя в процессе 💙Ситуация: в еженедельном отчете падает количество успешных транзакций. 💙Задача для брейншторма: что привело к снижению числа успешных платежей? 💙Результат - сгенерированные гипотезы: - обновление страницы оплаты - проблемы у платежного провайдера - изменения в анти-фрод системе - ошибка в кешировании данных - сезонный фактор Cоздается список направлений для дальнейшей проверки Базовые правила 1. Запрещена критика идей 2. Количество важнее качества. Цель — заполнить доску вариантами 3. Поощряются нестандартные идеи 4. Идеи можно развивать и комбинировать Техники 💙 Классический брейншторм Когда использовать: простые открытые задачи Как проводится: участники устно предлагают идеи, фасилитатор фиксирует ➕ простота, высокая скорость ➖ риск доминирования активных участников Пример: генерация вариантов пользовательских сценариев 💙 SCAMPER Когда: улучшение текущего решения Как: генерация идей по наводящим вопросам 💙(Substitute (Заменить) 💙Combine (Комбинировать) 💙Adapt (Адаптировать) 💙Modify/Magnify Модифицировать/Увеличить) 💙Put to other uses (Применить иначе) 💙Eliminate (Устранить) 💙Reverse/Rearrange (Перевернуть/Изменить порядок) ➕ структурированный подход ➖ не подходит для задач «с чистого листа» Пример: Оптимизация бизнес-процессов 💙 Six Thinking Hats Когда: cложные задачи, конфликт мнений Как: участники мыслят в заданных ролях ➕ снижает споры, структурирует обсуждение ➖ требует подготовки Пример: проработка архитектурных альтернатив 💙 Обратный брейншторм Когда: поиск рисков и уязвимостей Как: генерация идей как ухудшить ситуацию ➕ эффективно выявляет проблемы ➖ требует аккуратной фасилитации Пример: выявление рисков реализации, ошибок в требованиях, потенциальных отказов системы. 📎 Материалы 1. Топ 8 инструментов для мозгового штурма 2. 15 способов превратить мозговой штурм в результат «огонь» 3. Пять техник мозгового штурма 4. Что такое мозговой штурм и как правильно его проводить в компании 5. Как провести мозговой штурм: основные правила, методы и ошибки #управление_проектами ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

Представьте себе коммуналку, в которой живут только аналитики. Как вы думаете, о чём там будут говорить? Если подумали исключительно про цифры, то зря 🙂 Потому что мы в Авито собрали в Телеграме комьюнити «Коммуналка аналитиков», чтобы посмотреть, что будет. Получилось очень даже интересно. Оказалось, аналитики с удовольствием пишут обо всём вокруг профессии: ✍️ Рассказывают о рабочих буднях ✍️ Хвастаются успехами и вспоминают фейлы ✍️ Постят мемы ✍️ Запускают опросы и собирают бинго ✍️ Шутят ✍️ Делятся лайфхаками ✍️ Создают серьёзные посты про аналитику ✍️ И-и-и обсуждают другие штуки, которые сложно классифицировать Подписывайтесь на канал и читайте недушную аналитику 😉

❓Как менять статусы объектов в процессе — и не утонуть в сервисных задачах Когда по процессу движется бизнес-объект — заказ, договор или заявка на кредит, то нужно изменять его статус в зависимости от пройденных этапов. При этом часто на статусы многое завязано и хочется видеть изменения на модели процесса. 💡 Решение в лоб — на каждое изменение ставить сервисную задачу, которая пропишет нужный атрибут сущности в прикладной системе. Будет все наглядно, но схема быстро захламляется однотипными элементами. Как быть? 👉 Можно моделировать смену статусов событиями — они компактнее. Но мы же хотим иметь исполняемую модель, чтобы статус менялся не только «на бумаге». А навесить бизнес-логику на события — задача нетривиальная. Не хочется городить сложные решения ради такой мелочи. ❗️Мы нашли лайфхак, как сохранить лаконичность схем и обойтись без лишнего кода. Как именно? 👇 Ответ — в Телеграм-канале BPM Developers. #реклама О рекламодателе