Oszacowanie kosztów integracji systemu płatności
Jak oszacować koszty integracji systemu płatności: środowisko testowe a środowisko produkcyjne, zwroty środków, webhooki, idempotencja, zakres zgodności z PCI. Rozmowa, którą należy przeprowadzić, zanim ustalona zostanie jakakolwiek kwota.
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 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 przegłosuje 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 ponawiania prób w przypadku, gdy Stripe ponownie wyśle żądanie?”
Finanse: „W jaki sposób rozliczane są zwroty kosztó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 oddaniem głosu
- Najpierw wyłącznie w środowisku testowym, czy od samego początku z uwzględnieniem kluczy produkcyjnych?
- 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 przestrzegamy wymogów 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?
- Błędy w doświadczeniu użytkownika (UX): odrzucona karta, karta z wygasłą ważnością, weryfikacja 3DS — czy wszystkie te przypadki wchodzą w zakres?
W przypadku takiego zadania właściwym rozwiązaniem jest często podzielenie go. „Pobranie środków” to jedno zadanie; „zwrot środków” to kolejne; „uzgodnienie ś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 rozwiązaliś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 szacowań lub rozpocznij bezpłatną sesję planning pokera, gdy dopracowanie zadania będzie gotowe.