Привет! Меня зовут Николай Горланов, и я анонимный начинающий продакт-менеджер :) Хочу поделиться своим первым опытом работы по развитию Pullenti Address SDK, который помогает нормализовать адреса и автоматизировать работу с ними в различных системах.

Гипотеза: новая функция повысит уровень заинтересованности продуктом

Дано: программный продукт Pullenti Address SDK, который умеет приводить адреса к нормализованному виду. Программа может из текстовой строки вроде «Самара, Артёмовская, 22, 23» понять, что Самара — это город, Артёмовская — улица, 22 — номер дома, а 23 — номер квартиры.

Гипотеза: если дополнить наш продукт данными о GPS-координатах объектов (адресов), это будет полезно для потенциальных клиентов. В моем воображении нарисовался образ магазина с доставкой, который сможет проверять, входит ли клиент в зону доставки при вводе адреса в CRM (ранее сталкивался с подобной проблемой, когда нужно было организовать доставку документов по районам).

Примеры использования функции GPS-координат

Согласно методике Jobs to be Done (JTBD), продукт должен выполнять конкретную работу для клиента. Приведу примеры ниже.

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

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

  3. Обслуживающая компания: Оператор контакт-центра мгновенно определяет обслуживающего клиента менеджера и телефон обслуживающего центра на основании информации об адресе клиента.

  4. Автоматизированная система распознавания голоса: Администрация городского округа при приеме звонков по телефонной линии хочет, чтобы продиктованные голосом адреса с информацией о проблемах в ЖКХ были верифицированы и записаны в базу данных.

Первый шаг: реализация гипотезы

Я предложил эту гипотезу разработчику SDK. Вместе мы определили источник получения данных для координат GPS — данные из Росреестра, которые являются официальными и точными. Через месяц нам удалось загрузить эти данные, провели ручное тестирования новой функциональности. На выходе мы получили новую версию программы, которая теперь имела новую функцию — определение GPS‑координат введенного адреса.

Обнаруженные проблемы и новые возможности

В процессе работы мы выяснили, что GPS‑координаты имеют далеко не все объекты, которые есть в реестре недвижимости. Это подтолкнуло нас к следующему шагу — загрузке данных из других источников, первым из которых стал OpenStreetMap (еще в процессе).

Ура! Моя первая фича выведена в прод! Новая версия Pullenti Address умеет определять геопозицию объекта по адресу. Причем делает она это в некоторых случаях лучше, чем другие геосервисы. В данной статье как раз хотелось рассказать о некоторых примерах.

Возьмем такую текстовую строку, которая относится к объекту недвижимости (в таком виде адрес фигурирует в Росреестре):

Самарская область, г. Самара, Кировский район, 17 км Московского шоссе, здание 2 В.

API Яндекса возвращает по данному адресу следующие координаты: [53.246822, 50.286252]

Но адрес возвращается с параметром «other». Таким образом, мы понимаем, что это не совсем тот адрес, который нас интересует, а какой‑то другой. При проверке оказывается, что это адрес Кировского района (видимо, какая‑то средняя точка). Кировский муниципальный район — это слишком большой объект, чтобы принимать во внимание определение координат.

Результат поиска по текстовой строке в 2GIS (используя веб‑интерфейс): «Точных совпадений нет. Посмотрите похожие места или измените запрос.»

Результат поиска через Pullenti Address: «Выделение текущей сущности в исходном тексте Коэффициент качества: 100. Штатная нормализация через ToString/GetFullPath: Россия, область Самарская, город Самара, внутригородской район Кировский, шоссе Московское, километр 17, д.2В»

Разбор адреса в Pullenti Address
Разбор адреса в Pullenti Address

Параметр GPS для данного адреса в Pullenti Address: 53.27284, 50.25372

Проверим, что по этим координатам найдется в 2GIS: Ссылка на 2GIS 

Ага, есть какой-то объект недалеко от стадиона.
Ага, есть какой-то объект недалеко от стадиона.

На Яндекс.Картах: Ссылка на Яндекс.Карты

Ага, тут даже есть подпись, что это диспетчерский пункт.
Ага, тут даже есть подпись, что это диспетчерский пункт.

“Подсказки» и «Нормализация» от dadata позволяют найти точные координаты (почему-то разные для этих двух инструментов, но обе версии показывают на одно и то же здание: 53.272839, 50.2537247 или 53.2729098, 50.253668).

Продвижение, сотрудничество и первый отказ

Отлично, фича реализована, и теперь необходимо проверить гипотезу о том, что эта функция действительно нужна клиентам. Немного поразмыслив, было решено предложить функцию SDK для потенциальных клиентов. Но где их найти? Нужно искать партнеров! Так было принято решение о написании предложения об интеграции с одной известной CRM платформой.

Перед тем как обращаться к разработчикам этой системы, проверил работу с адресами внутри CRM. Оказалось, что там уже есть встроенный механизм нормализации адресов для поля «Адрес» в карточке клиента, но он не всегда работает корректно. Например, при вводе адрес «Самара, ул. Сердобская 8» система не может его найти на карте.

Оказалось, что дело в том, что CRM ищет адреса по базе данных OpenStreetMap и может отобразить его на карте. Но если в OSM адреса нет (как в моем случае), то он не определяется и не отображается на карте. Представляется, что это создает неудобства для пользователей, особенно если они работает с доставкой товаров или корреспонденцией.

Наш SDK умеет нормализовать адреса, разбивая текстовую строку на части (город, улица, дом и т. д.) и находить их координаты. Эти координаты можно затем отображать на OpenStreetMap. Внедрение Pullenti Address на стороне CRM позволило бы устранить необходимость в дополнительных интеграциях с другими системами, такими как DaData или Яндекс.Карты, что предполагает более высокий уровень удобства для пользователей CRM‑системы.

Итак, было решено предложить интеграцию нашего SDK с известной CRM платформой. Однако, был получен ответ: «Вы можете сделать свое приложение в маркете и интегрироваться в продукт. У нас открытый API». Спасибо, пока это не наш вариант. Это был ценный урок — несмотря на то, что у нас была отличная идея, у потенциального клиента в тот момент были другие приоритеты.

Подтверждение гипотезы: глубинные интервью с клиентами

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

Если Ваше приложение работает с адресами, и Вы хотите оптимизировать процесс работы с ними — рассмотрите возможность использования Pullenti Address SDK.

В любом случае, надеюсь, что мой опыт и уроки будут полезны другим начинающим продакт‑менеджерам. Удачи в ваших начинаниях и пусть GPS‑координаты всегда указывают вам верный путь!

UPD Уже после написания статьи понял, что не упомянул очень важный Job srory:

Разработчик систем хочет при работе с данными, которые содержат адреса иметь удобный и понятный инструмент, который можно встроить в систему как микросервис, который возьмет работу с адресами на себя, чтобы не выдумывать «велосипед».

UPD2 Затестить работу можно здесь https://garfias.ru/Demo

Комментарии (12)


  1. SpiderEkb
    17.07.2024 13:39
    +1

    А если в адресе нет улицы?

    Ну вот вам вполне реальный адрес

    4-й микрорайон, 41, Тобольск, Тюменская область

    Или кроме города там еще поселок с составе города

    Лесная улица, 9, посёлок Палкинский Торфяник, муниципальное образование Екатеринбург, Свердловская область

    Или когда город федерального значения где название региона совпадает с названием города - регион Москва, город Москва...


    1. gorlanovnn Автор
      17.07.2024 13:39

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

      Россия, область Тюменская, город Тобольск, микрорайон №4, 41

      Вот скнин с сайта, где можно это проверить https://garfias.ru/Demo:

      Второй пример разбирает так:

      Россия, область Свердловская, муниципальное образование Екатеринбург, поселок Палкинский Торфяник, улица Лесная, д.9

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


  1. datacompboy
    17.07.2024 13:39

    А что с имеющимися пользователями? Кому-нибудь из них фича нужна?


  1. Zivaka
    17.07.2024 13:39

    А какого еще ответа вы ожидали от amoCRM? Они уже лет 5 не могут сделать адекватно работающий функционал для борьбы с дублями контактов тупо по совпадению номера телефона.


    1. gorlanovnn Автор
      17.07.2024 13:39

      Специально не упоминал название CRM, но это был не amroCRM. Значит еще одна функция Pullenti - выделение одинаковых адресов пригодилась бы как минимум двум известным CRM системам )


      1. Zivaka
        17.07.2024 13:39

        Ну Б24 недалеко ушел получается, но по факту в Амо все тоже самое))


  1. maclaudstein
    17.07.2024 13:39
    +2

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

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

    А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.

    Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа


    1. gorlanovnn Автор
      17.07.2024 13:39

      Спасибо, отвечу в следующем комменте.


    1. SpiderEkb
      17.07.2024 13:39
      +1

      Проблема фичеринга в том, что разработчик пихает туда кучу фич без оглядки на то, что именно нужно клиенту, а просто "о, вот еще что я могу сделать!".

      В результате, как правило, получается очень тяжелый и запутанный API.

      Ну и еще есть вопросы по оптимизации и нагрузке. Сколько времени займет распарсить, скажем, 100 000 000 адресов? Сколько ресурсов процессора оно сожрет?


      1. gorlanovnn Автор
        17.07.2024 13:39

        Хороший вопрос! Обязательно проведем тестирование производительности. По возможности напишу отдельный пост.


  1. maclaudstein
    17.07.2024 13:39

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

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

    А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.

    Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.


    1. gorlanovnn Автор
      17.07.2024 13:39

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

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

      Что касается любых платформ - почему они не могут быть клиентами? Ведь мы можем улучшить их функционал! Обитают ли наши клиенты на amoCRM и Bitrix24 ? Это вопрос... Ведь наш SDK расчитан скорее на разработчиков систем, чем на конечных пользователей - они смогут реализовать эти функции только с помощью разработчиков.