Про количественные и качественные показатели сотрудников

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

• легко контролировать эффективность каждого сотрудника и принимать кадровые решения на основе данных;

• каждый сотрудник, зная свои целевые KPI, стремится к хорошему финансовому результату;

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

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

1. Сильный тимлид плохо перформит. По цифрам его надо уволить, но если копнем глубже, то выясним, что его подвела провальная менеджерская команда или непобедимое легаси.

2. Слаженная команда показывает хорошие Throughput и Lead time. Через полгода выясняется, что они хакнули систему и накрутили красивые метрики, не поставляя бизнес-ценности.

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

Больше об управлении IT-командами рассказываем здесь.

Как мы построили бесконечный винный фонтан своими руками

Каждый год мы с компанией ездим за город на AGIMA Camp. Это летний корпоратив, где мы общаемся с коллегами, строим планы и просто отдыхаем. В этот раз главной темой поездки был американский фестиваль Burning Man. Его участники возводят в пустыне всякие безумные скульптуры и сооружения. Вот и мы решили провести что-то наподобие — конкурс инженерной мысли.

Как раз для конкурса одна из команд собрала своими руками настоящий винный фонтан.

Вот как они это сделали:

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

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

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

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

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

Подробная смета, видео и фотографии механизма — в нашем блоге.

Lottie vs. Rive

Это два популярных инструмента для создания анимаций в приложениях на Flutter. Сравнили их плюсы и минусы.

Lottie

Плюсы:

• Простота использования: благодаря поддержке JSON, Lottie доступен для разработчиков любого уровня.

• Кроссплатформенность: позволяет использовать одни и те же анимации на разных платформах.

• Широкое комьюнити: в сети есть большое количество готовых анимаций.

• Гибкость: Lottie позволяет настраивать анимацию и эффекты, что дает больше контроля над результатом.

Минусы:

• Ограничения по сложности: Lottie не подходит для очень сложных анимаций с большим количеством элементов и эффектов.

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

Rive

Плюсы:

• Интерактивность: Rive поддерживает интерактивные анимации, которые реагируют на пользовательские действия.

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

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

Минусы:

• Сложность использования: у Rive более сложный интерфейс, чем у Lottie, новичкам с ним работать трудно.

• Размер файлов: Rive-анимации могут быть тяжелыми, и это влияет на вес всего приложения.

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

Подробнее про Rive писали в большой статье и в тг-канале о мобильной разработке и ИТ.

Как мы измеряем узнаваемость HR-бренда компании

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

Чтобы результаты были релевантными, добавили в начале вопрос «Работаете ли вы в IT?». Это было нужно, чтобы отсеять ответы, которые нам менее интересны. В итоге на сегодняшний день в опросе приняло участие уже около 1500 человек. Почти все вопросы так или иначе связаны с брендом компании. Но в первую очередь мы спрашиваем, что в целом, кроме зарплаты, мотивирует соискателя принять оффер.

Цели такого опроса:

• понять, что на рынке думают и что знают о нашей компании;

• уточнить, какие каналы привлечения кандидатов работают, а какие нет;

• выяснить, где в HR-бренде слабые места и над чем нужно поработать.

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

Больше подробностей про исследование HR-бренда в нашей статье.

4 совета про стажировки от Junior-разработчика

Перед тем как попасть на стажировку в AGIMA, фронтенд-разработчик Рома просмотрел сотни вакансий и побывал на десятках собеседований. Он проанализировал свой опыт и сделал полезную выжимку для тех, кто ищет стажировки в IT:

1. Не HH.ru единым

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

2. Изучайте инфу о компании

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

3. Учите Git

Многие новички пропускают этот пункт и думают, что Git — это несложно. Но даже изучения основных команд Git недостаточно. Советую сделать пет-проект в команде с такими же новичками — потренируете командную работу и важные навыки в Git: правильное название коммитов (commitlint), разработку отдельных задач в отдельных ветках и т. д.

4. Тренируйте навык тайм-менеджмента и умение отдыхать

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

Это часть большой статьи, где разрабы и их менторы дают советы, как выжить на стажировке в IT — enjoy!

Волшебник Изумрудного города, или Как тестировать MVP сложного продукта

Расскажем об интересном методе тестирования продуктов. Он называется — «Волшебник страны Оз».

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

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

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

Обычно этот метод используют для продуктов, в которых сложный функционал. Интегрировать такой в MVP дорого и накладно. Это может быть то же самое голосовое управление, AI-поиск, VR/AR.

Метод также может быть открытым, закрытым и смешанным.

✓ Открытый — когда у исследователя нет готовых реакций/ответов.

✓ Закрытый — когда они уже четко проработаны.

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

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

Больше о тестировании MVP и UX-исследованиях читайте в нашем Телеграмм-канале.

Новые условия IT-ипотеки

Правительство России продлило программу льготной IT-ипотеки до 2030 года, но исключило из нее Москву и Санкт-Петербург. Ранее сотрудники аккредитованных IT-компаний могли без проблем купить себе квартиру по льготной ставке, причем где угодно — география не влияла на применение льготы. Теперь же расположение компании и самой квартиры имеют значение.

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

Также, согласно новым условиям, процентная ставка выросла до 6%, а размер льготного кредита уменьшился до 9 млн рублей. Кроме того, раньше после оформления ипотеки человек должен был отработать в IT не менее 5 лет. Теперь же менять сферу нельзя, пока ипотека не будет погашена.

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

Как вы оцениваете новые условия IT-ипотеки?

Сперва определяем ценность для пользователя, потом придумываем решения

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

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

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

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

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

P. S. Это часть статьи о ловушке форм-фактора, читайте ее полную версию тут.

Два основных подхода к разработке UI-китов

1. All-in подход. Подключение компонента вместе со стилями или без них. Здесь любой компонент — это самостоятельная единица, которая уже содержит всё нужное. Внутри этого подхода можно выделить два подвида:

• Инлайн-стили через Styled Components (возможно, добавить просто подключение стилей внутри компонента). Этот метод позволяет писать стили непосредственно в компоненте. При этом стили изолированы, что уменьшает возможность конфликтов между стилями разных компонентов.

• Без добавления стилей (Headless). В этом случае компоненты предоставляют только логику без UI, что позволяет самостоятельно управлять стилями. Для создания подобной библиотеки нужно также ознакомиться с паттерном Compound component.

2. Dependency CSS & Bundle CSS подход. Второй большой подход — когда стили и компонент подключаются по отдельности. В этом случае стили и логика компонента отделены друг от друга.

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

• Bundle CSS предполагает подключение всех стилей сразу и отдельно — компонента. По сути, в этом случае все стили объединены в общий бандл и импортируются в корне проекта. 

Но при написании они схожи, и стили к компоненту подключаются как модули.

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

Про скоринг кандидатов

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

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

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

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

Немного цифр:

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

Больше об управлении IT-командами рассказываем здесь.

Кластеризация с использованием Etcd

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

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

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

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

Что касается кластера Etcd, разделенного между Data-центрами, то, если мы будем использовать два Data-центра, система не будет High Availability. В таком случае лучше использовать третий Data-центр, так называемую кворумную площадку. Это может быть любая виртуальная машина в третьем месте, вплоть до ноутбука системного администратора.

Об опыте работы с Etcd рассказываем в большой статье. Делитесь мнением в комментариях.

Зачем мы вкладываем столько времени и сил в стажеров

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

Но при этом на конференциях нам часто задают один и тот же вопрос: зачем вам это надо? Ответов может быть несколько, все они правильные:

• стажеры потенциально закрывают кадровые вопросы, которые по-прежнему на рынке стоят остро;

• стажеры куда более лояльны к компании — у нас, например, они работают не менее 2–3 лет;

• стажеры освобождают время мидлов и сеньоров для более сложных творческих задач;

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

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

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

Интересные кейсы использования Data Science

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

1. Сбербанк использует Data Science для анализа огромных объемов данных о клиентах.
   
   + Помогает предлагать более персонализированные продукты и услуги, а также эффективно бороться с мошенниками.

2. Благодаря анализу данных, Яндекс.Такси может прогнозировать спрос на такси в разных районах города и даже в разное время суток.
   
   + Помогает оптимизировать распределение машин и сокращать время ожидания для пассажиров.

3. Магнит — один из крупнейших ритейлеров в России — использует Data Science для управления запасами и прогнозирования спроса на товары.
   
   + Позволяет избегать дефицита и излишков на полках магазинов, а значит, экономить деньги и повышать удовлетворенность клиентов.

Больше подобных кейсов мы подробно разобрали на подкасте One Two Prod с Олегом Рудаковым, Data Science Head of Analytics крупной FMCG-компании. Ну а еще спросили у Олега о разнице работы в агентстве и продукте, о трендах в аналитике, кому вообще нужен Data Science и где больше платят.

One Two Prod — это совместный подкаст AGIMA и ONY, где мы говорим о развитии диджитал-продуктов. Первый выпуск уже доступен на YouTube и Яндекс Музыке, а второй выйдет на следующей неделе — не пропустите. В нем мы обсудим стратегии и метрики продуктов вместе с Павлом Аксеновым, ex CPO «Самолет Плюс».

Какие качественные и количественные исследования стоит проводить в рамках Discovery-процесса?

Качественные:

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

2. CJM

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

3. Юзабилити-тестирование

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

Количественные:

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

2. A/B-тесты
   
   Делим респондентов на 2 группы: тех, кто видит старый интерфейс, и тех, кто видит новый или экспериментальный. Иногда показываем два варианта дизайна для выбора лучшего. После сбора достаточного количества данных завершаем тест и подводим итоги.

Подробнее о Discovery пишем тут.

Сравниваем Headless- и традиционный подход на примере Strapi CMS и WordPress

Headless CMS — это Low Code Solution для управления контентом.

При первом приближении Headless CMS очень похожа на стандартный подход с Django, Laravel или WordPress с прикрученным JSON API. Но дело в том, что у Headless-подхода есть несколько дополнительных преимуществ.

Выделим главные из них, сравнив Strapi CMS и WordPress:

• Полная и простая кастомизация дизайна
  
  Фронтенд в Strapi — это отдельное приложение. Он не имеет отношения к самой CMS, что дает большую гибкость для создания интерфейсов.

• Скорость отдачи контента
  
  Спорный момент, но Google заявляет, что сайты разработанные с использованием Headless CMS работают быстрее, чем, например, на WordPress.

• Безопасность
  
  У WordPress достаточно много уязвимостей, и поэтому даже простой бэкэнд на нем не совсем безопасен.

• Простота обслуживания и деплоя
  
  Со Strapi всё проще: собираем Docker-образ, пушим изменения кода в репозиторий, и, если настроен CI/CD, всё деплоится без проблем.

• Мультиязычность
  
  В Strapi мультиязычность подключается проще, чем в WordPress. А также поддерживается интеграция со сторонними сервисами для переводов: можно отделить зону ответственности и не пускать переводчиков в систему управления контентом, и в таком случае, они будут использовать свой привычный инструмент.

Если есть, что добавить к плюсам Strapi CMS на фоне WordPress — велкам в комментарии, обсудим. А подробнее о тонкостях работы с Headless CMS пишем в большой статье.

Преимущества Rive при разработке Flutter-приложений

При разработке Flutter-приложений используют много типов анимации, о чем мы ранее уже писали. Но Rive всё-таки превосходит большинство из них. Во-первых, у него удобный встроенный UI-интерфейс. Во-вторых, в Rive есть раздел Community, где авторы выкладывают бесплатные анимации.

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

State Machine включает несколько уровней:

• Graph — пространство, в котором мы добавляем состояния и соединяем переходы.

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

• Transaction — переходы представляют собой логическую карту для State Machine.

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

• Layers — слой State Machine, который позволяет воспроизводить одну анимацию за раз.

Подробнее о том, как работает Rive и как интегрировать его в проект, в нашем блоге.

Как понять, что пора заканчивать процесс Discovery

В этом поможет закон убывающей полезности. Как он работает, объясним на примере.

Когда мы проводим качественные исследования, берем 5–7 человек на один сегмент целевой аудитории. Социология и статистика показывают, что этого достаточно, чтобы выявить 80–90% проблем сегмента. Конечно, мы можем опросить и 30 человек, но выявим ли мы таким образом 100% проблем? Скорее всего, мы потратим намного больше ресурсов, а в итоге сможем лишь незначительно уточнить данные.

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

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

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

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

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

Подробнее о процессе Discovery — в большой статье.

Человек vs машина, или Почему А/Б-тесты не панацея

Недавно Spotify выкатили новую фичу на основе ML — Shortcuts. По сути, это шесть персонализированных плейлистов c музыкальными предпочтениями пользователей.

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

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

🎵 Послушать сейчас.
🎵 Быстрый доступ.
🎵 Горячие кнопки.
🎵 Доброе утро.

Результаты A/B-теста не показали значительной разницы между ними.

Один из участников команды настаивал на варианте «Доброе утро»: так пользователь косвенно будет понимать, что страница с кнопками — его пространство, а горячие клавиши — его персонализированные песни.

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

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

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

Приходите обсуждать продуктовый подход к нам в Телеграм-канал.

Мы создали свой инструмент для доставки сборок Android-приложений

В условиях блокировки официального сервиса Firebase App Distribution в России, перед нашим отделом мобильной разработки встала задача создать собственный инструмент для доставки сборок Android-приложений тестировщикам.

Да, мы могли бы пользоваться Firebase App Distribution с помощью VPN, но это не очень удобно. VPN-сервисы ненадежны, потому что подвержены блокировкам. К тому же создание собственного решения позволяет добавлять новые функции и адаптировать инструмент под конкретные нужды команды.

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

Для его реализации выбрали фреймворк Ktor. Благодаря этому любой разработчик, знакомый с Kotlin, сможет быстро разобраться в кодовой базе, поддерживать инструмент и интегрировать его с различными проектами. А в качестве интерфейса решили выбрать Telegram. Наши рабочие чаты чаще всего находятся именно там. Кроме того, Telegram Bot API предоставляет много возможностей, хоть и имеет некоторые ограничения.

Делимся исходным кодом этого инструмента. А подробная инструкция по работе с ним — в отдельной статье.

Про роль HR бизнес-партнера в компании

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

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

Если же компания становится больше, иерархия усложняется, а связи между людьми становятся всё более комплексными, то доносить ценности и узнавать о потребностях и проблемах сотрудников становится всё сложнее. Тут на помощь приходит HRBP. Это член руководящей команды, играющий на стороне сотрудников. Он должен вставлять палки в колеса любых реформ и управленческих решений, выступая адвокатом сотрудников и не давая руководству (зачастую оторванному от коллектива) наделать глупостей. HRBP важно обладать авторитетом среди сотрудников, чтобы ему откровенно рассказывали о проблемах и сложностях в работе, и затем HRBP мог донести эти проблемы до топ-менеджмента и добиться их решения.

Из вышеописанных функций вытекает третья — трансляция ценностей и преимуществ наружу. Тут HRBP плотно работает с PR-ом, обеспечивая DevRel (Developer Relations) процесс, донося потенциальным соискателям и коммьюнити преимущества работы в компании и укрепляя HR-бренд.

Больше об управлении IT-компанией рассказываем здесь.