Sklep bez CTO: siedem decyzji, które idą nie tak

Firma e-commerce zatrudniająca, powiedzmy, od dziesięciu do stu osób jest w niewygodnym położeniu: za dużo technologii, żeby jechać na intuicji, za mało, żeby uzasadnić etat CTO. Ta luka nie zostaje pusta. Wypełnia ją ten, kto akurat jest najbliżej (założyciel, agencja, najpewniejszy siebie deweloper) i zapada seria decyzji, których nikt nie potrafi kompetentnie zawetować. Oto siedem najczęstszych błędów, które obserwujemy, i pytanie, które zadałby ktoś technicznie doświadczony.

1. Wybór platformy po demo. Platformy wybiera się po wypolerowanym panelu administracyjnym i obietnicach z rozmowy handlowej, a potem żyje z nimi przez dekadę przypadków brzegowych. Pytanie CTO: jakie są nasze trzy najbardziej nietypowe wymagania i czy możemy zobaczyć na tej platformie, jak realnie działają, zamiast słuchać obietnic?

2. Wybór agencji po pitchu. Najtańsza oferta i najgładszy deck to dwa różne błędy selekcji, a nie dowody kompetencji. Porażka wychodzi na jaw dwa lata później jako lock-in: kod w prywatnych repozytoriach agencji, infrastruktura na jej kontach, wiedza w głowach jej ludzi. Pytanie CTO: jeśli rozstaniemy się za dwanaście miesięcy, z czym dokładnie odchodzimy?

3. Zatrudnienie senior developera, gdy problemem jest architektura, albo architekta, gdy problemem jest przepustowość. Bez kogoś, kto widział jedno i drugie, firma zatrudnia lustrzane odbicie swojego ostatniego złego doświadczenia. Pytanie CTO: czy naszym wąskim gardłem jest decydowanie, co budować, czy budowanie?

4. Pozwolenie, żeby liczba pluginów stała się architekturą. Każdy plugin z osobna wyglądał na szybkie usprawnienie. Po pięćdziesięciu takich usprawnieniach aktualizacja zajmuje kwartał i nikt nie umie powiedzieć, który plugin odpowiada za liczenie ceny. Pytanie CTO: czy dla każdego z nich wiemy, co robi, i czy zainstalowalibyśmy go dziś jeszcze raz?

5. Odziedziczenie infrastruktury z rozpędu. Sklep działa tam, gdzie umieścił go pierwszy deweloper, zwymiarowany szacunkowo, monitorowany skargami klientów. Działa do pierwszej dużej kampanii, czyli dokładnie do chwili, w której nie może zawieść. A kiedy checkout pada pod ruchem, który serwery powinny unieść, ten domyślny wybór staje się nagle kosztowny. Pytanie CTO: co się dzieje przy pięciokrotności dzisiejszego ruchu i skąd to wiemy?

6. Brak własności kont. Domena u rejestratora agencji, analityka na googlowym koncie freelancera, klucze do deployu na laptopie, który odszedł razem z pracownikiem. Dopóki współpraca się układa, nikt tego nie odczuwa; przy rozstaniu każde z tych kont staje się problemem. Pytanie CTO: czy umiemy wyliczyć każde konto, od którego zależy biznes, i wiemy, kto kontroluje odzyskiwanie każdego z nich?

7. Traktowanie wydajności jako zadania na start. Strona była szybka przy starcie; od tamtej pory zwalnia z każdym kolejnym pluginem i banerem, a tej liczby nikt nie pilnuje. Szybkość to metryka operacyjna, jak uptime: potrzebuje właściciela i linii trendu, a nie jednorazowego projektu. Pytanie CTO: ile wynosiło nasze LCP w zeszłym miesiącu i kto zauważył zmianę?

Wspólny mianownik wszystkich siedmiu

Za żadną z tych decyzji nie stoi niekompetencja, raczej brak odpowiedzialności za całość: każda decyzja była lokalnie rozsądna, tylko nikt nie odpowiadał za sumę. Rozwiązaniem niekoniecznie jest etat: przy tej wielkości firmy praca CTO jest realna, ale niepełnoetatowa, i od tego jest fractional CTO: kilka godzin tygodniowo kogoś, kto zadaje powyższe pytania, zanim przyjdzie faktura, a nie po niej.

Jeśli kilka z tych siedmiu punktów brzmi znajomo, to jest temat na rozmowę. Rozmowa wstępna jest darmowa i uczciwa co do tego, czy w ogóle nas potrzebujesz.