A szoftverfejlesztéssel foglalkozó cégek életében mindig eljön a pont, amikor “refaktorálni kellene”, de közben új funkciót is “kéne” szolgáltatni az ügyfélnek. Ebben a helyzetben az üzlet és az IT általában egymásnak feszül. Az IT mindenképp a minőségbiztosítás felé húz, hogy stabil jól működő terméket tudjon szállítani, az üzlet pedig szeretne az ügyfeleknek újabb és újabb funkciókat adni. Ez normális, viszont ahhoz, hogy mindenki jól járjon meg kell találni az egyensúlyt a mérlegen.
Ha pár sprintre leállunk az új funkciók fejlesztésével és csak a refaktorálásokra koncentrálunk, akkor az ügyfelünk nem fog új funkciót kapni. Cserébe lesz egy modernizált és stabil alkalmazásunk. Ha csak új funkciók fejlesztésre költünk, az ügyfélnek vannak új funkciói, de az már más kérdés, hogy tudja-e használni, hiszen lehet tele van hibával vagy lassú. Biztos mindenkinek ismerős az érzés, amikor egy alkalmazást nagyon szeretne használni, de nem történik semmi: lassú, lefagy stb. Azt hiszem egyértelmű, hogy az egyik sem létezhet a másik nélkül. Ha agilis mindset-ben szeretnénk az ügyfeleinket kiszolgálni, akkor nem fér bele, hogy a mérlegnek csak az egyik oldalra koncentráljunk. Refaktorokra és innovációra mindig szükség lesz. Ha nem akarunk elmaradni technológiailag vagy gyors “heggesztéseket” rendes megoldásokra cserélni, akkor időt kell szánnunk ezekre is. Később megbosszulják az elhanyagolásukat. Olyan ez, mint egy lakás rendszeres karbantartása. Ha nem tesszük, egyszer csak egy lelakott lakásban találjuk magunkat, ahol már senki nem szeretne lakni. Kéne már egy festés, új elektromos hálózat, kád és még lehetne sorolni. Új funkciók nélkül fejleszteni egy alkalmazást szintén veszett fejsze. Alig várjuk ügyfélként, hogy jöjjön egy frissítés, várva azt a funkciót, amire már régóta vágyunk. Az ügyfeleink akkor lesznek lojálisak hozzánk, ha egy jól működő, stabil, folyamatosan megújuló alkalmazást használhatnak. Egy Product Owner-nek ezen a skálán mozogni nagyon nehéz feladat. Átlátni minden egyes technikai feladatot vagy refaktort, hogy üzletileg mit jelent, valljuk be, nem egy könnyű feladat. Ezekben a helyzetekben a fejlesztő kollégákat mindig meg szoktam kérni, hogy mondják el mit jelent üzletileg egy adott feladat és milyen következmények várhatók, ha nem készítjük el. Így máris könnyebben tud a PO is dönteni. Ennek ellenére mégis sok esetben a PO úgy dönt, hogy nem allokálunk időt a refaktorra. A nagyobb gond akkor van, amikor bekövetkezik az “én megmondtam” állapot. Fejlesztő koromban sajnos volt egy ilyen élményem. Hiába mondtuk el a Product Owner-nek, hogy baj lesz, ő nem foglalkozott vele. Miután megtörtént a baj, egy életre megtanulta, hogy ne hagyja figyelmen kívül a technikai feladatokat. Egy személyként dönteni egy alkalmazás sorsáról nehéz feladat. Nyomasztanak minden oldalról: – “Automazitálni kéne” – “Új tesztkörnyezet kellene” – “Van egy fontos refaktor” – “Kész van már az új funkció?” Minden nap hasonló megjegyzések esnek be egy Product Owner-hez, aki minden nap játszik a prioritással, hogy épp hosszabb távra vagy rövid távra fektet be. Tegyük fel van egy 10 fős csapatod, de minden is kellene mindenkinek. Általában ilyenkor, ha elveszik egy PO, arra szoktam őket bíztatni, hogy próbálják meg a legfontosabbakat előre venni az alapján, hogy legyen benne rövid távú és hosszú távú cél is. A csapattagokat pedig arra kérem álljanak a PO mellé és segítsenek. Ez egy átlagos eset volt. Mi történik akkor, ha lehagynak a versenytársaid? Esetleg nem foglalkoztál a karbantartással és technológiailag elmaradtál? Ekkor bizony döntened kell: Megállj pár hónapra, évre vagy ne? Fenn tudod tartani párhuzamosan az újításokat és az elmaradt karbantartásokat? Egy konferencián pár éve az egyik előadónak volt egy jó gondolata a működő szoftverről, ami nagyon megtetszett: Ha túl sokat költesz rá és csiszolgatod, olyan drága lesz, hogy senki nem veszi meg. Ha nem költesz rá eleget, nem fog jól működni és nem tudod eladni.
Sajnos volt részem olyanban, hogy egy szervezet piacvezetői pozícióját elveszítette, mert sosem költött a megújulásra. Egy idő után a háttérrendszerek “elöregedtek”. A nagyobb gond az volt, hogy a “baj lesz”-t senki nem vette komolyan, csak amikor már az ügyfél jelezte. Nagyon nehezen tudott életben maradni, miután éveken át csak a rendszer újraírásával tudott foglalkozni. Azt gondolom a megoldást ott kell keresni, hogy hogyan lesz egy priorizált lista a technikai feladatokból és az üzleti funkciókból. Minden ciklusban meg kell nézni a mérleget és dönteni kell aktuálisan merre billenjen. Sosem szabad mindig csak az egyik oldalon állni. Gondolkodj rövid és hosszabb távon is! A legjobb az, ha tudsz úgy tervezni, hogy mindig tudj karbantartásra és új funkció fejlesztésére is időt allokálni.
Comments