Húsz év és több száz projekt után az ember már nem az egyedi eseteket jegyzi meg, hanem az ismétlődő mintákat. A legérdekesebb felismerés az, hogy a sikeres szoftverprojektek mennyire hasonlítanak egymásra. Más az iparág, más a technológia, más a csapat, mégis ugyanazok az elvek térnek vissza bennük, újra és újra.

A kudarcok ezzel szemben mind a maguk módján egyediek, a siker viszont meglepően kiszámítható. Ez a cikk nem egy szolgáltatás bemutatása, hanem egy összegzés: mi az a pár dolog, ami szinte minden jól sikerült projektben közös. Egyik sem hangzatos újdonság, és pont ez a lényeg. A siker ritkán múlik egy zseniális ötleten, sokkal inkább néhány alapelv következetes betartásán.

A visszatérő tanulságok három nagy csoportba rendeződnek:

• az időzítés és a stratégia,
• az emberek és a kultúra,
• végül a kommunikáció és a folyamatok köré.

Időzítés és stratégia: a siker az elején dől el

A legtöbb minőségi kérdés nem a tesztelés során dől el, hanem jóval korábban, amikor a projekt céljait és kockázatait meghatározzuk.

A minőség az elején dől el, nem a végén. A sikeres projektek nem attól sikeresek, hogy a végén alaposan teszteltek, hanem attól, hogy a minőség már az első döntéseknél jelen volt. Egy félreértett követelmény a tervezőasztalnál néhány perc alatt tisztázható, ugyanez éles környezetben már adatjavítást és hétvégi hibaelhárítást jelenthet. A tiszta célok és a korai visszacsatolás többet érnek, mint bármilyen tűzoltás jellegű tesztelési hajrá a kiadás előtt.

Üzleti kockázatot kell csökkenteni, nem hibákat számolgatni. A gyenge minőségbiztosítás a talált hibák számával méri magát. A jó azt kérdezi, melyik hiba okozná a legnagyobb üzleti kárt, és azt előzi meg. Egy elrontott fizetési folyamat súlyosabb, mint tíz kozmetikai hiba egy ritkán használt képernyőn. Ez a szemléletváltás választja el a bugvadászatot a valódi értékteremtéstől, ahogy azt A tesztelés nem költség, hanem bevételvédelem cikkben is leírtuk.

Mindenki ugyanazt érti a „kész” alatt. A sikeres projektekben nincs vita arról, mit jelent a „kész” és a „jó minőség”, mert az elején kimondták, méghozzá mérhető formában. Egy egyszerű „legyen gyors a rendszer” elvárás mögött az egyik fél két másodpercet ért, a másik tízet. Ha ez nincs számmal rögzítve, a vita nem az elején, hanem az átadáskor robban ki. Ahol a definíció homályos marad, ott a projekt végén derül ki, hogy mindenki mást gondolt, és akkor már drága a félreértés.

Nem tesztelünk mindent egyformán. A jó projekt nem a teljességre törekszik, hanem a helyes sorrendre és prioritások megfelelő meghatározására. A legkockázatosabb, üzletileg legkritikusabb részek kapják a legtöbb figyelmet, nem az, ami éppen könnyen tesztelhető. A kockázatalapú gondolkodás nem szűkítés, hanem fókusz: ott vagyunk a legalaposabbak, ahol a hiba a legtöbbe kerülne.

Emberek és kultúra: a minőség közös ügy, de van gazdája

A legjobb folyamat is elbukik egy rossz szemléletű csapatban, és a legjobb csapat is csak akkor erős, ha a minőség kultúrája mindenki fejében ott van.

A független szem meglát olyat, ami a csapatnak vakfolt. Aki egy rendszert épít, az ösztönösen bizonyítani akarja, hogy működik, nem pedig kideríteni, hol törik el. Ez nem hozzáértés kérdése, hanem emberi működés. A sikeres projektekben ezért mindig van egy elfogulatlan, külső nézőpont, amely nem a saját munkáját igazolja. Erről szól a Miért nem szabad a fejlesztőnek a saját kódját tesztelnie? cikk.

A minőség kultúra, de a dedikált tesztelők a motorjai. A legjobban működő szervezetekben a minőség nem a tesztelők magánügye, hanem közös felelősség: a fejlesztő, a terméktulajdonos és a vezetés is a magáénak érzi. Fontos azonban tisztázni, mit jelent ez, és mit nem. A közös felelősség nem azt jelenti, hogy nincs szükség dedikált tesztelőkre. Épp ellenkezőleg: a minőségkultúra motorjai maguk a tesztelők, akik életben tartják ezt a szemléletet, mérhetővé teszik a minőséget, és napról napra emlékeztetik rá a csapatot. Ahol a minőség „mindenki dolga” dedikált gazda nélkül, ott a gyakorlatban senkié, és a határidő nyomása alatt elsőként ez esik ki.

A gyakorlatban ez azt jelenti, hogy a csapat minden tagja a minőség egy-egy szeletéért felel. A fejlesztő a kód minőségét tartja szinten, amit egyébként a tesztelő nem is ellenőriz. A business analyst a követelmények és a dokumentumok szerkezetéért, érthetőségéért és minőségéért. A projektvezető pedig a kommunikáció zavartalan folyásáért és minőségéért. A dedikált tesztelő mindezek fölött a termék egészének viselkedését és üzleti kockázatát nézi, és összefogja a szálakat, hogy a részekből valóban minőségi egész álljon össze.

Kommunikáció és folyamatok: a minőség végigkíséri az egész fejlesztést

A siker nem egy pillanat a folyamat végén, hanem az, ahogy a csapat végig kommunikál és dolgozik.

A minőségbiztosítás partner, nem kapu a folyamat végén. Ahol a QA csak az utolsó ellenőrző pont, ott elkésve érkezik. A sikeres projektekben a minőség végigkíséri az egész utat, a tervezéstől az éles működésig. A gyakorlatban ez azt jelenti, hogy a tesztelő már a követelmények tisztázásánál jelen van, nem csak a kész funkciót kapja meg ellenőrzésre, amikor a hibát már sokkal drágább javítani. A jó tesztelő nem a fejlesztés fékje, hanem a minőség motorja.

Az időben közölt rossz hír többet ér, mint a szépített státusz. Talán ez a legnehezebben megtanulható lecke. A sikeres projekteket nem az különbözteti meg, hogy soha nincs bennük gond, hanem hogy a gondok időben, őszintén az asztalra kerülnek, amikor még van idő korrigálni. A szépített státuszriport a legdrágább kényelem a szakmában: rövid távon megnyugtat, hosszú távon éppen a döntés lehetőségét veszi el.

A jó release unalmas. A legszebb kiadás az, amelyik után másnap reggel semmi különös nem történik: az ügyfél nem vesz észre semmit, a rendszer megy tovább, a telefon nem csörög. A kiszámítható, stresszmentes kiadás nem szerencse kérdése, hanem a felkészültségé, ahogy azt a Mit jelent egy sikeres release a CIO szemével? cikkben is megírtuk.

Összegzés

Ha ezeket a tanulságokat egyetlen mondatba kellene sűríteni, az így szólna: a sikeres projektek titka ritkán egy eszköz vagy egy módszer, sokkal inkább egy szemlélet. Korai minőség, üzleti fókusz, függetlenség, őszinte kommunikáció és minőségkultúra.

És van egy utolsó tanulság, amely mindezt keretbe foglalja: a jó elvek stabilak, a módszerek fejlődnek. Húsz év alatt a technológia a felismerhetetlenségig változott, az eszközök jöttek és mentek, a mostani AI hullám is átrajzolja a szakmát. A fenti alapelvek viszont nem változtak. A siker nem a legújabb eszközön múlik, hanem azon, hogy ezeket az egyszerű, de nehezen betartható elveket komolyan vesszük-e.