Egy módszer weblapok specifikálására
Amikor szóba kerül a specifikáció készítés fontossága, mindig felteszi valaki a kérdést, mit is kell tartalmaznia, hogyan is kell megírni egy ilyen dokumentumot. Lentebb szeretném bemutatni az elmúlt években kialakított gyakorlatomat, hogy én hogyan írom meg egy weblap-fejlesztési projekt specifikációját.
Először is szögezzük le, hogy a specifikáció feladata, elmagyarázni a megrendelőnek, mit kap majd a pénzéért, ugyanakkor egyértelműen meghatározza a fejlesztés irányát is.
A végeredményt általában három nagyobb szakaszra lehet bontani:
- célok, jelen helyzet felmérése
- használt eszközök, a leendő oldal funkcióinak meghatározása
- technikai részletek
Célok, jelen helyzet felmérése
Azt szokták mondani, hogy amelyik ötletet nem lehet egy A4 méretű papíron leírni, azt nem gondolták teljesen végig. Ezt a logikát követve a bemutató részt legfeljebb 3-4 bekezdésnyi (maximum fél oldal) szövegben szoktam megfogalmazni. Ez az a rész, ami leírja a cégvezetőknek, a marketingeseknek, lényegében minden érdeklődőnek, hogy miről fog szólni a projekt.
Ennek a szakasznak egy fejezete szól a helyzet felmérésről. Ha egy meglévő oldal átalakításáról szól a megbízás, akkor mindenképpen fel kell mérni a kiindulási állapotot. Itt le kell írni az ügyfél problémáit, mik azok a pontok, amik elavultak, amiktől megszabadulna. Szükséges ki kell emelni azokat a részeket, amelyek megtartását szeretné az ügyfél. Ezek a legtöbb esetben arculati elemek, színek szoktak lenni.
Használt eszközök, a leendő oldal funkcióinak meghatározása
A második szakasz már technikai részleteket is tartalmaz. Mire a specifikációt írja az ember, addigra eldől, hogy a megvalósításhoz egyedi fejlesztést, vagy valamelyik már kész, esetleg nyílt forrású megoldást fogja választani. Érdemes egy fejezetet szentelni a választás megindoklására, majd a választott eszközt pár mondatban bemutatni. Ki lehet térni arra is, hogy milyen lehetőségeket biztosít az alap szoftver, modulokkal milyen irányba bővíthető.
A következő fejezet szóljon az ügyféllel egyeztetett, és az ezen felül szükséges funkciókról. Mindegyik funkció mellett legyen egy kisebb leírás, melyből kiderül, miért van rá szükség, mit fog csinálni.
Az egyedi fejlesztésekről szóló részben ne csak az egyedileg fejlesztett modulokra, programrészekre gondoljunk, hanem itt írjuk le a megjelenést is. Itt kell hivatkozni a drótvázra (wireframe), bemutatni az oldal felépítését, az arculati elemeket. Ha elkészült, részletesen be lehet mutatni a teljes weboldal tervet is.
Technikai részletek
A harmadik fő szakasz már kifejezetten technikai részleteket tartalmaz. Milyen programozási nyelveken történik a megvalósítás, milyen technikai előfeltételeknek kell teljesülniük a tárhelyen.
Tapasztalatom szerint ebben a szakaszban mindenképp ki kell térni néhány, számunkra egyértelmű fogalom magyarázatára. Magyarázzuk el az olvasónak, mire szolgál a HTML, mire a CSS, mire a JavaScript! Mi az, amit csak szerver oldalon lehet megvalósítani, mire szolgál az adatbázis. A hozzáértők át fogják ugrani ezt a részt, azonban a megrendelők nagyon hálásak tudnak lenni, ha a későbbiekben nem lesz teljesen kínai, amikről beszélünk.
A működési leírás megírása a legnehezebb feladat. A bonyolultabb, több lépésből álló részeket érdemes egy-egy folyamat ábrán is megjeleníteni, segíti a megértést. A legfontosabb, hogy mindent el kell magyarázni az olvasónak. Milyen adatokat kezel az oldal, ezek milyen összefüggésben állnak egymással. Mi történik ha a felhasználó hibás adatokkal tölt ki egy űrlapot, vagy hiba jelentkezik a feldolgozáskor. Milyen mezőket tartalmaznak az űrlapok, milyen adat összefüggéseket fog ellenőrizni a program.
Összefoglalva
A specifikációban megpróbálok az általánosságoktól indulva, egy átfogó képet adni a jövendő oldal működéséről. Ugyanakkor megmutatom a háttérben húzódó logikát és technológiai hátteret is. A dokumentum írása közben végiggondolom a feladatokat, felmérem azok bonyolultságát, mennyi időt kell rászánni egy-egy rész-feladat megoldására. A fogalmazáskor próbálok közérthetően fogalmazni, az új kifejezéseket a lehető legrészletesebben megmagyarázni.
Ez a gyakorlat nekem bevált. Ti hogy írtok meg egy specifikációt?
■
Nagyon jó!
Nem ertek vele egyet. A
A specifikacio mibenleterol anno nagyon jo konyvet irtak, a Web Style Guide-ot (www.webstyleguide.com, letoltheto ingye'), es sokminden masrol is szol a dolog.
Odaig egyetertunk, hogy celok meghatarozasa, meg allapotfelmeres.
A specifikacio a celok meghatarozasa utan mindig a celkozonsegek meghatarozasaval kell, hogy foglalkozzon.
Ugyanis nehez ervelni celkozonsegek nelkul, ill. lehet, csak esetleg sz.r lesz a honlap. Raadasul egy honlap informacios medium, nem csak funkcionalitasai vannak.
Lehet egyszer osszefoglalom, de jelenleg hosszu lenne :)
Kérdés, hogy mire?
információ forrás
A célközönséget nem nekem kell meghatározni. Ez a megrendelő feladata. Ahogy a weboldalon megjelenített tartalmak megírása is. Én legfeljebb segíthetek benne, hogy milyen szövegeket jelenítsen meg, megpróbálhatom lebeszélni rossz ötletekről, elavult megvalósításokról.
Direkt kihagytam a navigáció leírását, ugyanis nagyon kivételes az az eset, amikor az ügyfélnek pontos elképzelése van erről. Minden egyéb esetben a tartalomszervezési kérdések megoldásával napok telnek el.
Ezeket a dolgokat (célközönség, megjelenített információk köre), szerintem csak abban az esetben kell belevenni a specifikációba, ha a megbízás marketing feladatokra is kiterjed. Bár ilyenkor kérdéses, hogy elég-e egyáltalán 1 db, a weboldalról szóló specifikáció
Nem tudom, en ahany
Ha webalkalmazas-specifikacio volt, az ugy indult, hogy felirtuk az aktorokat es a use case-eket, tehat egy hasonlo jellegu felosztas mindig van.
Hogy mennyire jatszunk egy ligaban, nem tudom, en a 'weblap' szonal leragadtam, a weblap szamomra informacios medium, nehany interaktiv szolgaltatassal esetleg :)
A tartalomszervezes a celkozonsegekbol indul, meg az un. inventoriumbol, azaz, hogy mi van meg, ill. mit mennyi ido osszerakni, es foleg: mennyire fenntarthato, vagy cel a fenntarthatosag (pl. jo-e ha csak a honlap keszulteig elkeszult referenciamunkak vannak fent, vagy lesz aki feltoltse, esetleg integralhato massal)
A technologia platform kotottsegevel se ertek egyet, a specifikacio arrol szol szamomra, hogy mit akarunk megvalositani funkcionalitast, majd ehhez utana vadasszuk le a megfelelo szoftvert, es/vagy szabjuk testre az[oka]t.
Persze jol tudom, a legtobb webes ceg drupalban utazik, es gyakran ugyis keresik meg oket, hogy kene egy drupal alapu weboldal. De ettol meg a kalapaccsal mindent szognek latunk latasmod nem feltetlenul kifizetodo.
Egy picit az az erzesem, hogy ezzel a forgatokonyvvel egy picit a megrendelo is koti az ebet a karohoz (o mondja meg a celkozonseget, meg a tartalmat), meg a fejleszto is (a platform adott), es kevesbe kooperativak, mindenkinek maga dolga.
Lehet, nem azt mondom, hogy nem mukodik, de felek tole, hogy lehetnek belole nagyobb veszekedesek is.
Az eddigi kommentek alapján ...
Magam azt gondolom, hogy ideális esetben egy honlap/WEB-es rendszer készítésére csak akkor szabad szerződni, ha van arra lehetőség, hogy akár több héten keresztül is tárgyalások follyanak a megrendelővel, hogy mit csinál a cég, stb.
Mert én úgy gondolom, hogy a honlap éppen olyan eszköz, mint a bolthelyiség, a cég tevékenységének és legfőképpen a marketingjének szerves része kell, hogy legyen. Ebből következően pedig a tényleges programozói munka már csak a végső fázis, addig eljutni, na az az igazi kihívás.
Persze vannak olyan esetek, hogy kell egy honlap 3 hét alatt, ki is lehet vitelezni, de ez részemről nem honlapkészítés, hanem bérprogramozás, a megrendelő kérésének és nem valós üzelti érdekeinek a kiszolgálása.
Nem tudom érezhető-e a két dolog között a különbség. Én az előbbi megoldásban hiszek és akik ilyen munkamódszer alapján képesek kivitelezővel együttműködni, na ők fognak olyan WEB-es megjelenéssel bírni, amivel a vállakozás valóban nyer és nem csak egy N+1-edig WEB-es munkát adnak át nekik.
Valami
Pedig ha tudnák, hogy mennyire sikeres ez a módszer! Egy pár éve leültünk a bátyámmal, mondván hogy kell neki valami honlap. Megnéztük a konkurenciát vevői szemmel, összeraktuk úgy, hogy a célközönségnek a lehető legjobban megfeleljen. Mára a sokszorosára nőtte ki magát a cég. Mi volt a titok nyitja? Egyrészt nem csak néhány photoshopolt mintaterméket raktunk ki, hanem a kurrens készletet fotóval, leírással, másrészt nem 62 mezős volt a "kapcsolat" form. Ennyi.
Usability
A slide megtekinthető itt: http://webgondolat.blog.hu/2010/09/10/a_usability_alapjai_prezentacio
A szöveges átirat röpke 14 oldalnyi, így értelemszerűen alkalmatlan egy-az-egyben történő publikálásra, de lesz belőle emészthető cikk(sorozat) hamarosan.
re:Usability (kicsit off)
az eloadas vegen mint egyik
ez alapjan en ugy gondolom, hogy nem azt a konyvet fogja egy az egyben lekovetni az eloadas/cikksorozat.
Tyrael
re:Usability (kicsit off)
Az előadásban kicsit több volt az elméleti háttérről, az egyéb területekhez (pl. SEO) való kapcsolódásról, drótvázról, prototípusokról, split tesztelésről.
Természetesen nem mondom, hogy én találtam fel a spanyol viaszt, az elhangzott dolgok mind megtalálhatók valamilyen formában máshol is.
A célom az volt, hogy a kollégáknak egy átfogó betekintést nyújtsak a téma alapjaiba, ezért rendszereztem a dolgokat egy általam logikusnak tartott gondolatmenet szerint.
OFF: várom a cikket!
Csak egy része ...
Ez kb. az, amit a ma oly' divatos online marketingesek kkv online marketing irányelvnek (vagy hosonlónak) neveznek, hogy a cégnek olyat kell adni, ami a profiljába illik, amit ki is használnak, bla-bla. Ja, csak ehhez nem kell ez a marketing rizsa, mert egy bolthelyiség, vagy raktárbővítés szükségességét sem ilyen bullshit marketing alapján adnak el egy cégnek -- remélem. Hanem egy jó tanácsadó beköltözik a céghez, és megmondja, hogy mit kellene csinálni, hogy az adott helyzetnél jobban, sokkal jobban menjen a bolt.
Ezt kell csinálni WEB-es fronton is. Persze így nem lehet futószalagon honlapokat gyártani és intregrált WEB-es rendszereket, de nem is kell, mert az önmagában senkinek sem érdeke.
Amiről én beszélek az egyfajta tanácsadó és kivitelezői minőség egyben, kicsivel több, mint a "megbeszéljük mit akarnak és lefejlesztjük" és kicsivel másabb, mintha külön tanácsadót vennének igénybe és ehhez pluszban egy fejlesztő céget. Persze ez utóbbi is járhatónak látszik, de ott komoly kommunikáció protokollnak kell meglennie a felek között, amihez mindenki tartja magát -- itt várhatóan az ügyfél komm. módszertana a gyenge láncszem.
Tehát én azt gondolom, hogy ha egy cégnek WEB-es rendszereket tervezünk és kivitelezünk, akkor majd' olyan szinten bele kell ásnunk magunkat a cégbe, mint egy belső munkatárs. És a project kivitelezését követően szoros együttműködésnek kell lennie a továbbiakban is, mert egy IT rendszer sosincsen kész. Ahogyan a cég fejlődik, annak követnie kell, még akkor is ha "csak" egy honlapról beszélünk.
Szóval a belső (IT) munkatárs vagy a "külső fejlesztő + tanácsadó" megoldás helyett egy olyan kapcsolatban látom a siker kulcsát, ahol a külsős cég közel belsős munkatárs szintre tud felfejlődni.
Erre tudok személyes példát is, hogy egy, a mostani munkahelyemnek bedolgozó cég elég mélyen benne van a mi cégünk működésében, mert különben nem tudná csinálni a fejlesztéseket. Tehát jóval több már, mint egy egyszerű külsős fejlesztő cég, évek óta folyamatosan követi a cégünk változásait.
Az integrációra egy példa. Most tartunk ott, hogy az SAP adatai alapján egy automatizált megoldással tudjuk kitolni a honlapra a termékpalettát (hamarosan ezzel váltjuk fel a külön honlap adatbázisokat). A SAP-ban beállítanak egy flag-et, hogy a termék éppen nem forgalmazható, ekkor az üzletkötők rendszeréből (ami szintén kapcsolatban van az SAP-val; egy lightweight WEB-es frontend) eltűnik, majd a honlapról is. Ez mind egy kattintással a belső munkatárs által, semmi IT-s beavatkozás, külön admin felület az egyes frontend rendszereknek. Na kb. ez az az integráció, ami érdeke egy cégnek, amit meg kell valósítani egy tanácsadó + kivitelező csapatnak. De ezt nem lehet egy három hetes gyorshonlap projectben megoldani. Ehhez ismeri kell a cég belső (sok esetben nem teljesen logikus) folyamatait.
Ez a fajta hozzáállás sok mindent kíván meg mindkét féltől, de ez kell ahhoz, hogy a megrendelő valóban azt érje el, amit akar, vagy ha ő nem is látja, hogy neki ez kell, akkor a kivitelezőnek/tanácsadónak kell ilyen irányba terelnie.
Mert végső soron mindenki azt szeretné, hogy egy jobb minőségű, profitábilisabb, termelékenyebb vállakozás legyen az egész proejct eredmnye, ami tágabbról nézve sokat hoz a közvetlen környezetének (város, kisebb vonzáskörzet) és összeségében az országnak.
támpont
Ami nem volt tárgya a bejegyzésnek (és talán nem is baj, hogy kimaradt, mert nagyon el lehet úszni vele), az a kommunikáció, ami megelőzi a specifikációt, illetve aminek később is nagy lesz a jelentősége.
Nekem az a tapasztalatom, hogy érdemes úgy megírni egy specifikációt, hogy az legalább később biztosítsa azt, hogy a megrendelő ne akarjon "csak még egy pici változtatás"-t (ismerős vicc: - Elnézést, egy csepp benzin ingyen van? - Igen! - Akkor csepegtesse tele a tankot legyen kedves!), hogy lehessen belőle normális fejlesztési ütemtervet csinálni, meg hogy úgy általában is: egyik résztvevő se ússzon el a fejlesztésben túlságosan.
Az, hogy ezen felül még mit kell tartalmazzon egy specifikáció, nagyon sokban függ a megrendelőtől is (magánszemély, kis cég, nagy cég, megbízó/kapcsolattartó hajlandósága a szakmai javaslatok befogadására stb...). Ezeket a dolgokat viszont ügyesen ki lehet - és ki kell - tapogatni a specifikációt megelőző megbeszéléseken. Specifikálni mindig kell a feladatot, akkor is ha matt unalom és több napos macera. És mivel a specifikáció is a munka része, természetesen ki kell fizettetni az ügyféllel: meg kell határozni előre, hogy mennyi idő van az egyeztetésekre és specifikálásra, mert ezen a ponton is el lehet úszni, és ha adott időkeret van az oldal elkészítésére (ez a gyakoribb), akkor nem lehet a specifikálás a projekt idejének 80%-a. Ez teljesen egyéni dolog, de szerintem a projekt tervezett idejének kb 1/4-1/5 részét érdemes a specifikálásra és egyeztetésekre ráfordítani. Az ennél kevesebb általában elégtelen, az ennél több pedig már azt az időt veszi el a fejlesztéstől, amit egyébként a specifikáció maga "lerövidít".
Akit untat a specifikálás, alakítson ki sablont rá. Azt is megjegyezném, nem árt, ha a specifikációnak arculata is van. Tapasztalatom szerint az ügyfelek szívesebben nyálaznak át N × 10 oldalt ha a fejlécben a termékük/cégük logója is szerepel. Ha a specifikációt informálisabbra akarjuk csinálni, érdemes a dizájn terveket (a mockup erre a divatos szóhasználat?) külön fejezetbe tenni és csak hivatkozni rájuk a folyó szövegben - így nem ragad le az olvasó a folyószöveg közti képeken - persze ez is lehet ügyfél függő. A technikai specifikációban mindenképp ki kell térni a lehető legpontosabban a kiszolgáló szoftveroldali specifikációjára, mert általában ebből adódnak félreértések. Ha nagyon kliensoldali lesz a termék, akkor kliens oldali minimális hardver igény és felbontás is szerepeljen itt, mert ennek hiányából is adódhatnak félreértések.
Usability előadás
A korábbi commentekben proclub által említett usability előadást újra meg fogom tartani 2011. január 4-én a Docler Akadémia keretén belül.
A kezdés időpontja: 18:30
A helyszín: Docler Irodaház, 1101 Bp., Albertirsai út 3-11.
Az előadás nyilvános, és mindenki számára ingyenes.
További infót hamarosan itt találhattok majd: http://www.facebook.com/doclerakademia