Miért jó a tartalom vezérelt fejlesztés?

Amikor a Virgo-nál kezdtem, akkor az első projektem egy viszonylag egyszerű, információs portál elkészítése volt. Kis csapattal, meglévő követelmény elemzéssel időre végeztünk, a termék bemutatása és az adminok oktatása után átadtuk a honlapot.

Elkezdődött a tartalommal való feltöltés és jöttek a problémák. Amikor elkészült a drótváz és a look&feel, ügyfél elfogadta azt, majd az élesítést követően a tartalom feltöltéskor derült ki, hogy a főoldalon a hírek boxok nem jól jelennek meg a tartalom miatt, és funkció szerint sem volt elfogadható.

Az alapfelállás szerint a három leggyakrabban olvasott hír jelenik meg a főoldalon, de a hírek publikálása után vált egyértelművé, hogy így a friss hírek sosem fognak megjelenni. Módosítottuk a főoldalon megjelenő hírek működését a kérésnek megfelelően:

- első helyen jelent meg a legfrissebb hír

- második helyen a legtöbbet olvasott hír van

- harmadik helyen pedig mostantól random jelennek meg a hírek

Bár apróságnak tűnik, de rosszul éreztem magam, csalódott voltam egy picit a termékben.

Egy feature vagy egy projekt átadása után gyakori eset, hogy az ügyfél panaszkodik. Az ügyfél azt mondja, nem erre gondolt, nem ezt beszéltük meg, stb. Egyértelmű, hogy kezelni kell az ilyen szituációkat, a nemeket. Ha már egy átadott fejlesztésen kell változtatni, akkor az kellemetlen beszélgetéseket tud szülni, és költség oldalról is nem várt kiadás az ügyfél számára. Így a cél nem a konfliktus feloldása, hanem annak megelőzése.

De miért is jutunk el ilyen helyzetekhez?

Röviden tekintsük át mi a fejlesztés megszokott menete, mikor történik meg a tartalom feltöltés:

- megtörténik a követelmény elemzés

- a storyk alapján a csapat lefejleszti a feature-t

- belső tesztelés után

- demozzuk az ügyfélnek

- átadjuk a terméket és

- elkezdődik a tartalom feltöltése

Bontsuk két részre a problémát belső és külső folyamatok alapján.

Ha nem áll rendelkezésre megfelelő adat vagy tartalom, akkor lassítja a fejlesztési folyamatot, illetve létrejöhet az úgynevezett fejlesztői software: a specifikáció szerint elkészült a software, de user oldalról használhatatlan.

Az adathiba vagy adat hiánya rossz terméket, felesleges munkát szül és bár költség oldalról ez talán még kezelhető, de egy rossz termékből jót faragni már nagyobb kihívás.

A tesztelés és a demo során is bizonytalan helyzet állhat elő, ha távol áll az éles környezettől, állapottól. Ha demo felületes, ha csak azt írjuk be egy statikus oldalra, hogy pl. ez egy teszt oldal, akkor nem kapunk visszajelzést az ott lefejlesztett funkciókról. Sokkal látványosabb tud lenni, ha valós adatokkal töltünk ki egy oldalt:

Hiányosan kitöltött statikus oldal

Feldíszített statikus oldal

Ha ügyfél oldalról közelítjük meg a problémát, akkor szerintem az egyik fő gond, hogy a demo során egy bizonytalan ügyfelet kaphatunk, aki nem tudja eldönteni, hogy az adott fejlesztés sikeres-e vagy nem, átvehető-e vagy nem. Ha átveszi, de a tartalom feltöltés során kiderül, hogy valami nem az elvárások szerint működik, akkor az plusz költséget jelent számára.

Nagyon fontos még, hogy adott funkcióval kapcsolatban a kivételek feltárása is megtörténjen  segítsük ebben az ügyfelet.

Előfordult olyan is, hogy beégetett adatokkal dolgoztunk egy projekt során, ami elfedte a valós adatokkal járó problémákat. A funkció fejlesztése során nem volt megfelelő termék import és emblémázás import file, még változott közben, így később derült ki az éles adatokkal való feltöltés során, hogy nem jól dolgozzuk fel, nem minden adatot dolgozunk fel a file-ból.

Mit tehetünk ezen problémák elkerülésére?

Célszerű már a story-k írása közben a tartalmakat, teszt adatokat összegyűjteni, a story-ra rárakni, becsatolni, use case-eket írni. Fel kell tárni a kivételeket, adott funkciónál a folyamaton végig menni, modellezni.

Ha a portál, a termék több nyelvű, akkor figyelni kell arra, hogy pl. egy gomb esetén más a hosszúságú a benne megjelenő szöveg magyar nyelven és más hosszúságú német nyelven.

Segítségünkre lehet a priorizálásban is, hogy azt a story-t vesszük előre, amihez van tartalom így az ügyfelet is motiváljuk a tartalom gyártásra. Ezen a ponton nagyon fontos, hogy ki az, aki a tartalmat előállítja, az információk eljussanak hozzá, illetve tőle hozzánk.

Előnyök

A sikeres demo mellett, csökkenteni tudjuk a fejlesztési időt, megkönnyíthetjük a tesztelést és egy jobb végterméket kapunk a fejlesztés folyamán. Ezáltal a CR-ek és a reworkok száma is kevesebb lesz.

Ha rendelkezésre állnak a végleges tartalmak, akkor a rollout idejét is csökkenthetjük, és a csapat mellett az ügyfél elégedettségét is növelhetjük.

Könnyűnek hangzik, igaz? :-)

Hátrányok

Nem mindig életszerű, hogy a fejlesztés előtt legyen meg minden majd egyszer lefejlesztendő funkcióhoz az éles tartalom, amit az ügyfélnek kell biztosítania. Agilis megközelítés szerint, roadmap alapján az adott funkció groomingjára/preplanningjére kell meglennie az adott anyagnak. Ha már a projekt elején bekérünk valamilyen anyagot, akkor előfordulhat, hogy mire a funkció gyártásához érünk az már nagy valószínűséggel nem lesz valid és mi téves magabiztossággal fogunk tervezni, fejleszteni.

Másik probléma, hogyha elvárjuk, hogy a PO/BA a userstoryba már bele írja a teszt eseteket, akkor az rengeteg ráfordítást kíván a részéről. Tapasztalat alapján ez nem mindig kivitelezhető, az egyéb teendők mellett nem biztos, hogy marad rá elég idő, így keressük meg a mi projekt szervezetünkbe illeszthető megoldást.


Üzenet

Egyértelmű, hogy az előkészítés sok időbe telik, ezért edukálni kell az ügyfeleket. A jó termék elkészítéséhez jó adatokat kell előállítani, vagyis az ügyfélnek már előbb el kell kezdenie dolgozni, mint a csapatnak, ideális esetben már a követelmény elemzés során megkapnánk ezeket az információkat. Ez nem minden esetben kivitelezhető, főleg egy új termék fejlesztésekor, vagy a folyamatok optimalizálásakor, módosításakor, de törekednünk kell rá.