Oszacowanie kosztów integracji systemu płatności

Na bilecie widnieje napis „dodać pasek”. 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 o treści „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 przyjęliśmy, oraz poradzić sobie w przypadku sporu dotyczącego transakcji”. Dopóki zespół nie przeprowadzi głosowania w sprawie tego zakresu, podana liczba stanowi jedynie przypuszczenie dotyczące 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ą charakteryzować się idempotencją. Jaka jest nasza strategia ponownych prób w przypadku, gdy Stripe ponownie wyśle żądanie?”

Finanse: „W jaki sposób rozliczane są zwroty? 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 oddaniem głosu

• Najpierw wyłącznie środowisko testowe, czy od samego początku w zakresie będą znajdowały się klucze produkcyjne?
• Zwroty i zwroty częściowe: 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 formularzem SAQ-A, nie mając żadnego kontaktu z numerem PAN?
• Uzgodnienie: kto sporządza raport i w oparciu o jakie wiarygodne źródło danych?
• UX w przypadku niepowodzeń: czy zakres obejmuje odrzucone karty, 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 podzielenie go na części. „Przyjęcie środków” to jedna część; „zwrot środków” to kolejna; „uzgodnienie środków” to trzecia. Traktowanie ich jako jednej całości 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 rozwiązaliśmy spór”, a nie za opcją „wywołać interfejs API kasy”.

Zobacz także: typowe błędy popełniane podczas gry w planning poker związane ze zbyt późnym dzieleniem opowieści; techniki szacowania nakładu pracy w przypadku zadań o tak niejasnym charakterze. Proszę zapoznać się z innymi przykładami szacowania lub rozpocząć bezpłatną sesję planning pokera, gdy dopracowanie zadania będzie gotowe.