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

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

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

https://habr.com/ru/post/699702/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699702

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

Мы используем preact/compat — с его помощью получаем доступ к множеству библиотек экосистемы React, что делает разработку более гибкой, и при этом можем использовать Preact. Но эти же плюсы зачастую оборачиваются в обратную сторону: например, нет единой методологии по проектированию приложений, как, например, в Angular. Кроме того, многообразие библиотек усложняет погружение в проект, а свобода в реализации и проектировании может обернуться захламлением кодовой базы, что пугает разработчиков, особенно новичков.

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

Для нашей команды эти проблемы также актуальны. Чтобы их решить раз и навсегда, мы обратились к активно развивающейся методологии Feature-Sliced Design (FSD). Ниже я познакомлю с ее главными принципами и с нашим опытом ее использования. Забыл представиться — я Женя, фронтенд-разработчик в команде Quick Experiments inDrive. Расскажу, как мы занимается разработкой внутренних стартапов на основе бизнес-гипотез с помощью FSD.

https://habr.com/ru/post/693768/?utm_source=habrahabr&utm_medium=rss&utm_campaign=693768

Всем привет! Я Айыына Егорова, Agile Coach в inDrive. Хочу поделиться небольшим опытом работы с командами без спринтов с применением Kanban-метода. Cтатья будет полезна руководителям команд, скрам-мастерам и любым агентам изменений.

Вы узнаете, как быстро запустить работу в команде без спринтов: с чего начать, какими инструментами мы пользуемся в компании и какие ошибки нельзя допускать. Отдельно разберем пример проведения воркшопа STATIK в команде Localization.

https://habr.com/ru/post/692358/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692358

Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент.

https://habr.com/ru/post/692998/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692998

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

Я Лиза, UX писатель в inDriver. В предыдущих статьях я рассказала про то, кто такой UX писатель, зачем он нужен продукту, и чем отличается UX писатель от копирайтера. Если пока не знаете ответов на эти вопросы, советую начать с этих материалов. Если вы уже погружены в сферу — приятного чтения!

https://habr.com/ru/post/690478/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690478

Всем привет, меня зовут Авксентий, я backend-разработчик в inDriver. Думаю, каждый начинающий разработчик сталкивался с проблемой, как правильно выстроить архитектуру и структуру проекта. Ведь организация кода проекта — постоянно развивающаяся проблема, а следование стандартной структуре сохраняет чистоту кода и повышает производительность команды.

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

https://habr.com/ru/post/690088/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690088

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

https://habr.com/ru/post/687102/?utm_source=habrahabr&utm_medium=rss&utm_campaign=687102

UX писатель (UXW) и копирайтер (CW) — две разные профессии. Их путают по одной причине: у них один и тот же основной рабочий инструмент — текст.

С помощью текста копирайтер создает красивую, завораживающую вселенную, а UX писатель наводит там порядок — в этой вселенной невозможно потеряться, провалить поставленную задачу, почувствовать себя глупо или беспомощно.

Копирайтер и UX писатель не могут быть взаимозаменяемыми: у них разный опыт, цели и рабочие процессы. Без одного из них вселенная потеряет свою красоту и очарование или будет неудобной для жизни. Но почему писать все тексты не может только один специалист?

Я Лиза, UX писатель в продуктовой команде inDriver. В этой статье собрала отличия UX писателей и копирайтеров по пунктам и в картинках.

https://habr.com/ru/post/683196/?utm_source=habrahabr&utm_medium=rss&utm_campaign=683196

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

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

https://habr.com/ru/post/678284/?utm_source=habrahabr&utm_medium=rss&utm_campaign=678284

Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье расскажу о том, как мы сократили время регрессионного тестирования релизной сборки мобильного приложения и релизный цикл до одной недели, с какими проблемами столкнулись и как их решали.

Ранее мы рассказали, как и почему перешли от хаотичных релизов к еженедельному выпуску нашего приложения на iOS и Android. Ниже поделюсь, как при этом мы уменьшили время проверки релиза с 3-4 дней для одной из платформ до 4 часов на проверку сразу двух платформ.

https://habr.com/ru/post/679266/?utm_source=habrahabr&utm_medium=rss&utm_campaign=679266

Хабр, привет. Я Леся, Senior QA Manual в команде Release Management. В статье поделюсь опытом проведения встреч формата 1-on-1 и правилами, которые я регулярно применяю. Расскажу, для чего нужна эта встреча, как вести себя на ней руководителю и сотруднику, а также какие ошибки могут допустить обе стороны. Поехали!

https://habr.com/ru/post/675650/?utm_source=habrahabr&utm_medium=rss&utm_campaign=675650

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

Меня зовут Лиза, я UX писатель в продуктовой команде inDriver. UX писателей не всегда зовут в компанию в момент ее основания. Чаще всего о найме задумываются, когда продукт уже сформировался, и, кажется, все и так хорошо работает.

Но любой продукт можно бустануть с помощью хороших текстов. Давайте разберемся, как это работает, на примере нашего приложения inDriver.

https://habr.com/ru/post/674946/?utm_source=habrahabr&utm_medium=rss&utm_campaign=674946

Прочитав по диагонали статью гражданина @Winseven«ICMP открывашка портов для сервера», я сдержался. Все-таки велосипединг — это весело. Но вчитавшись, я опешил. Зачем запускать отдельное приложение для отслеживания нужных пакетов? Правильно ли, что достаточно один раз попасть пальцем в небо, чтобы порт был открыт? По мне, как-то не по фэншую.

Душа все это не вынесла, и я решился на статью.

https://habr.com/ru/post/673976/?utm_source=habrahabr&utm_medium=rss&utm_campaign=673976

Всем привет! Меня зовут Тарас, я руководитель релизной команды в inDriver. Команда разработки inDriver в 2022 году — это более 40 кроссфункциональных команд, которые делятся на платформенные и продуктовые. Всего в разработке около 350 инженеров, из них примерно 80 — мобильные разработчики.

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

https://habr.com/ru/post/665892/?utm_source=habrahabr&utm_medium=rss&utm_campaign=665892

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

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

https://habr.com/ru/post/668960/?utm_source=habrahabr&utm_medium=rss&utm_campaign=668960

Меня все еще зовут Ильмир, и моя тушка продолжает работать в компании inDriver. В статье постараюсь дать краткое описание того, как выглядит Qase. При этом будут небольшие помарки там, где есть отличия от TestRail, который мы использовали ранее.

https://habr.com/ru/post/666192/?utm_source=habrahabr&utm_medium=rss&utm_campaign=666192

Привет! Меня зовут Ксения, я QA Automation Engineer в inDriver. Хочу сразу сказать, что это не история успеха. Было бы классно написать: «За один год мы научили всех ручных тестировщиков писать автотесты, и теперь у нас 100% покрытие функционала автотестами». Но нет, это история о том, как мы до сих пор ищем способы завести автотесты во всех командах разработки.

https://habr.com/ru/post/659777/?utm_source=habrahabr&utm_medium=rss&utm_campaign=659777