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

Бесплатный аудит вашего сайта или сервиса.

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

Что вы получите:
- Четкий список проблем и точек роста.
- Рекомендации, что исправить в первую очередь.
- Предварительную оценку сроков и бюджета.

Напишите в комментариях «Аудит» или оставьте заявку на нашем сайте.

Мы свяжемся с вами и обсудим детали.

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

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

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

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

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

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

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

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

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

Стек: 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

#услуги

"Сколько стоит MVP?" - вопрос, который обычно появляется очень рано. Иногда раньше, чем становится понятно, что именно мы собираемся делать.
Заказчику нужна цифра. Желательно одна, приятная и такая, чтобы подробности проекта не превращали ее в финансовый триллер.

Но у MVP нет тарифа.

MVP, или Minimum Viable Product, - это минимальная версия продукта, которой достаточно, чтобы проверить главную гипотезу: нужен ли он людям и стоит ли развивать его дальше.
А цена уже зависит от того, что потребуется для этой проверки.
Где-то хватит каталога и формы заявки. Где-то понадобятся личные кабинеты, роли пользователей и сложная логика. А если первая версия должна сразу работать с 1С, CRM, платежами и доставкой, слово "минимальный" начинает звучать слегка оптимистично.

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

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

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

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

Но это уже немного другой жанр.
Скорее лотерея.

Есть идея для MVP? Поможем отделить необходимое от лишнего и посчитать реальный бюджет до старта.

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

#услуги

Есть одна фраза, которая для аналитика звучит почти как приглашение копнуть глубже: "У нас все работает нормально".

У нас в команде есть Элина, бизнес-аналитик. В профессию она пришла через математику, но большую часть времени работает не с формулами, а с людьми. Спрашивает, уточняет и особенно внимательно относится к фразам вроде "у нас так принято" и "все и так понятно".

Работа обычно начинается с разговора.

Что вы делаете? Для кого? Как приходит заявка? Кто видит ее первым? Что происходит дальше? А если менеджер ушел в отпуск?

Клиент говорит:
"Отдел продаж обрабатывает заявки".
Хорошо. А что значит "обрабатывает"?

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

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

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

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

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

Узнать больше о команде можно на нашем сайте.

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

#команда

"Сделайте нам как у конкурентов. Только лучше".

Эту фразу мы слышим регулярно.
И сам по себе интерес к конкурентам абсолютно нормален. Более того, не смотреть на рынок было бы странно. Проблема начинается в тот момент, когда "посмотреть" превращается в "повторить".
Копирование кажется безопасным. Вот готовый сайт, вот структура, вот решение, которое вроде бы уже работает. Зачем изобретать свое?
Только вы видите фасад. А почему этот фасад работает - не знаете.

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

Мы открыли сайт и спросили:
"А что именно вам в нем нравится?"

Возникла пауза.

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

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

"Зачем вам это?"

Не "что хотите сделать", а именно "зачем".

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

Но сайт продолжали копировать. Потому что "у них же работает".

В этом и ловушка. Успех конкурента не означает, что каждое его решение удачное. Он может быть результатом бюджета, сильного бренда, времени выхода на рынок или десятка других причин, которых снаружи просто не видно.
Поэтому мы смотрим на конкурентов обязательно. Но не для того, чтобы понять, что у них повторить.
Наоборот - чтобы увидеть, где рынок уже стал одинаковым.
А потом смотрим на пользователя: что он ищет, что его раздражает, почему он уходит и почему возвращается.
И только после этого думаем про продукт.
Это сложнее, чем сказать "сделайте как у них".
Зато в итоге получается не еще один сайт как у всех.
А ваш.

Наши услуги

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

#услуги

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

Прямой эфир. На экране выступает участник, ведущий объявляет голосование - и в этот момент тысячи людей одновременно достают телефоны.

У такой системы есть одна неприятная особенность: сказать "починим завтра" нельзя. Завтра эфира уже не будет.

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

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

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

Голосовать можно было через SMS, email, ВКонтакте и Одноклассники. Задача была простой: не заставлять аудиторию подстраиваться под платформу.

Но самое сложное начиналось в пиковые моменты эфира.

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

В итоге через нее прошло более 300 000 голосов. Стабильность составила 99,9% даже в пиковые моменты, а количество ручных операций удалось сократить на 80%.

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

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

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

Она просто работает.

Именно так и должно быть.

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

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

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

#кейсы

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

В какой-то момент разработчик получает очередной макет и задаёт совершенно нормальный вопрос:
- А эта кнопка такая же, как на главной?

Дизайнер открывает макет, потом сайт, потом ещё один макет.
- Почти. Здесь она немного другая.

Менеджер молчит. Нервно проверяет дедлайн задачи.

Пользователю всё равно. Он кнопку видит и жмёт. Проблема не у него, а у проекта. Каждый новый экран превращается в расследование. Почему здесь высота 48 пикселей, а на соседнем экране 44? Где актуальная карточка? Почему в макете одно, а на сайте другое? Кто это трогал последним? Зачем? И самое неприятное - это не заметно. Нет задачи «потерять восемнадцать часов на расследование происхождения неизвестных изменений». Часы просто уходят. В комментариях, созвонах и фразах «а тут как должно быть?». Работаешь весь день. Вечером смотришь - что сделал? Непонятно.

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

Чаще всего так происходит, когда команда не имея релевантного опыта пытается всё делать сама, на ходу, или когда подрядчик берётся за проект без нормального процесса. Мы такое видели не раз. И обычно это не приговор - просто нужно вовремя остановиться и навести порядок.

Так что если в проекте всё чаще звучит вопрос «а тут как должно быть?» - возможно, пора не рисовать восьмую кнопку, а разобраться с первыми семью.

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

Рассказываем о:
- Проблемах устаревшей системы
- Создании новой архитектуры
- SEO и конечно о результатах

Читайте по ссылке: https://vc.ru/growth/3165659-kak-my-perestroili-internet-magazin-sportivnyh-tovarov-i-uvelichili-konversiyu-na-23-opyt-bulltech