Tworzenie nowych produktów, które przetrwają własny rozwój

Tworzymy oprogramowanie według specyfikacji: nowe produkty, headlessową architekturę treści oraz projekty greenfield wewnątrz przedsiębiorstw – dla grup FMCG, sieci handlowych i organizacji przetwarzających dane płatnicze lub inne dane regulowane. Nasze ostatnie realizacje to m.in. wielojęzyczna platforma programu publicznego dla Energy Upgrade California, platforma konsumencka o dużym ruchu dla Royal Canin oraz platforma treści obsługująca kilkadziesiąt krajów dla firmy z listy Forbes 500.

Porozmawiajmy o nowym produkcie

Cztery rodzaje prac, jeden standard inżynierski

Większość projektów należy do jednej z tych kategorii. Mają wspólne fundamenty, dlatego opisujemy je razem na jednej stronie, zamiast je rozdzielać.

Oprogramowanie szyte na miarę

Oprogramowanie tworzone według specyfikacji, a nie konfigurowane z gotowego pakietu. Platformy produktowe, systemy dla klientów i narzędzia wewnętrzne, w tym systemy przetwarzające dane płatnicze lub osobowe. Decyzje architektoniczne podejmujemy razem z Tobą i odpowiadamy za nie również później.

Architektura headless CMS

Treści zarządzane i dostarczane przez API, dzięki czemu praca redakcyjna i wydania produktu mogą przebiegać w różnym tempie. To typowy model dla środowisk wielorynkowych i wielomarkowych, w których te same dane produktowe zasilają stronę, aplikację i partnerów handlowych. Tu zwykle pojawia się Flotiq – nasz własny headless CMS.

Skalowanie produktów

Dla produktów, które działały w pierwotnej skali, a potem urosły. Mierzymy, gdzie system faktycznie zwalnia, a następnie zmieniamy te elementy, podczas gdy produkt nadal działa. Zwykle przyczyną jest ruch pojawiający się w szczytach, a nie równomiernie, lub model danych zakładający obsługę jednego rynku.

Realizacje w przedsiębiorstwach

Nowe systemy budowane w organizacjach, które już utrzymują rozbudowane systemy. Standard inżynierski jest taki sam. Zmieniają się ograniczenia: przegląd bezpieczeństwa, procesy zakupowe, akceptacja audytowa i integracja z platformami, których nikt w pełni nie udokumentował – w terminach, jakich to faktycznie wymaga.

Dlaczego pierwsza wersja decyduje o koszcie trzeciej

Pierwsza wersja często powstaje szybko, by dotrzeć do użytkowników, przetestować pomysł i zapewnić dalsze finansowanie lub budżet. Większość decyzji technicznych podejmowanych na tym etapie ma w danym momencie sens. Problemy zwykle pojawiają się później i rzadko jako jedna duża awaria. Na przykład model danych, który sprawdzał się na jednym rynku, może nie pasować do innego. Uwierzytelnianie zaprojektowane dla jednego typu użytkownika może nie obsługiwać ról. Proces wydawniczy, który odpowiadał małemu zespołowi, może spowalniać większy. Te decyzje miały sens w swoim czasie, ale nigdy nie zostały zweryfikowane. W efekcie problemy często objawiają się spowolnieniami, a nie awariami. Prawdziwa różnica nie dotyczy szybkości ani ostrożności. Chodzi o to, które decyzje łatwo zmienić później, a które trudno odwrócić. Tylko niewiele decyzji można bezpiecznie odłożyć. Jeszcze mniej, jeśli zostaną podjęte zbyt wcześnie, staje się kosztownych w naprawie.
Szybkie budowanie i budowanie czegoś, co przetrwa skalowanie, to nie przeciwieństwa. To ta sama praca, wykonana w określonej kolejności.

Sygnały, że system zmierza do przedwczesnej przebudowy

Zwykle pojawiają się, zanim ktokolwiek jest gotów przyznać, że problemem jest sam system.

TEMPO

Nowe funkcje powstają dłużej niż rok temu i nikt nie potrafi dokładnie powiedzieć dlaczego. Estymacje się wydłużają, a zmiana tej samej wielkości z każdym kwartałem kosztuje więcej.

DANE

Każde nowe wymaganie walczy z modelem danych. Nowe pola pojawiają się jako nowe tabele i obejścia, a dane produktowe lub klientów nie mają jednego źródła.

WYDANIA

Wdrożenia stały się wydarzeniami. Wydania czekają na okno czasowe, a nie na decyzję, a ktoś musi być potem dostępny – tak na wszelki wypadek.

WIEDZA

Tylko jedna lub dwie osoby rozumieją, jak system naprawdę działa. Wszyscy inni pracują wokół nich, a onboarding trwa miesiące zamiast tygodni.

KOSZTY

Wydatki na infrastrukturę rosną szybciej niż jej wykorzystanie. Nikt nie potrafi przypisać ich do konkretnego rynku, marki czy funkcji.

ZAUFANIE

W systemie jest obszar, którego nikt nie chce dotykać. Błędy są zgłaszane, a nikt nie potrafi wykazać, co i kiedy się zmieniło.

Umów się na bezpłatną konsultację z naszymi ekspertami i CTO

Porozmawiajmy o Twoich obecnych wyzwaniach i sprawdźmy, w czym możemy pomóc.

Napisz do nas

Jak powstaje nowy produkt – od pierwszego kształtu do działającego systemu

Cztery etapy, w kolejności, w jakiej faktycznie następują. Każdy kończy się w punkcie, w którym produkt może przez jakiś czas funkcjonować, zanim rozpocznie się kolejny etap. Etapy są ułożone tak, by najkosztowniejsze decyzje zapadały najpierw, a pozostałe wybory mogły poczekać.

Kształtowanie
Problem, ograniczenia i granice pierwszej wersji są uzgadniane, zanim cokolwiek zostanie zbudowane. Na tym etapie wychodzą na jaw kwestie przeglądu bezpieczeństwa, rezydencji danych i integracji z istniejącymi systemami – a nie trzy miesiące później, gdy architektura jest już ustalona. Efekt: zakres, któremu ktoś może powiedzieć „nie”, oraz pisemny zapis decyzji, które go określiły.
Wdrożenie
Pierwsza wersja trafia do prawdziwych użytkowników i jest zbudowana na fundamentach, które można rozbudowywać. Od pierwszego wdrożenia działa w środowisku spełniającym Twoje zasady dostępu i zarządzania zmianami, a nie w sandboksie, który dopiero później zostaje dostosowany do wymogów. Efekt: produkt działający na produkcji, który można wdrażać na żądanie, a nie tylko w dniu wydania.
Skalowanie
Po zakończeniu budowy ktoś przejmuje odpowiedzialność za dostępność, koszty i bezpieczeństwo. Wspólne dyżury, koszty przypisane do zespołu lub rynku oraz imienny właściciel, a nie osoba, która akurat jest najbliżej kodu. Efekt: produkt z imiennym właścicielem, a nie zespół, który ma nadzieję, że nic się nie wydarzy.
Utrzymanie
Ktoś długofalowo odpowiada za dostępność, koszty i bezpieczeństwo. Dyżury są współdzielone, cele poziomu usług (SLO) powiązane z rzeczywistym wpływem na użytkowników, a system udokumentowany tak, by Twój wewnętrzny zespół mógł go przejąć wraz z rozwojem. Efekt: produkt, który działa, i zespół, który potrafi go utrzymać.

Te same cztery etapy, trzy różne zestawy ograniczeń

Inżynieria pozostaje taka sama, niezależnie od wielkości firmy. Zmienia się wszystko wokół niej – i to zwykle wyznacza harmonogram.

	Startup	Scale-up	Enterprise
Najtrudniejsza część	Decyzja, czego jeszcze nie budować	Zmiana struktury bez zatrzymywania systemu	Integracja z systemami, których nikt w pełni nie udokumentował: core banking, ERP, dane produktowe specyficzne dla rynków
Ograniczenie wyznaczające tempo	Runway	Ruch, który już napływa	Przegląd bezpieczeństwa, procesy zakupowe i akceptacja audytowa
Kto decyduje	Jeden lub dwóch założycieli	Product lead i przeciążony zespół inżynierski	Wielu interesariuszy z różnymi definicjami ukończenia
Gdzie projekt zwykle się wykłada	Budowanie pod skalę, która nigdy nie nadchodzi	Odkładanie prac strukturalnych, aż zostaje tylko przepisanie systemu od nowa	Wymagania ustalane po zamknięciu architektury
Typowy punkt wejścia	Discovery lub budowa MVP	Przegląd pod kątem skalowania	Discovery, a następnie ograniczone pierwsze wdrożenie
Co Flotiq zwykle skraca	Czas do pierwszej wersji	Treści wielorynkowe i wielomarkowe	Dostarczanie treści on-premise zgodnie z obowiązującymi politykami

Czy treści w ogóle powinny być headless

Wybór architektury headless to decyzja architektoniczna, zanim stanie się decyzją produktową. Treści stają się API, dostarczanie staje się osobnym zadaniem, a redaktorzy nie muszą już czekać na wydania. Jednocześnie zwiększa to złożoność, co nie zawsze się opłaca.

Headless się opłaca, gdy

Klasyczny (sprzężony) CMS jest lepszym wyborem, gdy

Te same treści są wykorzystywane w więcej niż jednym kanale.

Jedną stronę obsługuje jeden zespół, a treści zmieniają się rzadko.

Prawdopodobne są różne rynki, języki lub marki – jak w większości portfeli FMCG.

Nikt nie będzie utrzymywał drugiego wdrażanego komponentu.

Osoby nietechniczne muszą wprowadzać zmiany bez nowego wydania.

Produkt ma charakter transakcyjny i zawiera niewiele treści redakcyjnych.

Front-end prawdopodobnie zostanie wymieniony wcześniej niż treści.

Istniejąca platforma już działa wystarczająco dobrze.

Warstwa treści musi działać w środowisku regulowanym lub on-premise.

Koszt przebudowy przewyższa zyskaną elastyczność.

Miejsce Flotiq w stacku technologicznym

Flotiq to nasz własny headless CMS i platforma, z której korzystamy najczęściej. Dlatego jasno mówimy o jego ograniczeniach.

W przeciwnym razie budowane od zera

Czego potrzebujemy

Modelowanie treści i interfejs redakcyjny

Ustrukturyzowane typy treści, interfejs dla redaktorów, wersjonowanie

API treści, cache’owanie i dostarczanie

Dostarczanie w modelu API-first z przewidywalną wydajnością pod obciążeniem

Obsługa wielu języków i rynków – standardowy model portfela marek FMCG.

Lokalizacja i warianty rynkowe jako konfiguracja

Obsługa i przetwarzanie multimediów

Zarządzanie zasobami i przetwarzanie obrazów w locie

Decyzje dotyczące wdrożenia i hostingu warstwy treści

Wersja zarządzana lub on-premise, także w środowiskach regulowanych

Kiedy Flotiq nie jest właściwym narzędziem

Co zrobić zamiast tego

Kluczową wartością jest autorski algorytm lub pipeline danych

Porządnie zbuduj rdzeń. Platforma treści, jeśli w ogóle, powinna znaleźć się na obrzeżach.

Wymagania wskazują na relacyjny rdzeń ze złożonymi regułami integralności

Relacyjna baza danych i dedykowany panel administracyjny, a nie platforma treści

Istniejąca platforma treści już działa wystarczająco dobrze

Zostaw ją. Koszt migracji rzadko zwraca się w przypadku systemu, na który nikt nie narzeka.

Organizacja z dobrych powodów ustandaryzowała się na innym rozwiązaniu

Pracuj z tym, co już istnieje, zamiast dodawać drugi system treści

Co mówią nasi klienci

Case study

"Od czasu wdrożenia zaobserwowaliśmy znaczną poprawę wskaźników wydajności, m.in. skrócenie TTFB o 86%. Dzięki CODEWAVE nasz serwis, z którego korzysta kilka tysięcy pracowników, działa bez ryzyka awarii systemu."

Magdalena Tarnas-Kaczmarek

Dyrektor ds. komunikacji wewnętrznej

Porozmawiajmy o możliwej współpracy.

Proponujemy rozmowę techniczną o tym, co budujesz, co może się blokować lub co nie działa – a my szczerze powiemy, czy jesteśmy właściwym zespołem do tego zadania.

Porozmawiajmy o możliwej współpracy

Czym jest współpraca przy skalowaniu produktu, a czym nie jest

To najczęstszy punkt wyjścia w przypadku produktu zbudowanego przez kogoś innego. Wzrost już trwa, więc zatrzymanie się na przebudowę nie wchodzi w grę.

Co obejmuje

Czym nie jest

Mierzymy, gdzie system faktycznie się psuje – pod rzeczywistym obciążeniem, a nie w teorii.

Przepisaniem systemu od nowa. Do tego dochodzi, gdy te prace są odkładane zbyt długo.

Zmieniamy strukturę stopniowo, a produkt przez cały czas działa i jest rozwijany.

Akcją ratunkową wymagającą zamrożenia rozwoju funkcji.

Ustalamy punkt odniesienia dla wydajności i kosztów, dzięki czemu wzrost przestaje być zaskoczeniem.

Oceną inżynierów, którzy budowali pierwszą wersję w innych warunkach.

Sprawiamy, że system staje się zrozumiały dla zespołu, który za chwilę się podwoi.

Równoległym zespołem, który pracuje z pominięciem istniejącego.

Zostawiamy wewnętrzny zespół w pełni zdolny do utrzymania wprowadzonych zmian.

Trwałą zależnością. Przekazanie jest częścią współpracy, a nie późniejszym etapem.

Od czego może zacząć się współpraca – od przeglądu produktu po pełną odpowiedzialność

Oferujemy różne formy współpracy, a nie sztywne menu. Nowe projekty często zaczynają się od Discovery lub budowy MVP. Produkty, które już są na rynku, zwykle zaczynają od przeglądu pod kątem skalowania.

Prace koncepcyjne o ściśle określonym zakresie: model domeny, warianty architektury, realistyczny zakres i koszt.Discovery

Pierwsza wersja na produkcji, zbudowana na fundamentach, których nie trzeba będzie cofać.Budowa MVP – od tego zaczyna większość

Istniejący produkt przeprowadzony od etapu „działa” do etapu „rośnie”: zmierzone wąskie gardła, stopniowe zmiany struktury, przez cały czas na produkcji.Skalowanie produktu

Obsługujemy to, co zostało zbudowane: dyżury, SLO, koszty i poziom bezpieczeństwa.Usługa zarządzana

Wieloletnia odpowiedzialność w miarę rozwoju produktu i organizacji.Długofalowe partnerstwo

Zmierzone na produkcji – w projektach dla bankowości, FMCG i retailu

0k+: sklepów obsługiwanych przez jedną platformę treści w kilkudziesięciu krajach
0%: wzrostu responsywności po migracji do Flotiq
0s: Proces e-recepty skrócony z czternastu kroków do około trzydziestu sekund