Az alkalmazás súlyának csökkentése funkcionalitás elvesztése nélkül

Funkcionalitás csökkentése magánügyfeleknek

A Funkcionalitás csökkentése akkor hasznos, amikor egy mobilalkalmazás túl nehéz, lassú, bonyolult vagy túl sok felesleges elemet tartalmaz. Ilyenkor nem az a cél, hogy az alkalmazás kevesebbet tudjon, hanem az, hogy a valóban fontos részek gyorsabban, tisztábban és érthetőbben működjenek. Szerintem sok ügyfél először attól tart, hogy az egyszerűsítés veszteséget jelent. A gyakorlatban ez inkább rendrakás. A magánszakember átnézi a funkciókat, a képernyőket, a felhasználói útvonalakat és a terhelő részeket, majd javaslatot ad arra, mit érdemes megtartani, átalakítani vagy kivenni.

Ez a munka távolról is jól elvégezhető. A megrendelő elküldi az alkalmazás leírását, hozzáférést ad a tesztverzióhoz, képernyőképeket vagy hibajelentéseket küld. A szakember ezek alapján dolgozik. Nem kell személyes találkozó. Fontosabb a pontos feladatleírás, a jó kommunikáció és az, hogy a cél világos legyen. Ha a cél csak annyi, hogy legyen kisebb az alkalmazás, az kevés. Ha viszont az a cél, hogy gyorsabban induljon, kevesebb tárhelyet foglaljon és ne zavarja a felhasználót felesleges részekkel, akkor már lehet jó döntéseket hozni.

A Qjob.hu felületén magánszakemberek között lehet keresni olyan fejlesztőt vagy alkalmazáselemzőt, aki ilyen online feladatot vállal. Én azt látom, hogy a sikeres megbízás általában nem a leghosszabb műszaki leírással indul, hanem egy őszinte problémával. Például az alkalmazás lassan nyílik meg, túl sok menüpontja van, a felhasználók nem találják a fő funkciót, vagy a frissítés után nőtt a méret. Ezekből már el lehet indulni.

Mikor indokolt az alkalmazás egyszerűsítése

Az alkalmazás egyszerűsítése akkor indokolt, ha a felhasználó többet várakozik, mint használja a programot. Ez keményen hangzik, de gyakori. Egy app lehet látványos, mégis kényelmetlen. Lehet benne sok funkció, de ha a fő művelethez öt felesleges lépés kell, akkor a felhasználó hamar elhagyja. Tapasztalatom szerint az ügyfelek sokszor csak akkor kérnek segítséget, amikor már láthatóan romlanak a visszajelzések.

Sokan ott hibáznak, hogy minden új ötletet beépítenek. Egy új gomb, egy új képernyő, egy új értesítés önmagában apróságnak tűnik. De ezek összeadódnak. Az alkalmazás nehezebb lesz, a kezelése lassabb, a kód bonyolultabb. A Funkcionalitás csökkentése ilyen helyzetben nem rombolás, hanem célzott szűrés. Meg kell nézni, melyik funkciót használják tényleg, melyik csak zavaró, és melyik okoz aránytalan terhelést.

Volt olyan eset, amikor egy ügyfél egy régebbi mobilalkalmazást akart frissíteni, de közben ragaszkodott minden régi modulhoz. A szakember először nem törölt semmit. Készített egy listát a funkciók használatáról, a képernyők szerepéről és a hibák gyakoriságáról. Kiderült, hogy három rész alig volt használatban, mégis ezek lassították az indítást. A végén nem egyszerűen kevesebb lett az app, hanem használhatóbb. Ez a különbség fontos.

Funkciócsökkentés árak online munkához

A funkciócsökkentés ára főleg attól függ, mennyire összetett az alkalmazás, van-e hozzáférés a kódhoz, kell-e csak elemzés, vagy konkrét fejlesztői munka is szükséges. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a szakember csak gyorsan töröl valamit, de nem nézi meg a következményeket. Ez veszélyes. Egy rosszul kivett funkció hibát okozhat a fizetésben, a belépésben, az értesítésekben vagy az adatkezelésben.

A táblázatban szereplő összegek irányadóak. Egy magánszakember ennél adhat alacsonyabb vagy magasabb ajánlatot is, ha a feladat nagyon egyszerű, vagy éppen sok kockázatot hordoz. Szerintem érdemes külön választani az elemzést és a megvalósítást. Először legyen tiszta, mit kell csökkenteni. Csak utána jöjjön a fejlesztés.

Megőrzött funkciók és használhatóság

A megőrzött funkciók kiválasztása a munka legfontosabb része. Nem minden régi elem értékes, de nem is minden felesleges. Egy funkció lehet ritkán használt, mégis fontos. Például a jelszó-visszaállítás, az adatletöltés vagy a számlázási beállítás nem mindennapi művelet, de ha hiányzik, az komoly gondot okoz. Ezért a szakember nem csak azt nézi, hogy mi népszerű. Azt is figyeli, mi szükséges a biztonságos és értelmes működéshez.

Az alkalmazás karcsúsítása akkor jó, ha a felhasználó nem érzi veszteségnek. Rövidebb útvonalak, tisztább menük, gyorsabb betöltés, kevesebb zavaró elem. Ezeket a változásokat a legtöbben pozitívan veszik észre, még akkor is, ha nem tudják pontosan megnevezni, mi változott. Én azt látom, hogy a jó eredmény gyakran csendes. Nincs nagy látványos fordulat. Egyszerűen kevésbé fárasztó használni az alkalmazást.

Az online munka során érdemes listát készíteni azokról a részekről, amelyek nem nyúlhatók meg külön egyeztetés nélkül. Ilyen lehet a regisztráció, a fizetés, az adatvédelem, az értesítési rendszer vagy a fő szolgáltatási folyamat. Ha ezek nincsenek rögzítve, könnyen félreértés lesz. A fejlesztő azt gondolhatja, hogy egy elem elhagyható, az ügyfél viszont üzleti szempontból fontosnak tartja.

Hogyan válassz szakembert funkciócsökkentéshez

A megfelelő szakember nem csak kódot töröl. Kérdez. Meg akarja érteni, miért kell a csökkentés, milyen panaszok érkeztek, mi a fő cél és milyen eredmény számít elfogadhatónak. Ha valaki azonnal árat ad úgy, hogy nem látja az alkalmazást, az szerintem kockázatos. Lehet, hogy csak egy egyszerű vizsgálatról van szó, de lehet, hogy a háttérben sok összefüggés van.

Érdemes olyan magánszakembert keresni, aki tud mobilalkalmazás használhatósági, teljesítménybeli és fejlesztői szempontból is gondolkodni. Nem kell minden területen mély szakértőnek lennie, de értse a következményeket. A jó jel az, ha először felmérést javasol, kéri a képernyőket, a jelenlegi hibákat, az elemzési adatokat és a kívánt célt. A portfólió is számít, de ennél fontosabb, hogy világosan beszéljen. Ha az ügyfél nem érti, mit fog kapni, abból később vita lehet.

A választásnál hasznos rákérdezni a javítási körökre is. Egy funkciócsökkentési munka ritkán tökéletes elsőre. Lehet, hogy a szakember jó irányt javasol, de a teszt után még finomítani kell. Ez természetes. De legyen előre tiszta, hány kör egyeztetés fér bele az árba, milyen formátumban kapod meg a javaslatokat, és mikor zárul le a munka.

Távoli munkafolyamat és eredményátadás

A távoli munkafolyamat általában rövid felméréssel indul. Az ügyfél elküldi a jelenlegi alkalmazás elérhetőségét, a fontos képernyőket, a panaszokat, a célokat és a korlátokat. Ezután a szakember átnézi a működést, kérdéseket tesz fel, majd elkészíti a javaslatot. Ha fejlesztés is szükséges, akkor külön ütemezés készül. Így a megrendelő nem egy homályos ígéretet kap, hanem követhető lépéseket.

Az eredmény lehet dokumentum, feladatlista, képernyőnkénti javaslat, fejlesztői specifikáció vagy módosított kód. A forma attól függ, mire van szükség. Egy magánügyfélnek gyakran elég egy érthető jelentés, amely megmutatja, mit érdemes kivenni, mit kell összevonni és mit nem szabad bántani. Ha van külön fejlesztő, akkor részletesebb műszaki átadás kell.

Határidő szempontjából egy kisebb elemzés néhány nap alatt elkészülhet. Egy összetettebb átalakítás több hetet is igényelhet. De a gyorsaság önmagában nem erény. A Funkcionalitás csökkentése akkor működik jól, ha van idő átgondolni a hatást. Egy eltávolított funkció után tesztelni kell a kapcsolódó részeket is. Ezt sok ügyfél alábecsüli.

Gyakori hibák a funkciók visszavágásánál

A leggyakoribb hiba az, hogy az ügyfél csak a látványos részeket nézi. Például ki akar venni egy képernyőt, mert ritkán használja. Később derül ki, hogy az a képernyő kapcsolódik egy beállításhoz, amely nélkül más funkció hibásan működik. A másik hiba a túl gyors döntés. Ha nincs mérés, nincs visszajelzés és nincs teszt, akkor a csökkentés inkább találgatás.

Sokan ott hibáznak, hogy a felhasználói panaszokat szó szerint veszik. Ha valaki azt írja, hogy túl sok a funkció, az nem feltétlenül azt jelenti, hogy mindent törölni kell. Lehet, hogy csak rossz helyen vannak a fontos elemek. Lehet, hogy a menü zavaros. Lehet, hogy a fő művelet nincs eléggé kiemelve. Egy jó szakember ilyenkor nem azonnal csökkent, hanem először rendszerez.

Van egy másik probléma is. A megrendelő néha azért akar kevesebb funkciót, mert olcsóbb fejlesztést remél. Ez érthető, de nem mindig igaz. Egy rosszul felépített alkalmazásból kivenni valamit néha nehezebb, mint hozzáadni egy új részt. A függőségek, régi kódrészek és rejtett kapcsolatok miatt a munka több figyelmet kérhet. Ezért az árnál nem csak a törölt elemek számát kell nézni.

Minőségi elvárások egyszerűbb alkalmazásnál

Az egyszerűbb alkalmazás nem lehet szegényes. Ez fontos. A cél az, hogy a felhasználó gyorsabban érje el, amiért megnyitotta az appot. Ha a csökkentés után hiányzik egy alapvető beállítás, eltűnik egy fontos visszajelzés vagy romlik a biztonság, akkor a munka nem sikeres. A minőséget nem a funkciók száma adja, hanem az, hogy a megmaradt részek mennyire pontosan működnek.

Én azt tartom jó eredménynek, amikor a megrendelő egy rövid listában látja a változásokat, a megtartott funkciókat és a kockázatokat. Nem elég annyi, hogy kész. Tudni kell, miért történt a módosítás. A későbbi fejlesztéseknél ez sok időt spórol. És segít abban is, hogy ne kerüljenek vissza ugyanazok a felesleges elemek.

A funkciók ésszerű visszavágása hosszabb távon tisztább fejlesztést adhat. Kevesebb hibaforrás, gyorsabb ellenőrzés, érthetőbb felület. De csak akkor, ha a döntések nem érzésből születnek. A szakember szerepe itt az, hogy a megrendelő szándékát lefordítsa működő, biztonságos és használható megoldássá. Ez online is jól kezelhető, ha a feladat világos, az anyagok rendben vannak, és mindkét fél tudja, mi számít kész eredménynek.