Я вот не делаю вывод, что они пытаются заменить техсобес опросом со стороны рекрутера. Больше похоже на устный опросник, чтоб выяснить, где описание в резюме расходится с реальным опытом; плюс собрать больше деталей по используемым технологиям. Это и правда может помочь отсеить кандидатов, которые приукрасили резюме (например, проектировали REST API, но один раз два года назад) или наоборот описали слишком обобщенно ("использовал нотацию UML").
Рассказ о своём опыте тоже нужно адаптировать к вакансии. Странным будет делать акцент, например, на задачах по разработке какого-нибудь ETL конвейера, когда предлагаемый проект, скажем, про интеграцию с ГосУслугами.
А чтобы узнать детали о новом проекте, нужно как раз задавать их после тех. собеседования. Рекрутер обычно очень поверхностно знает специфику. Впрочем, не факт, что и собеседующий на техническом сможет подробно ответить на такие вопросы - тут скорее их надо запасти для интервью с командой / руководством.
Что значит "придумали"? Появление роли системного аналитика это следствие потребности айтишной отрасли в отдельном специалисте. А профстандарт лишь систематизирует требования к знаниям и навыкам такого специалиста в зависимости от уровня.
Большой спектр требований и обязанностей в вакансиях аналитика присутствовал почти всегда, т.е. по моим наблюдениям - например, умение общаться с закачиком и описывать структуру БД, или составлять макеты интерфейса пользователя и участвовать в приёмке-передаче системы - такие пункты можно было увидеть ещё в начале 2010-х.
Но это не тренд!
В российском айти основная тенденция последних лет сводится к тому, что акцент в работе системного-аналитика смещается от выявления требований к проектированию решений. Собственно, новая версия профстандарта это и отражает. Некоторые из его авторов про это рассказывали на различных площадках.
А поскольку вы, судя по тексту в начале статьи, смотрите на работу аналитика прежде всего с точки зрения модели компетенции BABoK, то и "новые" реалии рынка труда сбивают вас с толку. И, кстати, системный анализ как научный метод или даже дисциплина не является основой знаний исключительно аналитика - по-хорошему этим должен владеть любой ИТ-инженер.
Значит, на входе было 26 представителей айти компаний - двух ролей, из разных отраслей бизнеса, плюс с отличным опытом работы. И на основе такой выборки вы сформировали два портрета типового бизнес-аналитика. Качественное исследование, ничего не скажешь!
Продакт не должен делать работу бизнес-аналитика, хотя может в некоторых ситуациях. Иначе не было бы двух отдельных специальностей и профстандартов для них.
Касаемо отсутствия системных аналитиков в некоторых компаниях. Это решение конкретной компании, у которой наверняка есть на то веские причины. Во многих других фирмах ситуация иная - и системный аналитик может быть обязательной ролью в команде.
Диаграмма контекста в примере с GetDelivery некорректна: база данных, очередь и балансировщик должны быть отдельными контейнерами. Впрочем, балансировщик автор нотации вообще рекомендует указывать на отдельной диаграмме развёртывания.
Если в прошлом году редакционных материалов было 37%, а число корпоративных публикаций на полпроцента превышало пользовательские, то в этом году «пирог» практически равномерный, как значок «Мерседеса». Кажется, неплохой баланс, всех поровну!
Читая такие фразы от команды Хабра, напрашивается мысль, что вы сами не знаете, чего хотите достичь! И как это лишь пример. В статье голая статистика (ок, со сравнением динамики за предыдущий год) - выводы предлагается делать сообществу?
Я к тому, что куда полезнее было бы соотнести полученную из чисел информацию с целями и задачами площадки. Если про это была в начале года статья - дать ссылку хотя бы, а в идеале сделать выжимки в стиле "мы стремились к такому эффекту, для чего поменяли то-то, получилось вот что".
Иначе получается, что все эти числа, как сториз в мобильном приложении банка про траты за прошедший год: если не было у тебя задачи, например, сократить расходы на сигареты или накопить на новый монитор - то посмотреть разок просто из любопытства.
Потребности рынка с вами не согласны. В компентеции системного аналитика в РФ уже как много лет входит большой пласт работ по проектированию решений - и как раз разработка спецификаций API стоит в первых рядах. При этом обязанность по выявлению и анализу требований никуда не уходит.
Слишком много внимания мнению министра, которое не подкреплено статистикой. СМИ как обычно вырвали из какой-то беседы фразу и приподнесли её как нечто стоящее.
Позволю себе тоже придраться к некоторым моментам по тексту:
В gRPC один компонент, клиент, вызывает определенные функции в другом программном компоненте — сервере. При этом программная реализация клиента и сервера не имеет особого значения благодаря кроссплатформенности протокола gRPC.
Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.
В примере описания библиотеки я постаралась собрать самые часто встречающиеся (хорошие и не очень) паттерны реализации контрактов.
Proto сильно облегчает жизнь разработчикам сервиса, для которого пишется контракт. Если меняется ответ, сервис узнает об этом сразу, а не когда обновят документацию (если обновят). Сваггер всем писать всегда лень.
Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.
REST API
Нет документирования и стандартизации.
Нет стандарта использования кодов ответов, поэтому часто в успешных кодах могут передаваться ошибки.
Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.
Контракт: обязательно пишется по стандарту Protocol Buffers, компилируется внутренним компилятором protoc, который генерирует необходимый исходный код классов из определений в proto-файле.
С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model
Я вот не делаю вывод, что они пытаются заменить техсобес опросом со стороны рекрутера. Больше похоже на устный опросник, чтоб выяснить, где описание в резюме расходится с реальным опытом; плюс собрать больше деталей по используемым технологиям. Это и правда может помочь отсеить кандидатов, которые приукрасили резюме (например, проектировали REST API, но один раз два года назад) или наоборот описали слишком обобщенно ("использовал нотацию UML").
Рассказ о своём опыте тоже нужно адаптировать к вакансии. Странным будет делать акцент, например, на задачах по разработке какого-нибудь ETL конвейера, когда предлагаемый проект, скажем, про интеграцию с ГосУслугами.
А чтобы узнать детали о новом проекте, нужно как раз задавать их после тех. собеседования. Рекрутер обычно очень поверхностно знает специфику. Впрочем, не факт, что и собеседующий на техническом сможет подробно ответить на такие вопросы - тут скорее их надо запасти для интервью с командой / руководством.
Что значит "придумали"? Появление роли системного аналитика это следствие потребности айтишной отрасли в отдельном специалисте. А профстандарт лишь систематизирует требования к знаниям и навыкам такого специалиста в зависимости от уровня.
Большой спектр требований и обязанностей в вакансиях аналитика присутствовал почти всегда, т.е. по моим наблюдениям - например, умение общаться с закачиком и описывать структуру БД, или составлять макеты интерфейса пользователя и участвовать в приёмке-передаче системы - такие пункты можно было увидеть ещё в начале 2010-х.
Но это не тренд!
В российском айти основная тенденция последних лет сводится к тому, что акцент в работе системного-аналитика смещается от выявления требований к проектированию решений. Собственно, новая версия профстандарта это и отражает. Некоторые из его авторов про это рассказывали на различных площадках.
А поскольку вы, судя по тексту в начале статьи, смотрите на работу аналитика прежде всего с точки зрения модели компетенции BABoK, то и "новые" реалии рынка труда сбивают вас с толку. И, кстати, системный анализ как научный метод или даже дисциплина не является основой знаний исключительно аналитика - по-хорошему этим должен владеть любой ИТ-инженер.
Ричардс Марк, Форд Нил - Фундаментальный подход к программной архитектуре
Значит, на входе было 26 представителей айти компаний - двух ролей, из разных отраслей бизнеса, плюс с отличным опытом работы. И на основе такой выборки вы сформировали два портрета типового бизнес-аналитика. Качественное исследование, ничего не скажешь!
Продакт не должен делать работу бизнес-аналитика, хотя может в некоторых ситуациях. Иначе не было бы двух отдельных специальностей и профстандартов для них.
Касаемо отсутствия системных аналитиков в некоторых компаниях. Это решение конкретной компании, у которой наверняка есть на то веские причины. Во многих других фирмах ситуация иная - и системный аналитик может быть обязательной ролью в команде.
Диаграмма контекста в примере с GetDelivery некорректна: база данных, очередь и балансировщик должны быть отдельными контейнерами. Впрочем, балансировщик автор нотации вообще рекомендует указывать на отдельной диаграмме развёртывания.
Бесплатное обучение и мастер-классы
Большинство конференций - платные. Что-то не стыкуется!
А рассматривали изначальнр вариант с веб-приложением для взаимодействия с водителем?
Читая такие фразы от команды Хабра, напрашивается мысль, что вы сами не знаете, чего хотите достичь! И как это лишь пример. В статье голая статистика (ок, со сравнением динамики за предыдущий год) - выводы предлагается делать сообществу?
Я к тому, что куда полезнее было бы соотнести полученную из чисел информацию с целями и задачами площадки. Если про это была в начале года статья - дать ссылку хотя бы, а в идеале сделать выжимки в стиле "мы стремились к такому эффекту, для чего поменяли то-то, получилось вот что".
Иначе получается, что все эти числа, как сториз в мобильном приложении банка про траты за прошедший год: если не было у тебя задачи, например, сократить расходы на сигареты или накопить на новый монитор - то посмотреть разок просто из любопытства.
Как минимум странно судить о потребностях рынка труда по опыту проведения собеседований в одной или даже нескольких компаниях.
В этом году был утверждён профстандарт "системный аналитик", в котором акцент сделан на обязанностях по разработке проектных решений.
Вот стоило бы раскрыть во введении к статье про "не особо зашел". Если дело исключительно в этом:
то в чём именно проявилось неудобство в разработке и использовании частей спецификации в разных местах?
Потребности рынка с вами не согласны. В компентеции системного аналитика в РФ уже как много лет входит большой пласт работ по проектированию решений - и как раз разработка спецификаций API стоит в первых рядах. При этом обязанность по выявлению и анализу требований никуда не уходит.
Вы не правы. За "банкет" уже давно платят также ЕС и США, и вряд ли он прекратится в следующем году.
Слишком много внимания мнению министра, которое не подкреплено статистикой. СМИ как обычно вырвали из какой-то беседы фразу и приподнесли её как нечто стоящее.
Позволю себе тоже придраться к некоторым моментам по тексту:
Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.
На официальном сайте Protobuf есть основные рекомендации https://protobuf.dev/programming-guides/dos-donts/ - можно было бы добавить в статью.
Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.
Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.
А HTTP-коды описаны в стандарте https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes.
Строго говоря, gRPC можно использовать с другими форматами передачи данных, например https://grpc.io/blog/grpc-with-json/
С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model
Это аллюзия к Авроре?
Распил чего? Сказано же, что за собственные средства разработка ведётся.
Это предположение?