в процессе мы сталкивались с разными трудностями, но каждая из них стала точкой роста.
неполные сценарии и разные версии макетов
часть процессов не имела описанных юзкейсов, а для одних и тех же сервисов встречались разные макеты.
решение: мы вместе с продактами пик выстроили актуальные сценарии. отдельные процессы проверяли офлайн — например, проходили этап заселения прямо в жилом комплексе со старым приложением. это помогло оптимизировать новый сценарий.
масштаб проекта
нужен был единый подход к дизайну.
решение: создали библиотеку компонентов и централизованную дизайн-систему. интерфейсы стали единообразными и согласованными.
устаревшая или отсутствующая документация
решение: собрали актуальный swagger и описали план интеграции api. это упростило работу всем командам и синхронизировало сайт с приложением.
сжатые сроки
работали параллельно: дизайн-команды, спринты front-end и выделенная команда для промежуточного слоя интеграций. это позволило уложиться в три месяца.
регулярные изменения функционала
решение: постоянно держали контакт с продуктовыми командами пик и оперативно синхронизировали изменения.
отсутствие готового бэка для всех процессов
решение: часть сервисов сделали через webview, сохранив плавный пользовательский опыт. переходы ощущались как нативные.
в итоге мы стали частью продуктовой команды пик: быстро реагировали на изменения, вместе решали проблемы и создавали гибкий, продуманный продукт.