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

В IT это отдельное состояние проекта. Еще недавно у него были сроки, план и понятный список задач. Потом сроки начали двигаться, задачи - прибавляться, а слово «срочно» постепенно стало обычной частью переписки. В какой-то момент кажется, что решение очевидно: нужно просто работать быстрее. Больше разработчиков. Больше часов. Больше контроля. Желательно все сразу. Но если проект уже буксует, скорость редко бывает главной проблемой. Поэтому первое, что мы делаем в такой ситуации - не начинаем срочно писать еще больше кода. Сначала разбираемся, где именно проект остановился. Причина может оказаться технической: не собирается приложение, падает интеграция с 1С, одна часть системы блокирует другую. А может оказаться, что с кодом все более-менее нормально. Просто требования за месяц менялис…

Очень распространенная последовательность. Сначала несколько месяцев проектируют сайт, рисуют страницы, согласовывают тексты, запускают. А потом вспоминают, что хорошо бы еще появляться в Яндексе и Google. И кажется, что дальше дело нехитрое: добавить ключевые слова, прописать пару метатегов - и поисковый трафик наконец пойдет. А дальше Яндекс и Google, по замыслу, должны сами догадаться, какой прекрасный сайт перед ними. Но у SEO неприятная особенность: многое из того, что ему нужно, создается еще до того, как сайт становится "готовым". Подготовили для вас чек-лист "Что должно быть готово на сайте до старта SEO-продвижения": 🔲 Техническая база. Скорость загрузки (Core Web Vitals), корректная работа на мобильных устройствах, SSL-сертификат. Если сайт грузится 5 секунд, никакие тексты е…

Бесплатный аудит вашего сайта или сервиса. Проведем анализ: - Структуры и сценария: где теряются клиенты. - Скорость загрузки и мобильную версию. - SEO-показателей и технические ошибки. - Интеграций с различными сервисами. Что вы получите: - Четкий список проблем и точек роста. - Рекомендации, что исправить в первую очередь. - Предварительную оценку сроков и бюджета. Напишите в комментариях «Аудит» или оставьте заявку на нашем сайте. Мы свяжемся с вами и обсудим детали. Бультех в Telegram | MAX | ВКонтакте | VC | Behance

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

Пользователь нашел ваш сайт. Разобрался в услуге. Посмотрел кейсы. Почти решился и нажал "Оставить заявку". Казалось бы, клиент уже у двери. И тут начинается: имя, фамилия, отчество, компания, должность, email, телефон, город, бюджет, сроки, комментарий... Еще два вопроса - и пользователь уже вправе рассчитывать на соцпакет. Мы видели сотни таких форм. И каждый раз возникает один вопрос: зачем вам отчество человека, который пока даже не знает, сколько стоят ваши услуги? Вот основные ошибки и то, как их исправить. Ошибка 1: Сбор досье вместо начала разговора На первом касании форма пытается узнать всё и сразу. Но чем больше обязательных полей, тем больше причин этот разговор вообще не начинать. Решение: Сделайте первый шаг коротким. Имя и телефон (или email). Остальное можно узнать по…

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