25 декабря я проведу бесплатный вебинар: «Разработка требований к интеграции в практической задаче», где мы рассмотрим проработку и описание требований на практике с реальным кейсом. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Подробно разберем процесс работы с требованиями в интеграционных задачах
Что мы поняли о пользователях из России, пока делали UX-исследование для гватемальцев
Немногие с ходу вспомнят, где на карте мира находится Гватемала. Она расположена в южной части Северной Америки, на севере граничит с Мексикой и имеет выход сразу к двум океанам — Тихому и Атлантическому.
Итоги нашей работы оказались интересными не только для заказчика, но и для нас: они подсветили различия в цифровом поведении между гватемальскими и российскими пользователями. Делимся ими с вами в этом посте.
1. Пользователи в Гватемале ценят личное общение.
Гватемальцы предпочитают звонить напрямую, чтобы уточнить детали, они больше ценят возможность живого общения с представителем бизнеса. При этом большинство опрошенных в исследовании положительно отнеслись к ссылкам на чаты WhatsApp, а вот чат-боты их совсем не интересовали. Сравните с российскими пользователями, которые чаще выбирают переписки в мессенджерах и всё реже пользуются телефонными звонками.
В работе над сайтом девелопера для нас эта особенность гватемальцев стала сигналом о необходимости разместить контакты на самом видном месте — так, чтобы их можно было найти в один клик.
2. 3D-модели жилья повышают доверие.
Простые фотографии не производили должного впечатления на гватемальских пользователей. Они хотели видеть больше деталей, желательно в формате, который позволил бы «почувствовать» пространство. Интерактивные 3D-туры стали идеальным решением, которое позволило потенциальным покупателям глубже погрузиться в атмосферу района и нового жилья.
В России, например, 3D-модели также находят отклик у пользователей, но часто воспринимаются как дополнительная опция, а не обязательный элемент.
3. Карта территории — необходимость.
Район, где работал наш заказчик, состоял из нескольких блоков с буквенными обозначениями домов. Для туристов или неместных людей такая навигация была сложной. Многие не могли понять, как добраться до нужного места. Поэтому мы решили добавить на сайт интерактивную карты.
Интересно, что местные жители и риелторы, которые хорошо знали город, не видели в этом проблемы. Российские же пользователи привыкли считать карты базовым функционалом, без которого сайт теряет значительную часть своей пользы.
Этот случай наглядно показал, как разные группы пользователей могут по-разному воспринимать одни и те же аспекты интерфейса.
4. Всем гватемальцам важна экология.
Вопросы экологии оказались важны для всех респондентов в Гватемале, независимо от возраста или социального статуса. Пользователи позитивно отзывались о разделе сайта, посвященном экологическим проектам, и считали его наличие важным показателем ответственности компании.
Для нас этот инсайт стал важным аргументом в пользу сохранения и улучшения существующего раздела. Это резко контрастирует с российской аудиторией, которая уделяет экологии мало внимания.
Тут мы собрали только малую часть интересных открытий нашего проекта. Если хотите узнать больше деталей и результатов, читайтекейс в нашем блоге на Хабре.
Макс приехал в Санкт-Петербург и гуляет по Васильевскому острову. Большая часть острова — это сетка из трёх параллельных проспектов и перпендикулярных им линий. Макс хочет дойти от причалов (точка А) до дома друга (точка В), не проходя по одной и той же улице дважды и не разворачиваясь назад.
Ему нужно пройти шесть кварталов вперёд и два вправо. Можно сначала повернуть, потом идти вперёд. Можно сначала пройти вперёд, а потом уже поворачивать. А можно идти вперёд, потом повернуть, потом снова идти вперёд… в общем, вариантов много! Но сколько именно?
Посчитайте количество способов добраться из точки А в точку B. Делитесь способом решения и результатом.
Собрали статьи, которые будут интересны начинающим аналитикам. Если вы только начинаете знакомство с SQL или хотите освежить знания, эта подборка для вас.
Типы данных SQL — что о них нужно знать начинающему аналитику. Разбираем, какими они бывают и как с ними работать.
Основные ошибки SQL — список распространённых ошибок в работе с запросами баз данных SQL и лучших практик, о которых забывают некоторые пользователи. Рассказываем, как найти ошибки и исправить их.
Производители SoC, как правило, предоставляют окружение для разработки и документацию с примерами реализации универсальных решений. Но много важных деталей упускается или скрывается от пользователя. В итоге нетривиальная модификация системы требует долгих исследований и экспериментов.
Изучили все нюансы на практике за вас, реализовав проект запуска Embedded Linux на Hard- и Soft-процессорах Xilinx Zynq. Пойдем по этапам:
Вебинар «Базы данных для системного аналитика на практике»
12 декабря я проведу бесплатный вебинар: «Базы данных для системного аналитика на практике», где я подробно разберу необходимые навыки для системного аналитика в практических задачах. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Разберем задачи, которые системный аналитик решает в базе данных
Поговорим о необходимых навыках
Рассмотрим проблемы, возникающие на практике
Разберем подходы к их решению на примере реальных задач
– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.
– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.
– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.
– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает. Поэтому правильнее готовить такие схемы в виде кода. Хорошим решением будет Structurizr, опенсорсная self-hosted штуковина. Помимо самих схем, там же можно документировать своё решение.
– По моему опыту очень полезной может оказаться Deployment-диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение:
Пример Deployment-диаграммы
Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.
Пишем эффективные аналитические запросы: третья лекция курса в МГТУ им. Баумана
Третья лекция нашего курса «Deep dive into SQL and DWH» прошла 21 ноября — делимся видеозаписью!
Дата-архитектор Павел Ковалёв рассказал о внутреннем устройстве систем Greenplum и Clickhouse и возможностях, которые они предоставляют с точки зрения оптимизации запросов.
Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?
Мы обсудили, как фиксировать зоны ответственности. А теперь обсудим несколько причин, почему это полезно: – если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами – позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены – более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно – и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
Простыми словами: как устроена аутентификация/авторизация через Keycloak
При работе с микросервисной архитектурой, тем более в финтехе, системный аналитик рано или поздно столкнется с межсервисной аутентификацией и авторизацией и системами, их обеспечивающими. У нас это Keycloak.
Оказалось, этот зверь полезный, и среди его достоинств - opensource и дружелюбные взаимоотношения с Java.
Keycloak позволяет создавать для разных систем и сред realms, к которым добавляют сущности клиентов (других систем) с присвоением определенных прав. Схема аутентификации/авторизации через Keycloak несложная и чем-то напоминает аутентификацию по сертификатам. Нужно создать клиента системы А в realm системы B, добавить определенные роли и не забыть получить client_secret, по которому система А будет аутентифицироваться уже в самом Keycloak.
А теперь процесс по порядку:
Система А делает запрос на токен в Keycloak (аутентификация по client_id и client_secret).
Keycloak отдает JWT-токен, в котором имеется вся необходимая информация, включая роли и все, что нужно для проверки валидности токена.
Система А передает запрос с указанием в заголовке токена в систему B.
Система B проверяет валидность токена (либо напрямую обращаясь к Keycloak, либо при помощи ранее полученного сертификата).
Если все в порядке и с токеном, и с правами – система B отдает ответ системе А.
Совсем не страшно. Но деталей хватит и на целую статью. Какие вопросы лучше затронуть в ней? Обсудим в комментариях.
Продолжая тему архитектурных схем. Ещё одним полезным артефактом команды разработки проекта является табличка с зонами ответственности и компетенциями. И вроде банально, но смотрел в разные проекты и не везде подобное видел.
Структура подобной таблички: – сервис – самая верхнеуровневая сущность для удобной навигации по табличке. Если у вас монолитная архитектура, то можно эту колонку опустить или взять любую другую верхнеуровневую единицу разделения. Тут главное, чтобы вам удобно было ориентироваться – модуль – более конкретное уточнение функционала – ответственный разработчик – кто именно отвечает за этот модуль, с ним советуются, если что-то хотят туда внедрить, его тегают в МРах, к нему идут, если что-то сильно сломалось – разработчики – те, кто принимал участие в разработке модуля и представляют, что там происходит – аналитик – если в вашей команде есть системные аналитики, то имеет смысл указать этих ребят в этой же табличке
Конечно, такая табличка может разрастаться на другие области: бизнес-анализ, тестирование, дизайн. Но это уже пусть руководители проектов ведут. Я тут делаю акцент на команде разработки. Чтобы к пуговицам претензий не было.
Следующая лекция курса будет посвящена техникам оптимизации аналитических SQL-запросов и состоится уже в ближайший четверг, 21 ноября, с 17:25 до 19:00.
Один из наших стартапных продуктов дозрел до того, чтобы для него подготовили архитектурную схему. По результату я даже удивился, насколько всё стало разухабисто.
Для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.
Онбординг. Технический онбординг мы начинаем с архитектурной схемы. Это позволяет новому сотруднику посмотреть на систему с высоты птичьего полета, начать ориентироваться, кто на ком стоял. Тут же можно бегло рассказать о каждом компоненте, внешних зависимостях и способах их взаимодействия. Причём это работает не только с разработчиками.
Обсуждение работ со смежными командами. Обычно разрабатываемая система работает не в соло. И есть соседние сервисы, с которыми нужно интегрироваться. Первичные обсуждения всегда удобно делать с наглядной картинкой.
Обсуждение и планирование больших фичей. Когда планируется разработка чего-то сложного, затрагивающего многие компоненты/сервисы. Опять же, можно собраться с командой разработки, аналитиками, обсудить и зафиксировать первичные договорённости. Эта же картинка будет полезна, когда перед стартом разработки будет презентоваться окончательное решение.
Напоминалка о сложности. Да, для этого также нужна архитектурная схема, просто чтобы помнить о комплексности, о потребности в людях на хозяйстве, о невозможности реализовать фичу в маленькие сроки, о наличии вооот такого сервиса, о котором уже никто и не помнит.
Следующая лекция курса, посвященная архитектурному обзору инструментов для построения DWH, пройдёт уже в ближайший четверг, 14 ноября, с 17:25 до 19:00. Присоединяйтесь в онлайне!
***
Больше информации о наших лекциях, митапах, статьях и других полезных материалах про ИТ, в тг-канале Sravni Tech.
В архитектуру входят сервисы, базы данных, брокеры сообщений, внешние интеграции и хорошо бы понимать, кто на ком стоял и кто с кем взаимодействует.
Замечательная статья, охватывающая многие аспекты документирования. Начинает автор с главного, объясняя, зачем нужно документировать архитектуру.
В качестве структурного шаблона для документирования предлагается использовать arc42. Для визуализации — C4 model. Кстати, C4 оказалась вполне удобной, и мы активно применяем её у себя.
Из приятного — для arc42 и C4 автор приводит ссылки на хорошие примеры реализации.
В конце автор рассказывает, как можно всё описанное организовать, применяя подход — documentation as code, а так же приводит полезные тулзы для этого.
Валера Бабушкин в новом Sravni Podcast: «Выйдет GPT-5, и я стану плотником!»
Поговорили с Валерой Бабушкиным — экспертом в области ML и анализа данных, автором книги о проектировании ML-систем.
Обсудили будущее машинного обучения, сложности с поиском хороших инженеров и менеджеров, несовершенство собеседований и специфику работы в big tech. А ещё разыгрываем книгу Валеры — смотрите выпуск до конца и участвуйте в конкурсе!
Также в этом выпуске:
Неизвестный бэкграунд Валеры: чем занимался ранее?
Компетенции и карьерный путь ML-специалистов
Как успешно управлять командами в ИТ
Кто самый крутой в ML прямо сейчас — среди отдельных специалистов и компаний
Аналитики часто сталкиваются с необходимостью представлять сложные данные в простой и понятной форме. Визуальные инструменты, такие как дашборды, диаграммы и нотации, помогают систематизировать информацию, улучшая процессы принятия решений. Эта подборка объяснит ключевые принципы визуализации и способы их использования в бизнесе.
Визуализация данных — применение в работе, основные принципы, способы и инструменты для использования.
Дашборды — что это, какие бывают и как их строить.
ER‑диаграммы — пригодятся системным аналитикам, чтобы определить, с какими данными предстоит работать и как они связаны между собой перед разработкой ПО.
BPMN 2.0 — инструмент для создания моделей бизнес-процессов.
Приглашаем на Alfa Analyze IT Meetup. В программе: генерация документации, LLM и уязвимости
5 ноября в 18:30 проведём третий на тему искусственного интеллекта. Расскажем и покажем, как применять его в работе, а ещё обсудим, какие потенциальные угрозы могут нести большие языковые модели. После докладов оставим время на афтерпати и нетворкинг.
В программе:
№1. Генерация документации на API-сервис рядом с кодом
Как ИИ-агенты могут облегчить формирование системной документации на микросервисы.
Спикер: Иван Шелапутов, руководитель направления
№2. LLM для системных аналитиков на практике
Онлайн-демонстрация работы системного аналитика с ChatGPT на реальной задаче.
Спикер: Андрей Кнутсон, старший системный аналитик.
№3. Уязвимости приложений с LLM
Обсудим, как большие языковые модели, став мощным инструментом для бизнеса, одновременно становятся новой целью для злоумышленников и представляют потенциальные угрозы, о которых важно знать каждому аналитику.
Спикер: Артем Гринько, главный технический лидер разработки
Привет. Меня зовут Настя, я занимаюсь контентом Хабр Карьеры. Недавно мы посмотрели, сколько зарабатывали аналитики в первой половине этого года.
Важно: мы берем данные не из вакансий или резюме, а из калькулятора зарплат — там можно отслеживать, сколько зарабатывают разные специалисты прямо сейчас.
Теперь к зарплатам аналитиков по городам:
Самый высокий рост показали оклады аналитиков из Екатеринбурга (+51%) — до 169 тыс. руб. На втором месте зарплаты в Нижнем Новгороде (+45%) — до 150 тыс. руб. На третьем — рост зарплаты аналитиков из Санкт-Петербурга (+32%), до 185 тыс. руб.
В целом, медианная зарплата аналитиков выросла во всех городах, кроме Челябинска — там она снизилась на 2%, до 140 тыс. руб.
В полном тексте исследования больше данных о зарплатах аналитиков, а если хотите посмотреть, сколько зарабатывают в других специализациях, вы можете отфильтровать калькулятор зарплат по своему запросу.