Бультех - разработка IT-продуктов

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

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

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

То есть каталог один. Но для разных людей он уже немного разный.

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

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

Дальше начинается то, чего пользователь обычно не замечает. И хорошо, что не замечает.

Технические детали и масштаб:

Стек: Python (backend), React + TypeScript (frontend).

Бесшовная авторизация: пользователь переходит из внешней системы и сразу попадает в сервис.

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

Автоматизация: тяжелые операции вынесены в фоновые задачи, а система сама следит за сроками действия акций.

Первый MVP команда из пяти человек запустила за полтора месяца.
А дальше MVP сделал то, что хороший MVP и должен делать: не остался MVP.
За два года вышло больше 100 релизов. Сервис регулярно проходит нагрузочное тестирование, для него настроены мониторинг и алерты, чтобы он стабильно работал, когда пользователей уже не тысячи, а сотни тысяч.

В итоге получилось то, что снаружи выглядит довольно просто: каталог предложений.
Только один человек видит одно, другой - другое, третьему сервис меняет даже оформление.
Каталог один, но сценариев - тысячи.

Полный разбор кейса на нашем сайте.

Бультех в Telegram | MAX | ВКонтакте | VC | Behance

#кейсы

Пользователь нашел ваш сайт. Разобрался в услуге. Посмотрел кейсы. Почти решился и нажал "Оставить заявку". Казалось бы, клиент уже у двери.

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

Мы видели сотни таких форм. И каждый раз возникает один вопрос: зачем вам отчество человека, который пока даже не знает, сколько стоят ваши услуги?

Вот основные ошибки и то, как их исправить.

Ошибка 1: Сбор досье вместо начала разговора

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

Решение: Сделайте первый шаг коротким. Имя и телефон (или email). Остальное можно узнать потом при звонке. И оставьте альтернативу: рядом с формой дайте телефон, почту, мессенджер. Кому-то проще написать два слова в Telegram. Перевоспитывать клиента в этот момент довольно поздно.

Ошибка 2: Тишина после отправки

Человек нажимает "Отправить" - и ничего. Позвонят через десять минут или через три дня? Заявка вообще ушла? Может, кнопку нужно нажать еще раз? Тишина в этот момент работает против вас.

Решение: Покажите простое человеческое сообщение: "Спасибо, заявка принята. Свяжемся в течение дня". Человек должен понимать, что произошло и что будет дальше.

Ошибка 3: Технический квест при вводе данных

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

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

Ошибка 4: Проверка формы "на глаз"
Вы видите надпись "Спасибо" на экране и считаете, что всё работает.

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

Иногда весь сайт свою работу уже сделал: дизайн убедил, текст объяснил, кейсы сняли сомнения. А потом появляется поле "Отчество*". И начинается самое интересное.

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

Бультех в Telegram | MAX | ВКонтакте | VC | Behance

#услуги

Фраза прекрасная. В ней есть все: оптимизм, вера в код и вполне человеческое желание нажать "Опубликовать" уже сегодня.

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

Вот только QA - это не человек, который еще раз нажимает те же кнопки.

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

Это как с парашютом: до прыжка проверяют все, что можно проверить. Оставлять тестирование на момент свободного падения - стратегия эффектная, но не очень практичная.

С релизом примерно так же.

Ошибки тоже бывают разные. Где-то на старом смартфоне съехала верстка. Неприятно, но мир переживет. А где-то пользователь дважды нажал "Оплатить", интеграция с 1С не ожидала такой инициативы, и заказ потерялся в базе.
Пользователь вообще редко ведет себя строго так, как для него задумали. Нажимает дважды, возвращается назад, закрывает окно в самый неподходящий момент. Иногда кажется, что исключительно из исследовательского интереса.

Поэтому в Bulltech QA подключается еще на этапе требований. Тестировщик смотрит прототипы, затем реализацию и заранее задает те самые вопросы: "А что будет, если..?"

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

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

Бультех в Telegram | MAX | ВКонтакте | VC | Behance

#услуги