Új funkciók kidolgozása, amelyek forradalmasítják az élményt!

Új funkciók fejlesztése magánügyfeleknek

Az Új funkciók fejlesztése akkor hasznos, amikor egy meglévő weboldal, alkalmazás vagy belső felület már működik, de hiányzik belőle valami fontos. Ilyenkor nem teljes rendszerépítésről van szó, hanem egy konkrét online feladat megoldásáról. Lehet ez új űrlap, ügyfélfiók rész, fizetési lépés, értesítési logika, kereső, szűrő, adminisztrációs oldal vagy egy kisebb automatizálás. A lényeg az, hogy a fejlesztő érthető feladatot kapjon, a végeredmény pedig valóban használható legyen.

Én azt látom, hogy a legtöbb magánügyfél nem új rendszert akar. Inkább azt szeretné, hogy a meglévő oldal végre azt tudja, amire a mindennapi munka során szükség van. Ez teljesen érthető. Egy jó szakember nem csak kódot ír, hanem rákérdez a célra, az adatokra, a felhasználókra és arra is, mi történjen hibás működés esetén. Az online fejlesztési munka ezért akkor halad jól, ha már az elején világos, mire kell a funkció és milyen eredményt vár az ügyfél.

Új funkció fejlesztésének tipikus esetei

Az új funkció fejlesztése sokféle helyzetben felmerülhet. Gyakori, hogy egy oldal tulajdonosa először csak egyszerű kiegészítést kér, majd a beszélgetés során kiderül, hogy a háttérben több apró szabály van. Például nem elég egy gombot elhelyezni. A gombnak adatot kell mentenie, értesítést kell küldenie, jogosultságot kell ellenőriznie, és néha visszajelzést is kell adnia a felhasználónak.

Szerintem a legfontosabb különbség az, hogy a funkció csak látszik egyszerűnek, vagy valóban egyszerű. Egy új menüpont elkészítése lehet gyors munka. De ha mögötte külön adatkezelés, több felhasználói szerep és hibakezelés van, akkor már komolyabb fejlesztési feladat. Ezt érdemes az elején tisztázni, mert így kevesebb lesz a félreértés.

Volt olyan eset, amikor egy ügyfél csak egy új beküldő űrlapot szeretett volna. A beszélgetés után kiderült, hogy a beküldött adatokat külön státuszokkal kell kezelni, e-mailt kell küldeni a felhasználónak, és az admin felületen is szűrhetővé kell tenni. Maga az űrlap csak a munka kisebb része volt. A valódi feladat az adatfolyamat kialakítása lett.

Árak új funkció fejlesztésénél

Az ár attól függ, mennyi logika van a funkció mögött, milyen rendszerhez kell kapcsolódni, és mennyire pontos a leírás. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, főleg akkor, ha adatkezelés, fizetés, felhasználói fiók vagy jogosultság is érintett. Nem mindig a magasabb ár a jó választás, de a gyanúsan alacsony ajánlatot érdemes óvatosan kezelni.

Tapasztalatom szerint a pontos ár akkor adható meg jól, ha a szakember látja a jelenlegi rendszert és megérti a kért működést. Egy rövid leírás jó kezdés, de ritkán elég. Kell hozzá hozzáférés, képernyőkép, folyamatleírás vagy legalább egy részletes példa arról, hogyan kellene működnie az új résznek.

Megfelelő fejlesztő kiválasztása

A megfelelő fejlesztő kiválasztása nem csak technikai kérdés. Fontos, hogy a szakember érthetően kommunikáljon, ne kerülje a konkrét kérdéseket, és tudjon reális határidőt mondani. Egy online fejlesztési feladatnál a bizalom nagy része abból jön, hogy az ügyfél látja, a másik fél érti a problémát.

Érdemes portfóliót kérni, de nem kell feltétlenül ugyanolyan projektet keresni. Hasznosabb azt nézni, hogy a fejlesztő dolgozott-e már meglévő rendszeren, javított-e más által készített kódot, és vállal-e kisebb, pontosan körülhatárolt feladatokat. Az ilyen munka sokszor nehezebb, mint egy új oldal nulláról, mert alkalmazkodni kell a meglévő szerkezethez.

Sokan ott hibáznak, hogy csak az óradíjat nézik. Pedig egy tapasztaltabb szakember néha kevesebb idő alatt jobb megoldást ad. A Qjob.hu felületén magánszakemberek között lehet keresni, de a döntéshez itt is érdemes konkrét feladatleírást, korábbi munkákat és válaszadási stílust figyelni. Egy jó fejlesztő nem ígér mindent azonnal. Inkább tisztázza a részleteket.

Online munka menete és átadás

Az online munka általában rövid egyeztetéssel kezdődik. Az ügyfél leírja, milyen funkcióra van szüksége, hol jelenjen meg, milyen adatokat kezeljen, és ki fogja használni. Ezután a fejlesztő kérdéseket tesz fel. Ez nem időhúzás. Sőt, ez a jó jel. Ha nincs kérdés, akkor gyakran később jönnek elő a problémák.

A munka menete lehet egyszerű. Először készül egy pontosítás, majd jön a fejlesztés, utána a tesztelés, végül az átadás. Nagyobb feladatnál érdemes részekre bontani. Így az ügyfél hamarabb lát működő részletet, a szakember pedig időben észreveszi, ha valami mást jelentett a megrendelőnek, mint amit ő értett.

Az átadásnál fontos, hogy ne csak a kész funkció legyen meg. Kell rövid magyarázat is. Hol lehet beállítani, milyen adatot ment, mikor küld értesítést, mit tegyen az ügyfél hiba esetén. Nem kell hosszú dokumentáció minden kis munkához, de egy érthető leírás sok későbbi kérdést megelőz.

Minőség és hibák új funkció fejlesztése közben

Az új funkció fejlesztése közben a leggyakoribb gond nem maga a programozás, hanem a pontatlan elvárás. Az ügyfél azt gondolja, hogy a dolog magától értetődő. A fejlesztő pedig a leírás alapján mást épít. Ilyenkor mindkét fél csalódott lesz, pedig a probléma sokszor egy hiányzó példa vagy egy kihagyott szabály miatt keletkezik.

Én azt látom, hogy a jó minőséghez három dolog kell. Világos feladat, tesztelhető eredmény és nyugodt javítási kör. Nem baj, ha az első változat után van néhány módosítás. Ez természetes. De az már gond, ha a javítások valójában új igényeket jelentenek. Ezért érdemes előre meghatározni, mi számít hibajavításnak és mi számít új kérésnek.

A kommunikáció minősége itt legalább olyan fontos, mint a kód. Ha a szakember eltűnik, nem ad visszajelzést, vagy nem jelzi időben az akadályt, az ügyfél nem tud tervezni. De az is gond, ha az ügyfél nem válaszol, nem ad hozzáférést, vagy folyton változtatja a feladatot. Az online együttműködés akkor működik, ha mindkét oldal kiszámítható.

Funkciófejlesztés előtt szükséges anyagok

Egy fejlesztési feladat előtt hasznos összegyűjteni a belépési adatokat, képernyőképeket, jelenlegi működést bemutató leírást és a kívánt végeredményt. Nem kell bonyolult műszaki dokumentum, de kell egy érthető irány. Például melyik oldalon jelenjen meg az új elem, ki láthatja, milyen adatot kérjen be, és mi történjen mentés után.

Ha van korábbi hibaüzenet, azt is érdemes elküldeni. Ha van hasonló példa más felületen, az segíthet, de nem helyettesíti a saját szabályokat. Szerintem a legjobb brief rövid, de konkrét. Nem azt írja, hogy legyen modern funkció, hanem azt, hogy a felhasználó a fiókjában módosítani tudja az értesítési beállításait, majd mentés után kapjon visszajelzést.

Az ügyfélnek azt is érdemes eldöntenie, mennyire sürgős a munka. Egy kisebb online fejlesztés elkészülhet néhány nap alatt, de összetettebb funkciónál a tesztelés és a javítás több időt igényel. A gyors munka nem mindig rossz. De ha minden azonnal kell, miközben a feladat nincs pontosítva, akkor nő a hibák esélye.

Reális elvárások új online funkciónál

Reális elvárás az, hogy a funkció a megbeszélt módon működjön, ne rontsa el a meglévő részeket, és használat közben érthető legyen. Az már nem mindig reális, hogy egy kisebb megbízásból teljes új rendszer szülessen. Ezt érdemes különválasztani, mert így az ügyfél is jobban látja, mire fizet.

Az online szakember akkor tud jól dolgozni, ha a cél nem változik naponta. Lehet módosítani, lehet pontosítani, de minden változás időt és pénzt érinthet. Ez nem rosszindulat, hanem a munka természete. Egy funkció sok apró döntésből áll, és ezek a döntések együtt adják a végeredményt.

A jó végeredmény nem feltétlenül látványos. Néha csak annyi, hogy egy folyamat végre nem kézzel történik, egy ügyfél nem akad el, vagy egy adminisztrációs lépés kevesebb időt vesz igénybe. Éppen ezért az Új funkciók fejlesztése akkor éri meg igazán, ha a megrendelő nem csak ötletet ad, hanem meg tudja mondani, milyen problémát szeretne megszüntetni.