Спасибо, что были с нами на эфире "Как войти в профессию системного аналитика: первые шаги и лайфхаки". Мы рады, что вы присоединились и надеемся, что вам было полезно!

Мы публикуем полезный отрывок по Hard-скиллам, которыми должен обладать системный аналитик, вот некоторые из них:

— Написание требований: изучение нотации Use-Case/User-Story/Job Story; функциональные/нефункциональные требования
— Понимание клиент-серверного взаимодействия
— Базовое умение проектировать запросы REST API
— Визуализация требований и бизнес-процессов
— Базовое понимание баз данных (БД)

Следующий эфир по теме «Чего работодатель ждет от соискателя на позицию джуниор», который будет посвящен обзору скиллсетов и нашему опыту в качестве работодателя, будет очень интересно, let’s go регистрироваться!

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

Разбор тестового задания со стажировки!

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

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

Представьте, подаёте заявку на стажировку, вам дают такое задание:

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

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

1. Прозрачно и четко донести в чём именно проблема;
2. Взять ответственность на себя и явно об этом написать;
3. Объяснить какое влияние проблема оказывает на заказчика и какое на пользователей. Нужен ответ на вопрос “что конкретно это для нас означает?”;
4. Предложить несколько вариантов решений, по каждому из которых указать сколько это займет времени, в какую стоимость обойдётся заказчику (в том числе с учетом затрат, которые несет заказчик от наличия проблемы) и какие оно несет риски и прочие обстоятельства;
5. Указать какое решение вы считаете наилучшим и почему;
6. Позвонить заказчику для оперативного принятия решения.

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

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

Производственный процесс и управление проектами

Сегодня о книжках, процессах, менеджменте…

Впервые рекомендацию на книгу «Цель», Элияху Голдратт, я получил от Ильи Красинского на подкасте у Вани Замесина. С тех пор я еще много раз слышал как её рекомендуют, и сегодня хочу присоединиться к эстафете, и порекомендовать эту книгу вам.

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

Один из показательных принципов этой теории там рассматривается на примере похода. Представьте, что вы идёте в поход группой человек и вам нужно пройти из точки А в точку Б за сутки. Вам также необходимо идти в ряд друг за другом. Допустим, вам нужно проходить 3 км/ч, чтобы успеть в срок. Если вы поставите в начало ряда тощего бегуна, то он убежит и оторвётся от группы. Другие люди тоже могут идти с разной скоростью, из-за чего образуются разрывы.

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

Поэтому задача заключается в том, чтобы организовать ряд таким образом, чтобы все шли с одной скоростью и она была не ниже чем 3 км/ч. Сделать это можно выявив ограничения, которые этому мешают. Например, если в начале ряда идет крупный человек с большим рюкзаком, то вашим ограничением может быть его лишний вес или тяжесть рюкзака. Возможно, если распределить вещи из его рюкзака между остальными людьми в отряде, то и скорость выровняется. Или если ментально его замотивировать повысить скорость. Или, если ничего не помогает, заменить его на более быстрого “фронтмена”.

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

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

Enjoy!

Конкурс на вакансии в 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 в работе, и нужно быть к этому готовым.