Programozók szájából gyakran elhangzik az ominózus mondat. Vegyük kicsit nagyító alá, ez igaz-e?

Programozók szájából gyakran elhangzik az ominózus mondat. Vegyük kicsit nagyító alá, ez igaz-e?

Profi programozóktól hallani azt, hogy az ügyfél nem tudja mit akar, és ha ad is egy specifikációt, akkor azt kezeljük „rugalmasan”: azaz ne vegyük komolyan, a végén úgyis minden másképp lesz.

Ezt a képet még annak idején fejlesztőként magam is tapasztaltam, most menedzserként újra átgondolom.

A kijelentéssel rögtön az a baj, hogy az „ügyfél” nehezen definiálható. Tankönyvekben olvashatjuk azt, hogy az ügyfél az egy személy vagy egy felhasználói csoport. Kisvállalkozás esetén ez valóban így van, de egy igazi komoly, nagy multinál semmiképpen sem áll fenn. Százas nagyságrendű felhasználókkal, több felhasználói csoporttal kell dolgozni, akik érdekei eltérőek lehetnek/lesznek. A felhasználói csoportokon felül pedig sok szakmai csoport létezik, akiknek beleszólása van a szoftverfejlesztésbe, például Enterprise Architect, QA, Üzemeltetés, PMO, adatbázis szakértők, stb. Vagyis amikor egy nagyvállalati ügyfélről beszélünk, akkor egy kívülről nem átlátható dzsungelre kell gondolni.
Olyan finomságokról nem is beszélve, hogy definíció szerint az ügyfél az, aki fizet, márpedig itt nagyon nem egyezik az, aki a szoftverért fizet, aki használni fogja, aki üzemelteti, és aki beleszól a szoftver fejlesztésébe. Átfedések vannak, de ezek nem ugyanazok az emberek/csoportok.

Éppen ezért a projektvezetési módszertanok is igyekeznek pontosan definiálni a szerepköröket és felelősséget. Ügyfél helyett van Project Sponsor, Stakeholder, Felügyelő bizottság, Project Team. Előre azonosítjuk a projekt szempontjából fontos felhasználó csoportokat, eldöntjük ki képviseli őket, és ki hozhat a nevükben döntést.

Át kellene fogalmazni a kijelentést, de hogyan?
Mondjuk ki azt, hogy „a megrendelő nagyvállalatnál senki sem tudja, hogy mit akar”?
Vagy azt, hogy „a Product Owner/Stakeholder/Customer Representative nem tudja, mit akar”?

Azt vallom, hogy nincs informatikai projekt üzleti projekt nélkül.
Beszéljünk konkrét példáról: tegyük fel, hogy cégünk – autóipari cég, tehát autók és alkatrészek eladásából él – ki akar hozni egy új modellt szeptemberben. Az új modellt nevezzük mondjuk Alfának.

Ehhez minden egyes üzleti terület megnézi, hogy képes lesz-e kezelni az Alfa megjelenését, és indít egy projektet, hogy képes legyen rá. Ez egy tisztán üzleti projekt, nagyrészt üzleti feladatokról van szó, mint például: a márkaszervizek és kereskedők oktatása, reklámot kell csinálni a tv-be, át kell állítani az új gyártósort, szükség van alkatrészekre, stb. Mindezek mellett hozzá kell nyúlni a szoftverekhez is, hiszen bele kell tenni az Alfa modellt, a modell jellemzőit, a rendelési szoftverből lehessen Alfát rendelni, tudjunk Alfát számlázni. Mivel az üzleti folyamatok változtak, ezeket szükségszerűen a szoftverekkel is követni kell.
(Egy pillanatra tekintsünk el attól, hogy a szoftverek paraméterezhetőek…)

Van egy üzleti projektünk, aminek a célja az Alfa indítása, a scope-ja pedig sok-sok feladatot tartalmaz, amiből néhány szoftver fejlesztés lesz. A projektnek tehát van célja, határideje, ROI-ja, lesznek erőforrások.
Nagyjából ekkor eljut a konkrét fejlesztési igény a fejlesztőkhöz.

Jól látható, hogy – bár ez a fejlesztők számára nem látható – de üzleti változások is vannak, és hogy az IT az üzlettel egy hajóban (közös projektben) evez. Van cél, van ROI, ismertek és meghatározottak a feladatok. Ha ezek nem lennének ismertek, akkor nem is lenne projekt, és nem is kaptak volna a fejlesztők megrendelést.

Tehát fizikai képtelenség, hogy a megrendelőnek ne lenne elképzelése az elérendő célról.

Ha – tegyük fel – a Customer Representative, a Stakeholder vagy a Product Owner nem tudja, hogy mit kérjen a fejlesztőktől. Mivel a munka nem csak szoftver fejlesztésből áll, ezért ha a kulcsfelhasználó nincs tisztában a követelményekkel, akkor nyilvánvalóan a saját – szoftver fejlesztésen kívüli – munkáját sem fogja tudni elvégezni. Az üzleti projekt össze fog omlani – nem a rossz szoftver miatt, hanem az üzleti feladatok bukása miatt. Ekkor már nem oszt-nem szoroz, hogy a specifikáció jó vagy rossz volt-e.

Akkor miért gondolják a fejlesztők, hogy az „ügyfél” nem tudja mit akar? Mert számukra az ügyfelet egy konkrét személy jelenti, akihez kérdésekkel fordulhatnak. Ez az ember lehet képzetlen a koordinációban/kommunikációban. A projekt célja és a követelmények léteznek, csak az adott ember nem tudja ezeket értelmesen elmondani és/vagy nem ér rá ezzel foglalkozni.
Már az önmagában kihívás, hogy valakinek a fejéből kinyerjünk igényeket – hát még ha neki előtte 100 másik embertől kellene azokat összegyűjteni! Amikor a fejlesztő ezzel a helyzettel szembesül, akkor nem azt látja, hogy az adott ember alkalmatlan a feladatára, hanem általánosít, és végletes következtetést von le – tévesen.

A helyzetet rontja, hogy a fejlesztők nem kommunikáció-specialisták, és nem beszélnek egy nyelvet az üzleti szakértőkkel. Pont ezért kell(ene) Business Analyst-et alkalmazni. Sok fejlesztő sajnos azt képzeli, hogy ő simán elvégzi a BA feladatát is.

Tisztáztuk, hogy a projektnek van célja, és a követelmények adottak.
Végső érvként mondhatja azt egy fejlesztő, hogy a követelmények idővel úgyis változnak… és itt most mindenki nosztalgiával gondolhat a saját tapasztalataira, amikor közvetlenül az átadás előtt bukkantak fel a szoftvert gyökeresen megváltoztatni fejlesztési igények.

Az tény, hogy új igények MINDIG jönnek. De ezek száma összehasonlítva a projekt teljes scope-ját még mindig csak elenyészőek. Tehát hiba lenne abból kiindulni, hogy a megkapott követelmény specifikáció hibás, és majd úgyis másmilyen lesz a szoftver.

Saját tapasztalatom az, a projekt célja azért elég konstans dolog, nem fog változni. Tehát példánkhoz visszatérve, mindvégig az Alfa modell indítása lesz a cél. Az Alfa modell paraméterei, sajátosságai is előre ismertek lesznek. Lesznek persze ismeretlen dolgok, kb a követelmények 10%-a nem lesz meghatározva, nem határozható meg az elején. Ezeket előre tudjuk, esetleg ismerjük a legvalószínűbb alternatívákat is, tehát nem lesz meglepetés. Lesz nagyjából 10%-nyi változás a teljes specifikáción. És a maradék 80% marad.

Aki azt mondja, hogy a pohár félig üres, a specifikáció félig rossz, azzal szemben én azt állítom: a pohár félig tele van, a specifikáció félig jó. Sőt továbbmenve, a specifikáció nagyobb része fog megmaradni, mint amit megváltoztatnak, tehát a pohár nem félig van tele, hanem ennél sokkal nagyobb mértékben.

Ha a fejlesztők eltöltenének 1-2 hónapot a felhasználók között, ha részt vennének az üzleti megbeszéléseken, akkor látnák, hogy az a szervezetlen csürhe, amelyik szerintük azt se tudja mit akar, az valójában nagyon is tudatosan és hosszú távra tervez, mindennek van oka, a döntéseket megfelelő módon hozzák, a részletek ismertek, a tapasztalat és a szakértelem ott van.

Viszont ők azt gondolják, hogy a fejlesztők jelentik a leggyengébb láncszemet a projektben…