Если вы читаете это, то скорее всего, поиск нового (или даже первого) места работы вызывает стресс, требования в вакансиях на HeadHunter кажутся невыполнимыми,
а свое резюме не то что не хочется никуда отправлять — есть желание никогда его не открывать.

На старте карьеры каждый испытывает все эти чувства. Давайте начнем немного менять ситуацию с последнего пункта — резюме!

Да, мы не сможем за 30 минут повысить ваш опыт работы на 3 года, но даже в банальном оформлении своего резюме многие делают (или не делают) достаточно странные вещи.

Перейдем к пункту 0...

Меня зовут Дмитрий Иванов, я старший аналитик данных компании билайн, и первое правило хорошего резюме — это простота. Пока мы не идём на позицию ТОПа или вице-президента, давайте оставим излишний формализм за пределами того PDF-файлика, который вы будете рассылать рекрутёрам.

0. Пишите просто и понятно

Не надо делать делать из мухи (3 месяца работы в универской лаборатории) слона (оформить каждый тезис вашего курсача как отдельный научный проект). 3 месяца в лаборатории = 3 месяца в лаборатории. 

Всем привет!

Меня зовут Станислав, сейчас я работаю старшим системным аналитиком в отделе развития голосового антифрода.

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

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

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

В этом посте я хочу рассказать про архитектуру Flutter-приложений, о том, как мы в билайне это делаем, чего мы достигли и как это у нас работает. Поговорим о создании архитектуры, организации управления состояниями и зависимостями, о привычных и не очень методах и концепциях, затронем Mobx, GetX и Flutter modular, а также разберём всё это на живом примере — на нашем мобильном приложении для дилеров.

Мы обсудим его особенности, технические сложности, и посмотрим, как реализовать такое крупное приложение. Затем — углубимся в вопрос управления состоянием, зависимостями, приложением.

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

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

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

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

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

Набором этих правил я и хочу поделиться.

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

В данной статье мы порассуждаем о том, как такое разделение сделать.

React view как чистая функция состояния

React изменил наш подход к пользовательскому интерфейсу — его философия основана на простых, но мощных концепциях использования компонентов и однонаправленного потока данных.

Ещё считается, что React внес реактивность в пользовательский интерфейс, но это не так, так как шаблоны MVVM и фреймворки, которые сильно полагаются на реактивность, были введены раньше React. (Knockout и Angular с двойным биндингом данных, Ember.js Observable)

Эти концепции делают UI разработку не только интуитивнее, но и объединяют дизайн и разработку в одном инфополе. Кстати, Elm тоже полагается на подобные концепции и использует чистые композируемые функции представления без состояния.

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

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

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

Разработка IT-решений

В компаниях встречаются два подхода к организации команд разработки: функциональные команды и кросс-функциональные команды.

В первом случае предполагается, что образуются команды с одинаковым набором экспертиз: команда backend-разработчиков, команда frontend-разработчиков, команда data science и т. д. Во втором случае команды формируются из людей с различными компетенциями для достижения некоторой бизнес-цели. Бизнес-целью может являться как создание и развитие продукта, так и выполнение определенного проекта.

Легенды гласят, что кросс-функциональные команды появились в далеких 1950-х годах.

Сейчас набирает популярность относительно новый вид лидерства: secure base или «надёжная база». Этот подход в большей степени отражает контекст и потребности людей в вопросах построения карьеры и коммуникаций на работе. Во времена неопределенности важно, чтобы лидер мог воодушевить и поддержать команду, одновременно развивая потенциал людей и сосредотачивая на достижении KPI. Но как с учетом удалёнки и негативного внешнего контекста поддерживать доверительную атмосферу и создавать благоприятные условия для развития и роста? Или формировать в команде привычку делиться своими успехами и неудачами и работать сообща с другими командами?

Меня зовут Артём Каледин, я руководитель по анализу данных в команде геоаналитики в билайне. Эта статья написана по следам моего выступления на конференции Saint TeamLead Conf 2023. Я расскажу о новом типе лидерства — «надежной базе», формате, который помогает развиваться лидеру и растить сотрудников вокруг себя. В статье будет не только теория, но и мои примеры и идеи о лидерской роли и построении карьеры. Возможно, я смогу натолкнуть вас на размышления о дальнейшем развитии в лидерстве. 

Из прошлой статьи мы узнали, что CLTV (customer lifetime value) — метрика, используемая для оценки прибыли, которую компания может получить от своего клиента за время его пользования продуктами и сервисами компании.

Разберем, что означает каждая буква в определении CLTV (customer lifetime value). Кто такой клиент, что мы понимаем под lifetime и ценностью, которую приносит нам клиент. 

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

Под lifetime мы понимаем не полный жизненный цикл клиента от момента заключения договора до момента его закрытия, а пятилетний горизонт, который мы отсчитываем от текущего момента времени. То есть, если мы строим прогноз от января 2023 года, то прогноз будет построен помесячно до декабря 2027 года. Почему 5 лет? Этот срок был определен опытным путем — при нем достигается баланс между качеством предсказаний и потребностью в бизнес-процессах.

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

Технология NVMe через различные фабрики (далее NVMeOF) оформлена в качестве стандарта летом 2016 года, она была встроена в пятую ветку ядра Linux.

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

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

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

Задача: подключить много дисков с нескольких серверов

Всем привет! Меня зовут Николай Безносов, я отвечаю за применение и развитие машинного обучения и продвинутой аналитики в билайне. В одной из прошлых статей мои коллеги рассказывали о месте Seldon в ML-инфраструктуре компании, а сегодня мы поднимемся на уровень выше и поговорим о том, что из себя представляет MLOps в билайне в целом - как с точки зрения инфраструктуры, так и с точки зрения процессов.

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

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

Привет всем! Полное содержание первого сезона можно прочитать тут и тут, а краткое содержание такое: 

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

• Мониторинг был разным (Patrol, Zabbix. NetCool), про Elastic. Про Prometheus, трейсинг и Grafana не слышали.

• У всех команд эксплуатации были свои мониторинги, которые "что-то" показывали, но это все было разрознено и никак не связано.

Привести все это «богатство» в адекватное рабочее русло, как-то структурировать и реструктуризировать было поручено команде супергероев, которые в перерывах между паниками (страшно было) взялись за дело

ВАЖНО: Тут не будет скриптов развертывания. Не будет рецептов и настроек систем (что-то есть в интернете, к чему-то пришли через пот и слезы). Это взгляд людей, которые развивают системы мониторинга и философию, которой они придерживается. Что еще важно – среди нас до момента развертывания не было людей, которые слышали про эти системы. 

Наш первый сезон мы закончили с таким багажом и знаниями:

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

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

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

У нас получилось! Мы снизили количество данных на диске в 3 раза, при этом ускорив их обработку. И сейчас расскажу как. Меня зовут Александр Маркачев, я Data Engineer команды Голосовой Антифрод в beeline. В статье затронем тему форматов ORC и Parquet, как их правильно использовать и хранить, чтобы всем было хорошо.

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

Идея проекта

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

Привет! Меня зовут Андрей, я несколько лет занимаюсь разработкой, и за это время успел поработать с разными командами дизайнеров, посмотреть на разные подходы, кто где как делает, где какие есть сложности. 

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

Представьте ситуацию.

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

Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б. 

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

Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.

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

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

Немного душная, но важная вводная часть

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

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

• Какую сумму инвестировать в бизнес-направление и когда вложения окупятся?

• Сколько мы зарабатываем на продукте A, и не каннибализирует ли он доходы с продукта B?

• Насколько капитализация нашего бизнеса изменилась за последний год?

Помимо этого, мы принимаем (преимущественно в автоматизированном режиме) множество операционных решений:

• Информацию о каком продукте направить клиенту в SMS-рассылке?

• С каким приоритетом обслужить клиентов в условиях ограниченных ресурсов?

• Какую оптимальную цену предложить клиенту за потребляемые услуги?

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

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

В этой статье затронем тему организации процессов Machine Learning Operations (MLops) в beeline business, особое внимание акцентируем на тестировании моделей машинного обучения. Тестирование мы построили с использованием Gitlab (CI/CD), Mlflow и open-source фреймворка Seldon Core для деплоя REST API или gRPC сервисов с моделями в среде Kubernetes. А пока… 

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

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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