Как стать автором
Обновить
7
0
Виктор Глейм @ViseMoD

Серьёзный аналитик

Отправить сообщение

Рассказ о своём опыте тоже нужно адаптировать к вакансии. Странным будет делать акцент, например, на задачах по разработке какого-нибудь ETL конвейера, когда предлагаемый проект, скажем, про интеграцию с ГосУслугами.

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

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

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

Но это не тренд!

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

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

Ричардс Марк, Форд Нил - Фундаментальный подход к программной архитектуре

Значит, на входе было 26 представителей айти компаний - двух ролей, из разных отраслей бизнеса, плюс с отличным опытом работы. И на основе такой выборки вы сформировали два портрета типового бизнес-аналитика. Качественное исследование, ничего не скажешь!

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

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

Диаграмма контекста в примере с GetDelivery некорректна: база данных, очередь и балансировщик должны быть отдельными контейнерами. Впрочем, балансировщик автор нотации вообще рекомендует указывать на отдельной диаграмме развёртывания.

Бесплатное обучение и мастер-классы

Большинство конференций - платные. Что-то не стыкуется!

А рассматривали изначальнр вариант с веб-приложением для взаимодействия с водителем?

Если в прошлом году редакционных материалов было 37%, а число корпоративных публикаций на полпроцента превышало пользовательские, то в этом году «пирог» практически равномерный, как значок «Мерседеса». Кажется, неплохой баланс, всех поровну!

Читая такие фразы от команды Хабра, напрашивается мысль, что вы сами не знаете, чего хотите достичь! И как это лишь пример. В статье голая статистика (ок, со сравнением динамики за предыдущий год) - выводы предлагается делать сообществу?

Я к тому, что куда полезнее было бы соотнести полученную из чисел информацию с целями и задачами площадки. Если про это была в начале года статья - дать ссылку хотя бы, а в идеале сделать выжимки в стиле "мы стремились к такому эффекту, для чего поменяли то-то, получилось вот что".

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

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

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

Вот стоило бы раскрыть во введении к статье про "не особо зашел". Если дело исключительно в этом:

Параллельно описывали сценарии обработки запросов и маппинг параметров API в конфлюенсе.

то в чём именно проявилось неудобство в разработке и использовании частей спецификации в разных местах?

Потребности рынка с вами не согласны. В компентеции системного аналитика в РФ уже как много лет входит большой пласт работ по проектированию решений - и как раз разработка спецификаций API стоит в первых рядах. При этом обязанность по выявлению и анализу требований никуда не уходит.

Вы не правы. За "банкет" уже давно платят также ЕС и США, и вряд ли он прекратится в следующем году.

Слишком много внимания мнению министра, которое не подкреплено статистикой. СМИ как обычно вырвали из какой-то беседы фразу и приподнесли её как нечто стоящее.

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

В gRPC один компонент, клиент, вызывает определенные функции в другом программном компоненте — сервере. При этом программная реализация клиента и сервера не имеет особого значения благодаря кроссплатформенности протокола gRPC.

Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.

В примере описания библиотеки я постаралась собрать самые часто встречающиеся (хорошие и не очень) паттерны реализации контрактов.

На официальном сайте Protobuf есть основные рекомендации https://protobuf.dev/programming-guides/dos-donts/ - можно было бы добавить в статью.

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

Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.

REST API

Нет документирования и стандартизации.

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

Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.

А HTTP-коды описаны в стандарте https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes.

gRPC

Контракт: обязательно пишется по стандарту Protocol Buffers, компилируется внутренним компилятором protoc, который генерирует необходимый исходный код классов из определений в proto-файле.

Стандартизация кодов ошибок, зашитая в protobuf.

Строго говоря, gRPC можно использовать с другими форматами передачи данных, например https://grpc.io/blog/grpc-with-json/

С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model

Распил чего? Сказано же, что за собственные средства разработка ведётся.

Одного внимания мало, нужно замешивать в коктейль волю и интерес. Об этом весьма неплохая книга: https://www.livelib.ru/book/1000457252-pamyat-i-uhod-za-nej-vilyam-v-atkinson

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность

Специализация

Systems Analyst, Business Analyst
Senior