Fullstack Founder

Метка: пользователь

  • Сто часов на MVP

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

    Типичные блоки работ будут примерно такими:
    – Исследования, интервью, документация — 10-20 часов.
    – Проектирование пользовательских сценариев и прототипы — 10-20 часов.
    – Дизайн-макеты — 20-40 часов.
    – Работы программиста — 40-60 часов.
    – Инфраструктура и деплой — 5-10 часов.

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

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

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

  • На кукис надейся

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

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

    В Европе аналогичный закон GDPR породил целый класс стартапов, которые показывают окна с согласием на кукисы и ведут журналы.

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

  • Узнать больше о конкурентах

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

    Составить список конкурентов
    – На сайтах-справочниках можно платно выгрузить базу по ОКВЭД и региону.
    – Посмотреть, какие сайты будут в поисковых системах по вашему основному коммерческому запросу.

    Узнать юридическое лицо конкурента
    – Самое простое — посмотреть в тексте пользовательского соглашения на сайте. В самом начале или в самом конце должно быть написано название компании.
    – Можно что-то купить у конкурента и посмотреть на чек.

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

    Тайный покупатель
    Узнать, как устроен путь клиента — попробовать приобрести товар или услугу у конкурента.

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

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

    Я думаю, что проще и лучше всего — дружить с конкурентами и меняться опытом. Но не все рынки к этому располагают.

    А как вы изучаете ваших конкурентов?

  • Как Shazam распознаёт музыку

    Приложения для распознавания музыки (Shazam, SoundHound) и Content ID, который ищет пиратскую музыку на YouTube, работают по одному принципу.

    Как это работает:
    – Пользователь даёт приложению послушать играющую музыку.
    – Алгоритм преобразует звук с микрофона в спектрограмму.
    – Затем разбивает спектрограмму на одинаковые отрезки по доле секунды.
    – На каждом отрезке находит только самые громкие звуки и отмечает их положение (чёрные точки на иллюстрации к посту). Таким образом, одновременный крик и удар барабана оставят отметки в разных частях спектра.
    – Записывает координаты самых громких звуков в виде текстовой строки — хэша.
    – Ищет похожие хэши в своей базе с миллионами предварительно проанализированных песен.
    – Находит совпадение и показывает название песни и исполнителя.

    Таким образом, приложение даже не отправляет запись звука на сервер, а всё преобразование происходит в телефоне пользователя.

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

    Кстати, в начале 2000-х Шазам работал через звонки и СМС! Пользователь звонил на номер и Шазам слушал музыку по телефону. После анализа ответ с названием песни приходил по СМС.

  • Дефицит данных для обучения LLM

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

    Основная же масса лучшего контента защищена авторскими правами. Сейчас регулярно возникают судебные разборки, потому что модели обучают на книгах, изображениях, коде и музыке без разрешения правообладателей. Я не думаю, что такие датасеты попадают под добросовестное использование (fair use), ведь результаты работы моделей конкурируют с произведениями оригинальных авторов.

    Вероятно, скоро оригинального контента будет меньше, чем контента сделанного с нейросетями. Получится, что нейросети будут обучаться на контенте друг друга. В Nature вышла статья, где описывают явление model collapse: когда модели обучаются на сгенерированных данных, то с новыми циклами качество ответов начинает сильно деградировать и модели начинают выдавать бред.

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

    Так что вместе с улучшением технологий нас ждёт ухудшение контента. Тупеем вместе с LLM.

  • Как лигатуры в браузер попали

    Как лигатуры в браузер попали

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

    Это изобретение появилось одновременно из-за лени и ради красоты. Первые лигатуры писали вручную в манускриптах до изобретения печати. В типографском ручном наборе каждый символ был представлен отдельным кубиком ­— глифом. Но некоторые дополнительные глифы включали в себя сразу два символа. Получалась экономия времени при сборке страницы и экономия пространства на бумаге. Эту технику использовал Гутенберг при печати своих первых Библий.

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

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

    Adobe и Microsoft в середине 90-х объединились и сделали стандарт шрифтов OpenType. Это сделало лигатуры доступными на всех платформах. Но поддержку в интерфейсах и браузерах пришлось ждать ещё почти десятилетие.

    Apple, как известные фанаты дизайнерских мелочей, разработали свою технологию рендера шрифтов и свои шрифты. Так в интерфейсах на Mac OS, начиная с версии 8.5 (1998 год!), шрифты стали автоматически использовать лигатуры.

    В середине 2000-х движки браузеров внедрили OpenType, и это добавило поддержку лигатур в браузерах. Дизайнеры и верстальщики получили то, что было в типографике с момента изобретения книгопечати.

    Но обычный пользователь эти детали не видит. Какая разница, смыкаются ли две буквы или между ними есть расстояние?

  • Local-First веб-приложения

    Local-First веб-приложения

    Пропал интернет и приложение перестало работать, потому что все данные оно получало с удалённого сервера. Сообщения не прочитать, документы не отредактировать, а таск-трекер сломался. Знакомая картина?

    Большинство веб-приложений остановит работу, но не все. Набирает популярность новая (или хорошо забытая старая) парадигма Local-First: веб-приложение всегда работает с локальной базой данных, а интернет нужен только для синхронизации.

    Подход внедряют у себя Linear, Miro, Trello, Figma, Notion, Excalidraw, Replit, Obsidian и растущее множество веб-приложений.

    Чтобы реализовать Local-First, разработчикам нужно решить ряд технических вопросов:
    – В какой локальной базе хранить данные?
    – Как приложение должно себя вести при отключении от интернета?
    – Как синхронизировать изменения без конфликта?

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

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

    Замечу, что пользователь ожидает, что ваше приложение будет отзывчивым и поддерживать оффлайн-режим. Внедрение улучшит пользовательский опыт, но вряд ли станет главной фичей. Скорее всего, Local-First подход скоро станет частью фреймворков разработчиков и незаметно распространится.

  • Sentry для отлова ошибок

    Sentry для отлова ошибок

    Пользователи жалуются, что на сайте возникает ошибка. У разработчика “всё работает”. В команде разработки никто ошибку не может воспроизвести ни на одном устройстве. Бывает, что в логах нет ничего, потому что ошибка произошла на фронте. Или записи не информативны. А пользователи продолжают жаловаться…

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

    Это всё позволяет очень быстро найти реальную причину возникшей проблемы.

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

    Раньше мы пользовались SaaS-версией, но некоторое время назад всех РФ-пользователей попросили завершить обслуживание. Так что, я развернул бесплатную self-hosted версию на своей VDS. Система прожорливая, Docker Compose запускает три десятка контейнеров, поэтому требуется достаточно мощный сервер. Такой сервер у нас выходит на 4000 рублей в месяц, зато обслуживает десятки небольших проектов.

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

  • Тепловая карта скролла

    Тепловая карта скролла

    Запустили лендинг и пустили на него трафик. Чтобы понять, хороший ли у нас лендинг, нужно посмотреть на конверсию. Если конверсия низкая, важно понять, на каком этапе пользователь теряет интерес. Поможет нам в этом тепловая карта скроллинга по нашей странице. Она показывает, сколько времени люди провели в каждом блоке и как глубоко прокрутили страницу. Блоки должны терять температуру с глубиной скролла. Так же, как при погружении в океан: на поверхности вода тёплая, а на глубине холоднее.

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

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

    Карта скроллинга находится в Яндекс Метрике → Поведение → Карта скроллинга. Нужно включить Webvisor в настройках сайта и в коде счётчика.

  • Файлы теперь лежат в ведрах

    Файлы теперь лежат в ведрах

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

    В 2006 Амазон запустили Simple Storage Service (S3) — сервис с простым хранением файлов в облаке, призванный решить все эти вопросы. Через API загружаем файл, сервис генерирует ссылку. Файл загружается в вёдро (bucket), а не на диск. Вёдра не имеют ограничений как у папок и могут быть распределены по разным серверам.

    Сейчас S3-сервис можно создать на многих хостингах в пару кликов. Также можно развернуть своё S3-хранилище с помощью Open Source, например MinIO.

    Для чего это нужно нам сейчас на практике?
    – Загружать и хранить бэкапы — первое с чего обычно начинают.
    – Хранить файлы отдельно от нод, обрабатывающих запросы.
    – Отдавать статические файлы сайта (картинки, скрипты, файлы для скачивания) с отдельного сервиса.
    – Избегать ситуации с переполненным диском на сервере за счёт переноса всех больших файлов в S3.
    – Организовывать безразмерные хранилища файлов на терабайты с открытым и закрытым доступом.
    – Для S3-хранилищ есть библиотеки на всех популярных языках.
    – Все S3-совместимые хранилища работают по образцу Amazon S3, поэтому ко всем хранилищам нужна одна библиотека.
    – Для разработки в docker-compose удобно использовать образ MinIO.

    Может тарифицироваться:
    – Стоимость хранения в гигабайтах.
    – Стоимость трафика загрузки в облако (чаще всего бесплатно)
    – Стоимость трафика выгрузки из облака.
    – Запросы к файлам.
    – Хранение старых версий файла (если работает с версионированием).

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