← Esettár

FTKONF-023

Amikor bocsánatot kell kérned az ügyféltől

Helyzet

„Mit tegyek, ha törő változást vezettem be egy REST API-ban, és valós következményei lettek?” · „What to do when you introduced breaking changes in a REST API, consequences were real…?” · szerző: user27021198 · CC BY-SA

Egy külsős fejlesztő (tanácsadó) egy állami megbízónál módosított egy rendszert: kivett belőle valamit, amiről azt hitte, senki sem használja. Bemutatta a változást az egyik csapatnak, akik átálltak rá, de egy másik rendszer is használta az adatot, az ő tudta nélkül. Eredmény: több száz embernek nem ment ki a havi kifizetése, és ez csak egy hónappal később derült ki. Most rendeznie kell a megbízóval, a saját csapatvezetőjével és a megbízás-adó cégével is.

A forrásposzt teljes szövege (magyarul és angolul)

Az eredeti Stack Exchange-kérdés hű magyar fordítása · szerző: user27021198 · The Workplace, q198935 · CC BY-SA.

Kérdés: Mit tegyek, ha törő változtatásokat (breaking changes) vezettem be egy REST API-ban, a következmények valósak voltak, és csak utólag tudtam meg róla?

Külsős IT-tanácsadó vagyok (Java-fejlesztő), aki egy állami tulajdonú ügynökségnek (az ügyfélnek) dolgozom, amely havi kifizetésekkel foglalkozik (pl. juttatások, nyugdíjak stb.). A csapatom nem közvetlenül a kifizetésekkel foglalkozó rendszereket tartja karban, hanem egyfajta „ügyféladatot" kezelünk, amelyet az említett kifizetési rendszerek használnak. Épp egy hosszú szabadság előtt változtattam egy REST API válaszán, amelyet az A-Csapatnak kellett volna használnia egy olyan rendszerhez, amelyhez az API-t eredetileg fejlesztették. Ez a változtatás eljutott a produkcióba, regressziók nélkül stb. Az A-Csapat tudott róla, bemutattam a változtatásaimat egy demó-ülésen, ők hozzáigazították a rendszerüket stb. Azért változtattam meg az API válaszát, mert az tartalmazott néhány hibás adatot, és ezt a hibás adatot közvetlenül eltávolítottam, anélkül, hogy új verziót biztosítottam volna az API-hoz. De amikor visszajöttem a szabadságról, és átnéztem az e-mailjeimet, megtudtam, hogy egy másik kifizetési rendszer, amely ezt a REST API-t használta (az én vagy a csapatom tudta nélkül), nem találta meg a benne keresett információt a frissített API válaszában a változtatásomat követően, és több száz ember, aki kifizetésre számított, többé nem kapta meg. Időközben a másik rendszerért felelős B-Csapat hozzáigazította a kódját, és ezek az emberek végül megkapják a pénzüket. Amikor visszatértem a munkába, senki nem említett semmit erről. Nagyjából egy hónappal azután fedezték fel ezt a problémát, hogy produkcióba került, innen a több száz érintett ember... Most már belátom a hibáimat. A legfontosabb az volt, hogy nem új, különálló API-verzióként vezettem be a változtatásokat, hanem közvetlenül. Túl magabiztos voltam a hibás adat eltávolításában, mert azt hittem, senki sem használja, hiszen eleve hibás volt. Ugyanilyen fontos hiba volt, hogy nem kommunikáltam globálisan, egy globális csatornán, hogy változás lesz ebben a REST API-ban. Nem tartottam szükségesnek, mert ezt az API-t csak egyetlen projektre tervezték, és kommunikáltam velük, és tartottam egy demó-ülést. Hogyan kezeljem ezt szakszerűen a csapatunk ügynökségnél lévő Koordinátorával, az architekttel, a csapatom vezető elemzőjével és a céggel, amellyel a szerződésem van, a menedzseremmel? Hogyan vállaljak felelősséget szakszerű módon? Először a koordinátorhoz és/vagy az architekthez (ezek kereszt-csapat szerepkörök) forduljak? Vagy először a csapatom vezető elemzőjéhez? Frissítsem az önéletrajzomat, és kezdjek új állást keresni? Eddig ezt tettem: Bocsánatot kértem a B-Csapattól, írásban. Átnéztem a változtatásokat, amiket csináltam, és a B-Csapat által küldött példákat, hogy lássam, valóban azt használták-e, ami eleve hibás adatnak tűnt. Átnéztem a jegy (ticket) megjegyzéseit, és ellenőriztem, volt-e bármilyen módja annak, hogy magamtól tudjam, más rendszerek is használják-e ezt az API-t. Köszönöm!

A közösség legjobbnak ítélt válasza

Bart van Ingen Schenau (7) · CC BY-SA

The professional way to deal with this error is to tell your architect and lead analyst about what happened. This should not be in the form of an apology, but a fact-based narrative of a failure in the processes … then start looking together at how the processes can be improved so a repeat can be avoided.

Magyar összefoglaló: a működő bocsánatkérés nem szóvirág, hanem tényszerű elismerés + jóvátétel + a folyamat javítása, hogy ne ismétlődjön. A „sajnálom, ha" eltol; a „sajnálom, hogy" felelősséget vállal.

Valós forrás: „What to do when you introduced breaking changes in a REST API, consequences were real…?” · szerző: user27021198 · Stack Exchange / The Workplace (q198935) · CC BY-SA · magyar fordítás, anonimizálva. Az eredeti poszt →