Junior, Middle и Senior системные аналитики — в чём разница? 🧩
Вопрос от подписчика

Разница между джуниорами, мидлами и сеньорами — в уровне ответственности.

Junior
🌱 — только начинает
👶 — новичок
💡 — учится
📘 — много теории

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

Middle
🚀 — активно развивается
🔧 — уверенно владеет инструментами
📈 — берёт ответственность
👨‍💻 — работает самостоятельно

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

Senior
🦉 — опытный и мудрый
🏆 — с высокой квалификацией
🤝 — наставник
🌐 — имеет глобальный взгляд на проект

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

🔥 Чем дальше вы развиваетесь, тем больше ответственность и сложность задач.

#questions #dev_process

Системному аналитику нужна крепкая база, вне зависимости от уровня

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

Мы даём короткие видеоуроки, учебный проект и карьерный трек. С нами вы сможете добавить в своё резюме:

💻 Понимаю процесс разработки ПО (Waterfall, Agile, Scrum)
🔄 Умею работать по Scrum
🤝 Готов к общению с командой разработки
🧠 Умею собирать и анализировать требования, вести диалог с заказчиком
📄 Документирую требования с использованием Use Cases и User Stories
🛠️ Моделирую технические, бизнес-процессы и алгоритмы (BPMN, UML, DFD и др.)
🗃️ Владею основами SQL и проектирую реляционные базы данных (ER-модель)
🎨 Связываю пользовательский интерфейс с требованиями и БД, продумываю валидацию полей

Для кого курс?
* Новички: освоите новую профессию и будете готовы к поиску работы
* Джуниоры: укрепите знания и получите навыки для роста

Пройдите бесплатный модуль, чтобы познакомиться с курсом и нашей платформой (мы разработали её сами).
🍁 Но предупреждаем: осеннее повышение цен уже на подходе!

Сейчас — идеальный момент, чтобы попробовать курс и успеть купить место по текущей стоимости.

WELCOME на ТЕСТ-ДРАЙВ
https://analystcore.com/

Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы

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

Многие ответили, что для них «Го в зум» — не является чем-то грустным или страшным. Ребята готовы ко всему! 😄

Лично у меня каждый раз при виде этого сообщения возникает мысль: если это такой быстрый вопрос, почему бы его не написать? У системного аналитика поток мыслей, он погружен в свою задачу, а тут разработчики и тестировщики приходят с задачами, которые мы могли описывать месяц-два назад. Быстро ответить в зуме не получится — нужно погружаться в контекст, искать доку и прочее. 🤷‍♀️ Так что быстрый звонок в зуме часто бывает не таким быстрым.

Мой идеальный мир — когда в мессенджере сначала пишут вопрос. Если я могу ответить за 5-10 минут, то либо напишу ответ, либо созвонюсь. Но если с ходу ответ не найти, зачем нам сидеть в зуме и смотреть, как я ищу информацию в конфлюенсе!?

#sa_dev

Правило двух пицц 🍕🍕

Идея Джеффа Безоса проста: если команду нельзя накормить двумя пиццами, значит она слишком большая.

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

Этот принцип особенно полезен в IT-проектах, где важна скорость. Если проект движется медленно, возможно, в команде слишком много людей, и это ограничивает их свободу действий.

#dev_process

Виды разработки

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

1️⃣ Заказная разработка
Есть ИТ-компании, которые делают ПО под заказ. Например, цветочный магазин хочет разработать сайт — они обращаются в ИТ-компанию. В этом случае заказчик — цветочный магазин, исполнитель — ваша команда.
В крупных ИТ-компаниях есть много команд, и каждая занимается своим проектом. Системный аналитик здесь становится связующим звеном между заказчиком и командой разработки. Он много общается с заказчиками, участвует в совещаниях, формирует и согласовывает единое ТЗ, ставит задачи команде и презентует результаты заказчику (в том числе участвует в приёмо-сдаточных испытаниях, или ПСИ), а также защищает свою команду. 💼

2️⃣ Продуктовая разработка
Если компания разрабатывает собственный продукт для внешнего рынка, то они занимаются продуктовой разработкой. Например, банк разрабатывает своё банковское приложение. В этом случае системный аналитик работает над продуктом для клиентов банка.
Кроме того, бывают компании, которые одновременно занимаются заказной разработкой и создают собственные продукты. Здесь аналитик взаимодействует с владельцем продукта (Product Owner), который ориентируется на метрики, пользовательский фидбэк и формулирует гипотезы. Системный аналитик помогает воплощать их в жизнь, работая над улучшением продукта. 📈

3️⃣ Внутренняя разработка
В этом случае компания разрабатывает ПО только для своих нужд — для автоматизации внутренних процессов. Например, разработчики банка могут разрабатывать HR-систему для своих отделов, чтобы был удобный поиск по сотрудникам, отделам, отображение карточек сотрудников и их грейдов.
Работа системного аналитика здесь похожа на продуктовую, но более ориентирована на потребности внутреннего заказчика. Аналитик взаимодействует с менеджером и другими внутренними пользователями, собирает требования и адаптирует продукт под нужды сотрудников. Также часто требуется обучение пользователей для эффективного использования системы. 🧑‍💼

#dev_process

Напоминаем, что у нас есть ещё один канал — AnalystCore - Старт карьеры.
Вступайте! Там вы найдете теорию простыми словами и получите заряд мотивации на вашем пути системного аналитика. 💪

Ссылка: https://t.me/analystcorestart

Заказная разработка? Продуктовая? Внутренняя?
Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы

Привет! 👋
С вами Вера.

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

Продуктовая разработка — мой фаворит.
Здесь ты разрабатываешь приложение, которым можешь пользоваться сам, как клиент. Так ты лучше понимаешь пользователей и стараешься сделать всё по высшему разряду, как для себя. Юрий разделяет этот взгляд.
Собственно, поэтому нам захотелось создать свой продукт — AnalystCore. 😊

На втором месте для меня — внутренняя разработка. 
Интересное направление. Здесь спокойнее, чем в продуктовой, так как не горят сроки и последствия от ошибок не так высоки. Дружная и приятная атмосфера, делаешь ПО для своих коллег и хочешь стараться для них, думаешь об их удобстве. 🧑‍💻

Заказная разработка для меня на последнем месте.
Я провела два года в этой сфере — и это был настоящий вызов! 😅 Но именно там я получила много опыта и столкнулась с самыми разнообразными задачами системного аналитика. В заказной разработке многое зависит от заказчика. Если ваша компания с заказчиком нашли общий язык, выстроили доверительные отношения и прочее, то всё будет хорошо! Да, бывают сложности, но их можно преодолеть.

#sa_dev

В какой-то момент в айти меньше улыбаются 😭

Не унывайте! Каждый баг — это возможность для новой фичи, каждый дедлайн — шанс потренировать скорость, а каждый зум — ещё один шаг к совершенству вашего poker face 😄

Системный аналитик может работать в самых разных условиях и форматах

1️⃣ Вы — один аналитик на проекте
Бывает, что аналитик один на проекте и работает со своей небольшой командой разработки. Это близкая работа с разработчиками и продакт оунером, когда вы вместе прорабатываете задачи и собираете требования.

2️⃣ Несколько аналитиков на проекте
На крупных проектах аналитиков может быть несколько, и тогда обычно есть тимлид, который курирует команду аналитиков. Помимо общих встреч с разработчиками, часто проводят отдельные встречи только для аналитиков, где обсуждают и распределяют задачи.

3️⃣ Комьюнити аналитиков
В крупных компаниях создают целое сообщество аналитиков. Они регулярно собираются, делятся опытом, готовят доклады и могут обратиться за советом к менторам.

4️⃣ Аналитик на несколько команд
Бывает и так, что один аналитик работает сразу на несколько команд.

#dev_process

Никто не сделает это за вас! 🫵
Никто не будет учиться за вас.

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

🔹 Хотите поднять уровень своей зарплаты? Учитесь новому и практикуйтесь
🔹 Возьмитесь за статьи, книги и курсы, которые давно откладывали
🔹 Применяйте знания прямо сейчас — делайте учебные проекты, берите новые задачи на работе

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

У вас есть система с пользовательским интерфейсом.
📌 Как описать документацию по системе?

В документации можно описать множество разделов. Сейчас остановимся на описании элементов интерфейса.

Пример: Описание страницы «Акция» в приложении для инвестиций
Для этого разделяем описание веб-страницы на блоки:
- Хедер
- Блок информации об акции
- Блок покупки
- Блок комментариев
- Футер
и т.д.

📌 Блок покупки
Данные из ответа GET /stocks/{stockId}
При выполнении запроса отображается скелетон. Если метод вернул ошибку, то также отображается скелетон.

Описание элементов:

1) Название акции — из stock.name

2) Цена покупки — из price.buy при открытии страницы, затем по вебсокету из buy.price (/stocks/{stockId}/price)

3) Кнопка «Купить» — отображается, если Биржа открыта (это ссылка на логику работы биржи). При нажатии:
1. Если поле Количество не скрыто, происходит Процесс покупки (ссылка на блок покупки)
2. Иначе появляется поле Количество

4) Поле «Количество» — по умолчанию скрыто — инпут — допустимые символы 0-9

📌 Процесс покупки
При нажатии на кнопку «Купить»:
1. Если Количество > 0, вызывается метод POST /stocks/{stockId}/buy с параметрами:
— stockId={stockId из урла}
— quantity=значение в поле Количество
1.1. Если метод вернул http-код=200, то отображается уведомление «Покупка прошла успешно»
1.2. Иначе отображается алерт с ошибкой с текстом из error.textError из POST /stocks/{stockId}/buy
2. ⚠️ Иначе под полем Количество выводится ошибка с текстом «Укажите количество».

#frontend #documentation