Дубль один, дубль два: как я делала одну фичу дважды

от автора

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

Оба продукта — CDP (Customer Data Platform) для маркетинга. По сути это база данных, которая собирает информацию о клиенте отовсюду и нарезает её в сегменты, — а сверху на эту базу наслаиваются рассылки, бонусы и акции, ласково выманивающие клиента с дивана. Задача-дубль — конструктор сценариев: визуальный редактор, где кампания собирается цепочкой блоков. Классика жанра — сценарий на день рождения:

Сценарий «День рождения»

Сценарий «День рождения»

Это статья про работу над ошибками. Моими. CDP можно не знать: ошибки универсальные — что-то похожее может случиться и у вас.

Дубль один

Начала я как по учебнику: конкурентный анализ, собрать лучшее с рынка, сделать «такое же, только лучше» — то, что по-умному называется бенчмаркингом. Стартовала с блоков: какие будут, что умеют, какие цепочки из них строятся. Кстати, тут появляется иллюзия, что можно предусмотреть все сценарии, которые соберут пользователи. Нельзя: конструктором рулят блоки, и пользователь имеет полное право собрать из них любую ахинею, а она обязана работать.

Блоки есть, просмотр есть, редактирование есть. Живи и радуйся.

Вопрос на засыпку: а что будет, если отредактировать активный сценарий — тот, по которому прямо сейчас идут живые люди?

Пример. Сценарий начисляет 50 бонусов и через пару блоков шлёт: «У вас +50 бонусов!» — текст зашит руками. Поднимаем ставки: меняем начисление на 100, правим текст. А клиент, уже получивший свои 50, до сообщения ещё не дошёл. Дойдёт — и узнает про 100 бонусов, которых у него нет. Поздравляю: мы соврали клиенту, а если клиент лояльный — ещё и выбесили.

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

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

я там кое-что нахреновертила

Дубль два

Во вторую компанию я пришла с этим шрамом — и со старой докой, которая внезапно стала конкурентным референсом. Ирония судьбы. Концепт накидала быстро, а дальше — не кидаться на блоки, смотреть за угол в далекое будущее.

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

Бонусом закрылась ещё одна боль: во многих системах завершение сценария — рубильник. Дёрнул — и все, кому что-то обещали, на улице. Для клиента это ред флаг 🚩, для бренда — репутационный риск. Наш сценарий умеет завершаться вежливо: все дойдут до конца.

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

Словесно драться пришлось за всё

Споры были и в первый раз. Но другие. Однажды мы вдвоём с системным аналитиком полчаса объясняли, почему нельзя завести «универсальное поле», куда из чужих систем по вебхукам будет прилетать любая информация, а мы потом будем с ней «как-нибудь работать». Не будем: это просто текст — в статистике не применишь, по нему не сегментируешь, это вам не поле «пол», которое есть у всех и понятно системе. Поле для всего — это поле ни для чего. Мы отстояли своё, но приз за такую победу — только усталость.

Спор без погружения — налог. Спор погружённых — метод проектирования. Во второй компании были вторые. Три любимых:

Проиграла — и правильно. Я предложила красивое упрощение: пусть система сама делит изменения на «опасные» и «безопасные». Меня ткнули носом, я пораскинула мозгами — и согласилась: система не может обещать «это безопасно» и ошибаться. Самое смешное, что я и сама это знала. Просто идея была уж больно красивая.

окей, признаю

окей, признаю

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

Спор про ДР. День рождения — триггер или расписание? Технически — расписание: система каждый день ищет именинников по базе, никакого «события» нет. Но пользователь мыслит иначе: наступил ДР — бац, сработало. Дожали до триггера. Технически неверно. По-человечески верно. А в интерфейсе должно побеждать человеческое.

Расписание против триггера

Расписание против триггера

Общий знаменатель всех трёх — уровни абстракции. Пользователь не мыслит системой. Я мыслю, но не как архитектор. Архитектор мыслит кодом. Аналитик тут перевозчик между уровнями абстракции. Устаёшь так, что хочется конфет. Считайте это профессиональной вредностью.

История про мечту

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

ну теперь мне уже не хочется

Во второй можно строить хоть космолёт, но мечта должна выйти на другой уровень — аргументированный. Моя вышла.

Условие моей мечты. Отдельный сайд-квест — с боссом в конце. У главного конкурента ветвление пляшет от одного признака: выбрал возраст — и все ветки только про возраст. Я хотела веток по совершенно независимым правилам, чтобы маркетолог крутил аудиторию как угодно. Архитектор отказывал, и по делу: тяжело для системы. Мы долго крутили варианты, потом он покрутил ещё сам — и сделал. Как в моей мечте. Путь от «это мы делать не будем» до «как в моей мечте» существует, просто он не быстрый. В первой компании эта мечта, скорее всего, так и осталась бы в бэклоге — с пометкой «дорого».

Что в итоге

Сценарии на проде, вводим первых клиентов. Новый конструктор мощнее и гибче — правда, целится в профи, а у нас есть клиенты и с одним ресторанчиком. Посмотрим, как эта мощь встретится с рынком.

Первое дитя при этом не плохое: рабочее решение, которое закрыло свои задачи. Просто второе строилось на фундаменте, а первое — на энтузиазме.

Может, в третий раз рожу что-то совсем новое — попроще для пользователя, а значит, посложнее для нас, — с ML-предсказаниями внутри. Главное — без костылей, которые мы все так любим.

Выжимка

✅ Фундамент раньше деталей — к готовому дому его не пристроишь.

✅ Конкуренты дарят идеи в комплекте со своими слепыми зонами и проблемами.

✅ Всех вариантов использования не пропишешь — проектируй элементы и правила их сочетания, любая комбинация обязана работать.

✅ В интерфейсе побеждает логика пользователя, а не устройство системы.

✅ Исследуй на профи, работавших с аналогами: они видят то, чего не видит рынок.

А почему одна и та же задача в первой компании заняла почти два года, а во второй уложилась месяцев в десять, кто такие авторитарные аналитики и при чём тут четырёхчасовые споры о кнопках — расскажу в следующей статье, про процесс

ссылка на оригинал статьи https://habr.com/ru/articles/1063132/