Kostenvoranschlag für eine Zahlungsintegration

Auf dem Ticket steht „Stripe hinzufügen“. Im Text ist von einem halben Viertel die Rede.

Der Zahlungsbereich verfügt über eine öffentliche API-Oberfläche, die auf eine Seite passt, und eine private Entscheidungsoberfläche, die dies nicht tut. Die Auswahl eines Anbieters ist eine einmalige Aufgabe, die einen Tag in Anspruch nimmt. Die Einrichtung des „Happy-Path“-Checkouts dauert einige Tage. Alles, was danach kommt (der Rückerstattungsprozess, die Richtlinie für Webhook-Wiederholungsversuche, die Idempotenzschlüssel, der Abgleichsbericht, den die Finanzabteilung im zweiten Monat anfordern wird), stellt die eigentliche Funktion dar, und nichts davon ist im Ticket enthalten.

Die Anforderung, die lautet: „Stripe integrieren“, ist selten die Anforderung, die tatsächlich geschätzt wird. Die Anforderung, die geschätzt wird, lautet: „Wir können Zahlungen entgegennehmen, Rückerstattungen vornehmen, nachweisen, dass wir die Zahlung erhalten haben, und im Falle einer strittigen Abbuchung bestehen.“ Solange die Gruppe nicht über diesen Umfang abstimmt, handelt es sich bei der Zahl lediglich um eine Schätzung, die sich auf etwas anderes bezieht.

Was in dem Raum gesagt wird

Backend: „Die Sandbox ist unkompliziert. Die Bibliothek übernimmt den Großteil der Arbeit.“

SRE: „Webhooks erfordern Idempotenz. Wie sieht unsere Strategie für Wiederholungsversuche aus, falls Stripe die Übertragung erneut durchführt?“

Finanzen: „Wie werden Rückerstattungen abgeglichen? Was ist mit Teilrückerstattungen?“

Compliance: „Verarbeiten wir Kreditkartennummern oder bleiben wir bei SAQ-A?“

PM: „Was steht in der E-Mail bezüglich der fehlgeschlagenen Zahlung, und wer verfasst sie?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

• Zunächst nur in der Sandbox oder sind Live-Schlüssel von Anfang an im Geltungsbereich enthalten?
• Rückerstattungen und Teilrückerstattungen: UI, API oder nur für Administratoren?
• Idempotenz von Webhooks und die Behandlung von Wiederholungsversuchen: Wem gehört die Deduplizierungstabelle?
• Geltungsbereich der PCI-Vorschriften: Erfüllen wir die Anforderungen des SAQ-A, wenn wir die PAN niemals berühren?
• Abstimmung: Wer erstellt den Bericht, und anhand welcher Referenzquelle?
• Fehlererfahrungen (Failure UX): Gehören abgelehnte Karten, abgelaufene Karten und 3DS-Prüfungen alle in den Untersuchungsumfang?

Bei einem solchen Sachverhalt ist es oft ratsam, ihn aufzuteilen. „Geld entgegennehmen“ ist ein Sachverhalt; „Geld zurückerstatten“ ein anderer; „Geld abgleichen“ ein dritter. Wenn man diese als einen einzigen Sachverhalt betrachtet, führt dies dazu, dass die Integration in Woche drei ausgeliefert wird und die Finanzabteilung in Woche acht fragt, wo der Bericht bleibt.

Stimmen Sie für „Beweisen Sie, dass wir das Geld erhalten und den Streit überstanden haben“, nicht für „Rufen Sie die Checkout-API auf“.

Siehe auch: Häufige Fehler beim Planning Poker in Bezug auf eine zu späte Aufteilung von Stories; Schätzverfahren für so ungenau definierte Aufgaben. Sehen Sie sich die anderen Beispiele für gelungene Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Verfeinerung abgeschlossen ist.