AveTavern

Расскажу о нашем способе выстроить аналитику от потраченных до заработанных каждым маркетинговым каналом денег с помощью GTM, «Яндекс Метрики», Superset, BILLmanager, Data Layer и кастомных скриптов.

Без аналитики нам не обойтись. UTM-метки годятся для отдельных активностей. А вот чтобы проанализировать, какой канал прибыльный, какой — убыточный, куда инвестировать, как оптимизировать конверсии, проанализировать причины роста или падения продаж, — нужно было забуриться глубже. 

Например, каждый раз, когда продажи резко росли или падали, причины приходилось раскапывать руками. Долго и мучительно: копались в Brand Analytics — вдруг упомянул блогер, шли в «Яндекс Метрику» — был ли скачок в SEO, думали — а может, что-то из рекламы. Но узнать точно всё равно было невозможно. А значит, повторить или избежать — тоже никак.Способ работает при нашем легаси и любви к космолётам и не претендует на то, чтобы быть оптимальным для всех. У нас не получилось срастить Roistat, его счётчик на сайте и BILLmanager с помощью стандартных интеграций. А у наших партнёров — вполне.

У коллег Roistat в комплекте с amoCRM работает как часы. Потому что ребята работают почти с каждым клиентом лично и всех заводят в amoCRM. Мы не можем вносить в CRM конечных пользователей: система переполнится записями. Эти клиенты у нас существуют только на уровне биллинга. А CRM есть только для партнёров, с которыми работает отдел продаж. И там своя система аналитики.

Наша схема подойдёт не всем. Тут много рукописных интеграций: ЯМ → BILLmanager, BILLmanager → Superset, ЯМ → Superset. И каждая из них может перестать работать из-за обновлений любого из компонентов. А ещё всё это нужно поддерживать и следить за чистотой данных. Гораздо проще пользоваться нативными интеграциями. 

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

С чего начали, что получили, куда идем дальше

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

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

Теперь видим:

• Стоимость лида и сколько денег принёс каждый из них, когда стал клиентом.

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

• Сколько было пользователей по каналам и стоимость их привлечения.

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

Инструменты, которые мы использовали на разных этапах

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

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

«Яндекс Метрика» — система аналитики трафика, приходящего на сайт. 

Google Tag Manager (GTM) — ПО, позволяющее в конструкторе отслеживать события на сайте и передавать их в нужные аналитические системы — «Яндекс Метрику» или Google Analytics. 

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

Документация в «Яндексе» 

Документация в GTM

Apache Superset — open-source-решение для визуализации данных.

ClickHouse — open-source-решение для управления базами данных и формирования отчётов на их основании.

Дальше расскажу о наших экспериментах подробнее. 

Roistat, BILLmanager и гугл-таблицы

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

Вот так выглядела и работала схема. Какое-то время.

Общих интеграций у Roistat, его счётчика на сайте и BILLmanager нет, поэтому в ход пошли костыльные решения. Мы не стали писать отдельный обработчик данных для передачи из BILLmanager в Roistat, а воспользовались интеграцией Roistat и гугл-таблиц. Из BILLmanager в таблицы передавались данные о лицензиях вместе с Roistat Id — анонимной меткой, которую BILLmanager получал от счётчика Roistat при регистрации или покупке лицензии пользователем. А Roistat забирал данные из таблиц в свою внутреннюю систему и сращивал их с информацией, которую он получал от счётчика.

Метка в BILLmanager должна где-то храниться — нужно было добавить кастомное поле в таблицу «Услуги». Сделать это можно как со стороны фронтенда, так и на бэкенде — с помощью плагинов. Когда мы делали интеграцию, мы с ISPsystem были одной компанией. Поэтому нам помогали ребята из разработки BILLmanager. Они использовали стандартные возможности биллинга для создания плагинов. При необходимости вы сможете создать похожий плагин самостоятельно.
Документация по настройке типов услуг в BILLmanager
Документация по плагинам для BILLmanager

О бэкенде интеграции BILLmanager и Roistat рассказывает Ваня Мешков, продакт-менеджер BILLmanager

Интеграция с Roistat состояла из следующих частей:
1. Плагин для BILLmanager на Python.
2. Скрипт isp6stat на Go. 

Описание работы плагина BILLmanager

Файлы:
    /usr/local/mgr5/etc/xml/billmgr_mod_isp6stat.xml,
    /usr/local/mgr5/addon/roistat_visit,
    /usr/local/mgr5/addon/roistat_visit_change_project,
    /usr/local/mgr5/addon/isp6stat.

В настройках бренда в BILLmanager в html-вставке указываем счётчик, который предоставляет Roistat. В результате для клиентов, которые входят в биллинг, выставляется уникальный roistat_visit в куках.

/usr/local/mgr5/addon/roistat_visit представляет собой событие, которое навешено на функцию soft.order.param. Это событие извлекает roistat_visit и id заказываемой услуги и запускает файл /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat_roistat.sh, передавая roistat_visit и item_id в качестве аргументов.

/usr/local/mgr5/addon/roistat_visit_change_project — событие, предназначенное для передачи существующего roistat_visit при переходе в другого провайдера BILLmanager, чтобы roistat_visit в куках клиента на разных провайдерах был одинаковым. Иначе бы у разных провайдеров был разный roistat_visit — при условии, что у провайдеров заданы разные домены.

/usr/local/mgr5/addon/roistat_visit — функция, которая позволяет сотруднику или вручную с помощью cron через http api запустить сбор статистики по услугам ispmanager 6 с последующей записью в гугл-таблицу. Функция запускает файл /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh

Описание работы скрипта isp6stat

Файлы:
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat — исходный скрипт. 
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat_roistat.sh — bash-скрипт, который запускает бинарник с параметром --set-roistat-label и перенаправляет вывод в logs/isp6stat_roistat_{текущая дата}.log
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh — скрипт, который запускает бинарник для сбора статистики по услугам ispmanager 6 с последующей записью в гугл-таблицу. Перенаправляет вывод в logs/isp6stat_{текущая дата}.log
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/config.ini — файл настроек.
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/gkey.json — ключ google api, используется приложением для записи в гугл-таблицу.
    /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/logs — директория с логами.

Бинарник создаёт отдельную БД isp6stat в СУБД для BILLmanager, в которой создаются следующие таблички:
isp6stat.roistat_visit — хранит информацию о roistat_visit'ах c привязкой к id услуги;
isp6stat.client — информация о сделках. По сути, копия данных в гугл-таблице.

Общий принцип работы

Клиенты с выставленным в куках roistat_visit заказывают услугу. В момент заказа вызывается isp6stat_roistat.sh, сохраняется привязка roistat_visit к услуге.

По расписанию, указанному в crontab, запускается /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh и собирается статистика по услугам c тарифными планами, указанными в конфиге — запрос sqlItemsQuery в billmgr/billmgr.go. Далее выполняется предобработка. Например: перевод валюты, выставление roistat_visit. Потом данные сохраняются в таблицу isp6stat.client. Потом эти же данные отправляются в гугл-таблицу.

Почему не взлетело. Если бы всё сработало так, как и было задумано, мы бы увидели в Roistat стоимость лида и сколько денег принёс каждый из них, когда стал клиентом. Со стороны Roistat всё работало отлично, только интеграция с гугл-таблицами непонятно почему периодически ломалась. Roistat — сложный и полезный продукт. Там хорошо видны каналы и даже есть мультиканальная атрибуция. Мы бы с удовольствием им пользовались и дальше — но не случилось. Дальше платить за лицензию Roistat было бессмысленно: мы всё равно не видели в аналитике того, что было нужно. 

Пришлось искать альтернативу. 

GTM, «Яндекс Метрика», Superset и BILLmanager

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

Писать свой счётчик мы не стали — это звезда смерти. Задача настолько большая, что даже непонятно, с какой стороны к ней подойти. Нужно сделать обработку куков, понять, как отслеживать переходы с разных источников и кучу других показателей… Делать всё это мы были не готовы. Поэтому решили построить систему на уже имеющихся элементах: GTM, «Яндекс Метрике», Superset и BILLmanager.

На уровне сайта цели, созданные Roistat, заменили на Data Layer. Data Layer — это технология, которая позволяет передавать информацию о выполнении цели с более глубокой настройкой. Например, информация передаётся не после нажатия кнопки на форме, а после того как бэкенд отработал и отрапортовал, что form submitted. После этого информация подхватывается GTMом и передаётся в «Яндекс Метрику». Так узнаём, какой пользователь какие формы заполнил и какие действия совершил.

После прошлых экспериментов в BILLmanager у нас осталось место, куда можно передавать Roistat ID. Но поскольку поле текстовое, передавать туда можно что угодно. Мы решили запихнуть туда «Яндекс ID», который выполнял ту же функцию, что и Roistat ID. 

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

Теперь наша система аналитики выглядит так

Как теперь выглядит аналитика

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

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

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

Ещё мы строим математические модели для прогнозирования количества клиентов. Но о них в другой раз.

Так что именно имеющаяся у меня приставка Apple TV послужила отправной точкой для дальнейших изысканий.

Сразу же отмечу одну неприятную особенность коммерческих систем: к ним можно подключать только совместимые, заранее одобренные устройства. Это справедливо как для Apple, так и для всевозможных Xiaomi, Tuya и Aqara.

Подход я с самого начала предпочёл нестандартный: вместо того чтобы вкручивать по всему дому лампочки и умные розетки, решил начать с климата. Нашёл в интернете совместимый с HomeKit очиститель воздуха, установил и подключил его. Никакого экшена — всё заработало из коробки. Скучно 🙂 По горячим следам я написал обзорную статью на популярный в то время портал Sprut.AI.

Через какое-то время мне на глаза попалась термоголовка для регулирования температуры батареи отопления, тоже совместимая с Apple HomeKit. Про неё я написал ещё один подробный обзор, когда её интегрировал.

Конечно, насчёт света я слукавил. Была попытка установить умный выключатель света фирмы Koogeek. Но он оказался несовместим с разводкой электросети в квартире. Интегрировать не получилось, пришлось продать на «Авито».

Расширяем возможности HomeKit с помощью Homebridge

Как известно, аппетит приходит во время еды. Поэтому я решил не останавливаться на достигнутом и вскоре нашёл на одном ресурсе инструкцию по сборке датчика контроля концентрации углекислого газа в воздухе на ESP8266. Узнал, что если в помещении слишком высокий уровень содержания CO2, может начать болеть голова. «Полезно!» — подумал я и устремился на AliExpress за деталями. Заказал, дождался, собрал, прошил — и всё на удивление заработало. Однако был нюанс: самодельный датчик, разумеется, никак не мог быть сертифицирован Apple, поэтому в моём умном доме прописать его не получилось бы.

Ситуация не безвыходная: существует такой опенсорсный проект, как Homebridge. Он позволяет подключать к Apple HomeKit любые устройства, даже несовместимые с ним изначально. Фактически это программная прослойка между Apple HomeKit и миром несертифицированных яблочной компанией гаджетов. Но чтобы запустить Homebridge, нужен хотя бы самый примитивный домашний сервер. Так что новый этап строительства умного дома начался с покупки Raspberry Pi, или «малинки» в просторечии.

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

Мойка воздуха очищает его от пыли, запахов, но от CO2 избавить не может. Сейчас у меня настроена система, основанная на принудительной приточной вентиляции. Это пробурённое в стене дома отверстие на улицу. В нём установлен вентилятор с фильтром, который нагнетает воздух с улицы, очищает его и подаёт в комнату. Теперь датчик CO2 работает в связке с этой приточной системой. Если уровень углекислого газа выше 1200 ppm, начинает болеть голова, появляется усталость. Я настроил систему так, что при концентрации выше 1000 ppm автоматически включается приточная вентиляция, а после снижения до приемлемого уровня — выключается.

Получив возможность подключать к умному дому любые сторонние устройства, я потихоньку докупил разных датчиков от Aqara, Xiaomi и Tuya и успешно интегрировал их в Apple HomeKit. Плюс собрал ещё несколько самоделок на ESP. Однако у них есть существенный минус лично для меня: они работают только по вайфаю, в то время как для умного дома существуют специализированные энергоэффективные протоколы. Мне очень нравится Zigbee: для питания датчика достаточно одной батарейки, и она будет служить годами, не требуя замены. А вайфай-устройствам непременно требуется внешнее питание (знаю, знаю, что датчиков CO2, даже зигбишных, на батарейках не бывает, но речь о других). Кроме того, их нельзя использовать для ретрансляции сигнала, в отличие от того же Zigbee, где каждое устройство может выполнять функцию роутера для своих соседей, которые «не добивают» до хаба. Но куда деваться, приходится жить с тем, что в умном доме есть гаджеты и на вайфае, и на Zigbee, и даже что-то на блютусе.

Все развиваются, и скоро на смену этому зоопарку протоколов должен прийти единый удобный протокол Matter. Устройства с его поддержкой уже есть на рынке. Говорят, что с ним всё будет совсем легко и просто. Посмотрим.

Переход на новый уровень: Home Assistant

Со временем система Apple стала мне тесновата. Хотелось создавать более сложные автоматизации, чем предусмотрено вендором. Например, чтобы в конкретных местах при соблюдении ряда условий зажигался свет. Или запускались цепочки действий при достижении каких‑то пороговых значений на датчиках и со сложными условиями. По своей сути умный дом и есть автоматизация рутинных процессов. Всё настраивается так, чтобы в типовых сценариях действия совершались без участия человека. А без сложных (по меркам HomeKit) сценариев здесь никак.

Это и стало толчком к решению, что дальнейшее развитие системы умного дома будет строиться уже без привязки к Apple HomeKit, а на базе какой‑нибудь продвинутой опенсорсной системы, способной при этом служить и хабом для устройств, и движком автоматизации. Выбор пал на Home Assistant, хотя популярный в некоторых кругах Node‑RED я тоже попробовал. В пользу Home Assistant говорили и огромное комьюнити, и множество публикаций в интернете. Так что я решил развернуть Home Assistant на том же Raspberry Pi, благо Homebridge мне больше не понадобится.

Устанавливая Home Assistant в те времена, нужно было быть готовым к тому, что без ковыряния в командной строке не обойтись. Меня это не пугало: более того, я превратил это занятие в своё новое хобби, так как проблем с Linux, благодаря профессии, у меня никогда не было. Несмотря на суровость Home Assistant (особенно её ранних версий) к пользователю, она давала огромные возможности, позволяла тонко настраивать все устройства и взаимосвязи между ними. Очень помогало большое русскоязычное сообщество в «Телеграме», достаточно много информации есть на «Ютубе». Мои возможности росли, а вместе с ними стал активно и разнонаправленно развиваться и мой умный дом.

Apple TV превратился из главного управляющего устройства в рядовой мультимедийный компонент системы. Поскольку одна из функций Home Assistant — служить бриджем в Apple HomeKit, всё, что подключено к Home Assistant, можно добавить и в HomeKit. Поэтому я по‑прежнему могу управлять умным домом и всеми подключёнными устройствами через приложение «Дом» на iPhone или, скажем, попросить Siri поднять шторы в зале.

Изначально я развернул систему на базе Raspberry Pi, но у «малинки» есть свои недостатки: ненадёжная дисковая подсистема на базе SD‑карты, шумный вентилятор охлаждения, который из соседней комнаты не давал спать моей жене 🙂 Поэтому я отправился на «Авито» и нашёл там готовый мини‑ПК Gigabyte с бесшумной пассивной системой охлаждения и с SSD‑диском.

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

Как всё работает сейчас

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

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

Вот какие автоматизации мне удалось реализовать.

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

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

Шторы по календарю. Простая, но самая любимая в нашей семье автоматизация. Автоматическое открывание и закрывание штор. На окнах у нас установлены рулонные шторы блэкаут. Управляются они цепочными моторчиками Aqara. У штор тоже есть условия срабатывания: система определяет, рабочий сегодня день или выходной (Home Assistant можно настроить в соответствии с российским календарём праздников), дома ли тот или иной член семьи, и в зависимости от этого поднимает утром шторы раньше в будние дни или позже в выходные и праздники. А закрываются они сами, по закату солнца. Голосом, конечно, управляются тоже — Siri или Алиса всегда к вашим услугам.

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

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

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

Люди в ванной. Иногда наша дочь подолгу занимает ванную комнату, пока мы с женой смотрим телевизор. Чтобы не стучаться каждые полчаса, я настроил вывод уведомления прямо на экране ТВ. Как только дочь выходит из ванной, мы видим на нём сообщение: «Ура! Ванная свободна!». Когда кто‑то занимает ванную, телевизор тоже об этом уведомляет.

Ёлочная гирлянда. Новогодняя ёлка у нас украшена адресной светодиодной лентой с управлением на базе ESP32 и прошивкой WLED. Можно включить любой из множества красивейших эффектов. Популярная вещь, очень легко интегрируется. Я настроил автоматизацию в Home Assistant так, чтобы раз в 10 секунд из огромной базы эффектов рандомно брался и проигрывался новый случайный эффект.

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

Автономность. Моя система умного дома не связана ни с какими облаками, абсолютно автономна и зависит только от наличия электричества. Даже это ограничение можно обойти с помощью ИБП. Я устроил систему бесперебойного питания, которая поддержит работу всего умного дома в течение 6–7 часов.

Безопасность. Что касается безопасности самих устройств: что ж, тут всё на свой страх и риск. Как известно, в аббревиатуре IoT буква S обозначает Security:)

Об экономии в умном доме и дальнейших планах

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

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

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

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

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

• Home Assistant - Система контроля и автоматизации умного дома

• Home Assistant

• Homever Chat

• Вокруг да около Zigbee

Первоначально интервью опубликовано в блоге компании ispmanager»

Общий принцип найма в ispmanager — короткий time-to-market. Чем быстрее сотрудник начинает приносить пользу компании — тем лучше. Тактики две: ищи готовых или расти новых.

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

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

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

Фильтры — внимательно читайте вакансию

Тут могут быть харды, софты, место жительства, опыт и другие важные элементы без которых кандидат даже до собеседования не доберется. Если принципиально важен опыт 6+ лет, то можно сколько угодно посылать резюме с 3 годами опыта. Вряд ли на него даже посмотрят. Хотя мы смотрим, потому что иногда там скрываются самородки =)

Фильтрами пользуемся всегда. Это помогает быстро обрабатывать большое количество резюме. Недавно у нас была открыта вакансия PR с опытом за рубежом. Поэтому не рассматривали всех кандидатов без опыта работы с зарубежными компаниями или зарубежными рынками.

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

Харды — повторите все, что знаете о навыках в вакансии

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

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

Софты — узнайте, человека с какими качествами ищут

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

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

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

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

Рабочий опыт — рассказывайте о деталях

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

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

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

Совет: перед собеседованием рекомендую перебрать свой опыт, который может быть полезен в вакансии, на которую откликаетесь. Хорошо, если он будет с деталями, но без лишней информации. Поскольку опыт без деталей можно просто выдумать. Но делать так не нужно =)

Профильное образование и опыт работы в индустрии — вытаскивайте наверх нужное

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

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

В ispmanager, как правило, на образование не смотрим — оно не показатель. В отличие от опыта в индустрии. В нашем узком сегменте даже эсэмэмщице нужно знать, что такое Apache, Nginx, OLS, Docker, WireGuard, API‑запросы, DNS.

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

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

Зарплатные ожидания — изучите рынок

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

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

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

Совет: следить за рынком, чтобы не занизить зарплатные ожидания по случайности. Если хотите прикрыть недостатки — попробуйте рассказать в сопроводительном письме в двух словах, какие они и как вы собираетесь это делать. Это поможет вам попасть на собеседование. Ну, а дальше — все зависит от вас самих =)

Бонус

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

А еще я попросил своих коллег-руководителей составить свои списки уровней для каждого из отделов. Делюсь.

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

Коммерческий директор: фильтры → рабочий опыт → опыт работы в индустрии → Meta Skills → софты → харды → зарплата.

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

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

Директор клиентского сервиса: «Если выбирать между софтами и хардами — нам важнее софты. Делать из человека эмпата, любителя коммуникаций — это сложно и долго. А при наличии хотя бы базового понимания IT- сервисов, обеспечивающих интернет, мы можем научить хардам достаточно быстро. Поэтому получается: софты → опыт в индустрии, то есть непосредственно на позиции саппорта → харды → общий рабочий опыт→ зарплата. По зарплате есть стандартная вилка, мы целимся в неё. Но если человек на собеседовании показывает отличные знания, хорошее образование, мы готовы рассмотреть его ожидания».

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