Menü

Mindenki tudja, hogy kéne, mégsem csinálja. Mi az?

Valljuk be, az emberek többsége nem szereti az időigényes, nagy alaposságot kívánó feladatokat, pedig bizony az ördög a részletekben lakozik és sokszor ezek miatt bukhatjuk el a várt sikert. Ilyen a specifikáció írás is, amit általában azért hagy ki a többség, mert látszólag időt spórolnak vele. Rossz kezdés. Fontos kiemelni, hogy kihagyni a specifikáció írását a létező legnagyobb kockázatvállalás, amit egy projektben tehetsz. Gondolj csak bele: ha házat építesz/építtetsz, akkor is a tervezés az első lépés. Biztosan nem költöznél olyan házba, amit a mérnökök nem rajzoltak le, nem nézte meg statikus és nem lett körültekintően kivitelezve. Persze egy weblap vagy design projekt nem omlik rád, ha nincs elég jól előkészítve és elkészítve, de az üzleted könnyen csődbe juthat! A specifikáció megírása tartalmazza ugyanis mindazokat az irányelveket és pontokat, amik alapján akik dolgoznak rajta, tudni fogják, mikor milyen stádium következik. Ezeket persze nagy valószínűséggel amúgy is tudnák, de ugye te is tisztában vagy vele hogy készül a húsleves, ám egy fárasztó nap végén lehet, hogy mégis lemarad valami fontos a bevásárlólistáról. Egy akár több hónapos projekttel még könnyeben előfordulhat, vagyis ahhoz, hogy (maradjunk a webes példánál) a fejlesztők jó kódokkal dolgozzanak, így jól funkcionáljon a honlapod, megfelelő legyen a felhasználói élmény, minden aloldal a helyén legyen és a design is stimmeljen, alaposan és rettentő precízen kell megtervezni a folyamatokat, megírni a specifikációt. Ez ugyanolyan fontos akkor is, ha egyedül dolgozol valamin, mint egy több szereplős projekt esetében, hiszen segíti a kommunikációt. Ha egyedül vagy egyszerűbben megérted a feladatot, ha pedig csapatban dolgoztok, segíti a kooperációt. Ha nincs specifikációd, akkor mindez a kommunikáció - hiszen kell - megtörténik, de ad-hoc jelleggel. Az előzetes egyeztetés helyett kérdések miatt akadhat meg a munka. Azon kívül, hogy ez a programozók hatékonyságának rovására is megy, a programozó azt válaszolja, amit ő a kódba beleírt, és nem feltétlenül a "jó választ". Így aztán a program úgy fog működni ahogy, nem pedig úgy, ahogy azt megtervezték. Funkcionálni fog, de további problémákat generál.

specifikáció írás

Ezzel el is értünk a vélt időgazdálkodás kérdéséhez. Mivel a megrendelő nem azt, vagy nem teljesen azt fogja kapni, amit várt, jöhetnek a javítások. Azt az időt, amit látszólag megspóroltál a specifikáció kihagyásával, itt stresszel kísérve töltöd el. Kell ez neked? Ugye, hogy nem. Mivel az ügyfeled fizet, joggal várja el, hogy a végeredmény az elképzelései szerint valósuljon meg, így biztosan addig fog a nyakadra járni, amíg ez meg nem történik, így a néhány hetes/1-2 hónapos projekt akár egy évre is rúghat. Előzd ezt meg az időben történő állapotfelméréssel és specifikáció írással. A következő fontos ok a specifikáció készítésére, hogy nélküle nincs ütemterv. A timing hiánya nem jelent problémát, ha kutatóként évekig szeretnél egy témán dolgozni, de a valódi üzleti életben szinte minden esetben muszáj tudnod, hogy mennyi ideig tart mondjuk a fejlesztés, mivel ez időalapon kerül pénzbe. Ezek a gondolatok valószínűleg eddig is ott voltak a fejedben, de akkor miért nem készítesz minden projekthez specifikációt? Valószínűleg azért, mert írni nem könnyű, de hidd el nekem, hogy kis gyakorlással bele lehet jönni.

Nézzük hát, hogy néz ki egy követelménykatalógus:

Alapvetően két fajta specifikáció típust különböztetünk meg: 1: Funkcionális: leírja a termék működését a felhasználó szemszögéből. Nem foglalkozik azzal, hogyan lesz ez megoldva, a tulajdonságokról beszél. Menüket, képernyőket, ablakokat határoz meg. 2: Technikai: bemutatja a konkrét megvalósítást. Adatstruktúrákról beszél, relációs adatbázis modellekről, a programnyelvek és eszközök és algoritmusok között választ. Terméke válogatja, hogy mikor melyikre, esetleg mindkettőre szükség van-e, így nehéz általánosan nézni a problémát, úgyhogy vázlatos how to helyett az alábbiakban adunk inkább néhány irányelvet, amit feltétlen érdemes követni a specifikáció írásánál:
  • A nem célok. Ha csapatban dolgoztok, jellemző lehet, hogy mindenki próbál a saját feje után menni. Ha ezt hagyod, akkor csomó időt és pénzt fogtok pazarolni. Ennek megakadlyozására a „Nem célok” kitűzése a legjobb módszer. A nem célok lehetnek például tulajdonságok, amiket nem akarsz (például „Nem fontos a teljesítmény. A 2. verzióban fogjuk optimalizálni a sebességet.”) Ezek a nem célok olyanok, amik vitákat okoznak, de pontosan ezért nagyon fontos olyan hamar kizárni őket, ahogy csak lehetséges.
  • Az áttekintés. Ez olyan, mint egy tartalomjegyzék a specifikációdhoz. Ez a legegyszerűbb út ahhoz, hogy legyen egy áttekintő képed az egészről, aztán a részleteket sokkal jobban megértsd.
  • Részletek!!! Menj bele a részletekbe. Annyira, amennyire csak képes vagy.
  • Nyitott problémák. Az rendben van, ha a specifikáció első változatában nyitott problémák maradnak, de ne hanyagold el őket. Éppen elég problémád lesz az új problémák megoldásakor, amik akkor jönnek elő, amikor a tényleges kivitelezés folyik, anélkül is, ha nincsenek régi nyitott problémáid. Gondolj a jövőre, és oldd meg őket.
  • Széljegyzetek. Amíg a specifikációt írod, emlékezz a különböző olvasóidra! Írás közben eszedbe juthatnak olyan dolgok, amik a munkatársak csak egy csoportját érdekelhetik. A hasznos, de nem mindenki számára releváns információkat így érdemes feltüntetni.
  • Változtatások. Sokak szerint a specifikációk használhatatlanok, mivel senki sem követi őket, ezért állandóan idejétmúltak és sosem tükrözik a kívánt igényeket. Nos, ez ellen könnyen lehet tenni, ha a specifikációt nem tekinted elkészültnek, hanem az egyes módosításokat is szorgalmasan lekönyveled.
Ha ezeket betartod, egy cél lebegjen még a szemed előtt, ez pedig a pontosság és minden rendben lesz. :)

Amennyiben szükséged lenne további tanácsokra, esetleg egy kis inspirációra vágysz, bátran csatlakozz az Online Marketing Inspirációk nevű csoportunkba!

blog