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

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

Статья получилась большая, поэтому можно сразу сориентироваться по плану:

●      предпосылки и типичные проблемы в командах аналитиков;

●      подготовка к делегированию или масштабированию задач;

●      шаблоны для описания артефактов;

●      технология дизайна;

●      план внедрения технологии дизайна;

●      распределение артефактов по ролям в команде.

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

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

Привет, Хабр! Я — Денис Сохранный, ведущий инженер саппорта и старший одной из смен поддержки в Nexign. Много лет работаю в IT-индустрии, связанной с телекомом и биллингом, на разных позициях от инженерных до тимлидских.

Расскажу о пути, который прошла наша команда при построении системы обучения и адаптации новичков — как мы прыгали на граблях и заходили в тупики. Возможно, наш опыт поможет вам избежать похожих ошибок и наконец ответить на вопрос: «База знаний — это добро, которое должно быть с кулаками?».

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

Я, Константин Лапин, руководитель технической поддержки Nexign. Мы пишем софт для телекома, создаём международные продукты и платформы, ускоряющие работу внутри компаний. Моя команда поддерживает одного из крупнейших телеком-операторов России. Мы отвечаем за то, чтобы технических сбоев либо не было, либо, если сбой случился, то минимально влиял на абонентов. В отделе четыре команды по 8-10 человек в каждой, работающие в графике 2×2.

Расскажу, как мы создали и внедрили систему развития от инженера до главного эксперта в своей команде. Мы обсудим:

▪ что такое инженерный карьерный трек, кому он нужен, а кому нет;

▪ что влияет на продвижение по треку;

▪ как мы обосновываем повышения бизнесу и сотрудникам;

▪ как растим новичков и что получилось по итогу внедрения готовой схемы в команде из 40 человек.

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

В данном случае речь о системе с СУБД DSE — удобной, отлично адаптированной к использованию под наши задачи, распределенной СУБД NoSQL-типа на базе Apache Cassandra с пудовыми рисками прекращения лицензирования со стороны Datastax.

При этом пересаживаться на другой «стул» требуется, разумеется, бесшовно, без потерь в вопросах производительности, безопасности и эксплуатационного качества в продукте. Вопрос это для нас особо важный, так как сама система, для которой рассматривалась замена СУБД высококритичная, и требования к решению были неизменными: возможность вертикального масштабирования «на лету» для поддержки значительного увеличения объема хранимых данных, высокая производительность записи и поддержка отказоустойчивости, включая распределение СУБД в нескольких ЦОД. У нас уже был накоплен весомый багаж информации в текущей базе, поэтому сама технология СУБД требовалась сродная по типу для исключения проблемы со сложностью миграции данных.

В статье начальник группы внедрения и тестирования продуктов и услуг Nexign Анна Алешина рассказывает, почему мы выбрали Scylla и решили прокачать ее до собственной «фирменной» СУБД Nexylla. Материал будет полезен всем, кто тоже задумывается о миграции на более надежные с точки зрения лицензирования СУБД.

В магистратуре ИТМО мы стараемся погружать студентов в работу реальных компаний ― через решение актуальных для бизнеса задач. Чаще всего это можно сделать на хакатонах, стажировках и с помощью организации корпоративных магистерских программ. Число таких проектов в университете с годами становится больше. Один из примеров ― совместный образовательный интенсив команды магистратуры ИТМО «Проектирование и разработка систем искусственного интеллекта» и IT-компании Nexign. Его участники разработали сервис для автоматической разметки рекламы на фото, который позволяет мобильному оператору упростить и ускорить работу с партнерскими торговыми точками. Под катом ― о деталях решения.

Сегодня предлагаем обсудить сжатие данных в Oracle.
 
Ситуация: один наш крупный клиент в сфере телекома стремится нарастить абонентскую базу, поощряет потребление услуг и рост трафика. Это позволяет развиваться компании в целом и каждой её системе в отдельности, включая нашу систему взаиморасчётов с партнёрами — Partner Relationships Managment.

Проблема: регулярный прирост информации в БД на 0.6 TБ в месяц превращается в 7.2 TБ в год. При этом востребованной для изменений является информация только за последние два-три месяца. Остальные данные накапливаются и хранятся для отчётности. При таком подходе база разрастается очень быстро, а каждый SSD системы хранения данных становится на вес золота. К тому же необходимо поддерживать согласованность резервной и тестовой БД. 

Есть два выхода: закидывать в базы, как «в топку», бесконечное количество дисков, либо оптимизировать хранение информации. Мы выбрали второе.

В этой статье главный инженер-программист по бизнес-системам Кирилл Солдатов расскажет, что конкретно сделали в Nexign. Информация будет полезна всем, кто как и мы сталкивается с необходимостью управления большими массивами в БД Oracle.

Теряли ли вы когда-нибудь данные в результате технической аварии? Была ли среди них критическая информация, которая восстанавливалась медленно или только частично? Именно в такие моменты в команде впервые начинают думать о резервировании. Предлагаем изменить подход и заранее корректно организовать резервные ресурсы.

За чем стоит будущее IT‑индустрии? Определить главный тренд совсем не сложно — искусственный интеллект и машинное обучение.

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

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

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

Почему именно NeoVim? Всё просто: этот текстовый редактор сохраняет совместимость с Vim, но также предлагает дополнительные возможности и улучшенный интерфейс. Он позволяет более эффективно работать с кодом, а главное — настраивать редактор под свои нужды.

Меня зовут Рустам Нурдавлятов, я являюсь руководителем одного из центров разработки в Nexign. В этой статье опишем кейс создания HRM-системы, расскажем о схеме совместной работы команд HR и разработки, а также на собственном примере разберем продуктовый подход к созданию HR-систем. 

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

Что нужно для успешного управления распределенной командой? Можно ли сделать команду сильнее за счет коллективного принятия решений? 

Константин Лапин, руководитель отдела по сопровождению Дежурная смена Nexign, поделился личным опытом и рассказал о том, как его команда использует пирамидальную структуру управления, как это отразилось на вовлеченности руководителей и на количестве системных проблем ключевого клиента (последние, кстати, удалось снизить в 10 раз).

Тема импортозамещения в телеком-отрасли набирает обороты. В критической информационной инфраструктуре очень высока вероятность того, что регулятор может в любой момент потребовать от операторов перейти на 100% российское ПО, поэтому ситуация мотивирует развиваться и переориентироваться быстрее.

По нашим приблизительным оценкам, 70-80% российских операторов используют зарубежные системы предбиллинга. Вендоры этих систем — те же Oracle и HP — ушли с рынка и, хотя у многих операторов внутренние команды поддержки имеют доступ к исходному коду, развивать такие решения тяжело. Но при этом обновлять их необходимо: сейчас операторы меняют сетевое оборудование на российское или «дружественное», расширяют IoT-направление, а это значит, что их предбиллинг должен уметь работать с новыми типами данных и новыми сценариями. Недавно мы разработали 100% российскую систему предбиллинга Nexign Mediation, призванную импортозаместить иностранные аналоги. Это low-code платформа, которая в потоковом режиме собирает и преобразовывает данные с сетевого оборудования оператора связи и отправляет их в нужном формате в системы тарификации.

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

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

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

Спойлер. Я был шокирован цифрами.

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

Реально ли справиться с огромным потоком рабочих задач, не потерять в продуктивности и при этом успеть сходить на обед? Своим опытом тайм-менеджмента делится Марат Галиаскаров, руководитель по управлению и развитию производственных процессов Nexign. Статья написана от первого лица, все советы носят прикладной характер и проверены автором ;)