5 принципов именования и документирования аналитических событий

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

1. Единое место документации событий. Создайте единое место документации всех событий (будь то Notion, Confluence, Google-документ или система аналитики с встроенным трекинг-планом) и используйте только его как источник правды.

2. Единая нотация. Выберите одно соглашение о наименовании (нотацию) и придерживайтесь его. Вот наиболее используемые из них:

• all lowercase — page view;

• snake_case — page_view;

• camelCase — pageView;

• Proper Case — Page View;

• Sentence case — Page view.

3. Структура в названии событий. Обычно название события — это комбинация названия объекта, совершенного над ним действия и, при желании, категории события.

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

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

Подробнее о каждом пункте мы рассказываем в отдельной статье.

Виды логирования в Swift

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

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

DebugPrint — очень похож на обычный Print, но отличается тем, что предоставляет дополнительную информацию о печатаемых объектах. DebugPrint имеет смысл использовать для дебага. Он покажет больше полезной информации о том, с каким типом объектов мы имеем дело. 

Dump — еще одна функция для распечатки сообщений в консоль. При работе с объектами и массивами объектов Dump показывает себя лучше, чем Print и DebugPrint. Мы получаем более наглядный результат, можем повлиять на то, в каком виде представлена информация, избавиться от лишнего «шума» в консоли.

OSLog — наш главный инструмент для ведения логов. Для этой функции мы передаем тип, название файла и название функции. Кастомизировать это можно как угодно.

Logger — более свежая альтернатива, доступная с iOS 14. Logger от OSLog отличается в деталях. Это разные уровни логирования и возможности настройки логов. С помощью расширений можно создать несколько логгеров, отвечающих за логирование разного функционала.

Подробнее о каждом инструменте — в нашем блоге.

Как оценить, нравится ли сотрудникам работать в компании

Чтобы понимать, какое настроение царит у нас в коллективе, мы раз в полгода проводим два опроса среди всех сотрудников: ESI и eNPS.

1. Индекс удовлетворенности ESI (Employee Satisfaction Index).

Опрос состоит из серии однотипных вопросов, где нужно оценить разные аспекты работы от 0 до 5 (например: уровень ЗП, интересность задач, соцпакет и т. д.).

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

2. Индекс лояльности eNPS (Employee Net Promoter Score).

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

По итогу мы выявляем количество сторонников, нейтралов и критиков.

Процент сторонников минус процент критиков — это и есть показатель, на который мы ориентируемся.

Улучшение этих показателей — основной KPI нашего HR-директора, и весь HR-отдел работает над тем, чтобы сотрудникам больше нравилось работать. Мы хотим, чтобы наши спецы становились евангелистами, которые помогают транслировать наши преимущества вовне и тем самым укреплять HR-бренд.

Больше материалов об управлении IT-компанией — в блоге нашего исполнительного директора Сергея Кожемякина. Чтобы почитать, включите VPN.

Главный принцип работы с правками от заказчика

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

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

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

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

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

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

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

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

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

Это навело команду Airbnb на хорошую мысль:

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

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

А вывод тут простой: люди зачастую сами прекрасно понимают, как им удобнее работать и какие фичи им нужны. Главное — правильно и вовремя расшифровать их поведение.

3 нескучных приложения для бега

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

Relive

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

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

«Бег» от VK

Сервис «Бег» от VK синхронизируется с данными о тренировках с мобильных гаджетов и публикует их в приложении «ВКонтакте».

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

Zombies, Run!

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

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

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

P. S. А полезные для бега гаджеты мы рассматриваем в отдельной статье — сохраняйте :)

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

NoSQL — нереляционные БД, у них нет жесткой структуры. Скажем, у нас есть класс — пользователи. У каждого из них есть ID, имя, фамилия и проч. Эти данные помещаются в отдельный файл (а не в таблицу), и взаимодействие происходит только с этим файлом. Вы уже не можете забрать какое-то одно поле и работаете только с этим классом.

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

• Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

• Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

• Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.

Docker Hub ушел из России. Чем это грозит?

Сегодня Docker Hub перестал работать для российских пользователей. Вместо репозитория открывается сообщение о блокировке IP-адресов в нескольких регионах мира, в том числе в Крыму. Однако сайт недоступен для всех россиян. Head of DevOps в AGIMA Дамир Грачев объясняет, почему это стало головной болью для большинства IT-компаний.

— Стресс сегодня пережили многие, потому что тема микросервисной архитектуры стала модной в последние годы и Docker Hub был популярен. Из-за его отключения, по сути, упала инфраструктура многих проектов, остановился процесс выпуска релизов. Ломается сборка докеров, пайплайны и т. д. Могут даже ломаться кластеры Kubernetes, если в них ссылка на Docker Hub без зеркала.

Эта ситуация приводит к производственным сбоям. Все отвлекаются на решение этой проблемы. А если говорить глобально, то у каких-то компаний могут возникнуть проблемы с безопасностью. Сегодня мы увидели кучу странных зеркал на Docker Hub, которым сложно доверять. При их использовании произойти может что угодно — вплоть до повторении истории со СДЭКом.

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

Плюсы и минусы GetX и BLoC

1. Простота в использовании.
   
   У GetX более низкий порог входа, он проще в освоении, чем BLoC. Он предоставляет простой и понятный API для управления состоянием, маршрутизации и управления зависимостями.

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

3. Тестирование.
   
   В BLoC есть мощные средства для тестирования потоков событий и состояний, например bloc_test.

4. Возможности.
   
   GetX предоставляет широкий спектр возможностей для маршрутизации и управления состоянием и зависимостями.

Что же выбрать?

Зависит от конкретных требований проекта и ваших предпочтений. Если приложение небольшое и простое, то GetX может быть более подходящим решением. Он предоставляет понятный API для работы, с ним можно писать меньше кода, что существенно экономит время.

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

Это часть статьи Flutter-разработчика Айдара Мавлетбаева — полную версию с кодом ищите тут.

Стили лидерства: как их использовать в работе

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

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

Подходит для кризисных ситуаций.

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

Подходит для задач, связанных с отказоустойчивостью систем. 

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

Подходит для творческих задач.

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

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

Узнать больше о самих стилях и о том, как их комбинировать, можно в отдельной статье.

Рекомендации врача: как минимизировать риски от сидячего образа жизни

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

Чтобы поддерживать физическое состояние в норме, врачи рекомендуют раз в час выполнять 5-минутную разминку.

1. На всё тело. Достаточно вспомнить разминку с уроков физкультуры и сделать что-то подобное: пройтись, сделайте наклоны, повороты головы и корпуса, повисеть на турнике.

2. На запястье. Что можно делать: сгибать запястье одной руки при помощи другой, делать круговые движения кистями, сжимать и разжимать ладони, разводить пальцы в стороны, вращать сцепленными в замок руками.

3. На икры. Добавьте к разминке стояние на носочках, так вы защититесь от варикоза. Просто встаньте на носки и снова опуститесь на стопу несколько раз. Подъемы можно разнообразить: подниматься на носки, стоя в приседе или в наклоне.

4. На глаза. Медленно поморгайте 10–15 раз, зажмурьтесь, посмотрите в окно на предметы на разном расстоянии, «порисуйте» глазами круги, стрелки или простые картины, посмотрите стереокартинки.

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

Три совета продакт-менеджерам

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

Продуктовые дашборды удобно строить в Tableau, а технические метрики отслеживать в Grafana. Еще могут пригодиться Amplitude для аналитики, Miro для майндмеппинга и Kaiten для управления работой продуктовой команды.

Ну и Excel/SQL — без них никуда.

2. Топ ошибок при разработке продуктовой стратегии.

1. Не продумать форс-мажор и план Б.
2. Строить стратегию, оторванную от практики, т. е. без метрик успеха, Roadmap и декомпозиции на проекты.
3. Планировать отдельно от разработки.
4. Считать только оптимистичный/обычный прогноз.
5. Закладывать риски менее 20%.

3. Как не поддаться панике, если стратегия не работает.

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

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

Чтобы ошибаться было не так больно, к стратегии стоит относиться, как к гибкому инструменту. Любая стратегия строится на гипотезах, которые могут не подтвердиться. Сокращайте время на подготовку стратегии, делайте MVP и быстрее приступайте к ее реализации и тестам.

Это пересказ интервью с продактами из «Зоозавра», VK, World Class и AGIMA. Полная версия тут.

Резюме разработчика: на что обратить внимание

1. Одно резюме — одна позиция.

Иногда кандидаты хотят отразить в резюме все свои навыки. Поэтому в заголовках пытаются уместить всё: PHP-разработчик, Python-разработчик, QA-инженер и т. д. Но это только путает. Чем ближе заголовок резюме к названию вакансии, тем лучше.

2. Опыт интереснее всего.

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

3. Важничать — плохо.

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

4. Резюме должно быть читаемым.

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

5. Постоянство — плюс.

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

А еще всегда можно воспользоваться методом бутерброда. Удачи в поисках!

Готовьте кроссовки — RUNIT 2024 уже скоро!

RUNIT — самый большой ежегодный фестиваль спорта и IT в России. Он пройдет 7 июля в Москве в парке «Коломенское».

Кто будет?

В этом году на забеге соберутся рекордные 4000 участников — это разработчики, тестировщики, дизайнеры, менеджеры и все причастные к Digital-индустрии. А поддержать бегунов придут еще как минимум 2000 — их родные, друзья и коллеги.

Что будет?

Для бегунов: несколько дистанций от 3 до 25 километров, личный и командный зачет, эстафета и детский марафон. Каждый участник забега получит стартовый пакет с фирменной футболкой и чипированный номер. Ну и, конечно, медаль на финише!

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

Где и когда?

Открытие фестиваля 7 июля в 8:00. На целый день займем территорию музея-заповедника «Коломенское» в Москве. Это огромная зеленая зона с прекрасными видами на Москву-реку.

RUNIT —  это классная возможность провести время с коллегами и близкими. Там можно обсудить рабочие вопросы, найти новых партнеров, сотрудников, зарядиться энергией и хорошим настроением. И в конце концов, просто испытать себя. Посмотрите, как проходил забег в 2023 году, и обязательно приходите в этом.

Билеты еще можно приобрести на официальном сайте. А самые свежие новости фестиваля — в телеграм-канале.

Ждем вас на старте!

Как развивать эмпатию

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

1. Анализировать конфликты.

Если вы стали участником или свидетелем конфликта, хорошо обдумайте его причины. Почему человек так реагирует? Дело в формулировке? Или в интонации? Или причины глубже? Привычка анализировать свои и чужие мотивы — путь к взаимопониманию.

2. Следить за своими эмоциями.

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

3. Активно слушать.

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

4. Получать обратную связь.

«Расскажи, чем я тебя разозлил», — такие просьбы к коллегам помогут сделать общение более доверительным и открытым. Люди редко говорят о своих эмоциях. Но эмоции часто влияют на поступки. Поэтому получать обратную связь полезно.

5. Читать книги.

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

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

Еще раз о дизайн-системах

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

Из чего состоит дизайн-система?

Дизайнеры создают UI Kit (набор готовых дизайн-решений) → Разработчики переводят UI Kit в код → Код помещают в репозитории

UI Kit и репозиторий связаны с помощью токенов. Это единицы информации, которые хранят в себе константы: например цвет, радиус скругления кнопки, параметры шрифта и т. д. Если поменять значение токена в Фигме, оно попадает в репозиторий и затем автоматически синхронизируется с сайтом.

Когда и кому нужна дизайн-система

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

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

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

• У вас несколько команд, которые работают над одним продуктом, и им нужно поддерживать консистентность.

Однако есть и ложка дегтя

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

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

P. S. Го к нам в канал о дизайне :)

Как часто стоит менять работу

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

Раз в год и чаще

Частая смена работы — это почти всегда красный флаг для работодателя. Большие компании рассчитывают взять человека в штат надолго. Поэтому непостоянство отпугивает рекрутеров.

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

Минусы: человек не успевает погрузиться в проекты и пополнить портфолио, а еще кажется неуживчивым.

Раз в 2–3 года

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

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

Минусы: корпорации всё же ждут от кандидата большей стабильности, особенно от руководителей, а российским компаниям и вовсе нравится шаг в 3–5 лет.

Раз в 5–10 лет

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

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

Минусы: такому человеку сложно проявить гибкость и перестроиться под новые процессы.

5 главных трендов среди мобильных приложений в 2024 году

Приложения здоровья (mHealth)

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

E-commerce

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

Видео- и фоторедакторы

Здесь основной потребитель — поколение Z с его увлечением медиаконтентом. Смартфоны и мобильные приложения уже сейчас предлагают супервозможности для создания контента от идеи до публикации. А применение ИИ здесь создает невероятные перспективы — только взгляните на современную обработку видео и фото, генерацию голоса и субтитров, создание фильтров и анимаций. 

Финтех

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

Искусственный интеллект

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

P. S. В полной версии этой статьи найдете еще больше деталей и аналитики по рынку мобильных приложений.

Как не выгорать, если иногда приходится перерабатывать

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

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

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

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

?‍♂️ Занимайтесь спортом и хорошо высыпайтесь. Тут комментарии излишни. Сон восстанавливает энергию, а физическая активность — пополняет ее запасы. Отвлечетесь от работы, а заодно и здоровье поправите.

? Не храните недовольство в себе. Терпеть — это, конечно, хорошо, но еще лучше — не терпеть. Сделайте с коллегами чат-оральню, где можно в любой момент написать, как вас всё бесит. Так вы выльете всё, что накипело, и получите лучи поддержки.

Другие способы не выгореть дотла в IT — в нашем блоге.

12 техник управления временем и задачами, помимо «Метода помидора»

Часть вторая

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

Reverse Planning. Сперва определяем желаемый результат и план шагов по его достижению. Затем каждый этап разбиваем на мелкие задачи и временные рамки. Получается ясный план действий с таймлайном.

Swiss Cheese. По аналогии с головкой швейцарского сыра с дырками, разбиваем большие и сложные задачи на более мелкие и управляемые. Остается только разрезать всё это на куски-задачи выполнить их. 

Метод Айви Ли. Разработан в начале 20-го века консультантом по управлению временем Айви Ли. Метод заключается в составлении списка из шести наиболее важных задач, которые вы выполняете за день в порядке приоритетности. Начинать нужно с первой задачи, и пока вы ее не закончите, нельзя переходить к следующей. Невыполненные задачи переносятся на следующий день.

Task batching. Это техника группировки задач, где для каждой группы выделяется свой период времени. Например, вы объединяете ответы на письма и звонки и выполняете их в установленное время. Это помогает не распыляться.

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

Часть первая — по ссылке.