Wyzwania przy tworzeniu aplikacji white label

Z terminem white label można spotkać się dość często. W kontekście IT oznacza on aplikację wyprodukowaną przez jedną firmę, a dystrybuowaną pod brandingiem firmy-klienta. W najbardziej podstawowej wersji przekłada się to na zmianę loga i niektórych stylów w aplikacji.

Jednak rzadko się na tym kończy. Klient często chce mieć dostęp do zaawansowanych opcji stylizacji, czy też chce, by w aplikacji znalazły się niestandardowe zachowania. Ta presja sprawia, że z czasem aplikacje white label pozwalają na coraz więcej. Klient chciałby dostać aplikację pozwalającą na tyle, co aplikacja dedykowana.

To tworzy wyzwania dla zespołu deweloperskiego - by nie utonąć w gąszczu nowych wymagań, trzeba zbudować cały proces i infrastrukturę pozwalającą na bezbolesny rozwój tego rodzaju produktu. O takim całościowym podejściu porozmawialiśmy z Przemkiem Pyznarskim z IDEMII. IDEMIA wiele ze swoich projektów sprzedaje jako rozwiązania white label i ma bardzo duże doświadczenie w tworzeniu tego rodzaju aplikacji. 

Główne problemy przy rozwoju aplikacji white label

Po rozmowie z Przemkiem wyniknął jeden główny wniosek - rozwój aplikacji white label nie jest trudny, o ile każda z osób w zespole rozumie dobrze swoją rolę i bierze za nią odpowiedzialność. Oczywiście nie będzie o tym mowy, jeżeli role, odpowiedzialności i oczekiwania nie zostaną jasno zdefiniowane.

Są dwa główne obszary, gdzie potrzeba odpowiedniego poziomu jasności - zarządzanie kodem, czyli część inżynierska oraz struktura organizacji i kultura pracy, czyli część dotycząca procesów. Im więcej pojawia się klientów i wymagań, tym trudniejsza jest część procesowa, jednak zawsze na początek trzeba rozwiązać kwestie techniczne.

Zarządzanie kodem i assetami

Jasna wizja architektury rozwiązania

Chodzi tu o zdefiniowanie podstawowych założeń, na których opiera się rozwiązanie. Zwykle white label oznacza aplikację webową czy mobilną, współpracującą z back-endem. Ustalenie odpowiedzialności każdej z tych części jest pierwszym krokiem. Drugim jest sposób, w jaki definiowane są i realizowane poszczególne funkcje aplikacji.

Np. w projekcie, w którym pracuje Przemek Pyznarski, wygląda to tak:

Aplikacja jest cienkim klientem, któremu serwer dyktuje dostępne scenariusze. Wszystkie funkcje realizowane są jako możliwie samodzielne pluginy, które mają własne UI, zachowania, a także interfejsy do komunikacji z innymi pluginami. Backend dyktuje, które pluginy powinny być uruchomione i w jakiej kolejności powinno się to zadziać.

Dzięki określeniu filozofii całego rozwiązania, minimalizujemy często spotykaną grę “wy powinniście to zrobić”, w którą bardzo często grają backendowcy z frontendowcami/mobile’ami.

Branding

Konfiguracja i utrzymanie strony wizualnej to tak naprawdę jeden z łatwiejszych elementów aplikacji white label, ale tylko wtedy, gdy pomyślano o tym już na etapie projektowania. Technicznie nie jest to duże wyzwanie - w końcu praktycznie wszystkie współczesne narzędzia do budowania wspierają tworzenie dynamicznych paczek assetów czy stylów.

Jeżeli z góry zostanie ustalone, co i jak można zmieniać, jeżeli chodzi o warstwę wizualną, to nie będzie problemu z przygotowaniem projektów przez team UX/UI, a także z późniejszym ich zaimplementowaniem oraz konfiguracją.

Przemek wspomina:

W zespole deweloperskim musieliśmy pielęgnować świadomość, że każdy kolor może zostać zmieniony, a więc za każdym razem trzeba użyć parametru. Natomiast team UI musi dostarczać każdą grafikę w formie wektorowej, by dało się łatwo zmienić jej kolory.

Repozytoria

Dla aplikacji white label można stosować bardzo wiele różnych konfiguracji repozytoriów. Ważne jest tu tak naprawdę wybranie możliwie odpowiedniej opcji dla danego przypadku.

Rozsądnym punktem wyjścia wydaje się rozdzielenie aplikacji generycznej od konfiguracji konkretnego klienta. Daje to większą swobodę działania i rozwój aplikacji dla klienta w tempie, jakiego on potrzebuje. Pozwala to na bardzo proste działanie na starszej wersji aplikacji generycznej, a także ogranicza możliwe konflikty. Przede wszystkim taki podział wprowadza jasny podział obowiązków.

Testowanie

Kolejnym ważnym elementem jest taka sama staranność w testowaniu aplikacji bazowej i końcowej, co zauważa Przemek:

Aplikacja generyczna również powinna mieć swój cykl wydawania nowych wersji, czemu towarzyszy proces testowania podobny do testowania aplikacji końcowych. Nie chodzi tu tylko o testy jednostkowe czy instrumentalne, ale także UAT, sesje testów manualnych, wydawanie aplikacji demo, w której znajdują się w zasadzie wszystkie możliwości.

Zapewnia to dobrą bazę do budowania aplikacji klienckich i pozwala na wykrycie błędów na wczesnym etapie.

Struktura organizacji

Odpowiedzialność poszczególnych osób i zespołów

Już pierwsza część, o zarządzaniu kodem i assetami, pokazała, że rozwijanie takiej aplikacji to pewien proces, w którym aplikacja przekazywana jest z rąk do rąk, a finalnie ma wylądować z zupełnie innym wyglądem i różnymi dostępnymi funkcjami u różnych klientów. Okazji do pomyłek czy przeoczeń jest o wiele więcej, niż gdy istnieje tylko jedna wersja aplikacji.

Dlatego niezbędne jest to, by każda osoba wiedziała, co musi mieć, by zacząć pracę, oraz co musi dostarczyć, aby następna osoba nie miała problemów ze zrobieniem swojej pracy. Natomiast w przypadku, gdy czegoś brakuje, powinna wiedzieć, gdzie się zwrócić. Przemek Pyznarski sugeruje nawet, że:

Warto rozpisać ścieżki przekazywania pracy, a do każdej działki przypisać osobę odpowiedzialną, product ownera.

Przekazywanie pracy między osobami czy zespołami może zająć zaskakująco dużo czasu, jeżeli nie pójdzie gładko. Problemy z przekazywaniem, gubienie informacji np. o wykrytych błędach czy zmianach w API, mogą znacznie wydłużyć czas potrzebny na dostarczenie finalnego produktu klientowi.

Oddzielne zespoły do rozwoju aplikacji i jej dostarczania

Na pewnym etapie rozwoju produktu może okazać się bardzo pomocne rozdzielenie zespołu rozwijającego aplikację white label od zespołu dostarczającego tę aplikację. W tym modelu zespół rozwijający aplikację projektuje i dostarcza nowe, grubsze funkcje, przekazując generyczny kod źródłowy drugiemu zespołowi. Tak więc klientem zespołu rozwijającego aplikację jest zespół dostarczający. Natomiast klientem dla zespołu dostarczającego jest klient końcowy. Zespoły te utrzymują np. własne CI, które odpowiadają bardziej temu, co finalnie dostarczają dalej.

Ma to sporo zalet - pierwszy team może się skupić na rozwoju kolejnych funkcji w produkcie, dzięki odizolowaniu od klienta, a drugi team może szybko odpowiadać na potrzeby klienta, zmieniać konfigurację jego aplikacji, bo nie ma na nich obowiązku pisania nowych funkcji.

W IDEMII zdecydowano się na takie podejście po wypróbowaniu modelu z jednym teamem. W pewnym momencie po prostu zajmowanie się typowo klienckimi problemami zaczęło zajmować ponad połowę czasu zespołu produktowego, co negatywnie wpłynęło zarówno na dostarczanie nowych funkcji, jak i doświadczenie klientów. Trzeba jednak pamiętać, że dla niewielkich aplikacji, które mają niewielkie opcje konfiguracji, może to nie być najlepsze rozwiązanie.

Podsumowanie

Najważniejsze w tworzeniu aplikacji white label jest dobre zdefiniowanie odpowiedzialności. W warstwie technicznej nie są wcale szczególnie różne od zwykłych aplikacji, jednak wymagają dopracowania procesu wytwarzania oprogramowania. Wymagają też całościowego spojrzenia na architekturę rozwiązania, które powinno mieć odzwierciedlenie w podjętych decyzjach, które następnie będą konsekwentnie wprowadzane.

Jeżeli wszystko się uda, to obsługa obecnych i wdrażanie nowych klientów nie będą problemem.