Привет! Меня зовут Николай Горланов, и я анонимный начинающий продакт-менеджер :) Хочу поделиться своим первым опытом работы по развитию Pullenti Address SDK, который помогает нормализовать адреса и автоматизировать работу с ними в различных системах.
Гипотеза: новая функция повысит уровень заинтересованности продуктом
Дано: программный продукт Pullenti Address SDK, который умеет приводить адреса к нормализованному виду. Программа может из текстовой строки вроде «Самара, Артёмовская, 22, 23» понять, что Самара — это город, Артёмовская — улица, 22 — номер дома, а 23 — номер квартиры.
Гипотеза: если дополнить наш продукт данными о GPS-координатах объектов (адресов), это будет полезно для потенциальных клиентов. В моем воображении нарисовался образ магазина с доставкой, который сможет проверять, входит ли клиент в зону доставки при вводе адреса в CRM (ранее сталкивался с подобной проблемой, когда нужно было организовать доставку документов по районам).
Примеры использования функции GPS-координат
Согласно методике Jobs to be Done (JTBD), продукт должен выполнять конкретную работу для клиента. Приведу примеры ниже.
Магазин с доставкой: Когда менеджер по доставке вводит адрес клиента в CRM, он хочет мгновенно определить зону доставки, чтобы оперативно организовать доставку без лишних проверок.
Логистическая компания: Когда логистическая компания планирует маршруты для своих водителей, она хочет учитывать точные координаты адресов, чтобы минимизировать время в пути и расходы на топливо.
Обслуживающая компания: Оператор контакт-центра мгновенно определяет обслуживающего клиента менеджера и телефон обслуживающего центра на основании информации об адресе клиента.
Автоматизированная система распознавания голоса: Администрация городского округа при приеме звонков по телефонной линии хочет, чтобы продиктованные голосом адреса с информацией о проблемах в ЖКХ были верифицированы и записаны в базу данных.
Первый шаг: реализация гипотезы
Я предложил эту гипотезу разработчику SDK. Вместе мы определили источник получения данных для координат GPS — данные из Росреестра, которые являются официальными и точными. Через месяц нам удалось загрузить эти данные, провели ручное тестирования новой функциональности. На выходе мы получили новую версию программы, которая теперь имела новую функцию — определение GPS‑координат введенного адреса.
Обнаруженные проблемы и новые возможности
В процессе работы мы выяснили, что GPS‑координаты имеют далеко не все объекты, которые есть в реестре недвижимости. Это подтолкнуло нас к следующему шагу — загрузке данных из других источников, первым из которых стал OpenStreetMap (еще в процессе).
Ура! Моя первая фича выведена в прод! Новая версия Pullenti Address умеет определять геопозицию объекта по адресу. Причем делает она это в некоторых случаях лучше, чем другие геосервисы. В данной статье как раз хотелось рассказать о некоторых примерах.
Возьмем такую текстовую строку, которая относится к объекту недвижимости (в таком виде адрес фигурирует в Росреестре):
Самарская область, г. Самара, Кировский район, 17 км Московского шоссе, здание 2 В.
API Яндекса возвращает по данному адресу следующие координаты: [53.246822, 50.286252]
Но адрес возвращается с параметром «other». Таким образом, мы понимаем, что это не совсем тот адрес, который нас интересует, а какой‑то другой. При проверке оказывается, что это адрес Кировского района (видимо, какая‑то средняя точка). Кировский муниципальный район — это слишком большой объект, чтобы принимать во внимание определение координат.
Результат поиска по текстовой строке в 2GIS (используя веб‑интерфейс): «Точных совпадений нет. Посмотрите похожие места или измените запрос.»
Результат поиска через Pullenti Address: «Выделение текущей сущности в исходном тексте Коэффициент качества: 100. Штатная нормализация через ToString/GetFullPath: Россия, область Самарская, город Самара, внутригородской район Кировский, шоссе Московское, километр 17, д.2В»
Параметр 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)
Zivaka
17.07.2024 13:39А какого еще ответа вы ожидали от amoCRM? Они уже лет 5 не могут сделать адекватно работающий функционал для борьбы с дублями контактов тупо по совпадению номера телефона.
gorlanovnn Автор
17.07.2024 13:39Специально не упоминал название CRM, но это был не amroCRM. Значит еще одна функция Pullenti - выделение одинаковых адресов пригодилась бы как минимум двум известным CRM системам )
maclaudstein
17.07.2024 13:39+2jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
SpiderEkb
17.07.2024 13:39+1Проблема фичеринга в том, что разработчик пихает туда кучу фич без оглядки на то, что именно нужно клиенту, а просто "о, вот еще что я могу сделать!".
В результате, как правило, получается очень тяжелый и запутанный API.
Ну и еще есть вопросы по оптимизации и нагрузке. Сколько времени займет распарсить, скажем, 100 000 000 адресов? Сколько ресурсов процессора оно сожрет?
gorlanovnn Автор
17.07.2024 13:39Хороший вопрос! Обязательно проведем тестирование производительности. По возможности напишу отдельный пост.
maclaudstein
17.07.2024 13:39jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
gorlanovnn Автор
17.07.2024 13:39Да, спасибо за комментарий. На самом деле все как описали: сначала появилась идея, а потом пытаемся найти применение. Но не совсем: перед началом технической реализации функции мы все-таки делали небольшой опрос потенциальных покупателей, который показал: функция может быть полезной. Наверное это нужно было отразить в статье... Просто охват такого опроса был небольшой. Реализация функции была относительно недолгой, поэтому можно рассматривать новую фунцию этапом создания MVP (хотя и получилось сделать полноценную функцию).
Что касается других преимуществ программы в целом - то это не предмет рассмотрения для текущей статьи, но я обязательно учту замечания, если буду писать статью на эту тему.
Что касается любых платформ - почему они не могут быть клиентами? Ведь мы можем улучшить их функционал! Обитают ли наши клиенты на amoCRM и Bitrix24 ? Это вопрос... Ведь наш SDK расчитан скорее на разработчиков систем, чем на конечных пользователей - они смогут реализовать эти функции только с помощью разработчиков.
SpiderEkb
А если в адресе нет улицы?
Ну вот вам вполне реальный адрес
Или кроме города там еще поселок с составе города
Или когда город федерального значения где название региона совпадает с названием города - регион Москва, город Москва...
gorlanovnn Автор
Pullenti прекрасно справляется, если в адресе нет улицы. Например, первый адрес из примера разбирается так:
Россия, область Тюменская, город Тобольск, микрорайон №4, 41
Вот скнин с сайта, где можно это проверить https://garfias.ru/Demo:
Второй пример разбирает так:
Россия, область Свердловская, муниципальное образование Екатеринбург, поселок Палкинский Торфяник, улица Лесная, д.9
Возможность такого разбора была и до появления функции отображения GPS координат.