PROстая аналитика с Дари

На экране — админка, которую я сама же и просила сделать: цифры, графики, карточки заказов. Красиво. И я минуту сижу и не понимаю: так, и что мне теперь с этим делать? Это было не один раз. Сначала админка была простым списком — заказы друг под другом, без всякой структуры. Потом я решила, что нужен «операционный дашборд» — побольше графиков, побольше метрик. Стало наряднее, но не понятнее. Следующая версия — разделы «Обзор», «Заказы», «Продукты», вроде бы логично разложено по полочкам. Потом ужали в более компактный вариант, чтобы не листать три экрана ради одной цифры. И каждый раз, глядя на очередную версию, я ловила себя на одном и том же вопросе: окей, а что мне с этим делать прямо сейчас? Красивая карточка с числом — это не действие. Это просто число. Дошли до сути только когда я перестала думать «какие данные показать» и начала думать «какое решение мне нужно принять». В итоге в корне остались четыре вкладки: РНП, Действия, Аналитика, Домашки. Не потому что так эффектнее выглядит, а потому что под каждой — конкретный ответ на вопрос «куда мне сейчас смотреть и что с этим делать». Провалился в заказ — увидел детали клиента. Провалился в РНП — увидел, где деньги. Аналитика, которая не ведёт к решению, — это просто украшение экрана. И это, кстати, ровно то, о чём я говорю в канале про маркетплейсы: не собирайте цифры ради цифр, стройте отчёт вокруг вопроса «что я сделаю дальше, увидев это».

Один из самых неприятных экранов, который я видела в собственном приложении, — когда человек, который уже оплатил курс, открывает Mini App и видит кнопку «Оплатить». Не «Продолжить обучение». Не «Урок». Именно «Оплатить». У нас часть доступа к курсам — помесячная. Человек платит не один раз, а раз в месяц, и заказ должен каждый раз продлеваться и оставаться «активным» в системе. Я специально много раз проверяла именно этот сценарий глазами клиента, потому что интуитивно чувствовала: это самое чувствительное место всего продукта — там, где встречаются деньги и доверие. И вот на одной из проверок наткнулась: помесячный заказ, который по факту активен, человек платит вовремя, — Mini App иногда не считал его активным. То есть доступ должен быть, а экран вёл себя так, будто оплаты никогда не было. Я не лезла разбираться, в какой строчке кода ломается проверка — не моя часть. Моя часть — сформулировать чётко: вот заказ, вот статус оплаты, вот что показывает экран, это неправильно, вот с чем сравнивать. И попросить проверить именно логику определения активного доступа, а не просто перерисовать экран покрасивее. Когда разобрались, стало понятно: красивый интерфейс — это только витрина. Настоящая надёжность продукта не в анимации кнопки и не в цвете экрана. Она в статусах — кто платит, что значит «активен», сколько длится доступ и кто вообще это проверяет. Неидеальную вёрстку можно пережить. А просить оплату у того, кто уже заплатил, — нельзя. Это не баг интерфейса. Это вопрос доверия. За каждым статусом в базе стоит живой человек, который тебе поверил.

«Дари, а где чек? Я же бесплатный урок открываю, а бот просит оплату» — написал мне однажды ученик. Я сначала не поняла, о чём вообще речь. В каталоге у нас есть бесплатные материалы — специально, чтобы человек мог попробовать формат до того, как платить за курс. Открыл, посмотрел, решил для себя, идти дальше или нет. Простая логика, ничего сложного. Но когда я сама зашла и повторила его путь — увидела то же самое. Бесплатный урок вёл себя как платный: просил подтвердить оплату, показывал что-то похожее на чек, будто я только что за него заплатила. Технически бот не был «сломан» — все части работали исправно. Просто внутри логики оба сценария, бесплатный и платный, шли по одной и той же дорожке. Систему один раз написали по формуле «продукт → оплата → доступ», а когда позже добавили бесплатные материалы, они просто встроились в ту же цепочку вместо того, чтобы получить свою. Разделили сценарии: для платного — оплата, чек, доступ. Для бесплатного — сразу доступ, без единого шага оплаты между человеком и материалом. После этого я поняла простую вещь: нельзя проектировать все продукты по одному шаблону просто потому, что так быстрее сделать. У бесплатного и платного разная природа, и если не заложить это с самого начала, система будет технически рабочей — и совершенно нелогичной для человека по ту сторону экрана.

«Готово, протестировано, работает» — эту фразу от ИИ я читала, кажется, чаще, чем «привет». И почти каждый раз происходило одно и то же: я открывала Mini App в Telegram, нажимала ту самую кнопку — и ничего не происходило. Сначала я в это верила. Модель написала код, прогнала какие-то свои проверки, отчиталась — логично ведь думать, что раз отчёт положительный, значит, всё в порядке. Особенно когда правок за день много, а сверять каждую руками — долго. Но на деле «готово» у модели означало «код написан и не падает с ошибкой». А не «человек нажал кнопку и получил то, что ожидал». Кнопка «скопировать промокод» (и реферальную ссылку заодно) исправно существовала на экране — просто ничего никуда не копировала. Один раз сломанный JSON прямо в атрибуте кнопки на несколько часов вырубил весь сценарий оплаты по графику: человеку нужно было просто оплатить следующий платёж, а вместо этого он утыкался в тишину. А ещё один раз при переключении темы интерфейса вместо экрана просто появлялся синий фон. После нескольких таких случаев я завела себе правило: не спрашивать «готово?» и верить на слово, а идти и смотреть глазами клиента. Открывать Mini App, нажимать именно ту кнопку, о которой шла речь, сравнивать с тем, что должно было случиться. Этим же способом всплыла история с постами в канале — они однажды стали публиковаться на три часа раньше срока, потому что в расписании перепутались UTC и московское время. В отчёте модели, конечно, об этом не было ни слова. Так постепенно сложился мой личный критерий готовности: не текст, который написала модель, а реальное поведение продукта в реальном сценарии. А вы проверяете свои автоматизации после того, как ИИ написал «готово» — или тоже сначала верите на слово?