Привет! Я Юля Трусова, старший UX-редактор в Авито. В этом году мы снова набирали стажёров, которые будут писать интерфейсы, лендинги, рассылки и многое другое.
В этой статье разберём типичные ошибки, которые кандидаты допускали в тестовом задании, и покажем удачные решения. Статья пригодится тем, кто решит попробовать силы в следующем году, откликнется на вакансию UX-редактора в Авито или захочет устроиться в другую компанию.
Осторожно — много картинок!
Каждый год мы набираем стажёров в отдел UX-исследований. По итогам прошлого набора мы написали материал о типичных ошибках в тестовых заданиях, в этот раз расскажем о «золотом пути» решения каждого из заданий для кандидатов. Статья будет полезна как всем, кто подавался на стажировку и пробовал сделать наши тестовые, так и начинающим исследователям, которые смогут проверить свои знания на примере двух сложных кейсов.
Привет! Меня зовут Илья, я разработчик и по совместительству скрам-мастер в B2B-команде Авито Автотека.
Сегодня хотел бы рассказать о том, как мы с командой запускали процесс приоритезации задач, формировали процессы их оценки и переоценки. С какими трудностями нам пришлось столкнуться и какие профиты удалось приобрести. Надеюсь, статья будет полезна командам, бэклог которых содержит > 50 айтемов, а знания о том, что делать, есть только у product owner.
Привет, я Дина Симкина, директор по аналитике Авито. Я отвечаю за то, чтобы аналитика помогала бизнесу принимать правильные решения. В статье я расскажу, кого мы в компании называем аналитиками данных и чего от них ждём в зависимости от профессионального уровня.
Это вторая часть статьи о том, как улучшить A/B-тесты. Здесь я подробно остановлюсь на методах увеличения мощности: поговорим про CUPED, бутстрап-критерии, стратификацию и парную стратификацию.
Всем привет! Я Дмитрий Лунин, работаю аналитиком в команде ценообразования Авито. Наш юнит отвечает за все платные услуги площадки. Наша основная задача — сделать цены на них оптимальными.
Мы не только пытаемся максимизировать выручку Авито, но и думаем про счастье пользователей. Если установить слишком большие цены, то пользователи возмутятся и начнут уходить с площадки, а если сделать цены слишком маленькими, то мы недополучим часть оптимальной выручки. Низкие цены также увеличивают количество «спамовых» объявлений, которые портят поисковую выдачу пользователям. Поэтому нам очень важно уметь принимать математически обоснованные решения — любая наша ошибка напрямую отразится на выручке и имидже компании.
Одним из инструментов для решения наших задач является A/B-тестирование.
В прошлой статье я показал, как можно собрать свой Lighthouse. Сегодня пришла очередь применить получившийся трифорс в Performance-тестах, которые мы с командой успешно применяем для оптимизации и ускорения платформ Авито.
Это не так просто, как хотелось бы. С функциональными тестами всё прозрачно — тест либо проходит успешно, либо фэйлится. А в Perfomance-тесте у вас есть какая-то цифра, и непонятно — хорошая она или плохая. Если бы мы использовали инструмент типа Lighthouse, можно было выставить performance-бюджет, чтобы зафиксировать эту цифру на каком-то уровне. Но для динамической ситуации это не подходит. Расскажу, как это понять и использовать.
Чем интенсивнее наш feature delivering, тем быстрее падает производительность. И, конечно, приходит время автоматизировать процесс слежения, чтобы просадка не дошла до прода или даже staging-окружения.
Про прод-мониторинг, оптимизацию и ручной анализ производительности легко узнать на web.dev. Но по автоматизации слежения за производительностью до того, как фичи покатятся в прод, информации не так уж много. Сегодня расскажу, как для профилирования собрать практически свой Lighthouse, чтобы проводить performance-тесты и успешно бороться с просадкой в работе команды фронтендеров.
Маркетплейсы и классифайды делят внимание аудитории, которая хочет что-то продать или купить, не только друг с другом, но и с социальными сетями и мессенджерами. Люди нередко продают и покупают товары в группах или чатах. Мы в UX-лаборатории хотели понять, почему так происходит и что мы упускаем на Авито.
Недавно мы провели свой первый митап для менеджеров продукта. Спикеры из Авито рассказали на нём о нашей менеджерской линейке, необходимых продакту компетенциях и устройстве дискавери-команд. А спикер Dodo Brands поделился, как они синхронизируют бизнес-цели и IT.
В посте — видеозаписи выступлений с таймкодами и ссылки на презентации.
Привет! Меня зовут Лиза Архангельская, я старший редактор в Авито. Наша команда пишет интерфейсы, рассылки, лендинги и многое другое.
За полтора года мы наняли троих новичков в профессии и принялись их обучать: один из младших редакторов уже стал мидлом, а стажёр — младшим редактором. Эта статья расскажет, как проходит обучение и чего от него ожидать. Опытным редакторам она поможет понять, нужен ли вам подопечный и как можно организовать процессы.
На нашем последнем митапе для аналитиков спикеры рассказали, как избегать ошибок в экспериментах, в чём польза Доставки и как мы продвигали её на Авито, а также как мы сделали рекомендации для менеджеров по продажам в Salesforce. Собрали для вас видеозаписи выступлений с таймкодами.
Инфомодель — это система управления метаданными в Авито. Она управляет категоризацией объявлений, их таксономией и каталогами. В недавней статье на Медиуме мы рассказали, как с ней работаем: зачем Инфомодель нужна и как она взаимодействует с остальными системами Авито.
Сегодня же я затрону такую немаловажную тему при работе с данными, как подготовка новых изменений и их деплой в prod.
Меня зовут Агалецкий Павел, я старший инженер в команде Архитектуры. Эта статья про новую для нас в Авито технологию — Apache Pulsar и построение системы очередей, Queues as a Service, на её основе.
Всем привет, меня зовут Александр Данковцев, я lead engineer команды Antimonolith. В этой статье я расскажу, как построен CI/CD монолита Авито. Речь пойдёт про нашу архитектуру стейджинга, pre-receive хуки, то, что из себя представляет сборка и деплой, как устроен прогон автотестов и какие проверки происходят на merge. А ещё рассмотрим after-merge actions.
Привет! Меня зовут Гера, я продуктовый редактор в Авито. Пишу тексты для интерфейсов и рассылок, а ещё — чейнджлоги для Google Play и App Store. Это тексты, в которых рассказывается, что появилось в новой версии приложения. По-английски их ещё иногда называют what's new или release notes.
Сам текст для стора — лишь верхушка айсберга. А под водой скрыто увлекательное приключение, которое требует наблюдательности, дипломатичности и задатков детектива.
Наиболее полезной статья будет для разработчиков, продактов и начинающих редакторов. Я покажу, как написать интересный чейнджлог — даже когда рассказать не о чем.
Вокруг Dependency Injection много инженерных практик. Несмотря на то, что эта статья про конкретный подход к написанию кода, она будет интересна широкому кругу разработчиков. Я постарался провести глубокий анализ существующих около Dependency Injection принципов разработки и хочу поделиться исследованием с сообществом.
Недавно прошёл наш третий митап для дизайнеров со спикерами из Сбера, WayRay, девелопмент-платформы Horovod и Авито. В этот раз продуктовым дизайном не ограничивались и поговорили про физическое пространство вокруг, индустриальный дизайн, идентичность городов и плагины для Фигмы.
Собрали видеозаписи выступлений с таймкодами и ссылки на презентации спикеров.
С июня 2020 года я работаю бэкенд-стажёром в Авито. Когда я искал стажировку, мне хотелось поподробнее узнать, что на самом деле происходит внутри каждой компании и какой у неё подход к стажёрам. Но обычно информация ограничивалась либо краткими текстами на лендингах, либо историями успехов.
Но ведь самое интересное — это процесс! Поэтому я решил рассказать о своей стажировке в Авито: как она проходит, какие ожидания от стажёра, какие задачи нужно решать.
Привет, я Саша Катин, дизайнер продукта в Авито. Примерно за месяц я написал плагин для Фигмы, чтобы помочь коллегам-дизайнерам.
В статье расскажу, что получилось хорошо и быстро, а что — не очень, и что нужно сделать, чтобы запустить свой энтерпрайз-плагин внутри компании. Заодно разберёмся с тем, как живут дизайнеры, какие их боли не покрываются стандартными инструментами, как мы нащупали проблему и как решили её с помощью плагина.