Геймификация программ лояльности: самые популярные и эффективные механики

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

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

2. Механика коллекционирования. Людям нравится собирать сущности, предметы или точки на карте. Особенно, если это органично вписано в общую сценарную канву. Сеттинг, миссии и обаятельные персонажи в этом контексте особенно важны. Они наполняют смыслом наши действия: мы не просто собираем камни в лесу — мы строим высокую башню, в котором укроем принцессу от дракона.

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

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

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

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

Как измерять SEO-видимость в эпоху AI-SERP

За последние годы поисковая выдача изменилась, а традиционный SEO уже не работает так, как раньше. В текущем поиске результаты Google — это не просто список ссылок, а множество слоев ответов: панель данных, блоки с ответами на вопросы, AI-обобщения, Knowledge Panels и др. Большая часть запросов завершается без клика — пользователи получают нужную информацию прямо в выдаче.

В таких условиях привычные метрики — CTR, позиции в топ-10, количество переходов — перестают быть главными показателями эффективности. На первый план выходит метрика Share of SERP Presence, то есть доля присутствия в выдаче. Она оценивает, насколько часто бренд появляются на разных поверхностях выдачи. Чем шире присутствие, тем выше шансы, что пользователь увидит ваш бренд и доверит ему решение, даже если и не перейдет по ссылке.

Формула этой метрики:

Где:

• Brand SERP Volume — суммарное количество упоминаний, блоков и визуальных поверхностей, в которых присутствует бренд по группе запросов.

• Category SERP Volume — совокупное количество всех возможных слотов в выдаче для той же категории запросов (включая AI-поверхности, карусели, интенты, навигационные блоки, органику, People Also Ask и т. д.).

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

Share of SERP Presence становится основным KPI в zero-click экосистеме, потому что:

• клики больше не отражают реальную видимость;

• AI-ответы начинают формировать пользовательское представление о брендах еще до переходов;

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

• отсутствие в AI-поверхностях означает выпадение из семантического поля.

Поэтому рост Share of SERP Presence напрямую коррелирует с повышением вероятности быть цитируемым в AI-ответах, попадать в шорт-листы и становиться «предпочтительным» решением на уровне модели.

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

Как за 30 минут понять, подходит системный аналитик или нет

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

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

1. Опрос по скиллам.

2. Решение прикладной задачи.

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

Выглядит таймлайн примерно так:

• 3 минуты — знакомство: тут представляемся и рассказываем о структуре интервью;

• 10 минут — опрос по скиллам: проходим по чек-листу (можете скопировать его себе) и заполняем соответствующие формы;

• 10 минут — сбор требований: предлагаем кандидату кейс на автоматизацию процесса, тему намеренно формулируем широко, а дальше обращаем внимание, какие вопросы задает соискатель;

• 7 минут — вопросы от кандидата и обратная связь.

Больше подробностей о нашем методе найдете в полной статье, где мы детально разбираем каждый блок интервью с системным и бизнес-аналитиком.

Из чего состоит хороший промпт для генерации картинок

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

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

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

Советы по формированию базового промпта: 

1. Пишите как для машины, а не как для человека. Лучше использовать английский язык, четко задавать субъект, избегать опечаток и ошибок, отделять части промпта друг от друга запятыми. Модели вроде Stable Diffusion 1.5 и 2.1 вообще лучше работают с тегоподобными описаниями. 

2. Важно не сколько слов мы используем, а какие это слова. Вообще в разных моделях разные ограничения по количеству символов. У Midjourney это 60 слов, а у Stable Diffusion — примерно 75. Но базовый промтп не стоит превращать в книгу: лучше задать ему образ четко и по делу, а доработать позже. 

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

4. Некоторые атрибуты тянут за собой другие. Нейронка понимает смыслы не так, как человек. У нее есть ассоциации, и она подтягивает одни атрибуты к другим. Например, голубые глаза могут подтянуть европейские черты лица. Если описывается атрибут, который может нести ассоциации (а они не нужны), лучше дописать, что именно вы хотите видеть. 

5. ИИ хорошо понимает, как общаться с ИИ. Не знаете, как составить базовый промпт — просто попросите об этом ChatGPT. Он справится с этой задачей на отлично. Также есть специальные сайты: PromptHero, PromptBase и др.

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

Как Google оценивает контент: скрытые метрики поискового доверия

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

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

• Question Fringe Score. По одним данным, это оценка того, насколько запрос находится на периферии известного Google пространства знаний — редкий, нетипичный, «длиннохвостый». По другим — оценка потенциальной опасности контента.

• Trust Bias. Это внутренний коэффициент доверия к источнику. Обычно высокий Trust Bias получают государственные домены, крупные медиа, старые сайты без санкций и спама, площадки, которые регулярно цитируют другие доверенные источники.

• Chard Signals. Скорее всего, это репутационная сетка, где Google хранит «ауру» людей и брендов. Сигналы включают тональность и контекст их упоминаний, ссылки с авторитетных площадок, сопоставление с экспертными источниками и жалобы и негативные реакции.

• Topic Authority. Метрика описывает, насколько Google считает автора экспертом в конкретной теме. На нее влияет количество публикаций автора в тематической нише, их качество и ссылочная масса, упоминания автора на сторонних ресурсах, совпадение его профиля с другими экспертами.

• Semantic Drift. Это постепенное расхождение изначального значения темы с ее текущим восприятием алгоритмами. По сути, эта метрика делает так, чтобы старые статьи терли видимость. Бороться с этим явлением можно только путем постоянного актуализации контента.

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

• Web Entity Confidence. Google всё чаще обрабатывает запросы не как набор слов, а как запросы о сущностях — брендах, людях, продуктах. Для каждой сущности существует скрытая метрика web_entity_confidence. Она показывает, насколько поисковик уверен, что она реальна и заслуживает доверия.

Больше о скрытых метриках доверия Google и о способах работы с ними — в отдельной статье.

Внедрение структурированных данных для ИИ-ассистентов: FAQPage, HowTo, таблицы сравнений

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

Типы структурированных данных для ИИ:

1. FAQPage. Такая разметка увеличивает шанс попасть в «Ленту ответов» Google (Featured Snippet) и голосовые ответы.

Как внедрять:

    ```json
    {
      "@context": "https://schema.org",
      "@type": "FAQPage",
      "mainEntity": [{
        "@type": "Question",
        "name": "Как выбрать CMS для интернет-магазина?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "<p>Критерии выбора: поддержка SSL, интеграция с платежными системами, нагрузка до 1000 запросов/сек. Рекомендуем: Shopify, Bitrix, WooCommerce.</p>"
        }
      }]
    }
    ```

2. HowTo. Страницы с HowTo получают на 50% больше переходов из Discover (Google Webmaster Trends 2025).

Как внедрять:

Обязательные поля:

• totalTime: указывайте общее время выполнения (например, «PT30M» для 30 минут);

• tool: перечисляйте инструменты с микроразметкой HowToTool. 

Пример для SaaS:

   ```json
    {
      "@type": "HowTo",
      "name": "Настройка сквозной аналитики в Roistat",
      "supply": [{
        "@type": "HowToSupply",
        "name": "Доступ к API"
      }],
      "step": [{
        "@type": "HowToStep",
        "text": "Авторизуйтесь в панели администратора...",
        "image": "https://example.com/step1.jpg",
        "url": "https://example.com/roistat-guide#step1"
      }]
    }

3. Таблицы сравнений. Страницы с таблицами сравнений конвертируются на 25% лучше (данные CXL Institute).

Как внедрять:

Используйте Product и Review:

    ```json
    {
      "@type": "Table",
      "about": "Сравнение CRM-систем",
      "column": ["Цена", "Интеграции", "Рейтинг"],
      "row": [{
        "@type": "Product",
        "name": "Bitrix24",
        "brand": "Bitrix",
        "aggregateRating": {
          "@type": "AggregateRating",
          "ratingValue": "4.7",
          "reviewCount": "1500"
        }
      }]
    }
    ```

Динамические данные: подключайте API для обновления цен/характеристик в реальном времени.  

Важно: в атрибуте citation указывайте источники данных. Например:

    ```json
    "citation": "Источник: исследование Gartner, 2025 г."
    ```  

Больше о структурированных данных и об интеграции с ИИ-ассистентами — в нашем блоге.

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

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

Именно поэтому AGIMA снова участвует в рейтинге лучших работодателей от HeadHunter — и мы будем рады вашей поддержке.

Проголосовать за нас очень просто:

1. Перейдите по ссылке https://rating.hh.ru/poll.

2. Авторизуйтесь на сайте HH.

3. Найдите AGIMA в категории «Digital‑агентства» и поставьте сердечко.

Опрос открыт до конца октября. 

Голосуйте за AGIMA и делитесь с коллегами бинго для удаленщика — мы вот почти в каждой клеточке узнали себя.

Конкурентов нет — есть единомышленники

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

• Единомышленники. С любым руководителем агентства есть что обсудить. У вас одни и те же проблемы и задачи. У каждого свой уникальный опыт — и из любого подобного разговора можно вынести много полезного.

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

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

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

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

Всего собрали в блоге 20 советов по управлении агентством, которые помогут вырастить из маленького агентства большое. А также будем рассказывать об этом на конференции BOOST 23–24 сентября.

Типы структурированных данных для ИИ-ассистентов

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

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

Какие типы структурированных данных существуют:

• FAQPage. Такая разметка увеличивает шанс попасть в «Ленту ответов» Google (Featured Snippet) и голосовые ответы.

• HowTo. Страницы с HowTo получают на 50% больше переходов из Discover (Google Webmaster Trends 2025).  

• Таблицы сравнений. Страницы с таблицами сравнений конвертируются на 25% лучше (данные CXL Institute).

Технологии вроде FAQPage, HowTo и таблиц сравнений — это не просто способ улучшить SEO, а стратегический актив, который определяет, будет ли ваш контент участвовать в голосовом поиске, чат-интерфейсах или AR-сценариях.

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

Как сделать так, чтобы дизайнер и фронтендер не ругались

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

1. Больше общаться.

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

Кроме того, если подключать фронтендера на этапе разработки прототипа, он сразу сможет подсказать, что будет сделать легко, а что сложно.

2. Следить за актуальностью UI-кита.

Это база. Чтобы всем было удобно работать, в макете должен быть UI-кит. Разработчик сразу будет видеть, какие шрифты и UI-элементы возникнут в проекте. И конечно, UI-кит важно оперативно обновлять и сообщать об этом отделу фронтенда.

3. Внедрять общий процесс на всех уровнях.

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

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

Красные флаги в код-ревью: перегибы, которых лучше избегать

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

2. Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.

3. Токсичность. Во время код-ревью лучше всё-таки искать потенциальные проблемы с кодом, а не учить коллег работать. То есть фокус внимания — не на поиске недостатков в чужой работе, а на самом коде. А личные предпочтения и вкусы относительно кода лучше обсуждать отдельно.

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

А каким должен быть хорошее код-ревью — в нашем блоге.

Google и Яндекс внедрили ИИ в поисковики — и это сильно меняет подход к SEO. Разработали план действий

Современные поисковые системы, в частности Google, все чаще используют большие языковые модели (LLM) для формирования ответов. Каждый из нас может в этом убедиться прямо сейчас. Если в поисковике вбить свой запрос, сначала увидим не конкретные сайты, а большой блок с саммари от нейросетей. Это и есть AI Overviews.

Большие языковые модели обучаются на огромных объемах текстов из открытых источников. В частности, нейросеть изучает закономерности: какие термины, бренды, понятия и темы встречаются в одних и тех же контекстах. Если ваш бренд упоминается в качественных (!) статьях и при этом прочно связан с определенной услугой, нейросеть формирует ассоциативную связь: бренд = тематика. 

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

Для бизнеса это значит следующее:

1. Теперь важно создавать связку «бренд + тематика», а все непрофильные упоминая могут даже навредить.

2. Источник публикаций теперь имеет большее значение: лучше рассказывать о себе в профильных медиа или на площадках со стабильным трафиком.

3. Регулярность публикаций теперь намного важнее. Разовая публикация просто не сформирует ассоциативную связь.

4. Качество контента выходит на первый план: он должен быть полезным и интересным, а не дежурным.

5. Цифровая репутация — новый фактор SEO-продвижения.

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

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

Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики  

На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.

В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.

🛠️ Внешние сервисы без тестовых контуров

Решение: собственный мок-сервис на основе WireMock.

Как он работает:

• тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;

• нужные вызовы подменяются в конфигурации;

• при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.

Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.

Плюс: так мы не зависим от внешних API, которые то работают, то нет.

💸 Платные вызовы и лимиты на тестовые запросы

Решение: изолированные стенды и замещение моками везде, где возможно.

Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.

Плюсы:

• не сжигаем бюджет;

• эмулируем ошибки и нестандартные ответы;

• ускоряем тесты без зависимости от внешней стороны.

🔄 Нестабильность интеграционных тестов

Решение: изоляция и моки как защитный слой.

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

• эмулируем нестабильные вызовы моками;

• изолируем свою часть и фокусируемся на ее стабильности;

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

🤝 Десятки команд, завязанных на общий процесс

Решение: интеграционные проверки и ревью на совместимость.

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

• общие тестовые фреймворки и единый подход к интеграционным тестам;

• сценарии, которые включают зависимости от других команд;

• проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.

Подробнее о каждом из подходов читайте в статье QA-инженера AGIMA Святослава Волохова.

Почему мы разлюбили Isar

Isar — это NoSQL база данных, которую когда-то разработали создатели Hive. Про все плюсы этой БД мы уже писали. Однако однажды нашей Flutter-команде достался проект, который заставил их в корне изменить отношение к Isar и отказаться от этой технологии раз и навсегда.

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

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

Как же мы ошибались! Так как у приложения был офлайн-режим, на старте оно загружало большие объемы данных, среди которых, например, было гигантского видео. И это создавало проблемы. В приложении добавлялись новые справочники, но документации на миграцию в Isar не было. К тому же на Android 32-ой архитектуры в базе вылезли баги.

Как исправить эти нюансы, мы не поняли. Писали письма разработчикам Isar, смотрели, что пишут об этом в сообществах. Но в итоге махнули рукой: решили всё переписать на SQL. Выбрали Drift, так как уже имели опыт работы с ним. Взяли уже готовый интерфейс и добавили его в приложение. Вскоре поняли, что Drift отвечает нашим запросам. Isar же использовать в проектах больше не планируем.

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

Хотим еще больше работ на конкурс маскота для RUNIT

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

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

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

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

Три точки зрения на работу поисковиков

Ответ на вопрос о том, как работают поисковые системы, зависит от того, у кого вы спрашиваете. Рассмотрим верии основных носителей знаний.

🟢 Официальные представители поисковиков: поисковик — это библиотекарь

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

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

🟢 Инженеры: поисковик — интеллектуальный помощник

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

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

🟢 SEO-специалисты: поисковик — это сад

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

Мышление SEO — это постоянные эксперименты и адаптация к новым условиям, ведь «климат» в саду постоянно меняется.

А подробнее о том, как работают поисковики, рассказываем в нашем блоге. Там найдете ссылки на кейсы специалистов, разборы утечек Google и цитаты инженеров.

Что такое чистая архитектура: основные особенности

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

Какие еще свойства чистой архитектуры важны:

1. Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.

2. Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится. 

3. Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.

Большой материал о том, на каком проекте была внедрен этот подход и почему выбрали именно его, читайте в блоге.

Чем полезна ротация разработчиков внутри компании

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

Разберем, как это работает:

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

• Обратная связь от новой команды поможет найти точки роста или новые, более эффективные инструменты. А всё вместе это может благотворно влиять на продуктивность разработчика.

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

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

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

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

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

Колобок как MVP: как запустить продукт и сделать так, чтобы тебя не съели на рынке

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

Если приглядеться, Колобок — это MVP в самом лучшем виде: минимум ресурсов (пришлось «скрести по сусекам»), минимум функционала, максимум очарования — для зайцев, волков, медведей и лис, по крайней мере. 

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

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

Что важно помнить при разработке такого MVP, разберем на примере нашей сказки.

1. Двигайтесь итерациями. Каждый зверь — это итерация. Заяц помог проверить базовую гипотезу и показал, что продукт интересен. Волк и медведь — подтвердили ее. А вот лиса раскрыла уязвимость — слишком Колобок доверчив.
   
   🔹 Совет: запускайте продукт в минимальном рабочем виде и тестируйте на реальных пользователях. Чем быстрее получите обратную связь, тем быстрее сможете доработать слабые места.

2. Работайте на репутацию. Во время тестирования Колобок никому не достался. Это частое переживание продуктологов: «Как быть, если продуктом заинтересуются, а его на самом деле пока нет». Звери остались в недоумении, но на реальных пользователей лучше произвести хорошее впечатление. Это будущая целевая аудитория — ею стоит дорожить, а не бежать от нее в лес.
   
   🔹 Совет: предлагайте пользователям любые плюшки, которые можете позволить. Это может быть промокод при условии предзаказа, благодарственное письмо или персонализированный сервис. Мелочь, а приятно.

3. Создавайте ценность для своей ЦА. Колобок румяный и привлекательный. Ни один зверь не прошел мимо него, потому что Колобок предлагал реальную ценность — как минимум, возможность утолить голод чем-то вкусным.
   
   🔹 Совет: ваш MVP должен решать конкретную проблему пользователя. Без реальной ценности он никому не нужен. Спросите себя: зачем клиентам ваш продукт? Если не можете ответить — дорабатывайте идею.

4. Запускайте быстрее — идеального старта не бывает. Над Колобком не сидели годами, шлифуя рецепт. Сделанный на скорую руку из остатков муки, он выкатился и сразу начал тестироваться.
   
   🔹 Совет: не тратьте месяцы на доводку продукта. Чем быстрее запуститесь, тем раньше узнаете, что нужно исправить. Первый блин комом? Отлично, зато теперь знаете, как делать лучше.

5. Работайте с обратной связью. Всем зверям Колобок явно пришелся по вкусу, и они хотели бы его съесть. Но готовы ли они за него платить и, если да, то сколько? Можно было бы установить цену и тестировать её от встречи к встрече. Лиса съела валявшегося в листьях Колобка, но купила бы его за деньги в следующий раз?
   
   🔹 Совет: Собирайте и анализируйте обратную связь от пользователей — они ваши тестировщики. Узнайте, что они думают о продукте, и спросите, сколько готовы платить.

6. Анализируйте неудачи — это тоже результат. Автономная доставка дала сбой — Колобка съели за бесплатно. Но в этом тоже есть урок: бабка и дед не учли риски и не подготовились к критическому сценарию.
   
   🔹 Совет: большинство MVP «съедают», но это не провал, а обучение. Разбирайте ошибки, улучшайте продукт, и следующий запуск будет сильнее. Может, Колобок 2.0 обзаведется броней от хищников или встроенным анти-лисиным радаром.

P. S. Мы увлеклись таким форматом и уже разобрали основы риск-менеджмента на «Репке» и дали советы по информационной безопасности в сказке «Волк и семеро козлят».

7 очень вредных советов для тимлида

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

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

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

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

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

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

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

7. Пресекайте неформальное общение в команде — это мешает работе. Поболтать о всяком можно и в свободное время. А в рабочих чатах и тем более в офисе не кружок по интересам.

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