Хочу поделиться своим опытом разработки продукта с нуля. Надеюсь, этот материал окажется полезным для кого-то. Может быть, продукт, описанный в этой статье, покажется кому-то интересным.
Возможно, я что-то упустил в своем рассказе. Если будут вопросы, прошу оставлять в комментариях.
Идея
Разработкой я начал заниматься еще в 2015, параллельно основной работе. Сначала был стартап, потом фриланс, и вот - свой проект, идея которого возникла в результате череды событий.
Меня раздражало мобильное приложение нашей управляющей компании (далее - УК). Никакой интерфейс, но больше всего я недоумевал над мелкими ошибками, которые затрудняли использование в принципе, но которые было возможно починить элементарно на мой взгляд. Дело в том, что на экране передачи показаний счётчиков, если ввести показания одного и перейти к полю следующего счетчика и ввести показания, то в предыдущем счетчике показания тоже менялись. Я пробовал связаться с разработчиком, предложить помощь, сотрудничество, но мне дали понять что сами справятся.
Был еще один момент. В то время мы оказывали услуги по разработке документов для одной местной УК. В ходе работы выяснилось, что они используют систему диспетчеризации (+ мобильные приложения) того же разработчика что и УК управляющая мои домом. И они постоянно получали жалобы на работу именно мобильных приложений клиентов.
И тогда я решил что смогу сделать свое решение. Мне хотелось создать что-то лучше, чем то что было, что-то качественнее. Так родилась идея своей системы диспетчеризации.
Рынок
Честно сказать, я не думаю что провел исчерпывающее исследование. Моей целью был наш локальный рынок в регионе (для начала хотя бы). На тот момент я толком не понимал даже целевую аудиторию которой было бы интересно мое решение. Сейчас я обозначил бы её как “небольшая УК, в которой максимум работы ведется на бумаге, не автоматизированы процессы и нет своего приложения для клиентов”.
Я дважды заказывал отчет в сервисе Яндекс.Взгляд, чтобы хоть примерно оценить спрос на такой продукт как система диспетчеризации или, как я считал на тот момент - CRM система для УК. И вот какие результаты я получил (на фото ниже):
Дальше я прикинул сколько есть УК в регионе, посчитал финансовую модель на полтора года вперед, примерные точки роста и окупаемости и постарался учесть все расходы. Исходя из расчета, я получил те параметры, при которых примерно через год проект должен был выйти в плюс. Но тем не менее пока остается вопрос реализуемости этих параметров.
Когда я дошел до анализа конкурентов, то понял, что решений достаточно много и есть очень разные по функционалу и возможностям. Посмотрел что они могут, и выделил то, что я считаю нужно обязательно: блок для оператора, мобилки для персонала и мобилки для клиентов. В остальном они мне показались слишком нагруженными разным функционалом для той целевой аудитории, которую я для себя определил.
Практически все решения которые я нашел в интернете предлагали схему монетизации, когда есть какая-то плата за количество лицевых счетов. Поэтому я не стал изобретать велосипед и взял этот вариант за основу.
Стэк
С 2015 я занимался нативной разработкой на Swift под iOS. И исходя из прошлого опыта стартапа, не хотел на старте зависеть от разработчиков Android, бэкендеров, а также маркетологов с дизайнерами.
Для начала надо было определиться с платформой для фронта. Посмотрев варианты мне приглянулся Flutter и я решил выбрать эту платформу. До того момента я ни разу не сталкивался ни с Flutter, ни с языком Dart, однако втянулся очень быстро. Уже в первый вечер была болванка пустого приложения для iOS и Android, пустая, но с рабочим интерфейсом.
Следующим нужно было решить вопрос бэкенда. И, так как у меня уже был опыт работы с Firebase, я решил выбрать его. В нем есть все что нужно: база, пуш-уведомления, метрики, хостинг… В общем всё что надо.
Разработка
Я начал с модуля для оператора. Это веб приложение состоящее из нескольких разделов: заявка, справочник домов, счетчики, контрагенты, материалы и услуги. С дизайном я не особо заморочился на тот момент, делал так как нравилось.
В разделе заявки оператор может создавать/редактировать заявки, назначать исполнителей, отправлять пуш-уведомления заявителям, печатать наряд-задания, печатать разные журналы по заявкам.
- Справочник домов позволяет вести базу домов, карточку дома, перечень квартир, лицевых счетов, собственников, а также отправлять сообщения всем собственникам какого-то конкретного дома.
Раздел счетчиков позволяет сейчас только просматривать показания которые передали собственники через мобильные приложения. В планах сделать выгрузку в таблицу Excel для удобства.
- Раздел контрагентов дает возможность вести базу контрагентов и их сотрудников, а также регистрировать сотрудников для доступа к системе.
- Раздел с материалами и услугами пока находится в разработке так как в последствии не стал приоритетным.
Следующим этапом я разработал мобильные приложения для клиентов. Оно состоит из 4 разделов: сообщения, заявки, счетчики и профиль. В будущем планирую добавить возможность оплаты услуг УК из приложения, но есть некоторые вопросы, которые нужно решить перед внедрением.
И вот, спустя полгода MVP был готов.
Сотрудничество
Мне повезло, один из моих знакомых был директором небольшой управляющей компании. Я поговорил с ними и их заинтересовало мое решение, мы договорились о встрече.
В ходе беседы выяснилось, что у них все процессы построены на бумаге. Было разве что пара таблиц Excel и всё. Им хотелось навести порядок в этом хаосе автоматизировать работу. Тогда мы решили доработать мое решение под их нужды.
Одним из основных требований была разработка мобильного приложения для сотрудников с разными ролями (директор, мастер и исполнитель).
То как сейчас выглядит приложение для исполнителей видно на скриншотах:
Также, было понятно, что некоторый функционал MVP нужно будет переделать, потому что мое представление о процессах оказалось неполным.
В последствии, перед тем как начать получать заявки, пришлось перенести базу с Firebase из-за федерального закона “О персональных данных” № 152-ФЗ. Но к тому моменту разбираться с бэкендом уже не было времени, поэтому я пригласил в проект знакомого бэкендщика. Я арендовал VDS, а он развернул на нем базу. Переписали приложения и всё заработало.
Итоги
Спустя чуть больше чем полтора года, мы имеем систему диспетчеризации с неплохим функционалом:
Но пока разработка ведется только для одного клиента.
В дальнейшем я хочу развить эту систему, добавить нового функционала, но сперва хочу попробовать предложить наше решение еще кому нибудь.
Пока проект окупает только собственные ресурсы в плане хостинга и аренды VDS, но и это я считаю не плохо.
Спасибо за внимание!
Только при чем тут диспетчеризация?
Под диспетчеризацией в ЖКХ традиционно понимается ЛДСС (как минимум) - лифтовая диспетчерская связь и сигнализация.
Это когда в диспетчерскую (а она есть у каждой УК) стекается информация с устройств на обслуживаемых объектах (домах) - аварии лифтов, вызовы из кабины, сигналы о несанкционированном проникновении в служебные помещения (машинные помещения лифтов, электрощитовые).
Я этой темой плотно занимался более 20-ти лет. Начинали мы реально с нуля, когда компьютеры в этой области не применялись совсем (вся диспетчеризация, тогда она называлась ОДС - объединенная диспетчерская связь, была реализована на огромных пультах ПД с лампочками, кнопочками и отдельными проводами до каждого устройства). Мы в начале 90-х разработали архитектуру системы (двухуровневая сеть промконтроллеров), классификацию устройств, систему их описания, протоколы связи, железо, интерфейсы, софт... Изначально еще не было инета, все было локально на RS485 построено.
Когда уходил уже была реализация на микроядре (я как раз занимался разработкой микроядра системы), использовались UDP каналы для связи контроллеров верхнего уровня с ядром и TCP для подключения к ядру интерфейсных клиентов.
Блин, спасибо огромное! Отличное замечание и ещё и с экскурсом в историю!
Вообще, изначально я назвал это CRM системой, но в последствии в ходе общения с заказчиком появился термин «система диспетчеризации».
Я вкладывал в это понятие смысл работы диспетчера управляющей компании. Но судя по всему слабо изучил вопрос с этой стороны.
Ещё раз спасибо!
Да не за что :-)
Просто для меня диспетчер - тот кто сидит перед монитором и получает из системы сообщения типа "ул. Передовиков КапТруда, д. 23, 5-й подъезд, грузовой лифт: авария лифта, кабина между этажами, кабина пуста, двери шахты закрыты". Или "пер. Отстойный, д.5, 2-й подъезд: проникновение в машинное помещение пассажирского лифта".
Вот чем занимались: http://mspural.ru/production/spajder-lajt-sistema-dispetcherizaczii-inzhenernogo-oborudovaniya.html
Правда, там инфа старая достаточно. Я оттуда в 17-м году ушел, что сейчас не знаю... Вроде как что-то живет как-то.
Фактически у нас было несколько типов интерфейсных клиентов - общий, для диспетчера куда все сигналы о всех событиях прилетают (отображаются в виде текстового сообщения и на карте подсвечивается объект, заносятся в протокол в том числе и когда диспетчер на него внимание обратил), клиент для аварийных бригад - там только с лифтами работа, причем для каждой бригады виден только "их" набор лифтов. Там можно диагностику проводить (если на лифте современный контроллер типа УБДЛ или подобного) онлайн, смотреть статистику по авариям, простоям и т.п.
Ну и служебные клиенты. Для конфигурации, администрирования, обновления прошивок контроллеров удаленно, просмотр протоколов.
Был даже "шпион" для ядра который позволял трейслоги удаленно получать если какие-то проблемы возникали.
В общем, там очень много вложено сил туда было. И железо (контроллеры) сами проектировали и софт весь сами делали.
Очень интересно! Спасибо большое за ответ! Вами и правда была большая работа проделана. Лично мне было бы интересно поучаствовать в таком проекте.
Ну да... Начинали с самодельных контроллеров на процессорах 8080 (92-93-й год) и две линии связи - данные по RS485 и голос (связь с кабинами лифтов, аналоговая).
А в последней версии контроллеры на STM32, связь между контроллерами верхнего (IP-шлюз) и нижнего (УСО) уровней по RS485, а выше уже UDP и VoIP для голоса.
Недавно прочитал книгу «Код. Тайный язык информатики» (Чарльз Петцольд), и в ней как раз рассказывалось про работу с памятью с самых низов, начиная вообще с того как это закладывалось на уровне булевой алгебры. Потом логические элементы складывались сумматоры и т.д. Про процессоры 8080 тоже было многое написано. Просто сквозь книгу представить как вы сами контроллеры делали и софт. Очень интересно!
Ну я собственно контроллерами не занимался. У меня был верхний уровень - то, что на компе работает.
В первых версиях была одна программа, она по RS232 общалась с головным контроллером системы.
Вот ее я полностью писал. Интерфейс, интерактивная карта обслуживаемого района, драйвера типов устройств, обмен с головным контроллером и все вот это вот.
Потом перешли на микроядро. Там уже интерфейсных клиентов другой человек делал (с использованием моих наработок), а я занимался микроядром. Оно реализовывало отношение "многие ко многим" между ip-шлюзами и интерфейсными клиентами (головного контроллера там уже не было в ip версии). Ну и еще ряд функций был.
На конечном этапе было два разработчика на верхнем уровне, один под контроллеры софт писал и два схемотехника - один контроллеры проектировал, второй аналоговую часть (блоки питания, усилители и коммутаторы на голосовых линиях).
Классная история! Спасибо что поделились!
Сейчас бы это назвали "стартап", а тогда таких слов не знали :-)
Насколько я помню, там все началось с домашних посиделок.
В той самой конторе, которая занималась обслуживанием лифтов, был коммерческий директор. А у него был младший брат, который закончил ту же кафедру что и я, но на год раньше (Молекулярная физика, ФТФ УПИ).
Ну и как-то старший брат поделился с младшим головной болью - в каждой диспетчерской стоит огромный пульт ПД-32. Обслуживает от 32 лифта. Лифты тогда были древние - из всей автоматики там Реле Контроля Дверей и Реле Индикации Точной Остановки. Плюс кнопка вызова диспетчера и полудуплексная линия голосовой связи. И от каждого (!) лифта в диспетчерскую 4 пары проводов - РКД, РИТО, Кнопка вызова и Голосовая линия. Т.е. на пуль приходит 128 пар. И на каждый лифт там три лампочки (сработка реле или нажатие кнопки вызова) и кнопка подключения к линии голосовой связи. Ну и бумажка с подписью какая группа к какому лифту относится.
Головная боль в том, что всю эту колбасу сложно монтировать, очень сложно обслуживать (если какая-то из пар порвалась) и емкость диспетчерской очень маленькая.
И вот возник вопрос - а нельзя ли все это сделать на современном высоком идейно-художественном уровне. Чтобы вместо пульта был комп.
Младший брат почесал репу, сказал что "надо подумать". И собрал команду из своих, физтехов. Ну и придумали :-)
Следующая проблема была убедить клиента что ему это надо. Потому что УК на тот момент ничего не надо было - и так хорошо. Пилотную версию (замена одного из пультов на нашу систему) году в 94-м где-то ставили за счет конторы и с условием что несколько лет все это будет бесплатно обслуживаться (только так удалось убедить клиента).
Ну а потом как-то все закрутилось. Кто-то про это узнал, вдруг появились конкуренты (у подавляющего большинства интерфейс на компе был до странности похож на наш :-) Ну и появился рынок таких систем.
Но когда мы начинали ничего подобного вообще не было. Все придумывали с нуля.
Жестко! Столько километров кабельных линий… А не думали запатентовать чтоб «похожих» систем не было? Или «похожий» не «копия»?
В том и была проблема.
1. малые расстояния от диспетчерской до объекта
2. огромное количество проводов с большими затратами на прокладку и обслуживание.
Даже в пилотной версии у нас осталось 2 пары (голос и денные) от головного контроллера до домовых концентраторов и по две пары межу домовым и каждым из УСО (но это уже в рамках одного дома или соседних домов).
В IP версии вообще так - есть "куст" из нескольких рядом стоящих домов, на нем стоит один IP шлюз от которого идет по две пары (данные RS485 и голос аналогом) на УСО. А с диспетчерской шлюз уже общается через инет по UDP + VoIP.
Запатентовать можно только против копирования.
А "похожая система" легко обходит патент - "мы тут сделали не так, а вот этак что снизило затраты/повысило производительность и т.п."
Ну и то, что мы ставили пилотом и что сейчас - это просто две разные системы. Идея одна, но идея не патентуется. Патентуется конкретная реализация. А она в каждой версии своя. И по софту и по железу. Есть ряд решений (по классификации устройств, протоколам, интерфейсу) которые изначально оказались удачными и с небольшими изменениями шли от версии к версии, но другие решения в каждой версии свои.
В пилотной версии мы просто заменили имеющийся ПД-32 (32 лифта), в той версии, что ставилась когда я оттуда уходил, на одном из последних объектов у нас было на одной диспетчерской навешано 6 участков в разных концах города (5 домов там, 10 домов здесь...). 18 IP шлюзов, на каждом от 5-ти до 30-ти УСО. Всего диспетчерская обслуживала более 300-т лифтов (а еще сигнализация служебных помещений - машзалы, электрощитовые...)
Ну и сервис - диспетчер сразу видит что случилось и где. Сообщения выводятся нормальным человеческим языком (на каждый код сигнала в БД есть его текстовая расшифровка, по идентификатору устройства-источника определяется где оно установлено), место источника сигнала подсвечивается на карте, ведется протокол - когда сигнал поступил, когда диспетчер его обработал, кто в этот момент дежурил и т.п...
Интересно! Думаю если эту систему уменьшить, то можно превратить в умный дом! Не думали попробовать?
Думал. Но напрямую слишком сложно смасштабировать. Основные принципы - да, можно. Но пока руки не доходят. Хотя дом есть :-) Построил. Некоторые вещи заложил уже на будущее для возможность построения умного дома. Но пока надо пожить и понять что именно нужно, сформулировать "бизнес-требования".
Успехов вам в этом!
А как то защиту каналов связи или самих данных обеспечивали?
Особо нет. Там были пропертиарные протоколы двоичные (точнее, один - датаграммный обмен сверху донизу). Ну были определенные проверки на достоверность сообщения, заголовка, данных. Но там нет ничего критичного, такого что стоило бы усилий по попытке разобраться в этом протоколе и пытаться туда что-то правдоподобное засунуть. А недостоверное игнорировалось сразу.
Спасибо!
Не совсем понятно почему вы это называете "CRM".
Основная задача CRM это не только ведение заявок/заказов/задач, но и организация коммуникаций в одной системе:
- Клиент позвонил, звонок будет виден в системе и доступен для прослушивания;
- написал на почту/мессенджер/в соц сети все попадет в CRM и оператор будет отвечать прямо из CRM в тот канал по которому поступил запрос;
- для рассылок которые в ЖКХ также важны (сообщить о проведении работ всех жильцам дома например), можно использовать интеграции с сервисами почтовых рассылок;
- если функционал позволяет можно вести много другой дополнительной информации:
- номера автомобилей владельцев например,
- показания с домовых счетчиков;
- вести учет оборудования и контроль выполнения регламентом по их обслуживанию.
Спасибо большое за ваш комментарий!
Отвечу вам так:
«Не совсем понятно почему вы это называете "CRM". Основная задача CRM это не только ведение заявок/заказов/задач, но и организация коммуникаций в одной системе:…»
Согласен, но на данный момент нужно понять более базовые вещи, например, будет ли спрос на мое решение. Можно, конечно, посмотреть с другой стороны - спрос будет когда будет достаточно много функционала. В любом случае, я считаю что мой проект - это прообраз CRM системы. Я стремлюсь к тому чтобы сделать её такой.
«…- Клиент позвонил, звонок будет виден в системе и доступен для прослушивания;…»
Да, отличный функционал! Но я бы хотел ещё и расшифровку включить сюда.
«… - написал на почту/мессенджер/в соц сети все попадет в CRM и оператор будет отвечать прямо из CRM в тот канал по которому поступил запрос;…»
Об этом не подумал, хотя это просто интеграция со сторонними сервисами. Спасибо за наводку!
«… - для рассылок которые в ЖКХ также важны (сообщить о проведении работ всех жильцам дома например), можно использовать интеграции с сервисами почтовых рассылок;..»
Я использую пуш-уведомления для рассылок объявлений по домам.
«.. - если функционал позволяет можно вести много другой дополнительной информации: - номера автомобилей владельцев например, - показания с домовых счетчиков; - вести учет оборудования и контроль выполнения регламентом по их обслуживанию.»
В моей системе предусмотрена передача показаний счётчиков. Регистрировать гос. номера автомобилей тоже интересная мысль, но опять же сперва я считаю нужно сделать основу вокруг которой потом уже будет появляться функционал.
Но для этого у 100%жителей должно быть ваше приложение. Как то анализировали эту тему? Будут ли жители ставить еще одно "приложение" при том что законодательство наверняка требует от обслуживающих организаций обязательной возможности передачи обращение по другим каналам.
А бабушке чт делать у которой кнопочный телефон.
Все таки тут ставки должны быть на работы с почтой (что кстати можно использовать в том числе и для решения споров в юридической плоскости, закрепить переписку по почте как официальную переписку по договору) и на смс (для срочных уведомлений, но это затраты на подключение такого сервиса, увы СМС никто бесплатно отправлять не дает).
Тему анализировал, и конечно же бабушка с кнопочным телефоном должна иметь возможность обратиться в УК.
Мой продукт не замена, а дополнительный канал общения с УК для жителей.
Юридические тонкости через почту и смс решать можно. Но так же я видел случаи когда прописывали в договоре что если в месенджере отмечено что человек прочитал сообщение, значит уведомлен. Всё зависит от того, что прописано в документах и пользовательских соглашениях. Например в нашем приложении для клиентов сообщение может быть прочитано и не прочитано.
Я как администратор базы данных конечно могу посмотреть когда именно человек прочитал сообщение, но вот это к делу не пришьёшь наверно.
Добрый день, Аlex K.
Отличный материал и интересует судьба проекта на текущий момент
Добрый день, Роман. Рад что оценили с статью, спасибо. Наша версия проекта пока на паузе. А для того, чтобы, возможно, кто-то захотел поразвивать или сделать свое, выложили исходники на гитхаб. Подробнее тут 👉 https://vc.ru/510469