«Петербургская Недвижимость» начала работу в 1994 году. Специализация — риэлтерская деятельность и брокерские услуги. Сейчас это лидер на рынке недвижимости не только в Санкт-Петербурге, но и на всем Северо-Западе.
С точки зрения разработки мобильного приложения работа с ведущей на рынке компанией означает, что придется иметь дело с очень сложным функционалом, непрерывным наращиванием возможностей и необходимостью постоянно выигрывать конкурентную борьбу за клиента.
«Петербургская недвижимость» активно развивается и нужно учитывать, что с ней взаимодействует множество агрегаторов и строительных компаний, а все новые функции, которые появляются на сайте, должны очень быстро отражаться и в мобильном приложении.
О проекте
Проект выдался не только долгоиграющим, но и очень сложным: много экранов, много состояний, много всевозможных нюансов — одна сплошная интеграция.
Существует несколько приложений, разработанных для «Петербургской Недвижимости». Мы работали над «Агент ПН», созданным, специально для агентов недвижимости.
Приложение такого рода значительно отличается от обычных сервисов, рассчитанных на пользователей, которые ищут себе квартиру. На первый взгляд может показаться, что у всех программных решений, созданных для работы на рынке недвижимости, функциональность довольно схожая. И это действительно так.
Существует несколько приложений, разработанных для «Петербургской Недвижимости». Мы работали над «Агент ПН», созданным, специально для агентов недвижимости.
Приложение такого рода значительно отличается от обычных сервисов, рассчитанных на пользователей, которые ищут себе квартиру. На первый взгляд может показаться, что у всех программных решений, созданных для работы на рынке недвижимости, функциональность довольно схожая. И это действительно так.
Однако насыщенность инструмента, рассчитанного на профессионалов, существенно выше, так как наряду с информацией по недвижимости, пользователю должны быть доступны все нюансы, связанные с агентской работой, включая личный кабинет с нетривиальными функциями.
Если оглянуться назад, то сделано много:
- Личный кабинет агента с отслеживанием статуса любого этапа сделки от показа объекта до выплаты комиссии плюс фильтрация записей по дате, клиенту, этапу сделки, статусу залога, типу оплаты и так далее;
- Внешние калькуляторы банков для расчета ипотеки по отдельным условиям;
- Возможность отправлять клиентам панорамы по объектам и презентации по корпусам;
- Отображение комиссионного вознаграждения в карточке квартиры и личном кабинете;
- Удобный поиск и подбор коммерческих помещений;
- Многофункциональный калькулятор ипотеки с расчетом ежемесячных платежей и суммы кредита, учитывающий изменение ставок и досрочные погашения, в который можно попасть прямо из карточки квартиры — все данные подтягиваются автоматически;
- Простой доступ к файлам с условиями различных банков;
- Умные фильтры на главной странице — можно выбрать квартиру по переуступке, этажу, высоте потолка и уникальным преимуществам;
- История изменения размеров комиссии;
- Обучающие видеоролики.
И это мы упомянули только часть функционала, добавленного в последних выпусках!
Если взглянуть на историю версий, то можно заметить, что обновления выходят регулярно, с периодичностью от одного до трех месяцев. Всего работа над проектом ведется более 4-х лет.
Если взглянуть на историю версий, то можно заметить, что обновления выходят регулярно, с периодичностью от одного до трех месяцев. Всего работа над проектом ведется более 4-х лет.
Особенности разработки
Разработка приложения подобной сложности подразумевает контроль над огромным количеством изменений. Как осуществлять учет многочисленных задач? Как отслеживать всё, что находится в конкретной сборке?
Мы организовали доступ заказчика в нашу учетную систему, где он мог самостоятельно формулировать задачи, отслеживать ход выполнения работ и оставлять комментарии. По результатам тестирования новой функциональности заказчик мог закрыть задачу или вернуть её на доработку.
В процессе эволюционного пути задачи меняется её статус. Задачи рождаются в бэклоге, куда заказчик добавляет свои пожелания. Добавление ведется независимо от того, что планировали, что сделали, что успели или не успели.
В процессе эволюционного пути задачи меняется её статус. Задачи рождаются в бэклоге, куда заказчик добавляет свои пожелания. Добавление ведется независимо от того, что планировали, что сделали, что успели или не успели.
Из бэклога задачи перемещаются в раздел оценки, где рассматриваются более предметно. Некоторые из задач требуют дизайна — для этого тоже есть соответствующий раздел.
После решения дизайнерских задач, после согласования методов API для интеграции сервисной части (бэкенда) с приложением задача попадает в раздел ближайшего спринта, откуда после согласования работ перемещается в раздел текущей разработки.
Перед попаданием в выпуск задача успеет побывать в разделе тестирования, где проверяется новая функциональность. Наконец, после прохождения тестов задача попадает в раздел готового, где ждут включения в следующий выпуск все нововведения.
После решения дизайнерских задач, после согласования методов API для интеграции сервисной части (бэкенда) с приложением задача попадает в раздел ближайшего спринта, откуда после согласования работ перемещается в раздел текущей разработки.
Перед попаданием в выпуск задача успеет побывать в разделе тестирования, где проверяется новая функциональность. Наконец, после прохождения тестов задача попадает в раздел готового, где ждут включения в следующий выпуск все нововведения.
Бывает, что со временем обнаруживаются недоработки, требующие исправления или улучшения. Для учета таких ситуаций есть специальный раздел ошибок.
Эту систему мы используем и для синхронизации действий с заказчиком. Её прототип зарождался как таблички в Excel. Тогда приходилось выполнять много ручных действий, что-то постоянно путалось. В конце концов получилось очень удобно и для нас, и для заказчика, где он сам и в любое время может формировать как простые, так и сложные задачи, а также перемещать их в раздел оценки.
Эту систему мы используем и для синхронизации действий с заказчиком. Её прототип зарождался как таблички в Excel. Тогда приходилось выполнять много ручных действий, что-то постоянно путалось. В конце концов получилось очень удобно и для нас, и для заказчика, где он сам и в любое время может формировать как простые, так и сложные задачи, а также перемещать их в раздел оценки.
Вот таким образом у нас образуется спринт — те новые функциональности, которые увидят пользователи в ближайшей версии.
Мы стараемся работать так, чтобы каждый месяц выходил новый релиз. Не трудно заметить, что это получается далеко не всегда. Причин, почему идеальный мир отличается от реального, много. Должны быть согласованы все организационные моменты, все методы API, необходимо дождаться благополучного завершения тестирования для разных платформ и разных устройств, подготовить к запуску внутреннюю инфраструктуру заказчика.
Ещё один созданный нами инструмент для управления сложностью — матрица сборок, которая позволяет наглядно видеть процесс и заказчику, и нашим разработчикам. Матрица сборок включает множество данных, таких как название задачи, платформу (iOS, Android), дату, номер сборки и так далее. Только для одной платформы получается по четыре–шесть сборок в месяц. У нас таких платформ две. Чтобы заказчик лучше понимал, что сделано, а что нет, помечается соответствие задачи и сборки, в которую она вошла.
Получилась простая и отличная система учёта сделанного, без которой так просто разобраться во всём обилии задач как мелких, так и крупных, не получится — и эта система показала себя превосходно.
Документирование — ещё одна часть работы, без которой трудно представить эффективность, особенно, когда основой процесса является интеграция. По каждому экрану приложения делается перечень методов API, которые задействуются при работе экрана. Методов много.
Вообще, тема API очень обширная. Есть поговорка: «Интеграция — опасность для любого проекта». Мы ходили разными путями. Первоначально пытались работать по следующей схеме: сначала разрабатывается дизайн, после чего мы формируем описание методов API.
Для заказчика такая схема работы оказалась неудобной, его представители говорили: «Параметры, которые вы озвучиваете, у нас отсутствуют». Тогда мы попробовали противоположный принцип — заказчик сам формирует документацию по методам API. Но при таком подходе иногда не учитывались все особенности структуры экрана — ведь описание метода составляет менеджер с той стороны, который не всегда детально представляет нюансы страницы на экране смартфона.
Очень быстро выработались правильные алгоритмы взаимодействия и все нестыковки и примеры недопонимания практически исчезли.
Очень быстро выработались правильные алгоритмы взаимодействия и все нестыковки и примеры недопонимания практически исчезли.
Допиливание методов API — перманентный процесс. При такой сложной интеграции учесть все детали заранее невозможно. Что-то можно выявить только в процессе реальной работы и в ходе самой разработки.
Никита Кокин
Разработчик NOTISSIMUS
Работа с дизайном несколько проще. Изменение элементов дизайна согласовывается с проектным менеджером заказчика, который очень хорошо разбирается во всех тонкостях, может грамотно составить задачу, понятно и подробно объяснить требования. Работу принимает тоже он.
В проекте существовала дизайн-система, на основании которой мы прорабатывали экранные состояния.
Так как возможностей у приложения много, то логику экранов и навигацию надо было спроектировать так, чтобы все функции были доступны из разных мест приложения и при этом требовалось минимальное количество действий пользователя.
Так как возможностей у приложения много, то логику экранов и навигацию надо было спроектировать так, чтобы все функции были доступны из разных мест приложения и при этом требовалось минимальное количество действий пользователя.
Сложности
Редко какой проект обходится без неожиданных сложностей, и приложение «Агент ПН» не стало исключением.
Одной такой сложностью оказалось тестирование приложения.
Тестировщики должны детально знать все бизнес-процессы (чтобы оценить качество и объем выдаваемых данных), хорошо разбираться в истории проекта, понимать функциональные особенности мобильного приложения. Поэтому со стороны исполнителя тестировались лишь ограниченные функции приложения — основная нагрузка легла на менеджеров проекта со стороны заказчика.
Одной такой сложностью оказалось тестирование приложения.
Тестировщики должны детально знать все бизнес-процессы (чтобы оценить качество и объем выдаваемых данных), хорошо разбираться в истории проекта, понимать функциональные особенности мобильного приложения. Поэтому со стороны исполнителя тестировались лишь ограниченные функции приложения — основная нагрузка легла на менеджеров проекта со стороны заказчика.
Для упрощения работ по тестированию сделали следующее. На сервере был организован специальный статус «тестировщик». Пользователи приложения с таким статусом могли оперативно переключаться с «боевого» сервера на тестовый и наоборот, без необходимости переустанавливать разные сборки приложения. Такой подход позволил значительно ускорить процесс.
Заканчивая разговор про тестирование, затронем непростой вопрос о гарантии на отдельный функционал. Гарантия должна распространяться, если неисправность вызвана действиями разработчика.
Однако, если изменения в функциональную часть непрерывно вносятся заказчиком (или вообще третьей стороной), то как разработчик может гарантировать неизменность работы?
Однако, если изменения в функциональную часть непрерывно вносятся заказчиком (или вообще третьей стороной), то как разработчик может гарантировать неизменность работы?
Вопрос гарантии на части программного кода очень непростой и зависит от архитектуры проекта и особенностей организации разработки. С «Петербургской Недвижимостью» у нас было хорошее взаимопонимание и по этому вопросу.
Александр Маркович
Руководитель проекта
Факторы успеха
О сложностях мы рассказали. Как же их преодолевать?
Есть несколько ключевых моментов для успеха.
Есть несколько ключевых моментов для успеха.
Когда много интеграции, то чем проще будет организовано общение между разработчиками двух сторон — тем лучше. Подойдет любой канал прямой связи: Telegram, Slack, Mattermost… Так эффективно и без посредников можно будет получать информацию, скажем, об особенностях метода или ограничениях на вызов функции, о добавлении параметров для определенного экрана.
Второй и главный ключевой момент успеха — грамотный менеджмент со стороны заказчика. Именно от этого в большой степени зависит признание проекта. Нельзя сказать, что это что-то исключительное, потому что в коммерческих компаниях на руководящие должности не попадают случайные люди. И тем не менее всегда радостно, когда видно и уровень, и результат.
Хорошим подспорьем явилось то, что у заказчика уже есть мощный сайт, на котором проще и быстрее запускать и «прокатывать» различные гипотезы, а в приложение внедрять уже «отшлифованный» вариант.
Кроме ежедневного рабочего общения раз в неделю в определенный день и час, планировались созвоны менеджеров двух сторон. При необходимости в разговоре принимали участие и разработчики. Такой тесный контакт способствовал общению «на одном языке».
Кроме ежедневного рабочего общения раз в неделю в определенный день и час, планировались созвоны менеджеров двух сторон. При необходимости в разговоре принимали участие и разработчики. Такой тесный контакт способствовал общению «на одном языке».
У нас нет каких-то бизнес-показателей заказчика, чтобы продемонстрировать: вот как было «до», вот как стало «после», как часто ждут читатели. Да и не бывает никогда таких показателей — это коммерческая тайна.
Но если заказчик вкладывается в мобильное приложение, если количество пользователей растет и они дают хорошую обратную связь, если наблюдаются конкуренты — значит, приложение востребовано.
Но если заказчик вкладывается в мобильное приложение, если количество пользователей растет и они дают хорошую обратную связь, если наблюдаются конкуренты — значит, приложение востребовано.
Также очень важно, чтобы пользователи видели прогресс, постоянное улучшение функциональности, какие-либо добавления и обновления.
Аналитика в личном кабинете тоже способствует привлечению новых пользователей. Например, агенту сферы недвижимости важно отслеживать динамику дохода, чтобы оптимизировать эффективность работы.
Приложение должно быть интуитивно понятным. Документацию никто читать не будет. Это не значит, что её не должно быть. Наоборот! Только нужно осознавать современный формат: ни у кого нет времени, никто не хочет напрягаться. Отлично работает документация в виде коротких обучающих видео.
Приложением «Агент ПН» пользуется большое количество людей. Если взглянуть на данные приложение в AppStore или Google Play, то увидим максимальную оценку — пять звезд! — несмотря на сложность приложения.
Если любить пользователя — успех обеспечен!
Если любить пользователя — успех обеспечен!
Проект оказался удачным, так как над ним трудились компетентные команды и с одной, и с другой стороны.
Размышляя о дальнейшем развитии проекта, напрашивается идея объединить два приложения в одно — и для агентов недвижимости, и для клиентов — ведь функционал-то схож по большей части.
Одним словом, агенты недвижимости, работающие с «Петербургской Недвижимостью» могут быть спокойны. Приложение будет развиваться и впереди только ещё больше удобства и возможностей.
Размышляя о дальнейшем развитии проекта, напрашивается идея объединить два приложения в одно — и для агентов недвижимости, и для клиентов — ведь функционал-то схож по большей части.
Одним словом, агенты недвижимости, работающие с «Петербургской Недвижимостью» могут быть спокойны. Приложение будет развиваться и впереди только ещё больше удобства и возможностей.
Результат проделанной работы
