"Volt ez a projekt." Egy közel 200.000 euro-s weboldal fejlesztése. Javarészt frontend, némi backend, integrálva egy másik beszállító termékével.

A projekt dedikált csapattal indult, SCRUM, kéthetes sprint, PO, négy fejlesztő. A pár hónapos mennyiségi fejlesztés végén kezdődött a UAT. A UAT "közepén" a cég frissen kinevezett operatív vezetője közölte, hogy a projekt költségvetése túlfutott, ezért a UAT során felmerült hibák javítását korlátozni kell az élesítést gátló elemek javítására, minden mást hagyjon a csapat. Tehát, se tesztelés, se hibajavítás, csak ha nagyon muszáj.

Sajnos az indok tévedésen alapult, amit a gyártási fedezet égetésének követésére használt szoftver is pontosan mutatott. A vezetés ezt egész egyszerűen figyelmen kívül hagyta (lásd később).

A hibákra egyesével kellett erőforrásbecslést adni, amit követően az operatív vezető személyesen engedélyezte az erőforrások allokálását. Most azon könnyelműen átlépünk, hogy ez szinte értelmetlen tevékenység volt, hiszen

1. hibajavításra becslést adni nem egzakt tudomány;
2. abban a pillanatban meg lett állítva a javítás, amint a valóság átlépte a becslést.

Tehát, elindult a csökkentett teljesítményű javítás / tesztelés ciklus. Ha elégett az allokált erőforrás, volt, hogy adott hónapban már nem történt haladás. Az ügyfél a projektvezetés felé jelezte, hogy nem látja, hogy bármi munka történne, és a projektvezetés ezt úgy egyben továbbította az operatív vezető felé - célzott eszkalációként.

„Nem érdekel, majd ha baj lesz, akkor majd én beszélek az ügyféllel”.

És baj lett. Az ügyfél leállította a tesztelést, miután láthatóan a kivitelező is így tett a javítással. Az időnként jelzett elégedetlenséggel együtt a projekt eldöcögött az élesítésig (hónapok teltek el, mivel egy másik beszállító teljesítésére várt a projekt).
Eközben az égvilágon senkinek fogalma sem volt róla, hogy milyen minőségi állapotban van a termék, hiszen egy teljes regressziós ciklust sem lehetett lefuttatni. Végül megnyomták a gombot, a termék kikerült éles környezetre (egyelőre csak zárt körben elérhetően). Ügyfél kénytelen-kelletlen csinált egy teljeskörű tesztet (mégiscsak élesítünk, na), és ezt követően öt teljes napig nem engedte a társadalom elé a weblapot, amíg a projektcsapat éjt nappallá téve a banálisabbnál banálisabb hibákat javítgatta.

Tehát, amit nem csinálhatott meg a csapat az élesítést megelőző hónapokban, azt most túlórában darálva pótolhatta.

 

Analízis

A projektvezetés és operatív vezetés egyaránt hibázott. Nagyot. Először is: olyan hibák tömkelegét kellett orvosolni, amiknek nem UAT alatt kellett volna előjönni, hanem még fejlesztés közben. Egész egyszerűen mondjuk ki: az alkalmazás nem volt folyamatában, tisztességesen tesztelve és javítva. A sprintek lementek szépen, a csapat demózott, a PO átvette, pont. Azt, hogy egyébként használható-e a sprintben szállított termék, senki nem ellenőrizte. Pedig, ez ugye az agilis fejlesztés alapköve: minden sprintben valami újat, használhatót.
Vakrepülés volt ez így, és rávilágított arra, hogy a nyugalmas időszakot megelőzésre kell használni. A QA-nek tervezetten végre kell hajtódnia. Nem térek ki arra, hogy egyébként a QA-nak miként kell működnie, most nem ez a lényeg. Tesztelni és javítani kell. Folyamatosan. Minden sprintben.

Az operatív vezetés pedig sajnos szimplán „nem értett hozzá”. Egyrészt, köztudott, tisztázott tévedés volt, hogy a projekt költségvetése túlszaladt. Simán elhatárolták a UAT-re szánt pénzt, még mielőtt az konkrétan végrehajtásra került volna. Hiába volt ez tényszerű, ötvözve ezt azzal, hogy miként a projektvezetés, úgy az ügyfél jelzéseit is figyelmen kívül hagyta, egészen egyszerűen nem értette meg, hogy ha nem azonnal, akkor majd később, de a rendszer hibái ki lesznek javítva. Ki lesznek javítva, és annak költségét a kivitelező fogja állni. Az igazén nagy kérdés az volt, hogy vajon elégedett ügyfelet akarunk-e teremteni, vagy ellenfelet. Nos, a projekt zárását követően teljesen egyértelmű, hogy melyiket nem sikerült megvalósítani.
Az operatív vezetés súlyos hiányossága ezen felül, hogy a kinevezett döntéshozónak nulla tapasztalata volt IT működés, projektvezetés területen. Részletezés nélkül annyit mondjunk ki: ha olyan döntéshozó kerül a projektvezetés fölé, akinek általában fogalma nincs arról, milyen egy projekt dinamikája, életciklusa, mindamellett - közvetve - tulajdonos a cégben, akkor érzelmi alapon fog döntést hozni, először a saját anyagi céljait figyelembe véve.

 

Tanulság

• Mindig tesztelni, javítani. Minden sprintben, allokálva a szükséges erőforrást. Szállíts lassan, de jól. Inkább csússz meg, mint idő előtt átadj valamit, ami használhatatlan.
• Akiknek nagy befolyása van a projektre, azokat kezelni kell. Házon belül is. Folyamatosan. Projektvezetőként tudnod kell hatni mindenkire. Irgalmatlanul nehéz tud lenni, ha nonszensz utasításokat kapsz, de mindenképpen próbálnod kell megértetni, hogy a végrehajtásnak milyen kockázai vannak. Ápold a kapcsolatot rendszeres beszélgetéssel, és szerezd meg a bizalmát, hogy kevésbé legyen hajlandó átlépni a javaslataidon. Keep your cool.
• A UAT nem arról szól, hogy a legkisebb hibákat is az ügyféllel fedeztetjük fel. Ha az ügyfél kénytelen helyettünk tesztelni, az óriási fekete pont. Muszáj mindent megtenni annak érdekében, hogy UAT-ra olyan csomaggal érkezhess, amiből kiírtottad a lehető legtöbb problémát. Ha kell, kérj haladékot, mert utólag mindig jobb az optikája a csúszással átadott minőséig terméknek, mint a határidőre átadott hibás szállításnak.