Желания в реальность: разработали платформу для краудфандинга

Привет! Мы команда разработки WPP.DIGITAL. Уже 15 лет мы помогаем компаниям поддерживать и развивать сайты, приложения и другие веб-продукты в основном для retail и e-commerce. В 2021 году к нам обратился клиент с нестандартным для нас сервисом на разработку —  краудфандинговой платформой.

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

Мы провели нагрузочное и регрессионное тестирования. Выяснили, что прототип способен стабильно обслуживать максимум 100 пользователей одновременно. Кроме того, обнаружили множество визуальных багов при открытии сайта в разных браузерах и на разных мобильных устройствах.

Мы обсудили результаты с клиентом и оказались единодушны в решении: mvp нужен глобальный upgrade. Его нужно было делать более надежным, производительным, расширяемым. Начали с того, что:

• обновили версию Python; 
• проанализировали код с помощью SonarCube и исправили замечания;
• сделали CI/CD через GitLab;
• настроили Nginx + Gunicorn.

Спринты и спринтеры

Изначально в команде было 6 человек:

• 1 project-менеджер
• 2 тестировщика + 1 QA-лид;
• 3 python-разработчика;
• 1 frontend-разработчик;
• 1 бизнес/системный-аналитик.

Спустя 5 месяцев команда выросла уже почти вдвое: добавились 3 разработчика на Python, один QA-инженер и один фронтендер. В дальнейшем количество специалистов в команде колебалось в районе 10 –12 человек.

Процессы постепенно менялись, адаптируясь к текущим нуждам. Сначала работали по Scrumban. В начале спринта собирались с заказчиком, слушали его пожелания и оборачивали все это в задачи. Каждой задаче выставляли приоритет:

0 — задача 100% должна быть сделана в этом спринте;

1 — когда заканчиваем с нулевым приоритетом, занимаемся этим;

2 — было бы неплохо начать действия по этой задаче;

3 — задача уходит в бэклог.

Затем договаривались о датах релиза и приступали.

Когда проект вышел в прод, то появился поток пользователей, от которых поступала обратная связь. Нам потребовалась более жесткая приоритизация, чтобы оперативно реагировать на пользовательский фидбек.

«Технологически мы работали по GitFlow, с CI/CD на базе Gitlab и обильным тестированием: более 700 тестов только на backend, в целом покрытие более 80% функционала. При сборке релиза прогон автотестов занимает где-то полчаса — довольно долго, зато точно знаешь, что ничего не сломалось».

Антон Седов, технический директор wpp.digital 

Архитектура платформы

Frontend на Vue + Vuex. Backend — Python 3.9, FastAPI. Backend написан максимально асинхронно. База данных — PostgreSQL 14.

Изначально использовался GraphQL, но мы быстро поняли, что это не наш вариант. У платформы нет мобильного приложения, единственный вид клиента — это сайт, поэтому запросам не нужна гибкость, которую предоставляет GraphQL. А гибкость дается не бесплатно — это человеко-часы труда, которые при таком раскладе уходили бы впустую. Поэтому мы перешли на старый добрый REST.

Впоследствии по сравнению с прототипом добавилось много интересного. А именно:

• Server-side rendering для лендинга с помощью Nuxt и NodeJS. Последний выступает прослойкой между клиентом и основным сервером и занимается исключительно SSR. Серверный рендеринг ускоряет загрузку лендинга и дружит с поисковиками — сайт поднимается в выдаче и становится более отзывчивым;
• Чат на сокетах и Redis Pub/Sub, где пользователи могут общаться в реальном времени. Для платформы, основанной на социальных механиках, чем больше социальности, тем лучше;
• Последним добавился RabbitMQ для тяжелых фоновых задач. Используя брокер сообщений, можно запускать их асинхронно, не блокируя сервер — это повышает доступность платформы, позволяя ей быстро обрабатывать пользовательские действия.

В теории все окей

У клиента были причины не запускать продукт пока не будут идеально реализован функционал, включая дополнительные функции. Для нас это был первый опыт, когда мы ориентировались только на результаты внутреннего тестирования и на данные фокус-групп. Это примерно как вести подводную лодку по перископу: вполне реализуемо, но с обзором на 360° было бы намного быстрее и точнее.

«Например, что касается адаптивной верстки, изначально мы ориентировались на iPhone 10 и выше. Небольшая вариативность размеров, простая задача. Но потом пришла фокус-группа с Android-устройствами, и мы сделали адаптив. А это уже совсем другая история: очень много вариантов размеров, соотношений сторон».

Дмитрий Шварев, project-менеджер wpp.digital 

Большинство задач — это мелкие изменения UI. Но когда сервис сложный, одно изменение UI — это 4–5 мест в коде, которые надо скорректировать, а затем протестировать на разных устройствах. В результате мы выпустили тщательно проработанный продукт, но это заняло больше времени, чем могло бы.

Неожиданная многоязычность

Изначально прототип был двуязычным. Однако вскоре пришло понимание, что такой проект нужно реализовывать в глобальных, мировых масштабах, ведь человеческая взаимопомощь не знает границ. Это с идейной точки зрения, а с технической стороны встал вопрос интернационализации. На нее у нас ушло 3 месяца.

Мы вносили в таблицу каждый кусочек текста, который пользователь может увидеть, а затем переводили на нужный язык. Трудность в том, что у каждого языка своя специфика. Например, в немецком слова часто намного длиннее, чем их английские аналоги. В итоге надпись, которая помещалась на кнопку в английской версии, в немецкой может уйти за ее пределы или сломать верстку. Если это происходит — нужно доработать интерфейс, чтобы все исправить.

Первый ощутимый результат

В 2023 году случился драматический момент. Команда клиента решила подать проект на большую ежегодную конференцию, в ней участвуют представители крупнейших компаний мира, знаменитости. Удачно выступить — значит заявить о себе, привлечь внимание и инвестиции.

В связи с поездкой на саммит возникла необходимость срочно, буквально за неделю, добавить в интерфейс португальский и испанский. Хоть механизм интернационализации уже был, но добавление нового языка — трудоемкая задача в любом случае.

Уже после мы добавили автоперевод пользовательского контента — переводить его вручную было бы долго и дорого. Сначала хотели использовать бесплатный сервис и нашли подходящий API. Но когда стали тестировать — ахнули. Проекты вроде «Собрать деньги для жертв вулкана» или «Отдых на пляже» превращались в нечто странное: «Животное убежище», «Клоуны-убийцы», «Суицидальные мысли на Мальте»… В общем, языковая модель галлюцинировала. В итоге ушли в сторону API переводов Google.

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