Rossz webfejlesztőt nem a látványos hiba árul el először, hanem az, ahogyan halad a projekt. A rossz webfejlesztő jelei közé tartozik, ha nem világos, ki miért felel, a határidő újra meg újra csúszik, és a kérdéseidre nem kapsz egyenes választ. Egyetlen fennakadás még nem ítélet, a visszatérő minta viszont már figyelmeztetés.
„De lehet, hogy csak nehézkesen indul a munka?” Persze. Egy csúszásnak vagy félreértésnek lehet egyszerű oka. Én azt figyelem, hogy a fejlesztő elmondja-e, mi történt, vállal-e felelősséget, és megnevezi-e az érthető következő lépést. Ha ezek rendre elmaradnak, nem érdemes csak a szép látványtervbe kapaszkodni.
Ebben a cikkben gyakorlati ellenőrzőlistát kapsz: milyen kérdéseket tegyél fel, mit nézz meg a feladatok, határidők és változtatások körül, és hogyan különböztesd meg az egyszeri fennakadást a visszatérő problémától. Így tisztábban láthatod, hogy érdemes-e folytatni a projektet, előbb felmérni a jelenlegi állapotát, vagy más irányt választani. A cél, hogy ne csak legyen egy weboldalad, hanem tudd is kezelni.
A visszatérő homályosság beszédesebb, mint egyetlen kellemetlen pillanat. Egy fejlesztő lehet fáradt, félreérthet egy kérdést, vagy késhet egy válasszal. Inkább azt figyeld, hogy az egyeztetések után tisztábban látod-e a célt, a feladatokat és a következő lépést. Ha újra meg újra csak annyit hallasz, hogy „majd megoldjuk”, abból nehéz tervezned.
A határozott szakmai válasz önmagában nem gyanús. Jó jel, ha a fejlesztő elmagyarázza, miért javasol egy megoldást, és azt is megmondja, milyen feltételezésből indul ki. Más a helyzet, ha még nem ismeri a vállalkozásodat, de már kész csomagot, oldalszerkezetet és funkciólistát kínál. A magabiztosság nem helyettesíti az igényfelmérést.
Egy használható ajánlat előtt legalább az alapokat érdemes tisztázni. Beszéljétek át, hogy:
Ezekből lesznek a valódi döntések. Ha egy pékség célja, hogy a vásárlók megtalálják a nyitvatartást és tortát rendeljenek, más tartalmi sorrend és funkció kell, mint egy B2B tanácsadónál. Utóbbinál a látogató hosszabb szakmai bemutatkozás és konzultációs lehetőség alapján dönthet. A cél tehát nem díszítőelem a megbeszélés elején, hanem az alapja annak, hogy mi kerüljön az oldalra.
A sablonos ajánlat ettől még nem feltétlenül rossz, de önmagában nem bizonyítja, hogy a fejlesztő megértette az igényedet. Kérdezd meg, melyik javaslat hogyan kapcsolódik a célodhoz, és miért. Ha konkrét választ kapsz, van miről tovább beszélni. Ha minden vállalkozás ugyanazt a kész megoldást kapja, az igényfelmérés valószínűleg kimaradt.
A portfóliót ne csak szemre nézd. Kérdezd meg magadtól, milyen feladatot oldott meg az adott oldal, és pontosan mi volt a fejlesztő szerepe benne. A látványos arculat mögött dolgozhatott más tervező, a fejlesztő pedig lehet, hogy csak egy részfeladatot végzett. Egy képernyőkép ezt nem árulja el.
A látványos portfólió azt mutatja meg, hogy készültek mutatós oldalak, de önmagában nem bizonyítja, hogy a fejlesztő a te üzleti célodat is érti. Nézd meg azt is, tud-e érthetően beszélni az adott munka feladatáról, nem csak a színeket és a betűtípusokat sorolja.
Az első válasz késése még nem feltétlenül gond. A tartósan követhetetlen kommunikáció már más: nem tudod, mikor várhatsz választ, ki kezeli a kérésedet, vagy mi történik a következő lépésben. A rendezett munka alapja a tiszta egyeztetés és a követhető feladatlista. Figyeld, hogy az első beszélgetések után könnyebb-e döntened, vagy csak több lett a megválaszolatlan kérdés.
A projekt akkor válik nehezen követhetővé, ha nem tudod, pontosan mi készül el, ki adja át a szükséges tartalmakat, és hogyan születnek meg a döntések. Nem kell hozzá bonyolult adminisztráció. Arra van szükség, hogy mindkét fél értse, mi a következő feladat, ki felel érte, és mikor kell visszajelezni.
A specifikáció a megbeszélt funkciók és elvárások írásos leírása. Rögzítheti például, milyen oldalrészek készülnek, mit tudjon az ajánlatkérő űrlap, vagy hogyan működjön a webáruházi vásárlás. Nem kell fejlesztői nyelven megírni. Akkor hasznos, ha később vissza lehet nézni, mi volt az eredeti megállapodás.
Én azt javaslom, hogy legalább a fő feladatokat, felelősöket és átadási pontokat rögzítsd írásban. Egy rövid levél vagy közös feladatlista is megfelel, ha abból kiderül:
A változtatás önmagában nem rossz jel. A projekt közben kiderülhet, hogy új funkcióra van szükséged. Például az egyszerű kapcsolatfelvételi űrlap helyett időpontfoglalást szeretnél. Ez hatással lehet a korábbi feladatokra, az elkészítés sorrendjére vagy a megbeszélt átadásra. Ilyenkor a fejlesztőnek érdemes elmondania, mit változtat ezeken, és rögzítenie az új megállapodást.
A kockázat ott kezdődik, amikor a vállalások magyarázat nélkül változnak, vagy utólag derül ki, hogy egy korábban megbeszélt funkció mégsem része a munkának. A rugalmasság azt jelenti, hogy lehet módosítani, és minden érintett érti a következményeket. A követhetetlenség azt jelenti, hogy már senki sem tudja, melyik változat az érvényes.
Figyeld, maradnak-e megválaszolatlanul olyan döntési kérdések, amelyek nélkül nem lehet továbblépni. Ugyanígy árulkodó a gazdátlan feladat: mindenki azt hiszi, hogy a másik küldi el a szöveget, ellenőrzi a gombot vagy hagyja jóvá az oldaltervet. Egy egyszerű státuszjelzés tisztázhatja, mi készült el, mi vár döntésre, ki lép következőként, és mi akadályozza a haladást.
„A következő feladat és a felelős mindig legyen egyértelmű.” Ezt érdemes észben tartanod, amikor a projekt állapotáról kérdezel. A jó munkamenet nem attól jó, hogy minden nap hosszú beszámolót kapsz, hanem attól, hogy érted, mi történik és mit kell tenned.
A technikai részletekről is kérhetsz érthető magyarázatot. Nem kell minden részletet szakértőként ellenőrizned. Azt viszont elvárhatod, hogy a fejlesztő el tudja mondani, miért fontos egy döntés a te oldalad működése szempontjából. A rossz webfejlesztő jelei közé tartozik, ha a kérdéseidre rendszeresen csak homályos ígéret érkezik, konkrét következő lépés nélkül.
Az átadáskor ne csak azt nézd meg, hogy elkészült-e az oldal, hanem próbáld ki, el tudja-e végezni rajta a látogató azt, amiért érkezett. Kérj hozzáférést az adminisztrációs felülethez, és győződj meg róla, hogy el tudod végezni a gyakori tartalmi módosításokat, vagy tudod, kitől kérhetsz segítséget. Ezt fejlesztői tudás nélkül is ellenőrizheted.
Indulj a látogató fő feladatából. Ha ajánlatkéréseket vársz, töltsd ki az űrlapot úgy, ahogy egy érdeklődő tenné. Ha webáruházad van, próbáld végig a vásárlás fő lépéseit. Ne állj meg az első gombnál. Nézd meg, ad-e visszajelzést az oldal, mi történik az elküldés után, és érthető-e, hogyan lép tovább a látogató.
Végezd el ugyanezt telefonon és számítógépen is. Telefonon ellenőrizd, olvasható-e a szöveg, könnyű-e megnyomni a gombokat, és nem kell-e oldalra húznod a képernyőt. Az űrlapnál próbáld ki, mi történik, ha egy szükséges mezőt üresen hagysz. A hibaüzenetnek meg kell mutatnia, mit javíts, az elküldés utáni visszajelzésnek pedig azt, hogy az üzenet továbbment.
Ha hibát találsz, az önmagában nem bizonyítja, hogy a fejlesztő rosszhiszeműen dolgozott. A reakciója viszont sokat elárul. Megérti a problémát, megmondja, mi a következő lépés, és visszajelez a javításról? Vagy a jelzésed válasz nélkül marad, és neked kell újra meg újra utánamenned? A rossz webfejlesztő jelei között a visszatérő elhárítás beszédesebb, mint egyetlen hiba.
Az átadáskor tisztázd, milyen fiókokhoz és adminisztrációs felületekhez férsz hozzá. Kérj rövid útmutatást az olyan hétköznapi feladatokhoz, mint egy szöveg frissítése, egy kép cseréje vagy egy új bejegyzés közzététele. Azt is rögzítsd, kihez fordulhatsz, ha később hibát tapasztalsz, vagy új funkciót szeretnél.
Több ügyfelem oldalát úgy vettem át karbantartásra, hogy nem én fejlesztettem. Ilyenkor az egyik első lépés, hogy végignézem a fizetős bővítményeket: mire valók, kinek a nevén futnak, és kell-e még mindegyik. A Marketing Amazing oldalainál több olyan prémium bővítményt találtam, amit vagy ki tudtam váltani a saját ügynökségi licencemmel, vagy egy egyszerű kódrészlettel. Így ezekért a licencekért az ügyfélnek már nem kell külön fizetnie. Ezért kérd el az átadáskor a hozzáférések és licencek listáját is: melyik fiók és melyik bővítmény kinek a nevén van, és mikor jár le.
Ha nem világos, milyen állapotban van a kész oldal vagy az átadás, a weboldal-audit segít módszeresen feltárni, mit érdemes ellenőrizni technikai, használhatósági és üzleti szempontból. Így a „valami nem stimmel” érzés helyett konkrét megfigyelések alapján tudsz dönteni a következő lépésről.
Egyetlen csúszás vagy félreértés miatt nem kell rögtön megszakítanod a projektet. Előbb nézd meg, mi történt, kérj tisztázást, majd figyeld meg, hogyan kezeli a fejlesztő a helyzetet. Én a döntést nem egy rossz napra, hanem az ismétlődő mintákra alapoznám.
Ha bizonytalan vagy, gyűjtsd össze tényszerűen, mi készült el, mi maradt nyitva, milyen vállalás hangzott el, és mikor történt az egyeztetés. Ne minősítéseket írj, hanem ellenőrizhető tényeket. Például: „A megbeszélt űrlap még nem működik, és a korábbi üzenetemre nem kaptam választ.” Így könnyebb konkrét megoldást kérned, és később is látod, egyszeri esetről vagy visszatérő problémáról van-e szó.
Egy javítható félreértésnél a fejlesztő reagál a jelzésedre, pontosítja a megállapodást, és követhetően halad tovább. Ha viszont rendszeresen változik, hogy mi készül el, elmaradnak a vállalt visszajelzések, vagy neked kell újra és újra kiderítened, hol tart a munka, az már komolyabb figyelmeztetés. A rossz webfejlesztő jelei nem egyetlen kellemetlen helyzetből állnak össze, hanem abból, hogy a problémák ismétlődnek, és nincs látható javulás.
Kérj rövid, írásos állapotjelentést. Derüljön ki belőle, mi készült el, mi van még hátra, melyik feladat vár döntésre, és mi a következő mérföldkő. A mérföldkő egy jól meghatározható köztes állomás, például egy oldalrész bemutatása vagy egy funkció kipróbálható változata. Ne elégedj meg annyival, hogy „hamarosan kész”. Kérdezz rá arra is, kell-e valamit átadnod vagy jóváhagynod.
Ha a válasz tisztázza a helyzetet, és a vállalások utána tarthatók, lehet, hogy egyszerű fennakadás történt. Ha a dátumok és a magyarázatok újra meg újra változnak, kezeld ezt visszatérő mintaként. Nincs minden projektre érvényes automatikus megoldás. A következő lépés attól függ, mi készült el, milyen hozzáféréseid vannak, és pontosan mi akadályozza a folytatást.
Ha nem világos, hogy működési hiba, hozzáféréshiány vagy gyengén teljesítő felhasználói útvonal okozza-e a gondot, kérj szakmai állapotfelmérést, mielőtt a folytatásról vagy a váltásról döntesz. Egy weboldal-audit segít konkrét kérdések mentén áttekinteni a technikai működést, a felhasználói élményt és a konverziós szempontokat. Az eredmény nem automatikus bizonyíték arra, hogy a fejlesztő hibázott. Tisztább képet adhat arról, mi működik, mi szorul javításra, és milyen következő lépés indokolt.
Jó együttműködés tisztázott üzleti céllal indul, majd érthető feladatokon és rendszeres visszajelzéseken keresztül halad. Nem kell minden technikai részletet ismerned. Azt viszont érdemes látnod, miért készül egy-egy funkció, hogyan kapcsolódik a célodhoz, és mi lesz a következő megvalósítható lépés.
Más feladatot kap egy weboldal, ha több érdeklődőt szeretnél, ha az értékesítési folyamatot akarod támogatni, vagy ha a sok kézi ügyintézésből vennél le valamennyit. Egy szolgáltatónál az ajánlatkérés megkönnyítése lehet a kiindulópont, egy webáruháznál pedig a vásárlási folyamat átláthatóbbá tétele. A cél nem ígéret egy bizonyos eredményre, hanem iránytű a döntésekhez.
Egy nagy projektet érdemes kisebb, megvalósítható részekre bontani. Először tisztázd, kinek szól az oldal és mit kell tudnia a látogatónak. Utána következhetnek a fő oldalak, majd a szükséges funkciók és azok kipróbálása. Így hamarabb kiderülhet, ha egy elképzelés pontosításra szorul, és nem kell minden döntést egyszerre meghoznod.
Az átláthatóság nem egy vaskos dokumentumon múlik. A feladatokból derüljön ki, mi készül el, a döntési pontoknál tudd, mikor kell választ adnod, a visszajelzésekből pedig lásd, mi haladt előre és mi vár még rád. Ez mindkét félnek kapaszkodót ad, különösen akkor, ha a projekt menet közben változik.
Az alábbi különbségek segítenek felismerni, hogy az együttműködésben van-e elég fogódzó:
| Kockázatos jel | Átláthatóbb működés |
|---|---|
| „Minden megoldható” ígéret, tisztázott feladat nélkül | Rögzített feladat, érthető elvárással |
| Nem derül ki, ki adja át vagy hagyja jóvá az anyagokat | A felelős és a döntési pont előre tisztázott |
| Visszajelzés nélkül változik a munka állapota | Rendszeres, rövid tájékoztatás a következő lépésről |
| Új igény kerül be, de a következménye homályos | A módosítás hatását átbeszélitek és rögzítitek |
Én egyéni szakemberként vezetem a projekteket, szükség esetén alvállalkozók bevonásával. A munkámban az üzleti célból indulok ki, és kezelhető lépésekre bontom a feladatokat. Több mint 50 ügyfél weboldalát kezelem és tartom karban. Ez tapasztalatot jelent különböző weboldalak működtetésében, nem ígéret előre meghatározott üzleti eredményre. A rossz webfejlesztő jelei helyett azt keresd, hogy a cél, a feladat és a következő döntés végig érthető marad-e.
Ha még hezitálsz, nem kell ma eldöntened, hogy folytatod-e a munkát vagy lezárod az együttműködést. Először fogalmazd meg, mi az az egy kérdés, amelyre válasz nélkül nem tudsz nyugodtan továbblépni. Lehet, hogy a készülő oldal állapotát szeretnéd megérteni, vagy azt, melyik feladatot érdemes előrevenni. Egy jól körülhatárolt kérdés általában többet ér, mint egy újabb hosszú levelezés arról, hogy „valami nem stimmel”.
A rossz webfejlesztő jelei nem arra valók, hogy minden hibánál azonnal ajtót csapj. Arra valók, hogy ne söpörd félre azt, ami újra és újra bizonytalanná teszi a projektet. Én azt javaslom, a következő döntésedet arra alapozd, amit tényszerűen látsz, ne arra, amit remélsz vagy amitől tartasz. Így akkor is visszaszerzed az irányítást, ha a folytatás mellett döntesz, és akkor is, ha más utat választasz. A tisztább kiindulópont már önmagában előrelépés.
Foglalj díjmentes konzultációt
Hasonlítsd össze a kész munkát azzal, amiben korábban megállapodtatok. Ha egy funkció másként működik, mint ahogy rögzítettétek, konkrét eltérésről beszélhetsz. Ha a feladat még nincs kész, de érthető magyarázatot és követhető új vállalást kapsz, lehet, hogy egyszeri csúszás történt. Jegyezd fel a dátumokat, a megbeszélt elvárást és a tényleges állapotot, így nem csak benyomás alapján döntesz.
Küldj egy rövid, tárgyszerű üzenetet, amelyben összegyűjtöd a nyitott kérdéseket, és kéred a projekt aktuális állapotát. Írd le, melyik döntés vagy információ hiányzik tőled, és kérdezd meg, mi a következő lépés. Ne küldj több külön üzenetet ugyanarról, attól nem lesz tisztább a helyzet. Ha továbbra sem kapsz választ, őrizd meg az egyeztetéseket, és mérlegeld a folyamat egészét.
Kérdezd meg, hogyan indul a munka, milyen adatokat vagy anyagokat vár tőled, és mikor kell majd döntéseket hoznod. Tisztázd azt is, milyen formában kapod meg az elkészült oldalt, hogyan próbálhatod ki a funkciókat, és mi történik, ha menet közben új igényed merül fel. Kérj példát arra, hogyan bontana kisebb feladatokra egy konkrét célodat. A válaszokból kiderül, mennyire érti a vállalkozásod működését.
Nem, a portfólió önmagában kevés. Segít megismerni a korábbi munkák megjelenését, de nem feltétlenül derül ki belőle, milyen feladatot oldottak meg, pontosan mi volt a fejlesztő szerepe, vagy hogyan működik az oldal a mindennapokban. Válassz ki egy bemutatott példát, és kérdezz rá a mögötte álló célra. Azt is nézd meg, tud-e a szakember közérthetően beszélni a döntéseiről, nem csak a látványról.
Ezt ne hagyd találgatásra: nézd meg, mit rögzít az írásos megállapodás a weboldalról, a hozzáférésekről és az átadásról. Tisztázd, milyen fiókokat tudsz saját néven kezelni, ki fér hozzá az adminisztrációs felülethez, és milyen módon kapod meg a szükséges belépési adatokat. A pontos jogi helyzet a megállapodástól és az adott körülményektől függ, ezért kétség esetén kérj jogi szakértőtől tanácsot.
Akkor mérlegeld az együttműködés lezárását, ha az ismételt tisztázási kérések után sem kapsz követhető választ, a vállalások rendszeresen változnak, vagy nem férsz hozzá a projekt állapotának megítéléséhez szükséges információkhoz. Előtte gyűjtsd össze, mi készült el, milyen hozzáféréseid vannak, és mely feladatok maradtak nyitva. A rossz webfejlesztő jelei nem egyetlen hibából állnak össze, hanem abból, ha a problémák visszatérnek és nem rendeződnek.
Próbáld ki az oldal legfontosabb feladatait úgy, mintha először járnál ott. Küldj tesztüzenetet, nézd meg, megérkezik-e a visszajelzés, majd ellenőrizd a menüpontokat és a fontos oldalak közötti továbblépést. Webáruháznál figyeld meg, érthető-e a kosár és a rendelés állapota. Mentsd el a hozzáféréseket biztonságos helyre, és jegyezd fel, melyik fiók mire szolgál, hogy később is tudd, hol intézd a módosításokat.
„Olyan érzés volt, hogy nem egyedül dolgozom az oldalamon, hanem ketten együtt, két tulajdonos gondolkodik...
...abban, hogyan lehetne ezt az üzletet a legjobban beindítani, hogyan lehet ezt az oldalt a legjobban összerakni."
„Az ügyfeleink a legfontosabbak számunkra. Ezért dolgozunk a legjobbakkal...
...és ezért bízzuk a weboldalaikat Rád.'
'Webfejlesztő sok van, Rudiból csak egy.
Szerencsések vagyunk, hogy a vele való munka során olyan szakemberre bízhatjuk magunkat és az ügyfeleinket, aki ugyanúgy a tökéletes végeredményre törekszik, mint mi."
"Rudi az, akit vállalkozóként webes "kollégának" álmodtam magamnak.
Megvalósítja azt, amiről még nem is tudom, hogy szükségem lesz rá. Mindig ott van, amikor szükségem van rá. Az első pillanattól kezdve érzem, hogy egy csapat vagyunk. Imádom!"
