Всем привет!

Меня зовут Ваня Назаров, я работаю менеджером проектов в Ozon Tech.

Одна из основных моих обязанностей — поддержание функции руководителя департамента одного из направлений работы всего Ozon.

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

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

Давайте вместе попробуем разобраться и понять, есть ли подводные камни в этом вопросе и, если есть, то какие.

Всем привет! Меня зовут Саша, я руковожу группой разработки Composer Core в Ozon Tech. В этой статье я расскажу о том, как устроена пользовательская часть одного из ведущих российских маркетплейсов, в развитии которой на момент написания статьи участвуют сотни специалистов из десятков команд. При наличии такого количества людей разрабатывать новую функциональность, не рискуя сломать уже существующую, является достаточно сложной задачей.

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

Продукт, который мы разработали, вряд ли когда-нибудь станет open-source-проектом, так как он слишком зависит от специфики инфраструктуры Ozon Tech. Но основные принципы могут быть полезны при проектировании похожих систем.

Привет! Меня зовут Анастасия. Я старший продуктовый дизайнер внутренних сервисов в Ozon Tech. Чтобы быстро решать вопросы клиентов Ozon, мы используем чат-ботов и постоянно их улучшаем. Такие боты встроены в клиентский чат, чат с продавцами, чат Ozon Travel и другие.

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

Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработчиков. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.

Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.

Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!

Всем привет! Меня зовут Люба, и я инженер по тестированию в команде Ozon Partners Platform. Наша команда занимается поддержкой и развитием системы, предназначенной для развития сети пунктов выдачи Ozon. Одним из компонентов этой системы является Открытая карта.

Хочу рассказать, как мы научили автотесты находить на ней точки, подходящие для открытия нового ПВЗ.

Однажды мы решили, что грамотных инженеров эффективнее всего растить самим. Так 3 года назад родился Route 256 — курсы Ozon для разработчиков и тестировщиков уровней junior и middle.

Во время курса ведущие специалисты Ozon погружают в индустрию e-com, знакомят с актуальным стеком и бизнес-задачами. Самые успешные выпускники получают оффер в команду Ozon.

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

Привет, Хабр! Я Женя, ведущий продуктовый дизайнер в Ozon, и за 10+ лет в дизайне повидала всякого: ошибок в макетах (своих и чужих), недостаточно полных спецификаций, неучтённых корнер-кейсов, сотни сообщений в тредах с разработкой и переносы релиза из-за досадных багов. 

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

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

^{Осторожно, количество мемов в статье зашкаливает}  

Всем привет! Меня зовут Саша, я iOS-разработчик компании Ozon. Я занимаюсь разработкой и развитием мобильного приложения продавца. Сегодня хотел бы поделиться опытом нашей команды по кастомизации онбординга для вашего мобильного приложения.

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

- Как представить новую фичу пользователю?

- Как сделать так, чтобы пользователь не пропустил добавленный функционал?

- Как повысить количество взаимодействий с новым функционалом?

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

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

Когда занимаешься каким-то делом достаточно долго, начинаешь ощущать себя сидящим на берегу бурной реки. Мимо проносятся годы, теории, подходы и принципы, можно пронаблюдать весь жизненный цикл каких-то явлений и течений. Одним из таких явлений стало появление бизнес-партнёров по информационной безопасности, которых в англоязычном мире принято величать Business Information Security Officer (BISO). Явлению этому менее 10 лет (если говорить о формировании как института и роли), но оно стало уже достаточно популярным как в российском дискурсе, так и в зарубежном. На пути от олдскульного «специалиста по защите информации» к BISO происходило много событий, но, как известно, дорогу осилит идущий.

Посмотрим на это моими глазами наблюдателя, но начать придётся издалека. Любое созерцание требует некоторого терпения. Путевые заметки расположены не в хронологическом порядке, но в логически связанном. Они посвящены трансформации индустрии и призваны ответить на вопрос: какой способ организации работы ИБ лучше и почему он претерпел именно такую трансформацию?

Привет! Это Маша, технический писатель в группе документации Ozon. Мы делаем внутреннюю документацию в департаменте «Поиск, рекомендации, реклама», в который входит 40 команд разработки. Наш департамент постоянно развивается, появляются новые команды и люди, которым нужно побыстрее влиться в компанию и коллектив. Недавно одна из команд планировала набирать новых сотрудников, и коллеги попросили помочь сделать приветственную страницу для новичков — онбординг.

Чтобы страница была полезной и простой, мы пообщались с командами и разработали страницу онбординга. Она получилась настолько хорошей, что мы сделали из неё универсальный шаблон, которым пользуемся сами и которым хотим поделиться. Он будет полезен любой IT-команде: разработчикам, тестировщикам, техническим писателям, продактам, проджектам и другим специалистам.

Привет, Хабр! Меня зовут Георгий, я руководитель команды Ozon Банк iOS. Я занимаюсь разработкой и развитием мобильного направления финансовых продуктов Ozon.

Сегодня хочу поделиться опытом нашей команды по запуску мобильного приложения на WebView.  

Часто разработчики используют только встроенный API взаимодействия JavaScript c нативными кодом, например Web API, но нам этого оказалось мало, и мы расширили спектр возможностей подхода web-native. Внутри статьи я расскажу, какой подход выбрал, как к этому пришёл и как обошёл возникшие проблемы. Подчеркну плюсы и минусы использования своего решения и в конце предложу несколько идей дальнейшего развития выбранного пути.

Привет, Хабр! Меня зовут Виктория Юльская, и я старший системный аналитик в Ozon.

Я думаю, здесь найдётся много людей, которые хоть раз работали с документацией API в Confluence. Да-да, те самые километровые страницы на каждый метод — с описанием всего и вся в виде текста, таблиц, диаграмм последовательности и т. д.

Зачастую такая документация API в Confluence устаревает ровно в тот момент, как её закончили писать. После передачи задачи в разработку, как только что-то непонятно, куда все идут? Правильно, к аналитику — «А как это работает? А что это значит? А что если...?».

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

Есть ли более эффективный способ ведения и поддержания документации API в актуальном состоянии? Давайте разбираться.

Привет! Меня зовут Маша, и я являюсь руководителем  первой линии Security Operation Center в Ozon.

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

Я поделюсь с вами тем, как мы решили мерить работу первой линии, какую пользу нам принесли метрики, а также с какими трудностями при разработке метрик мы столкнулись и как справились с ними.

Привет всем! Это не обычная статья, это целый курс про UX-редактуру от Ozon. Мы с вами разберем, что такое UX-редактура, какие бывают форматы интерфейсных текстов и как их писать качественно, быстро и просто.

Меня зовут Кира Калимулина, мы с командой занимаемся всеми интерфейсными текстами в Ozon. Я задумала этот курс, чтобы помочь дизайнерам, продакт-менеджерам, копирайтерам, разработчикам и другим специалистам научиться писать тексты для интерфейсов.

Этот курс подойдёт тем, кто только погружается в мир UX-редактуры и хочет стать продуктовым редактором. А также тем, кто вынужден писать тексты для приложений, но не умеет (или думает, что не умеет).

Я подготовила 4 урока, где разобрала, как мы пишем тексты в Ozon. Для вашего удобства основная информация продублирована в видеоуроках. В роликах есть ещё много приколов, которые невозможно передать в статье, так что можно и смотреть, и читать — как вам удобнее! 

Хей-хей! Меня зовут Айя, и я старший продуктовый дизайнер в Ozon, занимаюсь опытом покупателя в команде оформления заказов и геосервисов. 

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

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.

Привет, Хабр!

Меня зовут Дмитрий. Я успел отучиться в колледже, поступить в университет, окончить стажировку в Ozon Tech, перейти в штат и по сей день не прекращаю учиться, учиться и ещё раз учиться. Сейчас я работаю младшим аналитиком информационной безопасности в отделе Compliance и безопасности данных.

Это история о том, как я пару лет пытался войти в разработку, но зашёл не в ту дверь и остался, о постоянном обучении, а также о том, как найти то, что тебе по душе, и при чём тут стажировка.

Всем привет! Меня зовут Газимагомед, я занимаюсь разработкой внутреннего распределённого профайлера Vision в Ozon. В этой статье я раскрою понятие профиля, расскажу о том, что такое распределённый профайлинг, чем отличается автоматический сбор профилей от ручного. А также рассмотрим проблемы, возникающие при построении профайлера. Что ж, усаживайтесь поудобнее, мы начинаем.

Меня зовут Ира и я руковожу отделом тестирования мобильной платформы: наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек, которые используются в наших приложениях. Около года назад мы пытались понять, почему у одной из команд джоба с автотестами отваливается по тайм-ауту. К слову, это был проект мобильного приложения для продавцов, и на нем у нас для автоматизации тестирования используются нативные фреймворки: Kaspresso + Kotlin для Android и XCTest + Swift для iOS.

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

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

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

- Делать свою или взять готовую? Прыг.

- Платформенная или универсальная? Прыг.

- Версионировать компоненты или всю библиотеку? Прыг...

И ещё много таких «прыгов».

Давайте подготовимся к сложному контенту. Закроем глаза, успокоимся и представим идеальную дизайн-систему. Представили? Умные компоненты, продуманные паттерны, подробная документация. Автоматическая генерация кода. Кайф? А то! Только такая дизайн-система оставит нас без работы.

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