Dla wydawcy i firmy medialnej treść przestała być całym produktem. Coraz częściej wartość powstaje w platformie, która tę treść udostępnia, monetyzuje i spina z użytkownikiem: w aplikacji webowej, koncie użytkownika, marketplace, warstwie ogłoszeniowej czy transakcyjnej. Dla CTO i product ownera oznacza to prostą, ale wymagającą konsekwencję: tworzenie aplikacji dla mediów staje się ciągłym rozwojem produktu, a nie jednorazowym projektem z datą końca.
Z naszego doświadczenia najtrudniejsze nie jest zaprojektowanie pierwszej wersji, tylko utrzymanie tempa rozwoju przez lata, z zespołem, który rozumie i produkt, i ruch na nim. Dla lidera rynku mediów i digitalu zbudowaliśmy taki zespół i do dziś rozwijamy jego platformę marketplace do handlu nieruchomościami, łącząc architekturę Node.js, backend w Node i Javie oraz frontend w React.
Dlaczego media budują dziś własne aplikacje i platformy medialne?
Bo zmieniło się to, na czym firma medialna zarabia. Odsłony same w sobie przestały wystarczać, a czytelnik nie chce już tylko czytać, lecz coś przez platformę załatwić: znaleźć ofertę, porównać, skontaktować się, kupić. Wydawca, który ma zaufanie i zasięg, ma naturalną przewagę, żeby wejść w rolę platformy transakcyjnej w swojej niszy, na przykład w nieruchomościach czy ogłoszeniach.
To przesuwa środek ciężkości z redakcji do produktu cyfrowego. Pojawia się potrzeba konta użytkownika, wyszukiwarki, mechanizmów dopasowania, płatności i panelu dla wystawiających, a każdy z tych elementów trzeba nie tylko zbudować, ale też utrzymać i rozwijać pod rosnący ruch.
Jak przebiega droga od pomysłu do działającego produktu?
Zaczynamy od zawężenia, a nie od rozbudowy. Zamiast projektować całą platformę na raz, wyodrębniamy jedną ścieżkę, która musi zadziałać jako pierwsza, na przykład wystawienie ogłoszenia i jego znalezienie przez kupującego. Wokół niej układamy model danych, pierwsze API i interfejs, a dopiero potem dokładamy kolejne moduły.
Pracujemy w rytmie Agile, w krótkich iteracjach, bo produkt medialny i tak zmieni założenia po zderzeniu z realnym ruchem. Taki tryb pozwala pokazać działającą wersję szybko i korygować kierunek na podstawie zachowań użytkowników. W projekcie dla lidera mediów dopasowaliśmy zakres i tempo prac do budżetu klienta, zamiast narzucać z góry sztywny, kosztowny plan.
Jakie aplikacje webowe i marketplace’y budujemy dla mediów?
W projektach dla wydawców i firm medialnych skupiamy się na warstwie, która realnie obsługuje użytkownika i transakcję:
- aplikacje webowe z kontem użytkownika, wyszukiwaniem i personalizacją treści,
- marketplace’y i platformy ogłoszeniowe łączące dwie strony rynku,
- panele dla wystawiających i redakcji do zarządzania ofertami oraz treścią,
- integracje z systemami płatności, danymi zewnętrznymi i narzędziami analitycznymi.
Dla lidera mediów zbudowaliśmy i wciąż rozwijamy platformę marketplace do handlu nieruchomościami, czyli dokładnie ten typ produktu, w którym treść, ogłoszenie i transakcja spotykają się w jednym miejscu.
Jak wygląda backend platformy medialnej w Node.js i Javie?
Backend to serce platformy medialnej, bo to on przyjmuje ruch, trzyma logikę i udostępnia dane. Projektujemy go najczęściej jako zestaw usług w Node.js, uzupełniany o komponenty w Javie tam, gdzie liczy się dojrzałość i wydajność konkretnego fragmentu systemu. Nad całością czuwa architekt Node.js, który wyznacza granice usług, kontrakty API i sposób, w jaki poszczególne moduły się komunikują.
Taki rozdział pozwala rozwijać platformę bez przepisywania całości, bo zespół może dołożyć nowy moduł, nie ruszając tego, co już działa. W projekcie marketplace to właśnie architekci Node.js oraz developerzy Node i Java odpowiadali za to, żeby backend uniósł rosnącą liczbę ofert i zapytań.
Jak projektujemy frontend w React dla platformy medialnej?
Front platformy medialnej decyduje o tym, czy użytkownik zostaje. Budujemy go w React, w architekturze komponentowej, która pozwala wielokrotnie wykorzystywać te same elementy, listę ofert, filtry, kartę szczegółów, w różnych miejscach produktu. Dbamy o to, żeby wyszukiwanie i filtrowanie były szybkie, bo w marketplace to one zamieniają odwiedzającego w użytkownika, który wraca.
Frontend łączymy z backendem przez jasno opisane API, co pozwala obu warstwom rozwijać się we własnym tempie. W projekcie dla lidera mediów developerzy React pracowali ramię w ramię z zespołem backendowym, dzięki czemu nowe funkcje wchodziły spójnie po stronie danych i interfejsu.
Jak rozwijać istniejący produkt, a nie tylko budować od zera?
Wbrew pozorom to częstszy scenariusz. Wydawca zwykle ma już jakąś platformę i potrzebuje domknąć braki kompetencyjne oraz przyspieszyć rozwój, a nie zaczynać od pustej kartki. Wtedy wchodzimy w istniejący kod, uczymy się jego konwencji i dokładamy ludzi tam, gdzie zespół klienta nie wyrabia albo nie ma danej specjalizacji.
Tak właśnie wygląda nasz projekt marketplace: nie jest to jednorazowe wdrożenie, lecz ciągły rozwój produktu, w którym nasz zespół przejął odpowiedzialność za kolejne obszary i rozwija je razem z klientem.
Jak zaprojektować architekturę pod skalowanie platformy medialnej?
Platforma medialna bywa narażona na nierówny ruch: spokojny dzień i nagły szczyt po kampanii czy publikacji. Dlatego od początku zakładamy, że usługi muszą dać się skalować niezależnie, a wyszukiwanie i listy ofert, czyli najczęściej odpytywane elementy, projektujemy tak, żeby wytrzymały obciążenie bez degradacji reszty systemu. Rozdzielenie backendu na usługi w Node.js i Javie jest właśnie fundamentem pod takie skalowanie. Równie ważne jest to, żeby architektura nie blokowała rozwoju: jasne kontrakty API, rozdzielone moduły i czytelny model danych sprawiają, że kolejna funkcja nie wymaga przebudowy całości.
Jak dbamy o jakość platformy na etapie rozwoju?
Przy produkcie, który żyje latami i stale się zmienia, jakość nie może być dodatkiem na końcu. Włączamy testerów do zespołu od początku, obok developerów, a nie po oddaniu funkcji. Dzięki temu regresja wychodzi szybko, a każda nowa funkcja trafia na produkcję sprawdzona, a nie „na wiarę”.
W praktyce oznacza to testy nowych ścieżek użytkownika, kontrolę krytycznych funkcji marketplace (wystawianie, wyszukiwanie, kontakt) oraz stałą współpracę testerów z developerami w ramach jednego sprintu. W projekcie dla lidera mediów testerzy byli stałą częścią zespołu, co pozwalało rozwijać platformę szybko, bez psucia tego, co już działało.
Jak szybko zespół może wejść w projekt platformy medialnej?
Tempo wejścia decyduje o tym, czy przyspieszenie jest realne. Nasz proces rekrutacji i obsadzenia ról zwykle zamyka się w dwa do trzech tygodni, a skład dobieramy pod konkretną specyfikację projektu, a nie z gotowej półki. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc zespół wchodzi w przeglądy kodu, spotkania i rytm sprintów bez długiego rozruchu.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z realnym doświadczeniem w budowie i rozwoju platform medialnych:
- dla lidera rynku mediów i digitalu zbudowaliśmy i wciąż rozwijamy platformę marketplace do handlu nieruchomościami,
- dostarczyliśmy architektów Node.js, developerów Node, Java i React oraz testerów w jednym, zgranym zespole,
- pracujemy w Agile, dopasowując zakres i tempo prac do budżetu klienta,
- obsadzamy role zwykle w dwa do trzech tygodni, a kompetencje dobieramy pod specyfikację produktu.
Najczęściej robimy to jako dedykowane oprogramowanie budowane i rozwijane przez nasz zespół, a tam gdzie trzeba szybko uzupełnić kompetencje, w modelu wzmocnienia zespołu.
Od czego zacząć budowę aplikacji lub platformy medialnej?
Zacznij od jednej transakcji, która musi zadziałać, i od pytania, jakie dane oraz ruch musi unieść platforma. To wyznacza zakres pierwszej wersji, architekturę backendu, kształt frontendu i role, których potrzebujesz. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Budujesz lub rozwijasz aplikację albo platformę medialną? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój produkt.