Привет, Хабр! Меня зовут Антон Батищев, я бэкенд-разработчик в продуктовой команде Циан. В этой статье поделюсь опытом: как устроена наша работа, какие плюсы мы видим в таком подходе и с какими проблемами сталкиваемся на практике.
На ранних этапах разработки аналитика часто оказывается в тени функциональных требований: фича работает — значит, задача выполнена. Корректность событий, логика их отправки и влияние на будущие отчеты нередко проверяют только после релиза — если вообще доходят до этой проверки. Но аналитика — это полноценный продуктовый инструмент. Именно на результатах аналитики строят гипотезы, запускают A/B-эксперименты и принимают бизнес-решения.
В этой статье Андрей Смирнов, инженер по тестированию Циан, раскроет, почему аналитика — это не «дополнение», а часть фичи, какую роль в ней играет тестировщик, а также как ревью аналитики повлияло на процессы и качество решений в нашей команде. Статья отражает опыт взаимодействия QA и аналитика внутри нашей продуктовой команды.
Когда я был разработчиком, мне казалось, что оценивать задачи просто. Я знал код, понимал проект и верил, что 40-часовая неделя — надёжная рамка, в которую помещается всё нужное.
Реальность быстро показала обратное. В каждом спринте оставались незакрытые задачи, сроки сдвигались, а чувство «я где-то ошибся» становилось постоянным фоном — даже если работал честно и много.
Мы пробовали увеличивать оценки, переходить на стори-поинты, но бизнесу всё равно нужны конкретные даты. И если вы называете срок, от него зависят планы других команд — просрочка превращается не просто в накладку, а в риск.
Со временем мои оценки стали точнее. Но став тимлидом, я понял простую вещь: проблема не в людях и не в оценках.
Проблема — в самой модели планирования. Мы пытаемся работать внутри недели, которой в реальности не существует. Давайте разберёмся, почему планы продолжают срываться, даже если команда работает добросовестно и что с этим делать.
Когда проект растёт, а вместе с ним — количество проверок, CI превращается в марафон. Мы в Циан через это прошли: кодовая база растёт, тестов становится всё больше, и каждое изменение начинает тормозить весь пайплайн.
В этой статье расскажу, как мы сократили время выполнения unit-тестов с помощью Impact-анализа — метода, который позволяет запускать только те тесты, которые действительно нужны. Это продолжение моего подхода к оптимизации проверок в Android — в первой статье я показывал, как ускорить статические анализаторы. Теперь — про unit-тесты.
Примеры кода будут на JUnit, но подход подходит ко всем проверкам, которые гоняются через Gradle. В конце статьи — рабочий пример на GitHub, который можно адаптировать под себя.
В этой статье расскажу, как мне удалось «влезть» в плагин GitHub Copilot, обойти ограничения проприетарного инструмента и научить его помогать писать unit-тесты буквально в пару кликов. Думаю это будет полезно тем, кто хочет узнать как влезать в работу сторонних плагинов, ускорить написание тестов и тем, кто ищет способы прокачать работу с ИИ-помощниками в своих проектах.
Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.
В этой статье расскажу, с чего я обычно начинаю проектирование, какие вопросы задаю себе перед тем, как описывать архитектуру, и какие принципы помогают принимать решения.
Материал будет полезен тем, кто хочет влиять на архитектуру в своей команде и ищет, с чего начать.
Чем больше микросервисов в компании, тем веселее жизнь у тех, кто отвечает за безопасность. Количество зависимостей растёт, и в какой-то момент становится нереально уследить, откуда в коде может вылезти критичная уязвимость — будь то старая библиотека или транзитивная зависимость, о которой никто даже не помнит.
Решение этого — SCA (Software Composition Analysis) автоматический анализ зависимостей, который помогает вовремя вылавливать уязвимые библиотеки и понимать, что с ними делать.
Меня зовут Эрик Шахов, я AppSec-инженер в Циан. В этой статье расскажу, как мы перестроили систему SCA, изменили её архитектуру и какие инструменты теперь используем для контроля зависимостей. Поделюсь реальным опытом внедрения SBOM (Software Bill of Materials) и тем, как он помогает нам держать код в порядке.
Привет! Меня зовут Кирилл Сергеев, я ML-инженер в Циане. В этой статье я расскажу, как мы решили задачу дедупликации объявлений о недвижимости, разработав систему на основе трёх моделей. Эта система автоматически находит и объединяет дублирующиеся объявления, помогая пользователям видеть только актуальную и уникальную информацию.
Материал будет полезен ML-инженерам и специалистам по обработке данных, которым интересно, как мы подошли к решению этой задачи: какие методы использовали, какие проблемы возникли и как мы их преодолели.
Оркестрация процессов в Apache Airflow — мощный инструмент для управления данными. Но как внедрить его так, чтобы процессы стали прозрачными, гибкими и удобными для команд? Как организовать ETL-пайплайны, чтобы они легко масштабировались и адаптировались под нужды аналитиков, ML-инженеров и других специалистов?
Меня зовут Любовь Марисева, я инженер дата-платформы в Циан. Мы разрабатываем десятки ETL-процессов, обеспечиваем данными разные команды и постоянно ищем способы сделать работу с Airflow эффективнее. В этой статье я расскажу, как мы решили ключевые проблемы, сделали расчёты более управляемыми и упростили взаимодействие между командами.
Если вы только начинаете работать с Airflow или хотите улучшить свои подходы, присоединяйтесь! Эта статья поможет взглянуть на оркестрацию процессов под новым углом.
Когда команда растёт, а кодовая база стремительно увеличивается, время выполнения проверок может стать настоящей проблемой. Unit-тесты, UI-тесты, статический анализ — все эти процессы начинают занимать слишком много времени, замедляя разработку. Звучит знакомо?
В этой статье я поделюсь опытом нашей команды в Циан: расскажу, как мы перешли от полного выполнения всех проверок к выборочному запуску, снизив их длительность. И почему сделать это проще, чем кажется. Если вы считаете, что выборочный запуск статических анализаторов — это сложно и дорого в поддержке, я покажу, как обойтись всего 200 строками кода.
Хочется запускать проверки только там, где это действительно нужно, и ускорить работу своей команды? Тогда читайте дальше.
Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?
Меня зовут Иван Биленко, я инженер данных в команде дата-платформы Циан. В этой статье я хочу немного познакомить вас с процессами и стеком внутри нашей платформы, рассказать, почему мы решили попробовать Iceberg, с какими проблемами столкнулись при тестировании и какие преимущества Iceberg может дать тем, кто еще только задумывается о переходе. Дисклеймер: статья носит обзорный характер.
Быть тимлидом — это как управлять оркестром, где каждый инструмент должен звучать в нужный момент. Но что делать, когда ты становишься дирижёром в новом оркестре, где не всегда понятно, кто за что отвечает, и ты даже не знаком с музыкантами? В таких ситуациях, важность адаптации сложно переоценить.
Меня зовут Денис Кузнецов, я тимлид команды биллинга в продуктовой вертикали «Монетизация» в Циан. В этой статье я поделюсь, как успешно пройти адаптацию в роли тимлида, и покажу на примерах из своего опыта, как справиться с этой задачей.
Знаете, что объединяет всех iOS-разработчиков, работающих над крупными проектами? Все мы когда-то сталкивались с этим старым знакомым — файлом .xcodeproj, который хранит в себе десятки, а то и сотни конфликтов после каждого merge. Мы тоже жили с этой проблемой много лет, пока не нашли решение.
Знакомьтесь, Tuist — инструмент, который кардинально изменил наш подход к управлению проектами. Он не только помогает избежать конфликтов, но и автоматизирует генерацию ключевых компонентов, значительно облегчая команде жизнь.
Если у вас всё еще сохранился этот «реликт прошлого», то, возможно, наш опыт поможет вам наконец-то избавиться от него. Давайте разберемся, как это сделать.
Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо, но мало. Вы должны принимать решения не только исходя из технических деталей задачи, но и с учётом реалий бизнеса, его потребностей и направления развития.
Меня зовут Олег Федоткин, я СТО компании Циан. В этой статье расскажу, почему понимание бизнеса так важно для ИТ-менеджеров, тимлидов и архитекторов, и как оно влияет на принятие технических решений и развитие карьеры. Больше и чаще на подобные темы я пишу в свой ТГ-канал «Инженер и Менеджер».
Кому будет полезна статья:
Менеджерам в ИТ: тим-/юнит-лидам, руководителям направлений и СТО. Без понимания бизнеса у вас не получится построить карьеру — это аксиома.
Специалистам выше уровня senior: staff-/principal-инженерам и архитекторам для выработки полезных для компании технических решений.
Гильдии разработчиков становятся обычным явлением в IT-компаниях. Это своего рода неформальные клубы по интересам, которые помогают улучшать процессы, обмениваться опытом и развивать участников. Потенциал таких сообществ весьма высок, — они могут запустить изменения на уровне всей компании. Но что делать, если активность в гильдии снизилась и стало непонятно, зачем она вообще нужна?
Меня зовут Саша Киверин, я лид Python-гильдии в Циан. Сейчас в нашем сообществе более 60 разработчиков. За последние 2 года мы совместными усилиями сделали целый ряд крутых проектов. Перевели монолит с версии Python 2.7 на 3.12, создали библиотеку для внешних вызовов и внедрили автоматический чеклист здоровья микросервиса. Дотащить все это до прода нам помогли 5 простых советов, которыми я и поделюсь в этой статье. Надеюсь, они помогут оживить и вашу гильдию.
Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?
Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»
Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных.
На первый взгляд, это даёт несколько преимуществ. Во-первых, сокращается время от идеи до реализации фичи. Во-вторых, можно создать интерфейсы сразу для нескольких платформ. В-третьих, появляется возможность обновлять функциональность без необходимости обновления приложения, даже на старых версиях у пользователей.
На бумаге такие идеи кажутся идеальными, иногда даже «серебряной пулей». Однако на практике всё не так однозначно, и многое зависит от конкретного кейса. В этой статье я поделюсь опытом нашей компании, расскажу о нюансах, которые позволили нам извлечь пользу из BDUI, и представлю рабочий инструмент. Мы использовали нестандартные подходы, которые, надеюсь, вдохновят вас. Похоже, что для нас BDUI — это скорее удовольствие, чем боль. Давайте разберёмся, как нам это удалось!
Привет, Хабр! Я Александра Микелова, лид исследователей B2C-аудитории в PropTech-компании «Циан» и преподаватель на курсе «UX-исследования для дизайнеров» в Яндекс Практикуме. Сегодня расскажу о таком методе, как конфликтное интервью, чем оно отличается от классического глубинного и какие данные можно получить с его помощью.
Я — Саша Микелова, руководитель исследователей B2C-аудитории в Циан и преподаватель в Практикуме. Занимаюсь исследованиями уже 10 лет. Когда я только пришла в профессию, UX-исследований не делал практически никто. Индустрия развивалась за счёт исследований маркетинговых, основной целью которых было понять, как лучше позиционировать продукт (чаще FMCG — Fast Moving Consumer Goods, то есть товары повседневного спроса) на рынке. Но со временем стала развиваться IT-индустрия, появились новые приложения и, как следствие, стала расти конкуренция. В условиях, когда одну и ту же задачу пользователя могут решить несколько продуктов, важно уже не только само решение задачи, но и то, как именно это делается: фокус перешёл на пользовательский опыт. Сейчас представить разработку любого продукта или фичи без исследования — невозможно. Только получая обратную связь непосредственно от пользователей, можно создать продукт, попадающий аудитории в сердечко.
Доброго времени суток, дорогой читатель. Меня зовут Михаил, я Android-разработчик в компании Циан. Этой статьёй я открываю для себя цикл статей по внутренней кухне разработки плагинов для Jetbrains IDE: IDEA, Android Studio (AS) и пр. На дворе 2024 год, официальная документация не так богата информацией, как хотелось бы. Но есть исходники, которые смело можно дербанить. В этом цикле статей я буду описывать свой опыт поиска нужной мне информации и её разбор.
