Cutting edge = szívás

Cutting edge = szívás

Biztosan mindenki számára ismerős forgatókönyv: amikor megjelenik a legújabb technológia, akkor a marketingesek nagy konferenciát rendeznek, beindul a hype, mindenki izgatott. A fejlesztők csak erről beszélgetnek a kávéautomata mellett. A menőbbek otthon letöltik a béta cuccost és már ki is próbálják.
A konferencián nagy tömeg, osztják a pólókat és a pogácsát, az előadáson pedig már éles bevezetéseket mutatnak be a büszke vezető fejlesztők. Kiderül, hogy pár kattintással megcsinálhatjuk azt, amit eddig sok munkába tellett. Az ügyfelek között találunk pár közismert nevet (tipikusan bankot).
A hallgatóság ámul-bámul, és a pódiumon demózó gurukat irigyli, akik már zavarbaejtő könnyedséggel kezelik az űrtechnológiát.

Ha valakit érdekel, hogyan történnek az ilyen bevezetések, akkor szívesen elmondom J

A történet mozgatórugója a marketinges, aki az új technológiával minél nagyobb csinnadrattát szeretne csapni. A célja az, hogy minél gyorsabban minél többen bevezessék az új technológiát, azaz a kampány végén tömött sorokban beálljanak az értékesítők pénztárgépe elé.
Ehhez kell ügyfeleket szerezni, ami nagyjából két frontos támadást jelent:
a) Minél hamarabb el kell érni, hogy az IT cégek értsenek az új technológiához, képesek legyenek azt ügyfeleiknek szállítani, illetve az ajánlataikban már ezt a technológiát javasolják.
b) Az üzleti döntéshozók fejébe be kell tölteni az új technológiát, hogy beszállítóiktól ezt kérjék.

Valójában ez egy róka fogta csuka: az IT cégek megtanulják a technológiát, ha az ügyfelek ezért fizetnek, illetve az ügyfelek ezt fogják kérni, ha az IT cégeknél ez a standard.

Az ördögi kört ott lehet felbontani, hogy már az új technológia bevezetésének pillanatában legyenek éles bevezetések, business case-ek – azaz már ekkor álljon rendelkezésre szakértő a piacon, és már legyen ügyfél aki ezt használja.

Hogyan lehet valaki szakértője egy olyan technológiának, ami csak holnaptól elérhető? Hát úgy, hogy még az első release előtt megkapja – azaz már a béta fázisban is használja.

Mi motivál egy ügyfelet abban, hogy még nem létező technológiát használjon? Igazából semmi. Az ügyfélnek problémái vannak, amire informatikai megoldást keres. Nyilván e projekteknek van pilot jellege is, tehát az ügyfél tapasztalatot gyűjt későbbi projektekhez, meg ugye azt a kis problémáját megoldják, de ennyi.
(Arról nem is beszélve, hogy az idő rövidsége miatt csak kis probléma, kis projekt jöhet szóba)
Nyilván a marketinges meggyőzőerejére van szükség, hogy egyrészt az ügyfelet rávegye a projektre, másrészt az fejlesztőket rávegye, hogy tanuljanak meg egy új dolgot és vállalják be a kockázatokat.

Mivel jár egy béta technológia a fejlesztők oldaláról:
- Rá kell szánni az időt az új technológia megtanulására. Azaz ha a munkát meg lehet csinálni X idő alatt, akkor nagyjából 2*X időre lesz szükség.
- Mivel a technológiát még a release előtt kapják meg, ezért az szükségszerűen bétás lesz. Béta release = a funkciók ugyan jelzés értékűen ott vannak, de még nem történt meg az ellenőrzés -> tele lesz hibákkal. Ez nem azt jelenti, hogy a technológia rossz, mert ezek a hibák a végső release-ben már ki lesznek javítva, de addigra ugye a fejlesztőnek már késő.
- Ha a fejlesztő belefut egy genuine bug-ba, akkor nem tud vele mit kezdeni. Megvárhatja a végső release-t, vagy keressen egy másik megoldást. (ilyen esetben az addig készséges marketingesről rögtön kiderül, hogy nem tud segíteni)
- Nincs support. A gyártó definíció szerint nem vállal felelősséget egy bétás szoftverért.
- Miközben a fejlesztőt kötik a garanciák az ügyfelével szemben. (Két tűz között…)
- Megeshet, hogy a béta és a final között a gyártó megváltoztatott funkciókat, átírt interfészeket, mert a tesztelés alapján így látta jónak. Vagyis a fejlesztő által bétára írt szoftver nem fog futni részleges újraírás nélkül.
- A fejlesztő gyakorlatilag önkéntes béta teszter lett a gyártó részére.

És végül még valami. A béta technológiát használó fejlesztőt feszítheti a büszke tudat, hogy ő most valami olyasmit csinál, amiben első Magyarországon, amit rajta kívül más még nem, amit majd ő fog tanítani mindenki másnak. De mivel ez bétás, a fejlesztő valószínűleg olyan funkciókat, olyan módon használ, ahogyan arra a gyártója sem gondolt. Az új technológiák többé-kevésbé működni szoktak arra a fő feladatra, amire szánták őket, és bizony kevéssé minden másra.
Egy olyan gépre hasonlítanak, amelyiken sok gomb van, a zöldet és a kéket megnyomhatod, a többit meg ne piszkáld, mert ki tudja mi történik. A gond ugye az, hogy egy valódi éles megoldásnak teljes körűen működnie kell, nem csak a néhány teszt adatra, és nem csak labor körülmények között. A béta technológia pont, az ami definíció szerint ezt a szintet még nem ugrotta meg.

Mivel jár béta technológia alkalmazása az ügyfélre nézve:
- A gyártó nem ad rá support-ot, tehát semmi komolyat nem lehet vele csinálni.
- A fejlesztők bármikor előállhatnak azzal a szöveggel, hogy „belefutottunk egy technológiai hibába, nem működik a rendszer, és nem tudunk továbbmenni”. Ilyenkor lehet újra tervezni és programozni az egészet, vagy elfogadni a hibás működést – egyik eset sem jó.
- Fél év múlva úgyis kijön az új release és megváltoznak dolgok.
- Tegyük fel, hogy sikerült a projekt, elkészült a szoftver, élesben elindult, a felhasználók örömmel használják… aztán 1-2 hónap múlva belefutunk egy technológiai bug-ba, amire a gyártó majd 6-12 hónap múlva fogja szállítani a javítást.
- Nem kompatibilis semmivel.
- Ha a beszállítóval összeveszik, nehéz lesz rá másik beszállítót találni.
- És a legrosszabb: a kezdeti bevezetések után kiderül, hogy az új technológia a gyakorlatban nem használható, pl teljesítmény, nem elég kiforrott, kiderül hogy más technológiával fele annyi munka lett volna megvalósítani.
- Amit esetleg követ a gyártó beismerése, hogy a technológia mégsem váltotta be a reményeket, és egyszerűen leállítja.
- Ha valami nagyon rosszra fordulna (pl. adatvesztés, üzleti kár, forintosítható veszteség), akkor a gyártó ugye mossa kezeit (béta technológia ugyebár…), a fejlesztő cég pedig a projekt kis mérete miatt nem nagyon perelhető (ajándék ló esete a minőséggel).

Éppen ezért az ügyfelek részéről teljesen logikus védekezési reflex:
- Béta technológiát nem használunk
- Nem-béta technológiát is csak azután, hogy kijött az SP1
- De azt is csak akkor, ha a konkurenciánál már bevált

Tudom, hogy milyen nagyszerű kifejezés a „cutting edge”, én is lelkesedtem annak idején az új dolgokért, de ma már úgy látom, hogy az informatikai menedzser jellemfejlődése az alábbi:
1) Még nem használt béta technológiát
2) Már használt béta technológiát
3) Már nem használ béta technológiát