Business | System analyst

📊От основ и внедрения ИИ в аналитическую работу до защиты реального проекта за 136 часов обучения на курсе «Бизнес-аналитик в ИТ».

🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

1⃣28 сентября, 20:00 мск — «Инструменты ИИ в работе бизнес-аналитика»: разберём, какие ИИ-инструменты применяют в сборе требований и анализе данных, покажем примеры промптов и границы между пользой и риском.

2⃣15 октября, 20:00 мск — «Цели и метрики как одно целое»: разберём связь целей и метрик, инструменты для их согласования и почему ошибки в целях обесценивают даже точные метрики.

3⃣22 октября, 20:00 мск — «Управление изменениями требований»: обсудим, как выстроить процесс управления требованиями, чтобы изменения не разваливали скоуп проекта, и как держать реестр требований в порядке.

Записывайтесь ➡ https://clck.ru/3WAaKJ

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой...
Узнайте, как управлять командой системных аналитиков эффективно за 5 месяцев обучения вместе с OTUS на курсе «Системный аналитик. Управление командой»

🎁 Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

1️⃣ 8 сентября, 20:00 мск — «Системный аналитик и его ценность глазами компании»: разберём, как грамотная работа аналитика повышает эффективность команды и продукта, и почему бизнес готов платить за эту ценность.

2️⃣ 23 сентября, 20:00 мск — «Как проводить архитектурное ревью и находить риски до начала разработки»: научимся находить узкие места и точки отказа до старта разработки, чтобы архитектура не рассыпалась при запуске продукта.

Записывайтесь ➡️ OTUS.RU

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как выстроить репутацию внутри компании — и почему это не про то, чтобы всем нравиться

Салют! Помню, как на третьем году работы мне сказали, что у меня “хорошая репутация в команде”. Я тогда искренне не понимала, что именно я делаю правильно. Просто работала.
Потом наблюдала, как коллеги с похожим опытом и знаниями получали разные результаты. Одних звали на интересные проекты, другие годами сидели на одном месте и недоумевали почему. Стала думать — в чём разница.
Вот что поняла.

🧐Репутация строится не на том, что вы знаете, а на том, как вы себя ведёте

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

Предсказуемость — это валюта доверия. Накапливается медленно, тратится быстро.

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

✅Хорошая работа сама себя не продаёт

Это было самым сложным для меня лично. Я из тех, кто считает, что результат говорит сам за себя. Оказалось — нет.

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

Руководство видит проблемы — они громкие. Хорошую работу не видит — она тихая.

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

❌Кризис — лучший момент для репутации

Парадокс, который я поняла на собственном опыте: люди запоминают не то, как вы работаете, когда всё хорошо. Запоминают то, как вы ведёте себя, когда плохо.

У меня был проект, где мы просели по срокам. Частично моя недоработка — не докопалась до одного требования, которое потом вылезло и всё усложнило. Я пришла к руководителю сама, раньше чем он узнал из другого источника. С разбором того, что случилось, и с планом, как выправляем.

Было страшно. Но именно после того разговора отношение изменилось в лучшую сторону — не потому что всё было хорошо, а потому что я не спряталась.

Прятаться, когда плохо — худшее, что можно сделать для репутации. Все это замечают.

🤓Разработчики — недооценённый источник репутации

Мало кто думает об этом целенаправленно. А зря.

То, что разработчики говорят о вас между собой, расходится по компании быстрее любого официального фидбека. “С ней приятно работать — требования понятные, отвечает быстро, не пропадает, когда вопросы” — такая рекомендация стоит дорого.

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

📈 Горизонтальные связи работают дольше, чем вертикальные

Руководители меняются. Компании реструктурируются. А люди, с которыми вы работали — уходят на другие проекты, в другие компании и берут с собой воспоминание о вас.

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

Это не расчёт. Просто так устроены отношения — люди помнят тех, кто им помог, когда было сложно.

Синдром самозванца в профессии аналитика — как я с этим жила

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

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

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

Характерные симптомы которые я у себя замечала:
— Боялась задавать “глупые” вопросы на встречах
— Переписывала письма по десять раз прежде чем отправить
— Когда что-то получалось хорошо - думала что просто повезло
— Когда что-то шло не так - была уверена что это только моя вина
— Сравнивала себя с коллегами и всегда была не в свою пользу

Откуда это берётся в нашей профессии
Аналитик работает на стыке всего. Нужно понимать бизнес, технологии, процессы, людей. Область знаний бесконечная — всегда найдётся что-то чего ты не знаешь.
Плюс наша работа во многом невидима. Разработчик написал код — вот результат. Дизайнер сделал макет — вот результат. Аналитик провёл десять встреч, вытащил требования, предотвратил три конфликта — и что? Требования это не код, их не потрогаешь.
Когда результат работы сложно измерить — мозг начинает сомневаться: а была ли вообще ценность?

Что реально помогло

1️⃣ Разрешила себе не знать всего
Звучит банально. Но мне реально пришлось внутренне договориться с собой: я не обязана знать всё про архитектуру, про DevOps, про финансовую модель заказчика. Я обязана знать своё дело хорошо и уметь задавать правильные вопросы нужным людям.
“Не знаю, давайте разберёмся вместе” — это не слабость. Это профессиональная честность.

2️⃣ Начала вести список того что сделала хорошо
Не для резюме. Для себя. Буквально блокнот где я записывала: вот здесь я нашла противоречие в требованиях до того как оно стало проблемой. Вот здесь помогла разрулить конфликт между командами. Вот здесь заказчик сказал что это лучшая документация которую он видел.
Когда накрывало сомнениями — открывала и перечитывала. Работало.

3️⃣ Поговорила с коллегами
Оказалось что опытные аналитики которым я завидовала — чувствовали то же самое. Просто не говорили об этом вслух. Один разговор по душам с коллегой которая была в профессии семь лет снял с меня какое-то внутреннее напряжение которое я носила месяцами.
Мы все притворяемся что знаем больше чем знаем. Это нормально. Ненормально думать что ты одна такая.

4️⃣ Перестала сравнивать себя с чужими достижениями
Соцсети и профессиональные каналы показывают лучшее. Никто не пишет “сегодня я провалила встречу и не смогла ответить на половину вопросов”. Все пишут про успехи, про крутые проекты, про сертификаты.
Я сравнивала свою внутреннюю кухню с чужим парадным фасадом. Это заведомо проигрышная игра.

Что поняла спустя двенадцать лет

Синдром самозванца не исчезает полностью. Он просто меняет форму. Сейчас я могу провести сложнейшее интервью с производственниками, написать архитектурное описание интеграции, выступить перед советом директоров — и всё равно иногда поймаю себя на мысли “а вдруг я что-то важное упустила”.
Разница в том что раньше эта мысль меня парализовала. Теперь я её замечаю, киваю ей и иду делать своё дело.

❗️Если вы аналитик и узнали себя в этом тексте — вы не одни. И то что вы сомневаетесь в себе скорее всего означает что вы достаточно вдумчивы чтобы видеть собственные пробелы. Это не слабость. Это качество хорошего специалиста.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

📊 90% провалов в IT-проектах — из-за плохо собранных требований аналитиком. Научим собирать их правильно на курсе «Системный и бизнес-анализ»

🎁Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

5 августа, 20:00 мск — «MVP глазами бизнес-аналитика: от идеи до первых функций»: разберём, что такое MVP и как развивать первые наработки продукта, рассмотрим примеры удачных MVP и инструмент User Story Mapping для формирования его границ.

17 августа, 20:00 мск — «Строим модель в нотации BPMN с помощью ИИ»: разберём, как с помощью LLM построить модель процесса в BPMN, почему ИИ не создаёт графику напрямую и как обойти это на деле. Разберём примеры генерации диаграмм и другие способы применения ИИ в процессах.

Записывайтесь https://clck.ru/3UzUeq

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Именно там где интересы сталкиваются — нужен человек который удерживает общую картину и не теряет голову. Не бизнес, не разработка. Аналитик.

Источник: @ba_and_sa

Как аналитик выживает между бизнесом и разработкой

Салют! Есть шутка в профессии: аналитика не любят ни бизнес ни разработка. Бизнес считает что ты на стороне IT и тормозишь. Разработка считает, что ты на стороне бизнеса и генеришь бесконечные хотелки. А ты стоишь посередине и пытаешься сделать так чтобы все были живы.
Я провела в этой позиции двенадцать лет. И да, первые несколько лет это реально выматывало. Потом поняла несколько вещей которые изменили отношение к этой роли.

Ты не переводчик. Ты модератор конфликта интересов

Долгое время я думала, что моя задача — переводить с языка бизнеса на язык разработки и обратно. Технически это так. Но если смотреть глубже — аналитик работает в точке где сталкиваются два мира с разными целями.
Бизнес хочет всё, быстро и желательно вчера. Разработка хочет чёткие требования, стабильный скоуп и время сделать нормально. Эти желания почти никогда не совпадают полностью.
Главная ловушка — пытаться угодить всем. Это невозможно. И попытка усидеть на двух стульях приводит к тому что не доверяют ни те ни другие.
Баланс который я нашла: моя лояльность не людям, а результату. Я на стороне проекта — не бизнеса и не разработки. Звучит просто, но внутри перестроиться непросто.

Что реально помогает
Не передавай требования — объясняй контекст

Худшее что может сделать аналитик — принести разработчику список требований без контекста. “Бизнес сказал сделать вот так.” Всё, ты стала почтальоном.
Разработчик должен понимать зачем это нужно, какую проблему решает, что будет если сделать иначе. Когда человек понимает зачем — он предлагает решения лучше тех что придумал бизнес. И это победа для всех.
Не ходи к разработке с сырыми требованиями
Прежде чем идти к команде я сама прохожусь по требованиям и задаю себе неудобные вопросы. Что будет если пользователь сделает вот так? А если данных нет? А если два пользователя одновременно? Какой сценарий если что-то пошло не так?
Лучше найти дыры самой, чем услышать их на разборе задач с командой. Разработка это запомнит — в хорошем смысле.
Когда бизнес и разработка конфликтуют — не исчезай
Самый плохой сценарий: бизнес и разработка начинают выяснять отношения, а аналитик тихонько выходит из чата. Я так делала. Казалось что конфликт не мой.
Мой. Потому что в основе почти любого конфликта между бизнесом и разработкой — неточные или противоречивые требования. Разруливать это всё равно придётся, только потом и с большими потерями.
Сейчас я захожу в такие конфликты первой. Не чтобы встать на чью-то сторону, а чтобы вытащить на поверхность в чём реальное расхождение. Часто оказывается что люди спорят об одном и том же просто разными словами.

Фиксируй решения принятые не тобой

Бизнес принял решение которое технически сомнительное. Разработка приняла архитектурное решение которое ограничивает функциональность. Ты была на встрече, слышала, высказала мнение — но решение не твоё.
Фиксируй письменно. Не чтобы потом сказать “я же говорила”. А чтобы когда через три месяца это аукнется — был контекст почему так получилось и кто был в курсе. Это защищает всех, не только тебя.

Не бери на себя ответственность за чужие решения

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

Про эмоциональную сторону — это тоже важно

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

Когда перестаёшь приходить как “человек из IT который сейчас всё улучшит” и начинаешь приходить как человек который хочет разобраться — всё меняется.

Источник: @ba_and_sa

Как брать интервью у производственников — это совсем другая игра

Салют! Сегодня у нас разбор интервью производственников))

Первый раз я пришла на интервью к начальнику смены на установке с ноутбуком, красивым шаблоном вопросов и уверенностью что всё пройдёт как обычно. Через десять минут поняла — ничего как обычно не будет.
Он смотрел на меня как на человека который пришёл отнять у него время. Отвечал односложно. На вопрос “расскажите как вы работаете с данными по выходу продукта” — пожал плечами и сказал “ну, смотрим”.

Я вышла с того интервью почти с пустым блокнотом. И пошла думать что сделала не так.

Почему стандартный подход не работает 🧐

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

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

Встреча с аналитиком из IT — это помеха в этом ритме. Не потому что он плохой человек. Просто у него реально другие приоритеты.
Плюс есть негласная установка: “скажешь лишнее — потом переделывай”. Люди на производстве умеют молчать. Это навык выживания в большой организации.

Что изменила в своём подходе❗️

1️⃣ Никакого ноутбука в начале

Ноутбук на столе — это протокол, это фиксация, это официально. Человек закрывается.
Я стала приходить с блокнотом и ручкой. Иногда вообще без ничего — просто поговорить. Записи делала после, по памяти. Да, это сложнее. Но люди говорили в разы открытее.
Сначала про работу, потом про систему
Ошибка которую я делала в начале — сразу спрашивала про будущую систему. “А как вы хотите чтобы это работало?” Человек не знает. Он никогда не думал в этих категориях.
Правильный порядок: сначала полностью понять как устроена работа сейчас. Только потом — осторожно — переходить к тому что можно улучшить.

Вопросы которые реально работают:
— Покажите как вы это делаете прямо сейчас
— А что происходит если вот это пошло не так?
— Откуда вы узнаёте что нужно действовать?
— Кому вы передаёте эту информацию дальше?
Никаких “а как вы видите идеальный процесс”.

Производственник не обязан думать об идеальных процессах — это наша работа.

2️⃣ Идти на рабочее место, а не звать в переговорку

Переговорка — чужая территория. Человек там скован.
Когда я начала приходить прямо к установке, к рабочему месту — всё менялось. Он в своей среде, уверен, может показать руками. “Вот смотри — вот этот показатель, вот журнал, вот куда я смотрю когда что-то идёт не так.”
Один такой визит заменял три переговорки. И информации было в разы больше.
Не спорить и не умничать
Если технолог говорит что-то что кажется нелогичным — не спорить. Уточнять.
“Правильно я понимаю что вы делаете вот так потому что…?” Часто за нелогичным на первый взгляд решением стоит опыт десятилетий и несколько аварийных ситуаций которые этот человек пережил лично.
Найти союзника внутри
На каждом производственном проекте я искала одного человека который понимает зачем всё это нужно и готов помочь. Не обязательно руководителя — иногда это молодой инженер которому интересно.
Такой человек помогал договориться о встречах, объяснял коллегам что я не враг, и переводил с технологического на человеческий когда я совсем не понимала о чём речь.

3️⃣ Отдельно про документацию которой нет

На производстве часто слышишь: “Да всё написано в регламенте”. Берёшь регламент — а там описан процесс образца 2009 года который давно работает по-другому. Просто никто не обновлял.
Реальный процесс живёт в головах людей и в неофициальных инструкциях которые передаются от старшего к младшему устно. Задача аналитика — вытащить именно это, а не переписать регламент который и так все игнорируют.

И главное
Производственники — одни из самых ценных экспертов с которыми мне приходилось работать. Они знают свой процесс до деталей которые ни в каком документе не найдёшь.
Просто язык у них другой. И подход нужен другой.

Event Storming: как за один сеанс вытащить из бизнеса всё что нужно

Салют! Расскажу про технику, которая перевернула мой подход к сбору требований. Я до неё несколько лет ходила на интервью с бизнесом по старинке — вопрос-ответ, протокол, снова вопрос. Долго, сухо, и всё равно что-то важное всплывало уже в процессе разработки.
Потом познакомилась с Event Storming. И поняла что теряла время.

❓ Что это вообще такое
Event Storming — это фасилитационная техника, которую придумал Альберто Брандолини в 2013 году. Суть простая: вы собираете в одной комнате всех причастных — бизнес, разработку, аналитику — и вместе моделируете процесс через события.
Не через функции системы. Не через экраны. Через события — то, что происходит в бизнесе.
Главный материал — стикеры. Цвет каждого имеет значение.

Язык стикеров — запомните один раз
🟠 Оранжевый — доменное событие Что-то произошло в системе. Формулируется в прошедшем времени: “Заказ создан”, “Оплата подтверждена”, “Товар отгружен”
🔵 Синий — команда Действие, которое инициирует событие: “Создать заказ”, “Подтвердить оплату”
🟡 Жёлтый — актор Кто выполняет команду: пользователь, менеджер, система
🟣 Фиолетовый — политика Правило или реакция: “Когда заказ создан — отправить уведомление”
🔴 Красный — проблема или вопрос То, что непонятно прямо сейчас. Не пытаемся решить на месте — фиксируем и идём дальше.

Как проходит сессия — по шагам:

Шаг 1. Хаотичный штурм — 20-30 минут
Все участники одновременно пишут оранжевые стикеры — доменные события. Без порядка, без очерёдности. Просто всё что происходит в процессе.
Здесь важно не останавливать поток. Дубли — нормально, противоречия — отлично, значит нашли точку для обсуждения.

Шаг 2. Выстраиваем хронологию
Берём все события и раскладываем на стене слева направо — по времени. Именно здесь начинается самое интересное: бизнес видит свой процесс целиком, часто впервые. И сам находит дыры.

Шаг 3. Добавляем команды и акторов
К каждому событию добавляем — кто и что сделал чтобы оно произошло. Здесь выясняется кто реально принимает решения, а не кто написан в регламенте.

Шаг 4. Фиксируем политики и проблемы
Правила бизнеса, автоматические реакции, спорные моменты — всё на стикеры. Красных стикеров не бойтесь, чем их больше — тем честнее сессия.

Живой пример: интернет-магазин

Вот фрагмент того, что получается на стене:
[Пользователь] → Оформить заказ
→ 🟠 Заказ создан
→ 🟣 Когда заказ создан — проверить наличие товара
→ 🟠 Наличие подтверждено
→ [Система] → Создать платёж
→ 🟠 Платёж инициирован
→ 🟠 Оплата подтверждена
→ 🟣 Когда оплата подтверждена — передать в склад
→ 🟠 Заказ передан на сборку

И вот тут кто-нибудь из бизнеса обязательно скажет: “Стоп, а если товара нет — что происходит?” И выясняется, что этот сценарий никто не описал. Вешаем красный стикер.
За один такой вечер находим больше пробелов, чем за месяц переписки в почте.

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

Когда это особенно полезно
— Старт нового проекта когда процессы ещё не описаны — Сложные интеграции между несколькими командами — Когда разные отделы по-разному понимают один и тот же процесс — Рефакторинг legacy-системы где документации нет вообще

Что важно для хорошей сессии
Несколько вещей которые я поняла уже на практике, не из книжек:
— Зовите всех кто принимает решения, не только исполнителей. Без ЛПР сессия даёт половину результата — Физическая стена и стикеры работают лучше любого онлайн-инструмента. Miro — только если нет выбора — Сессия не должна длиться больше 4 часов. После люди перестают думать — Фасилитатор не эксперт в предметной области — и это хорошо. Глупые вопросы вскрывают самые интересные противоречия

Источник: @ba_and_sa

Архитектурный крест: как приручить System Design interview

⏳ 10 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

System Design: проектируем Rate Limiter, ограничитель запросов

⏳ 29 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу. Бесплатный урок курса «Руководитель команд в ИТ»

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

На открытом уроке 16 июня в 20:00 разберём, почему начинающие руководители команд чаще всего ломаются не из-за слабых технических навыков, а из-за непонимания новой роли.

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

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

👉 Записаться

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как спроектировать REST API без ошибок: 3 задачи с разбором

⏳ 11 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

Как превратить стохастический ИИ в детерминированную машину

⏳ 14 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

❓Как стать незаменимым специалистом в системном анализе?
Получите актуальные навыки анализа данных на практике и научитесь применять на реальных проектах с поддержкой преподавателей.
Объедините знания в финальный проект экспертного уровня на курсе «Системный аналитик. Экспертный уровень»

🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

Вебинар 1: «Шпаргалка по проектированию REST API»
⏰ 2 июня в 20:00 мск

В программе:
1. Что такое REST и его отличия от других подходов.
2. Правила проектирования ресурсов, эндпоинтов, HTTP-методов и кодов ответа.
3. Стандарты обработки ошибок, валидации данных и версионирования.
4. Безопасность, логирование и документация в OpenAPI/Swagger.

Вебинар 2: «Создаём ИИ-ассистента для системного аналитика за 1 час»
⏰ 11 июня в 20:00 мск

В программе:
1. На практике с нуля соберем ИИ-агента, превращающего сообщения из Telegram в готовые задачи с ТЗ и приоритетом.
2. На живом примере разберём путь от голосового сообщения коллеги до структуры в трекере за 2 минуты.
3. Готовые схемы автоматизации рутины: создание задач, документирование требований, сборка статистики
4. Разбор «подводных камней» при настройке ИИ.

Вебинар 3: «OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию»
⏰ 22 июня в 20:00 мск

В программе:
1. Use Case: сквозной сценарий защиты Access/Refresh токенов для веба, мобильных и десктоп-клиентов прямо в Use Case
2. Sequence-диаграммы: перестройка уязвимой модели Bearer token + localStorage в безопасную BFF + httpOnly Secure Cookie
3. Соберём «радар» типовых атак: защита требований от брутфорса и Replay-атак, так, чтобы эти сценарии не выпали из поля зрения разработки
4. OAuth 2.0 на языке аналитика: понятный разбор Flow и PKCE; готовый чек-лист выбора гранта под ваши бизнес-процессы

Записывайтесь ➡ OTUS.RU

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

❓Уровень обычного системного аналитика уже не для вас?
Научитесь управлять архитектурой и командой системных аналитиков на курсе «Системный аналитик. Управление командой»

🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

Вебинар 1: «C4 для системного аналитика: строим единый язык между бизнесом и разработкой»
⏰4 июня в 20:00 мск

Программа вебинара:
Разберём самую простую и мощную модель визуализации архитектуры, которая позволяет за 4 диаграммы объяснять систему бизнесу, разработчикам и команде.

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

Вебинар 2: «Архитектура информационных систем. Монолиты, SOA и микросервисы»
⏰17 июня в 20:00 мск

Программа вебинара:
1. Как выделять архитектурные слои информационной системы
2. Основные компоненты системы и как рисовать компонентные модели
3. Различия явных признаков хорошей и плохой архитектуры
4. Плюсы и минусы монолитной, SOA и микросервисной архитектуры

Вебинар 3: «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах»
⏰24 июня в 20:00 мск

Программа вебинара:
Разбор процесса внедрения новой фичи системным аналитиком. На вебинаре спикер покажет, как проектируются и выводятся реальные сервисы на портал Госуслуг.
1. Сбор требований
2. Моделирование бизнес-процесса
3. Проектирование интерфейса системы
4. Описание компонентов системы
5. Настройка форм для госуслуг
6. Настройка печатных форм
7. Проектирование базы данных
8. API
9. Интеграция систем

Записывайтесь ➡️ OTUS.RU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Салют! В продолжении прошлого поста про ретроспективу, хочу поделиться своей историей.

Моя первая ретроспектива. Как я облажалась по всем фронтам 😅

Я junior-аналитик в небольшой компании, нас 8 человек в команде. Мы только что сдали проект с задержкой в три недели, клиент недоволен, команда на нервах. Тимлид говорит: «Проведи ретро, ты же читала про Agile».

Я читала. Целых две статьи

Грабля №1: Я не подготовилась к формату

Я зашла на встречу с чистым листом и сказала:

«Ну, давайте обсудим, что пошло не так».

Первые две минуты — тишина. Потом наш бэкендер, сказал:

«Всё пошло не так с самого начала»
— и понеслось.

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

✅ Что поняла: без структуры люди не обсуждают проблемы — они выплёскивают накопленное. Это не одно и то же.

Грабля №2: Позвала руководителя

Наш PM сидел за столом. Молча. С ноутбуком.

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

После встречи подошел ко мне тестировщик и шёпотом сказал всё то, что не прозвучало вслух. За 20 минут.

✅ Что поняла: если в комнате есть человек с властью — честного разговора не будет. Либо договариваешься с руководителем, что он не присутствует, либо собираешь мнения анонимно до встречи.

Грабля №3: Action points в никуда

В конце я всё же вытащила из команды несколько идей и записала их на доске:

— Улучшить коммуникацию с клиентом
— Чётче фиксировать требования
— Не допускать переработок

Звучит красиво. Но никто не был назначен ответственным. Никто не поставил дедлайн. Через неделю все забыли.

На следующем проекте — те же проблемы.

✅ Что поняла: размытые формулировки — это иллюзия решения. «Улучшить коммуникацию» — не задача. Задача — это «Маша каждую пятницу отправляет клиенту статус в двух абзацах до 17:00».

Грабля №4: Я думала, что фасилитатор — это просто ведущий

Я говорила слишком много. Заполняла паузы. Перебивала. Направляла туда, куда мне казалось правильным.

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

Я поняла это только на пятой или шестой ретро.

‼️ Что изменила со второго раза:

▸ Сделала анонимный опрос в Google Forms за день до встречи
▸ Попросила PM-а не приходить — объяснила зачем, он согласился
▸ Взяла формат Start/Stop/Continue — простой и понятный всем
▸ В конце не уходили, пока у каждого action point не было имени и даты
▸ Через две недели — 10 минут на check-in: что сделано?

Второе ретро прошло живее, честнее и короче. И впервые после него что-то реально изменилось.

‼️Вывод, который я формулирую так:

Первая ретроспектива редко бывает хорошей. Но она обязательно должна быть — чтобы вторая стала лучше.

Это итеративный процесс. Как и всё в Agile.

Источник: @ba_and_sa

Как удачно провести первую ретроспективу? 🔍

Салют! За 12 лет в аналитике я провела ретроспективы в фин.техе, стартапе, производстве, государственных проектах и e-commerce. И везде — одни и те же грабли у тех, кто делает это впервые. Сегодня разбираю всё по-честному.

Часть 1.

❓ Что такое ретроспектива вообще?

Это не «разбор полётов» и не поиск виноватых. Ретроспектива — это встреча команды, где вы останавливаетесь, смотрите назад на пройденный период и отвечаете на три вопроса:

1. Что шло хорошо?
2. Что мешало работать?
3. Что конкретно изменим?

Это инструмент из Agile, но работает в любой команде — даже если вы не слышали про Scrum.

Ошибка №1: «Ну давайте просто поговорим»

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

Самый простой для старта — Start / Stop / Continue:

▸ Start — что начать делать
▸ Stop — что прекратить
▸ Continue — что оставить как есть
Занимает 60 минут, подходит для любой команды от 4 человек.

Ошибка №2: Собрать всех — и молчание

Люди боятся говорить правду вслух, особенно если в комнате руководитель.
Решение — анонимный сбор тезисов. Используйте Miro, Mural или даже обычный Google Forms. Люди пишут честнее, когда не смотрят в глаза начальнику.

Ошибка №3: Обсудили — и разошлись

Это убивает доверие к ретро навсегда. Если в конце не зафиксировано 2–3 конкретных действия с ответственным и дедлайном — встреча прошла впустую.

Пример плохого итога: «Надо улучшить коммуникацию» Пример хорошего: «Петя до пятницы настраивает общий чат для согласований, больше не пишем в личку»

Мой чеклист для первой ретро👇

✅ Предупредить команду за 2 дня — зачем встреча и что ожидается
✅ Выбрать нейтрального фасилитатора (не руководитель проекта!)
✅ Установить таймбокс — 60–90 минут максимум
✅ Собрать тезисы анонимно до встречи
✅ Проголосовать за топ-проблемы (не обсуждать всё подряд)
✅ Зафиксировать 2–3 action points с именем и датой
✅ Через 2 недели — проверить выполнение

‼️ И последнее — самое важное

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

«Здесь нет правых и виноватых. Мы говорим о процессах, не о людях.»

Повторяйте это как мантру, пока не станет нормой.

В след раз поделюсь первым проведением ретро💪 и расскажу, как я там провалилась

Источник: @ba_and_sa