Oszacowanie kosztów integracji systemu płatności

Na bilecie widnieje napis „dodaj Stripe”. W tekście mowa jest o połowie ćwierćdola.

Moduł płatności posiada publiczny interfejs API, który mieści się na jednej stronie, oraz prywatny interfejs decyzyjny, który tego nie robi. Wybór dostawcy to zadanie zajmujące jeden dzień. Skonfigurowanie standardowego procesu realizacji transakcji zajmuje kilka dni. Wszystko, co następuje później (proces zwrotu środków, zasady ponownych prób webhooków, klucze idempotencji, raport uzgodnieniowy, o który dział finansowy poprosi w drugim miesiącu) stanowi rzeczywistą funkcjonalność, a żadna z tych kwestii nie została uwzględniona w zgłoszeniu.

Zadanie zatytułowane „zintegrować Stripe” rzadko jest tym, co faktycznie podlega oszacowaniu. Zadaniem podlegającym oszacowaniu jest: „możemy przyjmować płatności, dokonywać zwrotów, udowodnić, że je otrzymaliśmy, oraz poradzić sobie w przypadku sporu dotyczącego transakcji”. Dopóki zespół nie przeprowadzi głosowania w sprawie tego zakresu, podana kwota stanowi jedynie przybliżoną wartość dotyczącą zupełnie innej kwestii.

O czym się mówi w tym pomieszczeniu

Backend: „Sandbox jest prosty w obsłudze. Biblioteka zajmuje się większością zadań”.

SRE: „Webhooki muszą być idempotentne. Jaka jest nasza strategia ponownych prób w przypadku, gdy Stripe ponownie wyśle żądanie?”

Finanse: „W jaki sposób rozliczane są zwroty środków? A co z częściowymi zwrotami?”

Zgodność z przepisami: „Czy przetwarzamy numery kart, czy też ograniczamy się do kwestionariusza SAQ-A?”

Premier: „Co zawiera wiadomość e-mail dotycząca nieudanej płatności i kto ją sporządza?”

Pytania, które warto zadać przed głosowaniem

• Najpierw wyłącznie w środowisku testowym, czy też od samego początku z uwzględnieniem kluczy produkcyjnych?
• Zwroty i częściowe zwroty: UI, API czy wyłącznie dla administratorów?
• Idempotencja webhooków i obsługa ponownych prób: kto jest właścicielem tabeli deduplikacji?
• Zakres standardu PCI: czy zachowujemy zgodność z SAQ-A, nie mając żadnego kontaktu z numerem PAN?
• Uzgadnianie danych: kto sporządza raport i w oparciu o jakie wiarygodne źródło danych?
• UX w przypadku niepowodzeń: czy zakres obejmuje karty odrzucone, karty, których ważność wygasła oraz problemy związane z weryfikacją 3DS?

W przypadku takiego zadania właściwym rozwiązaniem jest często podział. „Pobieranie środków” to jedno zadanie; „zwrot środków” to kolejne; „rozliczenie środków” to trzecie. Traktowanie ich jako jednego zadania prowadzi do sytuacji, w której integracja zostaje wdrożona w trzecim tygodniu, a dział finansowy pyta w ósmym tygodniu, gdzie jest raport.

Proszę głosować za opcją „udowodnić, że otrzymaliśmy pieniądze i przetrwaliśmy spór”, a nie za opcją „wywołać interfejs API kasy”.

Zobacz również: typowe błędy związane z planning pokerem dotyczące zbyt późnego dzielenia opowieści; techniki szacowania w przypadku zadań o tak niejasnym charakterze. Zapoznaj się z innymi przykładami udanych szacunków lub rozpocznij bezpłatną sesję planning pokera, gdy dopracowanie zadania będzie gotowe.