Привет, Хабр! Меня зовут Андрей Устьянцев, и я ведущий аналитик направления Big Data в Лиге Цифровой Экономики. Занимаясь digital-маркетингом с 2006 по 2019 год, в какой-то момент я осознал очевидную сейчас многим истину. Эффективность рекламной кампании в интернете зависит не только от качества настройки ее параметров, но и от продающего качества лендинга, на который ведется рекламный трафик.

Но как измерить качество? Оперирование субъективными мнениями дизайнеров и результатами опросов в «экспертных сообществах» (в духе «подскажите, что не так»), как я могу судить по моему опыту, ни к чему в итоге не приводит.

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

Коротко — суть:

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а еще предоставляем оптимальную конфигурацию для системы, которая передана в эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, рассказал, как его команда попробовала быстро подготовить задачи по классическому ТЗ (ГОСТ 19) в Jira при работе с государственным заказчиком и что из этого получилось.

Пожалуй, большинству известно, что ГОСТ предусматривает водопадную модель разработки ПО. До недавнего времени она была зафиксирована в постановлении Правительства Российской Федерации от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

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

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

Максим Денисов, разработчик в Лиге Цифровой Экономики, поделился опытом создания системы управления доступом на Android и рассказал, как менялся подход к контролю доступа.

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

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

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

Разработка началась в 2015 году, когда 5-я версия Android была последней.

1.           Подход на основе блокирующей view

1.1.  Блокировка

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

В манифесте приложения нужно добавить следующее разрешение:

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />

С API 23 необходимо явно его указывать. Поэтому при настройке приложения администратор должен выбрать «Разрешать всегда».

У блокирующего экрана добавить свойства:

WindowManager.LayoutParams.TYPE_SYSTEM_ALERT

WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN

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

Рассмотрим на примере вымышленной ситуации

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, порассуждал о роли аналитика в команде и для этого смоделировал ряд ситуаций, когда к работе над проектом стоит привлекать таких специалистов. О том, что из этого получилось — читайте в статье.

— Аналитики не нужны! — лицо Лаврентия, нового менеджера проекта по внедрению информационной системы по управлению всем (ИС СУВ) не выражало никаких эмоций, а степень решимости была сродни количеству лошадиных сил у грузового локомотива. За плечами Лаврентия — опыт разработки в IT-гиганте из Fortune 500, с коллегами он изобретал свой особенный форк gRPC и участвовал в эксперименте по переходу на трехчасовые спринты.

— Это же пустая трата времени. Лиды встретились, договорились по параметрам API, реализовали и в прод, — продолжил он и сдвинул брови.

— А документация... — начал было тимлид аналитики Савелий. За его плечами — десятки часов чтения ГОСТ и семь аналитиков.

— Скормим ChatGPT, потом студенты на аутсорсе поправят, — парировал Лаврентий.

— А веб-интерфейс?

Над Савелием будто сгустились тучи.

— Останемся на прежнем, а если что, — кнопки покрасить не проблема, — отрезал менеджер проекта и кивнул на fullstack Прасковью.

— Да, — отозвалась Прасковья, его вторая жена.

— А…

— Все, за работу! — отчеканил Лаврентий в ответ на пробившиеся было сквозь поток негодования Савелия аргументы и вышел.

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

Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data Лиги Цифровой Экономики, и в этой статье я расскажу, как писал чат-бот в Telegram на webhook. Если вы знаете, что это такое, и подготовка не вызывает интереса — можете сразу переходить к разделу «Очень кратко». С остальными поделюсь всеми необходимыми шагами.

Summary: Сотрудники Лиги Цифровой Экономики Юлия Крашеница, DBA PostgreSQL, Андрей Ходус, ведущий эксперт, и Елена Жикривецкая, старший эксперт PostgreSQL, рассказали об особенностях миграции с системы управления базами данных Oracle на PostgreSQL и возникших сложностях, а еще поделились своим опытом их решения.

Summary: Игорь Зубцов, руководитель автоматизированного тестирования в направлении омниканальных решений Лиги Цифровой Экономики, рассказал, как его команда разработала сервис для мониторинга покрытия автоматизированными сценариями, с какими сложностями столкнулись и как он работает.

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

Естественное желание — видеть наглядный результат работы автоматизаторов на проекте. Всегда хочется знать, а главное, видеть ответы на вопросы: «А что у нас с покрытием этого функционала?», «А покрыт ли у нас этот сценарий?» и подобные. Coverage Manager предназначен для визуальных ответов на многие такие вопросы. Любой причастный к проекту человек может зайти и посмотреть, покрыт ли тот или иной сценарий автотестами, а также пронаблюдать динамику.

***

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

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

Summary: Елена Бинун, ведущий аналитик направления развития экосистем Лиги Цифровой Экономики, поделилась лайфхаками по использованию платформы Miro для работы аналитика.

Как переехать из Slack в Mattermost — личный опыт

Приветствую, уважаемые читатели Хабра. Меня зовут Иван, я руковожу направлением омниканальных решений в Лиге Цифровой Экономики. На старте одного из проектов около шести лет назад мы с заказчиком решили, что будем вести все проектные коммуникации в Slack. На тот момент для нашей небольшой команды стоил он не так дорого, да еще и был удобнее, чем альтернативные мессенджеры.

Summary: Из-за проблем со Slack нам нужно было искать альтернативу, а терять накопленные наработки не хотелось. Мы нашли способ переехать относительно безболезненно и с сохранением данных — рассказываем, как это сделали.

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

Елизавета Голованова, ведущий аналитик в Лиге Цифровой Экономики, поделилась опытом и лайфхаками, которые помогут сделать из потерянных джунов уверенных в себе специалистов, чтобы это было выгодно для всех сторон.

Наша компания недавно преодолела планку в 5,5 тыс. сотрудников и продолжает расти. Мы регулярно проводим стажировки для молодых специалистов и для тех, кто хочет сменить профессию. Я поделюсь своим опытом вывода начинающих сотрудников на проекты, а также расскажу, как сделать появление нового специалиста полезным и выгодным для всех сторон.

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

Адаптацию я проходила в стиле «плыви, кутеночек». Меня вбросили в проект и сразу стали давать задачи, к которым на стажировке не готовили. Если честно, было очень страшно.

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

Синхронизация в UX-дизайне: как поддерживать единую стилистику сервисов для разных устройств

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

Такое взаимодействие должно быть понятным и предсказуемыми. О том, с помощью каких принципов дизайнерам добиваться согласованности между версиями приложений для разных устройств, рассказывает Александр Зерин, руководитель лаборатории продуктового дизайна FINIK Design Lab (входит в Лигу Цифровой Экономики).

Лига Цифровой Экономики выступала на конференции SQA Days 30 с несколькими докладами. Приглашаем вас в небольшое «приключение на 20 минут» по их мотивам: лид команды тестирования Екатерина Щеголева и руководитель направления Кирилл Панаков поделятся опытом компании в развитии тестировщиков. А еще раскроют, почему это было похоже на упомянутый выше мем.

Под катом – расшифровка доклада

Видео: ссылка на YouTube.

В материале:

● Какие раньше были проблемы с развитием команды;

● Какой комплекс решений найденных проблем мы реализовали;

● Четыре стадии внедрения решений;

● Что в итоге получилось.