Что такое анализ и кто такой аналитик

Многим из нас знакомо слово «анализ» еще со школы или универа, по урокам литературы или парам по мат. анализу. Обычно это слово ассоциируется с изучением и исследованием. В широком смысле это корректно, потому что проведение анализа является исследованием. Однако исследования могут проводиться разными способами, а анализ – лишь один из способов.

В чем суть анализа?

Анализ — это способ разделить что-то сложное на простые и понятные части. Слово «анализ» буквально переводится как «разложение, разделение». Представьте, что вы хотите понять, как стать аналитиком. Чтобы ответить на этот вопрос, его нужно разбить на подзадачи, например:

1. Погуглить статьи на эту тему;
2. Узнать, какие навыки нужны;
3. Найти курсы, обучающие этим навыкам;
4. Пройти курс и освоить навыки;
5. Устроиться на работу аналитиком.

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

Кто такой аналитик?

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

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

Виды аналитиков и в чём отличия

Вообще, существует множество ролей со словом “аналитик” в названии, в том числе в IT сфере. Поэтому мы остановимся на самых популярных и близких нам: аналитик данных, бизнес-аналитик и системный аналитик.

Чем они отличаются?

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

2. Бизнес-аналитики занимаются поиском вариантов оптимизации процессов бизнеса.
Например, давайте представим, что тот же сервис доставки, обнаружил, что их прямой конкурент доставляет еду в два раза быстрее. Задачей бизнес-аналитика будет, во-первых, обнаружить эту проблему, а, во-вторых, понять причину и предложить решение для ускорения доставки сервиса, согласовать это с руководителями бизнеса. А после принятия решения о том как устранить проблему, бизнес-аналитики описывают решение в формате бизнес-требований (верхнеуровневое описание того, что нужно бизнесу);

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

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

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

Всем привет
Мы решили, что живые обсуждения лучше текстов, особенно в классной компании.

Приглашаем вас!

Онлайн-встречи с командой аналитиков KODE:

1. "Как войти в профессию системного аналитика: первые шаги и лайфхаки"
Дарья Шелаева, старший аналитик KODE и Якуб Картоев, тимлид отдела системного анализа KODE
2 июля, 19:00 (мск)
Регистрация

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

2. "Чего работодатель ждет от соискателя на позицию джуниор"
Полина Майорова, старший аналитик KODE и Алексей Плаксин, системный аналитик KODE
16 июля, 19:00 (мск)
Регистрация

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

3. "Типичные ошибки системного аналитика в начале карьеры и как их избежать"
Якуб Картоев, тимлид отдела системного анализа KODE
30 июля, 19:00 (мск)
Регистрация

Рассмотрим самые распространенные ошибки, которые совершают начинающие аналитики, и дадим советы по их предотвращению. Разбор реальных кейсов и ситуаций.

Записи эфиров не будет, ждем вас онлайн!

Плюсы и минусы работы аналитиком

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

Будет много субъективного и спорного, начнем с минусов:

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

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

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

А в чем кайф?

Тут попроще:

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

Скорость развития. Я неоднократно становился свидетелем того как аналитики вырастали от джуна до мидла за 1.5-2 года, по-моему это очень быстро. У меня нет никакой статистики, но кажется тем же разработчикам расти посложнее. Вижу две причины: (1) у них набор компетенции пошире (больше навыков, инструментов и тп) и (2) область присутствия поуже, аналитики с первых дней всюду на проекте: и с заказчиком, и с командой, и в ресерче, и в проектировании. Субъективное, конечно, но мнение;

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

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

Зарплаты высокие даже по меркам IT. Тут уже больше объективизма, но когда будете гуглить «зарплата системного аналитика», делайте поправку на то, что в статистике скорее всего учитываются данные по открытым вакансиям, в которых всегда уровень ЗП выше чем в среднем по рынку (иначе не указывали бы его).

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

Недавно сходил к нашим ребятам на подкаст “Вдруг тут что-то важное”

Это подкаст про карьерный рост в IT для начинающих специалистов, поэтому говорили о моих любимых темах:

• менторской стажировке, на которую сейчас идет набор: Что такое менторская стажировка и как она проходит в KODE;
• Что отличает джуна от мидла;
• Где брать первые проекты и опыт для резюме;
• О нашей новой программе “Симулятор системного анализа”, которая сейчас начинает свою работу;

Послушать можно тут:
• ЯМузыка
• Apple Podcasts
• ВК
• Youtube

Буду рад обсудить в комментариях!

Напоминаем, завтра состоится наша первая онлайн-встреча “Как войти в профессию системного аналитика: первые шаги и лайфхаки”

Обещаем много пользы и конкретики. Только выжимка нашего реального опыта проведения стажировок и развития сотрудников.

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

Программа встречи:

1. Введение и знакомство.
2. Необходимые навыки на джуниор позиции для системного аналитика (софт-скиллы, хард-скиллы, проектный подход).
3. Где искать и как выбирать первые проекты.
4. Лайфхаки прохождения интервью.
5. Премьера новой программы "Симулятор системного анализа".
6. Вопросы и дискуссия.

Дата: 2 июля
Время: 19:00 (мск)
Регистрация по ссылке

Напоминаем, что через час состоится наш онлайн-эфир с Якубом и Дарьей!

Тема встречи: "Как войти в профессию системного аналитика: первые шаги и лайфхаки"

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

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

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

Мы публикуем полезный отрывок по 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. кто-то наоборот переносит логику на сервер настолько, насколько это возможно, а на клиенте оставляют только отображение данных и минимальные вычисления – это называется «тонкий клиент».

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

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