Развитие и поддержка мобильного приложения девелопера на коробочной платформе

Основное мобильное приложение крупного девелопера работало на коробочной платформе. Готовая инфраструктура давала личный кабинет жителя, сервисные сценарии, обращения, коммуникации и мини-приложения — но требовала постоянной доработки под реальные бизнес-процессы застройщика.

Задача была не «поддерживать приложение», а развивать его как продукт: анализировать данные и обращения, находить неработающие сценарии, писать БФТ на доработки, добавлять функциональность, дорабатывать CRM-сценарии, строить гипотезы на аналитике, контролировать подрядчиков, удерживать стабильность и оперативно реагировать на аварии.

Работа шла в режиме постоянного product ownership, а не разовых задач.

Что делали регулярно:

1. Анализ пользовательских сценариев, обращений в поддержку, поведения в приложении, точек отказа, данных CRM и обратной связи жителей.

2. Формирование гипотез и перевод их в БФТ, требования и acceptance criteria для подрядчиков.

3. Приоритизация бэклога по влиянию на бизнес-метрики и на нагрузку поддержки.

4. Контроль подрядчиков: постановка задач, приёмка, регресс, контроль сроков.

Зоны работы: главный экран, профиль, сервисные разделы, мини-приложения, CRM-сценарии, уведомления и статусы, обращения, интеграции, аналитические события, ошибки и производительность, UX-проблемы и регрессионные дефекты.

Отдельный блок — две аварийные ситуации из-за внешних обстоятельств. Ждать идеального архитектурного решения было нельзя: внедрили временные workaround-решения, которые на период полноценной починки заменили неработающий сценарий и сохранили работоспособность ключевых процессов.

Приложение развивалось как живая PropTech-платформа, а не как статичная коробка.

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

2. Гипотезы превращались в БФТ и доработки с понятной приёмкой.

3. CRM-сценарии адаптировались под реальные процессы управляющей компании.

4. Мини-приложения расширяли возможности приложения без переписывания платформы.

5. Аварии закрывались временными решениями в тот же цикл, без остановки ключевых сервисов для жителей.

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