Dlaczego integracje idą pierwsze w harmonogramie

W projektach z integracjami zewnętrznymi piszemy je jako pierwsze, przed resztą funkcji. Powód nie leży po naszej stronie: weryfikacja po stronie Google trwała w naszych projektach 2 do 4 razy dłużej niż u Meta, gdzie mieściła się zwykle w 2 tygodniach. Tego nie skróci ani budżet, ani większy zespół.

Jeśli zastanawiasz się, od czego zacząć wdrożenie, to jest konkretna odpowiedź na to pytanie. Nie od funkcji, którą widać na demo, tylko od tej części, która ma zewnętrzną kolejkę.

Harmonogram, który tego nie uwzględnia, wygląda poprawnie na papierze i pęka w ostatnim tygodniu. Nie dlatego, że ktoś się spóźnił z kodem. Dlatego, że kod czeka na czyjąś decyzję, o którą nikt nie wystąpił na czas.

Kolejność w harmonogramie decyduje o terminie bardziej niż tempo pracy

W jednym z projektów klient przyszedł z zakresem, w którym integracje zewnętrzne były rozłożone równomiernie w czasie, jak każda inna funkcja. Logicznie: skoro to podobna ilość pracy, niech leży tam, gdzie pasuje.

Doradziliśmy przełożenie integracji z Google na sam początek, przed resztą funkcji. Klient nie zrezygnował z żadnej integracji. Zmieniła się wyłącznie kolejność.

Efekt był taki, że weryfikacja szła równolegle z budowaniem systemu, a nie po niej. Termin się nie przesunął. Gdyby integracje zostały tam, gdzie były w pierwotnym zakresie, projekt czekałby na cudzą decyzję w tygodniu, w którym miał już działać.

Weryfikacja u Google trwa dwa do czterech razy dłużej niż u Meta

To jest obserwacja z naszych projektów, nie oficjalny termin żadnej z tych firm. U Meta weryfikacja mieściła się zwykle w dwóch tygodniach. U Google trwała wielokrotnie dłużej i była trudniejsza do przewidzenia.

Ta różnica ma jedną własność, która czyni ją ważniejszą od wielu innych ryzyk: nie skraca się. Możesz dołożyć programistów, zapłacić więcej, pracować w weekendy. Kolejka po drugiej stronie nie przyspieszy, bo nie jest twoja.

Dlatego traktujemy ją jak fundament, a nie jak zadanie. Fundament robi się pierwszy, choćby dlatego, że wszystko inne na nim stoi. Zadanie można przełożyć.

Co się dzieje, gdy tego nie zrobisz

Projekt wygląda dobrze przez większość czasu. Funkcje powstają, demo działa, raporty są zielone. Problem jest niewidoczny, bo nie objawia się jako opóźnienie, tylko jako brak czynności, której nikt nie zaplanował.

Ujawnia się na końcu, w tygodniu przeznaczonym na uruchomienie. Wtedy okazuje się, że system jest gotowy, a jedna integracja czeka na weryfikację, która potrwa jeszcze kilka tygodni. Nie ma czego naprawić, bo nic nie jest zepsute.

To jest ten sam kształt awarii, który zna każdy, kto przeżył wdrożenie ERP-a. Nie „nie zdążyliśmy zbudować”, tylko „zbudowaliśmy i nie możemy tego włączyć”. Drugie boli bardziej, bo pieniądze są już wydane.

Czego jeszcze nie ma w zakresie, który dostajemy

Przy planowaniu pierwszej wersji produktu myśli się o funkcjach. O tym, co użytkownik zobaczy i kliknie. Rzadko o tym, co jest potrzebne, żeby te funkcje legalnie udostępnić.

W tym samym projekcie w zakresie nie było mechanizmu zarządzania zgodami RODO. Dorzuciliśmy go z własnych zasobów: wersjonowanie i potwierdzanie zgód. Nie było go w wycenie i klient za niego nie zapłacił. Kosztowało nas to kilka dni pracy, obniżonych przez kod wielokrotnego użytku z wcześniejszych projektów tego typu.

Bez tego modułu problem nie ujawniłby się od razu. Ujawniłby się po walidacji w zamkniętej becie, przy przejściu do szerszego grona użytkowników. Zamiast skalować produkt o potwierdzonej wartości, klient zatrzymałby się i dobudowywał warstwę, o której nikt nie pomyślał na starcie. Znowu ten sam kształt: nie brak pracy, tylko brak pozwolenia.

Czego z tego nie obiecujemy

Nie podajemy terminu weryfikacji u zewnętrznego dostawcy, bo nie mamy na niego wpływu. Możemy powiedzieć, ile trwała u nas i ile razy, i na tej podstawie ustawić kolejność. Nie możemy powiedzieć, ile potrwa u ciebie.

Nie twierdzimy też, że dwa do czterech razy to liczba rynkowa. To jest to, co widzieliśmy w swoich projektach, i tak ją traktuj. Firma, która poda ci w tej sprawie dokładny procent, albo mierzyła to na dużej próbie i powie ci, na jakiej, albo zgaduje.

Nasze 63 dni robocze liczymy od podpisania zakresu i ten termin dotrzymujemy. Obejmuje on czas na weryfikację właśnie dlatego, że integracje idą pierwsze. Gdyby szły na końcu, ten sam termin byłby obietnicą, której nie kontrolujemy.

Które elementy mają zewnętrzną kolejkę i o co zapytać wykonawcę

Weryfikacja aplikacji u dostawcy API to najczęstszy przypadek, ale nie jedyny. Ta sama zasada dotyczy każdej rzeczy, w której czekasz na cudzą decyzję, a nie na własną pracę.

W projektach, które prowadziliśmy, kolejkę miały cztery rodzaje elementów. Weryfikacja dostępu do danych użytkownika u dużego dostawcy, bo to ona ustawia rytm całego harmonogramu. Publikacja w sklepie z aplikacjami, gdzie recenzja bywa szybka, a odrzucenie kosztuje pełny cykl od nowa. Uruchomienie płatności, gdzie operator weryfikuje firmę, a nie kod. Dostęp do systemu, który klient ma u innego dostawcy, bo tam decyduje kalendarz cudzego zespołu.

Sprawdzenie zajmuje jedno spotkanie. Przejdź listę funkcji i przy każdej zapytaj, czy ktoś spoza projektu musi coś zatwierdzić, zanim ta funkcja zadziała. Wszystko, przy czym odpowiedź brzmi „tak”, idzie na początek harmonogramu, niezależnie od tego, jak mało kodu wymaga.

Zapytaj też wykonawcę o jedno: które elementy projektu zależą od decyzji kogoś spoza zespołu. Odpowiedź „żadne” znaczy, że nikt tego nie sprawdził, bo integracje, płatności, sklepy z aplikacjami i dostęp do danych zwykle takie są.

Potem zapytaj, gdzie te elementy leżą w harmonogramie. Jeśli na końcu, poproś o przesunięcie ich na początek i o wyjaśnienie, co się zmieni w kosztach. Zwykle nic, bo to ta sama praca w innej kolejności.

Jeśli zastanawiasz się nad zakresem pierwszej wersji, a nie nad kolejnością, to osobne pytanie i mamy na nie osobny tekst: co musi mieć pierwsza wersja produktu, a co poczeka.

Zanim napiszesz

Nie obiecujemy terminu, którego nie kontrolujemy, i nie przyjmujemy projektów, w których zewnętrzna weryfikacja musi się zmieścić w dwóch tygodniach, bo tak wyszło w prezentacji dla zarządu. Jeśli data jest sztywna z powodów biznesowych, powiemy to przed podpisem, a nie w ostatnim tygodniu.

Jeśli planujesz system na zamówienie i chcesz zobaczyć, jak układamy harmonogram: zobacz, co obejmuje oprogramowanie na zamówienie. Cena i termin są tam podane wprost.