Van egy kérdés, ami folyton kísért. Egy kérdés, ami újra és újra megtalál a projektek során. Ezerszer megválaszoltam már, és már nem akarom soha többször, ezért most megírom a választ mindenkinek, akit érdekel. Aztán ha megkérdezik, nem mondok majd semmit, csak átadok egy kis kártyát majd, amin ennek a cikknek az URLje szerepel.

Hogy mi a kérdés? Hát az, hogy "Mi tart ezen a feladaton három napig??"

A három helyére persze lehet 147-et, vagy hat órát, vagy akármit írni. A lényeg az, hogy a kedves megrendelőnek mindig nagyon határozott elképzelése van arról, meddig is tart egy adott szoftverrészt elkészíteni vagy módosítani, még akkor is, ha informatikai ismeretei véget érnek az iPad háttérképének beállításánál, legkomolyabb számítástechnikai teljesítménye pedig még '92-ben volt, amikor megnyerte az osztályban rendezett Tetris versenyt gimnáziumi számtek órán.

Ez a határozott elképzelés kivétel nélkül mindig lényegesen kevesebb, mint amit a szakember (fejlesztő) mond, és kivétel nélkül mindig lényegesen kevesebb, mint amennyi idő alatt az adott feladat megvalósítható. Miből adódik ez a markáns véleménykülönbség? Hát abból, hogy általában a megrendelőknek a programozók munkájáról alkotott idealista képük igencsak messze van a rideg valóságtól.

Vegyünk most egy egyszerű példát, amin keresztül ezt a különbséget meg szeretném világítani. Tegyük fel, hogy felmerül egy nagyvállalati rendszerben két menüpont módosításának igénye: az egyiket arrébb kell rakni, a másikat át kell nevezni.

Lássuk, hogyan képzeli el a feladat megoldását és erőforrás igényét egy átlag megrendelő:

1. Számítógép bekapcsolása (5 perc)
2. Fejlesztői környezet indítása (3 perc)
3. Egyik menüpont áthelyezése drag-and-drop technikával (1 perc)
4. Másik menüpont átírása: eredeti szöveg backspace billentyű nyomkodással történő törlése, majd új beírása (2 perc)
5. Egy csésze kávé elfogyasztása (7 perc)
6. Módosítások megtekintése a fejlesztői környezetben (3 perc)
7. Mentés, fejlesztői környezetből kilépés, számítógép kikapcsolása (4 perc)

Ez összesen 25 perc, legyünk nagyvonalúak, szorozzuk meg kettővel és kerekítsünk fölfelé, még így is megvan a dolog egy órán belül.

Mi történik ezzel szemben a valóságban?

1. A fejlesztő és a projektvezető végigzsibbadnak egy 2 órás meetinget, ahol a résztvevők 20 percig vitatkoznak arról, mi legyen pontosan az őket érintő menüváltoztatási kérelem. (2 x 2 óra)
2. Három nappal később megérkezik levélben leírva a változtatási kérelem, ami azonban nem egyezik a megbeszélésen elhangzottakkal. Négy telefon és három email születik a témában. (2 óra)
3. A véglegesnek látszó írásos követelmény alapján a fejlesztő kibogarássza a szoftverben, hogy hol is van a menük szövege és szerkezete tárolva, nem tudja fejből, hiszen már 8 hónapja senki se nyúlt ahhoz a részhez. (1 óra)
4. A fejlesztő lassan megérti a menüt leíró kódrészt, és rádöbben, hogy a korábbi quick & dirty megoldások miatt át kell szerkesztenie a teljes menüleíró XML fájlt, és még négy helyen bele kell nyúlnia a controller osztályokba. (3 óra)
5. A fejlesztő kipróbálná a saját környezetében a módosítást, de a gépén levő WebSphere összeomlik, és nem indul el többet hosszas próbálkozás után sem. (2 óra)
6. Más választása nem lévén, a fejlesztő a változtatását berakja a repository-ba, és telepíti a módosítást a fejlesztői integrációs tesztrendszerre. (1 óra)
7. A módosítás tesztelésekor kiderül, hogy egy helyen még át kell írni az alkalmazást ahhoz, hogy a NullPointerException-ön túl egyéb funkciók is elérhetők legyenek. A javítás megtörténik. (1 óra)
8. A javítás után újabb telepítés, újabb teszt, ami ezúttal sikeres. (1 óra)
9. A változtatás kikerül az UAT környezetre (2 óra), ahonnan azonnal 6 darab kritikus hibajelentés érkezik, mert a menü nem felel meg a tesztesetben leírtaknak. (2 óra)
10. Heves vita után a tesztelők meghátrálnak, és duzzogva elvonulnak tesztesetet módosítani, a hibásan felvett hibajegyeket lezárják. (2 óra)
11. A módosításra élesítés előtt egy nappal ránéz a megrendelő terület, majd szirénaszerű reakciókat hallatva juttatja mindenki tudtára, hogy ezzel így nem lehet dolgozni, a módosítás elfogadhatatlan. (1 óra)
12. A fejesztőnél csörög a telefon, aki reszkető gyomorral kutatja fel az emailt, amiben a fejlesztés leírását kapta napokkal azelőtt. Fellélegezve látja, hogy ő azt csinálta meg, ami le volt írva, a levelet boldogan küldi szét mindenkinek. (1 óra)
13. Újabb megbeszélés a témában, ahol a felelősség áttolásának és az egymásra mutogatásnak a magasiskolája zajlik. A beszélgetés üvöltözésbe és ajtócsapkodásba torkollik, majd a fejlesztő megadja magát, és bevállalja a módosítás módosítását. (2 x 1 óra)
14. Programozás, tesztelés, nem jó, újra programozás, újra tesztelés, már jó, becsekkolás, telepítés UAT-ra, újra tesztelés, most már tényleg jó mindenkinek. (4 óra)
15. Élesítés során a fejlesztőt berendelik, hogy asszisztálja végig az üzemeltetőket, aki rezignáltan végigüli a telepítést este 8-tól 11-ig, majd hazamegy. (3 óra)

Ez összesen kb. 4 napnyi munka, de legyünk optimisták és higgyük azt, hogy nem fogunk minden fent felsorolt problémával szembesülni, úgyhogy legyen 3 nap.

Hát ezért tart három napig, és nem egy óráig. Van még kérdés? Ugye nincs? Na, akkor hajrá, lehet indítani a megrendelőt :)