Конкурс на вакансии в IT

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

Статистика по вакансиям и резюме на май 2023:

Разработка: Вакансий – 55К, резюме – 130К, кандидатов на одну вакансию – 2.36
Тестирование: Вакансий – 1.1К, резюме – 11К, кандидатов на одну вакансию – 10
Системный анализ: Вакансий – 2.5К, резюме – 2К, кандидатов на одну вакансию – 0.8

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

Статистика на сегодняшний день:

Разработка: Вакансий – 61К, резюме – 149К, кандидатов на одну вакансию – 2.44
Тестирование: Вакансий – 5К, резюме – 47К, кандидатов на одну вакансию – 9.4
Системный анализ: Вакансий – 5.5К, резюме – 8К, кандидатов на одну вакансию – 1.45
Бизнес-анализ: Вакансий – 6.5К, резюме – 39К, кандидатов на одну вакансию – 6
Анализ данных: Вакансий – 18К, резюме – 87К, кандидатов на одну вакансию – 4.8

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

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

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

Аналитики данных. Порог входа вновь чуть повыше, чем в СА, и конкуренция выше в несколько раз. Есть риск потратить много времени на обучение, но испытывать трудности с трудоустройством из-за высокой конкуренции. Опять же, подойдет тем, кто любит работу с данными, статистику, математику, и может позволить себе выделить много времени на обучение. В анализе данных, кстати, в 90% случаев нужны знания языков программирования.

Бизнес-аналитики. Порог входа чуть пониже, чем в системный анализ, однако это отражается и на среднем уровне зарплат, и на конкуренции. Зарплаты чуть ниже, конкуренция значительно выше. Такие же риски, как и в случае с тестировщиками.

Системные аналитики. Порог входа – нормальный (чуть выше QA и БА, но ниже чем в разработке и анализе данных). Зарплаты – уступают разве что разработчикам, но тоже высокие. Конкуренция на вакансию – самая низкая на рынке.

Кажется это тот самый случай когда кажется, что «too good to be true». Моя вам рекомендация: не откладывайте, чем раньше начнёте – тем выше шансы преуспеть :)

P.S. Статистика собиралась с сайта hh.ru. Учитывался рынок России и актуальные открытые вакансии: обновленные не более месяца назад.

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

Ведущие:
- Алексей Плаксин, аналитик KODE
- Полина Майорова, старший аналитик KODE

Когда: 16 июля
Время: 19.00 (мск)

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

Главные темы эфира:
- Софт-скиллы и хард-скиллы. Обсудим все необходимые навыки на примере реального скиллсета системных аналитиков KODE.
- Где искать первые проекты и стажировки, и как отличаться от других кандидатов.
- Программа "Симулятор системного анализа": преимущества и возможности.

Регистрация по ссылке!

Запись только для тех, кто зарегистрировался на эфир. Кроме того, мы приготовили для вас классные подарки, которые помогут получить опыт в системном анализе.

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

Внимание!
Онлайн-встреча 16 июля состоится по расписанию. Мы вас очень ждем!
Если вы еще не зарегестрировались, то это можно сделать тут

Клиент-серверное взаимодействие

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

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

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

Клиент-сервер – это подход к построению архитектуры. Подход предполагает наличие системы управления (сервер) и внешней оболочки, интерфейса, позволяющего взаимодействовать с этой системой (клиент). Еще иногда можно услышать другие названия: Front-end и Back-end.

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

Существуют разные подходы к реализации клиент-серверного взаимодействия:

1. кто-то закладывает все операции и сложную логику на клиент, а сервер используют, например, только для хранения данных. Этот подход называется «толстый клиент».

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

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

• Так быстрее. Приложение запускается и работает быстрее, если ему не нужно выполнять большое количество вычислений. Сервер может делать это быстрее, потому что вычислительные возможности компьютеров все еще больше, чем у мобильных устройств;
• Так безопаснее. У злоумышленника есть прямой доступ к клиенту, но нет доступа ко всем данным и механизмам их обработки, ведь это происходит на сервере;
• Так проще обновлять. Если клиент толстый, то нам даже по мелким причинам нужно выпускать новое обновление, а пользователям постоянно его загружать. Если же логика на севере, то мы можем внести обновления там, и они применятся у всех пользователей без необходимости обновляться. В этом случае мы выпускаем обновления только при внесении изменений в клиентский код.

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

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

1. «Путь аналитика: практическое руководство IT-специалиста» - Андрей Перерва

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

2. «Разработка требований к программному обеспечению» - Карл Виггерс

В этой книге автор подробно рассматривает процесс разработки требований. Он предлагает читателям методы для сбора, анализа и документирования требований, включая практические советы по управлению изменениями и обеспечению качества требований.

3. «Джедайские техники» - Максим Дорофеев

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

4. «Искусство системного мышления» - Джозеф О’Коннор

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

5. «Цель. Процесс непрерывного улучшения» - Кокс Голдратт

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

Напомню, что уже завтра состоится наш прямой эфир на тему "Чего работодатель ждет от соискателя на позицию джуниор".
Алексей и Полина раскроют тему на примере реального скиллсета системных аналитиков KODE!

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

Ссылка на регистрацию

Уже через час состоится наш онлайн-эфир с Полиной и Алексеем!

Тема встречи: "Чего работодатель ждет от соискателя на позицию джуниор".

Время: 19:00 (мск)

Ссылка на эфир: Присоединиться к эфиру
До встречи на эфире!

Скиллсет системного аналитика

Спасибо всем, кто присоединился к нашему вчерашнему онлайн-мероприятию! Мы рады видеть ваш активный интерес и участие.

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

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

Не забудьте присоединиться к нам на следующих эфирах, мы скоро обновим расписание!

📌 Оставайтесь с нами, впереди много интересного!

Отображаем целевой сценарий в виде диаграммы

Продолжаем разбирать задачи со стажировок! Вот условия:

Есть интернет-магазин со своим складом, курьерами, логистикой. Целевой сценарий взаимодействия магазина с клиентом начинается с входа на сайт и заканчивается получением клиентом оплаченного товара. Отобрази целевой сценарий в виде диаграммы (желательно в нотации UML SD).

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

Далее откройте несколько интернет-магазинов и посмотрите как данный сценарий работает у них, подумайте над тем как вы бы их оптимизировали.

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

Если не знакомы с нотацией UML и конкретно с диаграммой последовательности (SD, sequence diagram), посмотрите инструкцию на сайте plantUML.

Лучше сразу разобраться с синтаксисом plantUML и делать диаграммы прямо на сайте.

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

Еще в изначальном условии говорилось, что сценарий завершается когда пользователь получает оплаченный товар. Но это про бизнес-логику, а с точки зрения реализации, доставка – это вообще отдельный сценарий, который начинается после оплаты, поэтому лучше сценарий доставки собрать в отдельной диаграмме.

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

• Еще будет бонусом использование стандартных фрагментов типа alt, opt и т.п. Это вовсе необязательно, но помогает оптимизировать диаграмму и в некоторых случаях правильно изобразить сценарий.

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

P.S. Почему задание лучше делать в нотации UML SD:

1. она более предназначена для моделирования технической реализации сценариев, чем, например, BPMN (который предназначен для моделирования бизнес-процессов). И тут мы можем наглядно увидеть, насколько человек технически глубоко понимает сценарий, который он смоделировал;
2. это наиболее распространенный формат моделирования когда проектируешь реализацию сценариев. То есть любой аналитик так или иначе сталкивается с UML SD в работе, и нужно быть к этому готовым.

Роль аналитика в запуске проекта

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

Во-первых, надо разобраться в имеющемся контексте и артефактах. Согласованный с заказчиком список задач, которые будем делать в рамках проекта, должен точно соответствовать ожиданиям, описанным в техническом задании (ТЗ) и представленным в дизайне (уже готовом или пока только в концепции). Если возникают какие-то расхождения, важно сразу сообщить об этом менеджеру.

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

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

В-четвертых, настроить инструменты, шаблоны. Договориться с командой где вести документацию, где будет описание API, какой будет шаблон требований, об уровне детализации требований. Это нужно, чтобы удерживать консистентность (согласованность) документации и избежать беспорядка, а также чтобы вся команда, и приходящие люди, были синхронизированы в этом вопросе.

Ну и бонусом, в-пятых, надо приглядывать за другими, как минимум, в части:

1. ТЗ должно быть оценено разработчиками. За оценку работы должны быть ответственны те, кто выполняет эту работу. Когда команда вписывается в реализацию проекта, оцененного, например, менеджером, зачастую это либо плохо заканчивается, либо не начинается;
2. Процессы проекта должны быть выстроены так, чтобы команда функционировала практически автономно. Обратная полярность автономии – микроменджмент, это когда менеджер или тимлид делает работу за других (проектирует, разрабатывает, тестирует). Отсутствие автономии – серьезный риск для проекта, поэтому на это нельзя закрывать глаза;
3. Нельзя недооценивать RoadMap проекта. Команда, которая не знает куда идет, это отряд самураев, у которых есть только путь, причем обычно не очень эффективный.

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

Почему в обучении так важна практика и реальные задачи?

Давайте вспомним, сколько классных книжек по самулучшайзингу вы прочитали и сколько реально повлияли на вашу жизнь?
Можно предположить, что единицы. И скорее всего успешны были те авторы, что предлагали вам сразу же внедрять прочитанное в свою жизнь. Хочешь рано вставать и магию утра? Давай завтра проснемся хотя бы на 10 минут раньше. А дальше и остальное подтянется.

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

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

Например, на старте для стажеров мы даем памятку и делаем адаптационный лист, где даем на изучение теорию по архитектурным паттернам (монолит/микросервисы, тонкий и толстый клиент), клиент-серверному взаимодействую (с упором на архитектурный стиль REST), повторяем основы по сетевому взаимодействию (модель OSI) и базам данных, охватывая как реляционные, так и нереляционные.

Для закрепления теории стажеры сразу приступают к практической части, где:

• собирают требования с помощью интервью и анкетирования, анализируют текущие процессы;
• проектируют новую систему, охватывая полученные знания по архитектуре (часто это HLD или диаграмма компонентов);
• учатся создавать диаграммы вариантов использования, активностей и последовательностей в UML;
• проводят ревью UI/UX дизайна, используя гайдлайны;
• проектируют и тестируют API;
• моделируют логическую модель реляционной БД с использованием ERD диаграммы.

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

Роль аналитика в сборе требований. Часть 1

Давайте разберем, как собирать требования для проекта и избежать ошибок на ранних этапах.

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

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

Что обсудим?

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

1. Анализ предметной области
Сначала важно детально разобраться в предметной области. Это особенно критично, если вы раньше не работали с подобными продуктами.

Как погружаться в тему:

• Ресерч. Читайте книги, статьи, блоги, форумы. Изучите существующие процессы и подходы к автоматизации в данной области, а также заказчика и его конкурентов.
• Общение с экспертами. Найдите сообщества, Telegram- или YouTube-каналы, блоги, подкасты. Лучше всего — связаться напрямую с экспертами и задать им вопросы.
Результаты исследования делитесь с командой. Не ждите, что вам кто-то принесет всю информацию на блюдечке. Проактивность всегда лучше бездействия!

2. Работа с лицами, принимающими решения (ЛПР)

• Определите, кто входит в группу ЛПР. Это можно узнать у аккаунт-менеджера или самостоятельно.
• Проведите интервью с ключевыми ЛПР. Узнайте их цели и ожидания от продукта, а также степень их влияния.
Эта информация поможет вам правильно выстраивать коммуникацию с заказчиком и принимать решения в спорных ситуациях.

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