Vissza az összes cikkhez

A legnagyobb hiba, amit elkövethetünk fejlesztői brief írásakor

Fejlesztőknek szánt brief írásakor könnyen eshetünk abba a hibába, hogy marketing briefként gondolunk rájuk. Egy klasszikus marketing brief viszonylag sok kontextust ad a megbízócégről, hátteréről, ám a feladat felvázolásán és az ajánlat benyújtásához szükséges kritériumokon túl nagyon sok mindent a pályázó képzeletére bíz.

És ez sokszor így is van jól, hiszen a kreatív munka veszne el, ha már a brief megírásának pillanatában meglenne minden részlet. Ám egy fejlesztői brief esetében nagyon nem mindegy miről is beszélünk. Az apró részletek itt kulcsfontosságúak.

Mennyire kreatív feladat az üzletikövetelmény-specifikáció?

Ez persze nem azt jelenti, hogy a fejlesztői munka nem lehet kreatív, nagyon is az. Ám ezt a kreativitást már a fejlesztőcsapatokra kell bízni, akik a  leadott üzleti igények alapján át tudják gondolni merre induljanak a megvalósításban. A fix elképzelések alapján fel tudják állítani a legideálisabb technológiai kereteket, ki tudják találni, hogy az általuk szállított rendszeren az adott funkció hogyan tud jól, költséghatékonyan megvalósulni. (ez akár megkerülő megoldások felvetését is jelenti)
Az elnagyoltság, a konkrétumok hiánya tehát a legnagyobb baj, de hogyan eshetünk ebbe a csapdába bele túl könnyen?

"Csak egy pár új igényem van...a lényeg, hogy mindent tudjon, amit a jelenlegi weboldal. "

Ismerős mondat? Számoljunk le vele örökre!

Miért rossz megközelítés ez?

  1. A weboldalad vagy webshopod jó eséllyel sok olyan funkciót, külső integrációt tartalmaz, ami egyszerűen nem látszik kívülről az oldal egyszeri végignyomkodásával.
  2. Amennyiben az oldaladon már több fejlesztőcég is dolgozott az évek során, akkor arra kell készülnöd, hogy több olyan funkció van az adminban amit már nem is használsz. Mert az elődöd elődjének az elődje kérte, vagy egyszerűen már nem releváns.
  3. Ugyanígy, korosabb weboldalak esetén sok olyan funkció lehet, amely már nem szükséges. Egyszerűen azért, mert eljárt felette az idő, ma már máshogy kéne megoldani, vagy a jogszabályok változtak meg menet közben, ami még nem lett lekövetve.
  4. Ahhoz hogy árazható legyen így egy projekt részletes tesztnek kell alávetni, benézni a motorháztető alá, auditálni. Ez egy fejlesztőcégnek idő és pénz, vagy - ha nincs lehetősége átnézni a rendszert - akkor komoly kockázat, amit bizony be fog árazni (vagy rosszabb esetben egyszerűen nem is ad így ajánlatot)
  5. Összességében azt üzened ezzel a mondattal, hogy nincs kedved vagy időd foglalkozni a részletekkel, hogy átadnád az üzleti tervezés felelősséget és a fejlesztőnek. Ez hatalmas “red flag” a fejlesztők szemében, hiszen így nem bízhatnak a közreműködésedben a fejlesztés ideje alatt sem.

Összefoglalva, a “mindent tudjon amit az előző rendszer” igény átadja a teljes felelősséget a fejlesztőcégnek azzal kapcsolatban hogy mit és mennyit lát abból amit most használsz, valamint mennyi időt tud és akar beletenni annak letesztelésébe.

Ezzel ügyfélként valójában te kockáztatsz, miközben elmulasztod azt az izgalmas és fontos folyamatot, hogy átgondold, mire is van szükséged neked és a vevőidnek, felhasználóidnak igazán.

Vissza az összes cikkhez