Business | System analyst

❓️️️️️️️Хотите освоить востребованную профессию, которую не заменит ИИ?
За 13 месяцев обучения получите с нуля полное понимание работы системного аналитика и лицензированный диплом о профессиональной переподготовке на курсе «Системный аналитик» в OTUS.

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

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

2⃣17 ноября, 20:00 мск — «User Story vs Use Case: что выбрать для описания требований»: сравним подходы и поймём, когда хватит истории, а когда нужен сценарий.

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

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

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

Прошло две недели на новом проекте. И что теперь?

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

Примерно на третьей неделе наступает "провал"

Это нормально - но мало кто об этом предупреждает.

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

Не переставайте задавать вопросы. Просто меняйте формулировку. Не "объясните как это работает", а "я понимаю это вот так - правильно?" Разница небольшая, воспринимается совсем иначе.

Подводные камни которые вылезают после двух недель

1️⃣ Неформальные лидеры

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

2️⃣ Накопленный долг.

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

3️⃣ "У нас так не принято".

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

Как понять что ты на своём месте

Обычно это чувствуется к концу третьего-четвёртого месяца.

➕ Хорошие признаки: к вам приходят с вопросами сами, на встречах вы уже не просто слушаете, начинаете видеть проблемы чуть раньше чем они становятся кризисом.

➖Тревожные признаки: через три месяца не понимаете кто реально принимает решения, чувствуете что вас терпят но не слышат, каждый день ощущение что делаете что-то не то.

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

Про новых людей — и почему их не нужно бояться

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

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

Как понять проект по-настоящему

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

Дискомфорт первых месяцев — это не сигнал, что вы не на своём месте. Это сигнал что вы растёте.

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

Источник: @ba_and_sa

Первые две недели на новом проекте — что делать чтобы не облажаться

Салют! Помню своё первое погружение в большой незнакомый проект. Меня посадили, дали доступы к куче систем, скинули ссылку на Confluence где было триста страниц документации и сказали "изучай". Я изучала. Честно. Три дня читала документы и к концу понимала примерно столько же сколько в начале — потому что читала не то и не в том порядке.

С тех пор у меня есть своя система первых двух недель. Делюсь.

День 1-2. Сначала люди, потом документы

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

День 3-5. Разобраться в предметной области — но не глубоко

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

Что помогает:

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

День 5-7. Найти где болит прямо сейчас

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

Не жду пока мне скажут. Спрашиваю напрямую: "Что сейчас мешает команде работать быстрее?" или "Есть что-то что давно хотели разобрать но руки не доходили?"

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

День 7-10. Картина целиком

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

Рисую для себя — не для документации, просто для понимания:

— Кто главные участники процесса и как они связаны
— Как выглядит основной сценарий от начала до конца
— Где стыки между системами или командами — там обычно и прячутся проблемы

Этот набросок показываю кому-то из команды и прошу покритиковать. "Я правильно понимаю как это работает?" — один из самых продуктивных вопросов в первые две недели.

День 10-14. Договориться как будем работать

К концу второй недели уже понятно с кем предстоит работать плотнее всего. Самое время договориться о правилах — не потому что я люблю бюрократию, а потому что потом договариваться сложнее.
Как фиксируем требования. Кто финальный ЛПР по спорным вопросам. Как обрабатываем изменения. Где живёт документация.

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

Чего точно не стоит делать в первые две недели

— Предлагать "а вот у нас на прошлом проекте было лучше". Даже если правда. Особенно если правда — Брать на себя задачи раньше чем понял контекст — переделывать дороже чем сделать позже но правильно — Молчать когда что-то непонятно. Вопросы в первые две недели воспринимаются как норма. Через месяц — уже нет

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

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

Источник: @ba_and_sa

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

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

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

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

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

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

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

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

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

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

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