Comments 12
А если в адресе нет улицы?
Ну вот вам вполне реальный адрес
4-й микрорайон, 41, Тобольск, Тюменская областьИли кроме города там еще поселок с составе города
Лесная улица, 9, посёлок Палкинский Торфяник, муниципальное образование Екатеринбург, Свердловская областьИли когда город федерального значения где название региона совпадает с названием города - регион Москва, город Москва...
Pullenti прекрасно справляется, если в адресе нет улицы. Например, первый адрес из примера разбирается так:
Россия, область Тюменская, город Тобольск, микрорайон №4, 41
Вот скнин с сайта, где можно это проверить https://garfias.ru/Demo:
Второй пример разбирает так:
Россия, область Свердловская, муниципальное образование Екатеринбург, поселок Палкинский Торфяник, улица Лесная, д.9
Возможность такого разбора была и до появления функции отображения GPS координат.
А что с имеющимися пользователями? Кому-нибудь из них фича нужна?
А какого еще ответа вы ожидали от amoCRM? Они уже лет 5 не могут сделать адекватно работающий функционал для борьбы с дублями контактов тупо по совпадению номера телефона.
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
Спасибо, отвечу в следующем комменте.
Проблема фичеринга в том, что разработчик пихает туда кучу фич без оглядки на то, что именно нужно клиенту, а просто "о, вот еще что я могу сделать!".
В результате, как правило, получается очень тяжелый и запутанный API.
Ну и еще есть вопросы по оптимизации и нагрузке. Сколько времени займет распарсить, скажем, 100 000 000 адресов? Сколько ресурсов процессора оно сожрет?
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
Да, спасибо за комментарий. На самом деле все как описали: сначала появилась идея, а потом пытаемся найти применение. Но не совсем: перед началом технической реализации функции мы все-таки делали небольшой опрос потенциальных покупателей, который показал: функция может быть полезной. Наверное это нужно было отразить в статье... Просто охват такого опроса был небольшой. Реализация функции была относительно недолгой, поэтому можно рассматривать новую фунцию этапом создания MVP (хотя и получилось сделать полноценную функцию).
Что касается других преимуществ программы в целом - то это не предмет рассмотрения для текущей статьи, но я обязательно учту замечания, если буду писать статью на эту тему.
Что касается любых платформ - почему они не могут быть клиентами? Ведь мы можем улучшить их функционал! Обитают ли наши клиенты на amoCRM и Bitrix24 ? Это вопрос... Ведь наш SDK расчитан скорее на разработчиков систем, чем на конечных пользователей - они смогут реализовать эти функции только с помощью разработчиков.
Записки начинающего продакт-менеджера: новая функция для приложения нормализации адресов