Dobjunk ki egy feature-t!

Egy szoftver megoldás fejlesztése és folyamatos üzemeltetése során előbb vagy utóbb eljön az a pont, amikor felmerül, hogy egy feature-től meg kellene szabadulni. De miért is kell valamit kidobni, amibe szakértők óráinak százait vagy ezreit öltük? Ennek számtalan oka lehet, ezek közül nézzünk át most egy pár okot és hogy mi vezet odáig, hogy a feature törlése mellett döntünk.

Photo by Alexas Fotos from Pexels

Mindenki aki termék fejlesztésen dolgozik, általában alkotó munkát végez. Azért dolgozik, hogy a teljes rendszer még egyszerűbbé tegye a felhasználó életét, még jobban segítse a felhasználókat, a munkájukat. Nap mint nap új ötletekkel állunk elő, amik közül sokat elvetünk, de néhányat, ami egybe vág az ügyfelek igényeivel, új megoldássá formálunk. Talán éppen ez az alkotó tevékenység az oka annak, hogy ritkán merül fel a lehetőség annak, hogy egy funkciótól megváljunk. Sőt mi több, egy adott szolgáltatás hiánya akár még hátrányos helyzetbe is hozhat minket az értékesítés során, ha a versenytársaink olyat kínálnak, ami nekünk nincsen. Ezért az a nézet alakul ki, hogy egy rendszer minél többet tud, annál jobb. Ez viszont számos problémához is vezethet.

Először is ha nagyon sok funkciót zsúfolunk össze egy termékbe, akkor a felhasználók el is veszhetnek a sok funkció között és olyat is nehezen fognak tudni megtenni, ami addig viszonylag egyszerű volt. Emellett nő az egész rendszer komplexitása, sokkal többet kell tesztelni, sokkal több kódot kell karbantartani és az üzemeltetés is bonyolultabb lehet, a dokumentálásról és a support-ról nem is beszélve.

Ideje törölni!

Nem használják… Ha úgy látjuk a statisztikákból, hogy egy funkciót nem vagy csak nagyon ritkán használnak, akkor érdemes megvizsgálni, hogy azok akik még használják, azok számára mennyire értékes az adott feature. Ha meglennének nélküle is, akkor érdemes elgondolkozni azon, hogy leállítsuk az adott szolgáltatást.

Elavult… Már nem felel meg az aktuális jogszabályi követelményeknek vagy nem elég gyors a megoldás és az ügyfelek nem szeretik már használni a megoldást. Ebben az esetben mindenképpen el kell gondolkozni rajta, hogy milyen másik megoldással tudjuk az elavult funkciót helyettesíteni, mert nem az ügyfél igénye tűnt el, hanem a termék felett járt el az idő. Akkor lehet a feature-t leállítani, ha van helyettesítő megoldásunk, amire válthat az ügyfél.

Nem tudjuk gazdaságosan fejleszteni… Egy termék vagy egy feature hosszú évek alatt elérhet egy olyan komplexitást vagy egy olyan architektúra állapotot – főleg ha nem tartották karban -, hogy azt gazdaságosan fejleszteni már nem lehet. Vagy egész egyszerűen nem lehet már elérni vele adott performancia javulást. Ebben az esetben sem tűnt el az ügyfelek igénye, viszont az adott termék vagy feature egészen biztosan nem fejleszthető tovább. Új megoldást kell helyette kidolgozni, majd az ügyfeleket átterelni az új platformra, ami nem szenved már a korábbi problémáktól és folyamatosan fejleszthető is.

Komplexitás csökkentése (és keresztértékesítés)… Egy termék az idők során borzasztóan komplex rendszerre nőhet, ahol időről-időre érdemes megvizsgálni, hogy az adott komplexitás mellett hol lehet egyszerűsíteni akár úgy, hogy újabb feature-ök felé tereljük a felhasználóinkat. Így tett az Apple is, amikor elvette a Mac felhasználóktól a CD olvasót és helyette elkezdte promotálni a cloud megoldásokat. De ugyanilyen lépés volt a jack csatlakozó kihagyása az iPhone-okból, amivel megnyílt az út az újabb generációs bluetooth eszközök térhódítása előtt.

Photo by Christina Morillo from Pexels

Hogyan töröljünk?

Tudjuk, hogy kik használják?

Az első és legfontosabb, hogy pontosan tudjuk, hogy kik használják azt a feature-t amit készülünk halálra ítélni. Ha kulcsfontosságú ügyfelek is aktívan használják, akkor sokkal óvatosabban kell eljárnunk, mint ha már senki sem használná. Az sem mindegy, hogy a használat mit jelent. A feature hiánya teljesen ellehetetlenítené a munkájukat vagy észre sem vennék a hiányát?

Ha tudjuk, hogy kik a felhasználóink, akkor érdemes felvenni velük a kapcsolatot és megtudakolni, hogy miként használják a megoldást, illetve hogy mit jelentene számukra, ha nem lenne elérhető a szolgáltatás a jövőben. A beszélgetések célja, hogy megértsük a döntésünk következményét, akár a feature megtartása, akár a törlése mellett döntünk.

Kommunikáljunk!

Ha meghoztuk a döntést, azt először a szervezeten belül kell kommunikálni. Ezáltal biztosítani kell mindenkit arról, hogy a döntést megelőzően alaposan mérlegeltük a lehetőségeket és ez a helyes döntés. Legyünk rá felkészülve, hogy lesznek akik nem értenek egyet velünk. Különösképpen, ha éppen ők maguk fejlesztették az adott feature-t vagy szolgáltatást.

Legyen egy tervünk!

Ha abban a szerencsés helyzetben vagyunk, hogy az adott feature-t már senki nem használja, akkor egyszerűen leállíthatjuk. Ha viszont van még olyan, aki használná vagy találtunk olyat aki a törlési döntéssel nem ért egyet, akkor szépen szisztematikusan el kell érnünk, hogy minden akadály elháruljon a feature kivezetése elől. Az ellenálló felhasználóknak alternatívát kínálhatunk, az egyet nem értő kollégákat pedig meggyőzhetjük a döntés helyességéről. De csak lépésről lépésre és nem egyszerre mindenkit megcélozva. Legyen egy terv arra, hogy pontosan mit és hogyan szeretnénk elérni, hogy a feature törölhetővé váljon.

Új ügyfeleknek már nem!

Egy feature kivezetésének vagy rossz esetben kivéreztetésének első lépése lehet, hogy új ügyfelek számára már nem tesszük elérhetővé a megoldást. Ezzel lassan de biztosan ki tudjuk futtatni a feature-t, viszont ez akár évekig is tarthat, ameddig még üzemeltetni és támogatni kell. Emellett az ilyen szolgáltatásokat már ki kell venni az összes marketing anyagból is. Az új ügyfeleknek így már nem is kell tudni az adott feature létezéséről.

Migráljunk!

Ha már tudjuk, hogy pontosan kik azok az ügyfelek, akik az adott funkció leállítása miatt esetleg megharagudhatnak ránk, akkor őket kell megkeresni és elmagyarázni számukra a döntésünk hátterét, valamint felkínálni azokat a lehetőségeket, amelyekkel kompenzálhatjuk őket, ha van ilyen. Fontos az aktív kapcsolat és a mihamarabbi migrálás az új helyettesítő funkcióra.

Photo by Tim Gouw from Pexels

Egy megtörtént eset

Körülbelül 3 éve egy termék fejlesztésekor abban a helyzetben találtuk magunkat, hogy egy adott szolgáltatást szinte már senki sem használt, viszont nagyon nagy befektetés kellett volna ahhoz, hogy a megoldás legalább versenyképes legyen. Mivel a várható felhasználószám növekedés nem lett volna szignifikáns, ezért ezt a terméket leállítottuk. Megtörtént az ügyfelek felé a kommunikáció, mindenki megértette a döntést és senki sem volt csalódott. Pár embert kivéve, akiket jól felbőszítettünk.

Ők voltak azok, akik az eredeti termék alapjait lefektették. Talán a kommunikációt az sem segítette, hogy a leállításról szóló prezentáció az alábbi mondattal kezdődött: „We stopped it and we liked it!” Bár a döntéssel ők is egyetértettek, ugyanakkor nem esett jól nekik ez a fajta üzenet. A fentiekből jól látszik, hogy egy feature leállítása során nem csak arról kell gondoskodni, hogy az ügyfeleket ne érintse túlzottan negatívan, hanem azt is szem előtt kell tartani, hogy az összes többi érintettet is megfelelően kezeljük.

A cikkben felhasznált források: