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

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

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

2ГИС с самой первой версии навигатора умеет строить разные виды маршрутов — автомобильные, пешеходные, маршруты на общественном транспорте — на мобильных устройствах без доступа к интернету, но только внутри городов.

С 2019 года 2ГИС также умеет строить маршруты между городами, но только при наличии интернета.

Уже давно наши пользователи просили дать возможность строить междугородние маршруты без доступа к сети. И вот, мы наконец сделали это.

Можно ли объяснить модели, что такое «уютно», «романтично» или «пофоткаться»? Мы попробовали — и оказалось, что даже самые субъективные ощущения можно превратить в метрику.

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

2ГИС Ситискан — это мобильное приложение для автоматизированной съёмки городской среды. Оно устанавливается на смартфон, закреплённый в автомобиле, и во время движения делает снимки, собирает координаты, скорость и другие параметры. Эти данные обрабатываются с помощью ИИ, чтобы находить проблемы в инфраструктуре: ямы, мусор, повреждённые объекты и другое.

Одна из ключевых задач приложения — снимать изображения с высокой частотой, особенно при объездах сложных участков. Но на практике оказалось, что стандартный метод съёмки takePicture во Flutter может занимать до 3 секунд на один кадр. Это делает невозможной съёмку даже 1 кадра в секунду, не говоря уже о 4 кадрах, которые нам нужны для точного анализа.

В этой статье мы — Руслан Цицер и Арген Жукеев @zhukeev— расскажем, как исследовали узкие места, перепробовали разные подходы — от RepaintBoundary до нативной обработки на C и Java — и в итоге добились стабильной съёмки с минимальной задержкой. Наш кейс будет полезен Flutter-разработчикам, которым необходима высокая частота съёмки (до 4 fps и выше) для своих приложений и инженерам в области компьютерного зрения и машинного обучения или разработчики AR/VR-решений на Flutter, где важны каждая миллисекунда и каждый пиксель.

Привет! Я Алексей из команды Fiji, которая занимается внутренним продуктом для хранения и редактирования геоданных. Мы уже немного рассказывали о нем на Хабре: раз, два, три, четыре.

Наш проект активно развивается уже 10 лет, недавно ещё и команда выросла вдвое. Соответственно, почти вдвое увеличилось количество задач, а вместе с ним — и сложность интеграций с другими командами. Требования часто дополняются и меняются по ходу реализации, статьи в Confluence не всегда актуализируются, а часть информации оседает в чатах и на созвонах. Только код в мастере стабильно отражает то, что реально работает на продакшне.

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

Так и появилась идея сделать помощника как для новых ребят, так и для старичков, так как весь контекст держать в головах уже проблематично: основной солюшн — это почти 15 тысяч файлов на C# и около 1.5 млн строк кода, плюс утилиты и пара сервисов на Java.  В статье — история о пройденном пути создания командного ассистента, который помогает отвечать на любые вопросы о проекте.

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

Мы решили сделать навигацию нагляднее — с помощью AR прямо через камеру смартфона. Сейчас технология доступна в столичных торговых центрах «Авиапарк», «Афимолл», «Европейский» и в «Галерее» в Петербурге.

В этой статье расскажем, как мы подошли к задаче с точки зрения компьютерного зрения, какие грабли собрали, как ускоряли локализацию и как боролись с погрешностями ARKit.

Поиск — одна из ключевых функций в 2ГИС. Он помогает миллионам пользователей каждый день находить нужные места в городе. Долгое время мы опирались на классические методы: морфологию, справочник организаций, геопозицию и популярность объектов. Это позволяло покрывать множество сценариев, но со временем стало понятно — этого недостаточно.

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

1. как понять атмосферу заведения и добавили новый атрибут «вайб-фильтры»;

2. как находить похожие места по изображениям и сделали поиск по фото.

3. как дать пользователю возможность искать «по смыслу» и реализовали ИИ-поиск. 

Привет! Меня зовут Оля, я руководитель группы тестирования в 2ГИС. В QA пришла в 2016 году через переквалификацию и ещё хорошо помню, каково это — искать первую работу без опыта. Сейчас активно участвую в найме: провожу технические и финальные собеседования, много общаюсь с HR-коллегами и читаю резюме новичков.

За последние годы ситуация на рынке заметно изменилась. По данным HeadHunter и Хабр.Карьеры, в 2024 году вакансии для джунов составляли всего 10% от всех предложений, на каждую позицию претендовало около 11 человек. В 2025 году стало еще сложнее — количество входных позиций по всему миру упало на 70% (исследование Ravio).

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

Что, если бы дизайн-система умела не просто менять язык, а адаптироваться под культуру, направление чтения, шрифты и даже знаки препинания? А если бы она делала это автоматически — без боли, костылей и ручной работы?

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

Анимация уже давно стала стандартным инструментом в дизайне и способна выполнять самые разные задачи: обеспечивает плавность и приятную отзывчивость — как в современных ОС (например, дизайн-система Android Material 3 или Apple, которые используют принципы Springs), транслирует голос бренда и становится частью айдентики (CashMoney, Instagram, Plex), добавляет продуктовым сценариям эмоциональность и значимость. Недавно и перед нашей командой встала задача «оживить» некоторые из них. 

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

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

Мы живём в эпоху больших языковых моделей — инструментов вроде ChatGPT, Gemini, Claude, которые поражают своими способностями: они пишут тексты, отвечают на сложные вопросы, генерируют код и даже ведут осмысленные диалоги. Но задумывались ли вы, как им удаётся не просто понимать отдельные фразы, но и удерживать смысл длинных документов, многочасовых бесед или даже целых книг?

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

Мы не нашли свежего исследования про QA и решили: нужно делать своё. Так появилось наше первое большое огромное исследование про QA в России.

 Что внутри?

— Как работают в QA: какие процессы, инструменты и подходы используют.

— Зачем тестировщики работают: мотивация, удовлетворённость сферой и зарплатой.

— Будущее QA: как инженеры видят развитие профессии и какую роль в этом сыграет AI.  

Приправили статистику комментариями ребят из сообщества. 

Под катом собрали несколько важных инсайтов. С полной версией исследования можно ознакомиться по ссылке: https://qa-survey-2025.2gis.ru

Аврора — это отечественная мобильная ОС, развиваемая компанией «Открытая мобильная платформа». Она построена на базе Linux и унаследовала часть решений от Sailfish OS, но за последние годы превратилась в самостоятельную, зрелую платформу. Пятая версия, вышедшая в 2024 году, ориентирована не только на корпоративный сектор, но и на массового пользователя. В ней — переработанный интерфейс, поддержка планшетов, 64-битная архитектура, повышенная устойчивость и растущая экосистема приложений.

И вот в эту экосистему мы решили встроить наш Flutter Mobile SDK. В этой статье мы — тимлид Mobile SDK в 2ГИС Александр Максимовский и Flutter-разработчик @Sameri11 Михаил Новосельцев — расскажем про технические детали адаптации.

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

В этом посте расскажем, как мы искали вдохновение и свежие идеи для 2ГИС в Китае. Мы съездили туда командой продактов и дизайнеров транспорта: изучили местные навигационные приложения, культуру и протестировали транспортные сценарии в их естественной среде обитания.

Что, если навигатор перестанет упрямо твердить «Развернитесь!», когда  вы свернули с маршрута и предложит новый, более вам подходящий?

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

На связи тимлид Mobile SDK в 2ГИС Александр Максимовский и Flutter-разработчик Михаил Новосельцев (@Sameri11). Наша команда разработала собственный продукт для генерации платформенного Dart-кода на базе публичного C++ API, и мы уже рассказали об основных принципах его работы.

Эта статья — про то, как на основе сырого сгенерированного кода реализовать SDK, готовый к внедрению в пользовательские Flutter-приложения.

Меня зовут Александр Максимовский, и я тимлид команды Mobile SDK в 2ГИС. Мы разрабатываем SDK — набор инструментов, который позволяет другим разработчикам внедрять наши технологии (карту, справочник, построение маршрутов и навигатор) в свои мобильные приложения. Благодаря нам можно быстро и удобно интегрировать функциональность 2ГИС, не тратя время на реализацию сложных решений с нуля. Мы сделали решение, которое позволяет из Flutter-приложения напрямую вызывать C++ код. Под капотом:

▪️ FFI для прямого взаимодействия с C++ кодом ядром;

▪️ Кодогенерируемое API почти полностью аналогично iOS и Android Mobile SDK;

▪️ TextureWidget вместо PlatformView для рендеринга карты;

▪️ Единые виджеты для отображения карты как для Android, так и для iOS.

Если вы работаете с Flutter, интегрируете карты или маршруты или просто любите разбираться в архитектуре SDK — эта статья для вас. Под катом детально рассказываю про основу продукта — кодогенератор для генерации платформенного Dart-кода на основе C++ интерфейсов.

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

^{Руководитель: Хочешь техлидить новый проект?}

^{Я: Да, конечно. А что за проект?}

^{Руководитель: Распределённые бэкенды на Go.}

^{Я: Go? Но я же скалист-функциональщик…}

^{Чуть позже}

^{Коллега: Слышал, что ты будешь техлидить другой проект — вы там тоже Scala завозить будете?}

^{Я: Нет, будем писать на Go.}

^{Коллега: Ты что, бросаешь Scala и нашу тусовку?!}

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

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

Как запустить поисковый сервис, если у тебя всего три недели, а данные нужно агрегировать с десятков источников, каждый из которых работает по своим правилам? Как обойти жёсткие лимиты партнёров, которые ограничивают запросы в 500 RPM и p99 до 5 секунд, когда для быстрой загрузки первых результатов нужно минимум 1000 RPM? Как справиться с геопоиском, когда традиционные решения вроде Elasticsearch не подходят?

В 2022 году 2ГИС запустил сервис бронирования Отелло, и перед нами стояла амбициозная цель — не просто создать поиск, а сделать его быстрым, надёжным и масштабируемым, чтобы успеть занять место на рынке. Спойлер: мы справились. В этой статье расскажем, как именно.

Материал будет полезен бэкенд-разработчикам и продакт-менеджерам, которые сталкиваются с задачами интеграции сложных данных, высокой нагрузки и оптимизации поисковых алгоритмов. А если тебе понравится наш проект, рассмотри нашу вакансию — мы в поисках Senior Golang Engineer.