Programista o profilu T w handlu mobilnym. Model zespołu, ryzyka i lista pytań dla dyrektora technologii

Programista o profilu T ma głęboką specjalizację w jednej dziedzinie i praktyczne zrozumienie kilku sąsiednich obszarów. W handlu mobilnym może to być doświadczony programista React Native, który zna ograniczenia iOS oraz Androida, rozumie zasady wymiany danych między systemami, koszyk, płatności, analitykę, publikację w App Store i Google Play oraz wpływ systemu finansowo-magazynowego na użytkownika aplikacji.

To nie jest tańszy zamiennik zespołu. Prawdziwa wartość profilu T polega na tym, że taka osoba szybciej widzi zależności między warstwami produktu. Gdy koszyk w aplikacji zwraca błąd po zmianie cennika dla klientów firmowych, nie kończy diagnozy zdaniem "to problem zaplecza sprzedażowego". Sprawdza stan koszyka, ważność sesji, regułę cenową, synchronizację systemu finansowo-magazynowego, pamięć podręczną, wskaźniki działania i brakujący test regresji.

Dla kupującego usługę tworzenia oprogramowania to ważne rozróżnienie. Jeśli dostawca sprzedaje "profil T" jako jednego programistę, który ma sam zaprojektować doświadczenie użytkownika, napisać aplikację, zaplecze sprzedażowe, połączenia z systemami, testy i automatyzację wdrożeń, to nie jest model zespołu. To przerzucenie ryzyka na jedną osobę.

Aplikacja sprzedażowa nie jest tylko ekranem w telefonie. Łączy katalog, ceny, promocje, stany magazynowe, koszyk, płatności, logowanie, powiadomienia, analitykę, linki prowadzące prosto do konkretnego ekranu, zgody, proces oceny w sklepach z aplikacjami, raportowanie awarii i często te same procesy, z których korzysta sklep internetowy albo portal dla klientów firmowych.

React Native i Expo przyspieszają realizację na iOS i Android, ale nie usuwają granic systemowych. Czasem wystarcza gotowa biblioteka, czasem trzeba napisać moduł natywny w Swift lub Kotlinie, czasem problem leży w zapleczu sprzedażowym, a czasem w modelu danych. Expo dokumentuje, że większość aplikacji nie wymaga natywnego kodu, ale gdy brakuje biblioteki lub trzeba opakować firmowy zestaw narzędzi, zespół musi rozumieć warstwę natywną.

W architekturze z oddzielonym silnikiem sprzedażowym albo w modułowym podejściu do handlu internetowego dochodzą połączenia z systemami. Medusa opisuje moduły jako pakiety funkcji związane z obszarem biznesowym albo połączeniem z zewnętrznym systemem; w realnym projekcie te obszary nie są neutralne biznesowo. Zmiana modułu cenowego wpływa na marżę, koszyk, fakturę, limit kredytowy i komunikat w aplikacji. Doświadczony programista o profilu T skraca dystans między decyzją techniczną a skutkiem biznesowym.

Profil T pomaga najbardziej tam, gdzie zmiana przechodzi przez wiele warstw. Przykład: program lojalnościowy w aplikacji wymaga ekranu, zasad wymiany danych między aplikacją a zapleczem sprzedażowym, reguł naliczania punktów, zdarzeń analitycznych, powiadomień, testów regresji i obsługi sytuacji bez internetu. Bez szerokości zadanie łatwo zamienia się w przerzucanie zgłoszeń między osobami.

Drugi przypadek to rozpoznanie projektu i szacunek prac. Doświadczony lider, który widział publikację w sklepach, przekroczenia czasu płatności, odświeżanie sesji użytkownika i ponawianie odpowiedzi z systemów płatności, potrafi wcześniej powiedzieć: "ta funkcja wygląda prosto na ekranie, ale dotyka trzech źródeł prawdy". To zmniejsza ryzyko stałej ceny, bo zakres jest oparty na zależnościach, nie na samej makiecie ekranów.

Trzeci przypadek to awarie w produkcji. Gdy Black Friday albo kampania z powiadomieniami generuje skok ruchu, warto mieć kogoś, kto potrafi czytać dzienniki awarii, opóźnienia zaplecza sprzedażowego, stan kolejek, błędy płatności i zachowanie użytkownika w ścieżce zakupu. Miary DORA opisują sprawność dostarczania oprogramowania przez tempo i stabilność zmian, między innymi czas przejścia zmiany, częstotliwość wdrożeń, czas odtworzenia działania i odsetek zmian kończących się awarią. Zespół o profilu T powinien poprawiać te miary, a nie tylko mieć ładniejszy opis ról.

Największa czerwona flaga to płytka litera T: ktoś zna nazwy narzędzi, ale nie ma produkcyjnej głębi. Taki profil może zbudować wersję pokazową, ale pęka przy pierwszym audycie bezpieczeństwa, nietypowym zestawie narzędzi płatniczych, problemie z wydajnością katalogu albo konflikcie między stanem systemu finansowo-magazynowego i aplikacją.

Druga czerwona flaga to pojedynczy punkt awarii. Jeśli jedna osoba rozumie aplikację, zasady wymiany danych między systemami, publikację, połączenia z systemami i rozmowy z biznesem, projekt może wyglądać szybko przez dwa miesiące, a potem zwolnić, bo cały kontekst przechodzi przez jeden kalendarz. Team Topologies zwraca uwagę na obciążenie poznawcze: przeciążony zespół podejmuje gorsze decyzje i porusza się wolniej. To samo dotyczy przeciążonego lidera technicznego.

Trzecia czerwona flaga to brak definicji ukończenia. Scrum Guide podkreśla znaczenie zespołu międzyfunkcyjnego, samoorganizacji i wspólnego rozumienia jakości. W handlu mobilnym "gotowe" musi obejmować nie tylko kod, ale też pomiar działania, testy regresji, dostępność, zgody, gotowość do publikacji w sklepach, plan powrotu do poprzedniej wersji i informację dla obsługi klienta.

Dobry zespół handlu mobilnego łączy doświadczonych programistów o profilu T z wąskimi ekspertami tam, gdzie koszt błędu jest wysoki. Wąski ekspert ma sens przy audycie bezpieczeństwa, wydajności bazy, natywnym module iOS/Android, płatnościach, dostępności, inżynierii danych, testach obciążeniowych, zgodności z App Store albo złożonych połączeniach z systemem finansowo-magazynowym.

Doświadczony programista o profilu T powinien wiedzieć, kiedy poprosić o takiego eksperta. To często najważniejsza cecha do sprawdzenia w rozmowie. Pytanie nie brzmi "czy umiesz wszystko?", tylko "po czym poznajesz, że w tym miejscu potrzebujesz specjalisty i jak ustalasz z nim zakres odpowiedzialności?".

Dla klienta praktyczny model jest prosty: główny zespół o profilu T prowadzi produkt i decyzje od początku do końca, a specjaliści wchodzą punktowo na ryzykowne domeny. Dzięki temu nie przepalasz budżetu na pełny skład ekspertów od pierwszego dnia, ale też nie udajesz, że jedna osoba o szerokich kompetencjach wystarczy do każdego problemu.

Nie zaczynaj od listy technologii. Zacznij od historii z działającego produktu: awaria koszyka, problem z publikacją w sklepie, błąd w płatności, połączenie z systemem finansowo-magazynowym, spadek konwersji po zmianie ekranu, regresja po aktualizacji zestawu narzędzi. Prawdziwy profil T potrafi opowiedzieć, jak diagnozował problem przez kolejne warstwy i co zmienił, żeby nie wrócił.

• Poproś o przykład decyzji, w której ekran użytkownika, umowa techniczna między systemami i biznes miały konflikt interesów.
• Zapytaj, jakie miary obserwuje po wydaniu aplikacji sprzedażowej.
• Sprawdź, czy rozumie różnicę między przepływem pokazowym a produkcyjnym koszykiem.
• Poproś o opis sytuacji, w której odmówił wdrożenia bez dodatkowego testu albo eksperta.
• Zapytaj, jak dokumentuje zasady wymiany danych między systemami i odpowiedzialność za połączenia z systemami.
• Sprawdź, czy mówi o kodzie źródłowym, przekazaniu projektu, wglądzie w działanie systemu i utrzymaniu, a nie tylko o organizacji pracy.

W GMI nie sprzedajemy samej "mocy przerobowej programistów". Przy handlu mobilnym zaczynamy od rozpoznania biznesu, projektu i technologii: mapujemy biznes, użytkowników, procesy, ryzyka, połączenia z systemami, wymagania sklepów aplikacji i mierniki sukcesu. Dopiero potem składamy zespół i zakres prac.

Typowy rdzeń to lider techniczny lub doświadczony programista o profilu T, React Native/Expo, zaplecze sprzedażowe, kontrola jakości, projektowanie produktu i właściciel po stronie klienta. Do tego dokładamy specjalistów wtedy, gdy rozpoznanie projektu pokaże ryzyko: MedusaJS, architektura z oddzielonym silnikiem sprzedażowym, NestJS, PostgreSQL, system finansowo-magazynowy, baza produktów, magazyn, bezpieczeństwo, wydajność, moduł natywny albo wgląd w działanie systemu.

Po takim rozpoznaniu możemy rozmawiać o stałej cenie, bo znamy zależności. Klient dostaje kod źródłowy, dokumentację zasad wymiany danych między systemami, decyzje architektoniczne i plan utrzymania. To ogranicza uzależnienie od dostawcy i zmniejsza ryzyko, że "zespół o profilu T" stanie się czarną skrzynką.

Użyj tej listy pytań przed podpisaniem umowy albo przed dołożeniem ludzi do wewnętrznego zespołu. Jeżeli odpowiedzi są niejasne, nie masz jeszcze modelu realizacji - masz tylko listę ról.

• Jaka jest głęboka specjalizacja każdego kluczowego członka zespołu: aplikacje mobilne, zaplecze sprzedażowe, sprzedaż internetowa, kontrola jakości, automatyzacja wdrożeń, produkt?
• Które obszary szerokości są konieczne w tym projekcie: projektowanie doświadczenia użytkownika, analityka, sklepy aplikacji, system finansowo-magazynowy, baza produktów, magazyn, wgląd w działanie systemu, bezpieczeństwo?
• Gdzie mamy pojedynczy punkt awarii i jak ograniczamy go dokumentacją, przeglądem oraz rotacją?
• Jak wygląda definicja ukończenia dla koszyka, logowania, płatności, powiadomień i historii zamówień?
• Które miary realizacji będziemy śledzić: czas przejścia zmiany, częstotliwość wdrożeń, czas odtworzenia działania, odsetek zmian kończących się awarią, odsetek użytkowników bez awarii?
• Które ryzyka wymagają wąskiego eksperta, a które może obsłużyć główny zespół o profilu T?
• Co klient przejmuje po projekcie: kod źródłowy, instrukcje utrzymaniowe, zasady wymiany danych między systemami, testy, widoki pokazujące działanie systemu i listę prac utrzymaniowych?