Félmaraton, avagy 9 probléma, amivel találkozhatsz, ha nem figyelsz a scrum csapatodra

Tavaly szeptemberben, a nyár elmúltával kellemes, hűvös reggelre ébredtünk egyik szombaton. Összepakoltuk a szükséges felszerelést, az energiát adó ételt, italt, megfelelő öltözetet és elindultunk életem első félmaratonjára. Half.

Izgalom, egészséges félelem fogott el, ha őszinte akarok lenni magammal, nem edzettem rá megfelelő módon, de nem is lehet mindig mindenre felkészülni, testileg. Ezért fontos volt, hogy szellemileg ott legyen az ember.

Maga a pálya nagyon szép részen futott, a hőmérséklet ideális volt, a szint emelkedés 277 méter. Veszprémiként hozzá vagyok szokva a futás során az emelkedőkhöz és a lejtőkhöz, de ez durvábbnak ígérkezett. Szerencsére a pálya egy részét ismertem már az Ultrabalatonról, akkor is itt futottam.

A hétköznapi futások során 4:40-es, 5:00-ás pace-eket szoktam futni, és ezt 13 km-ig tudom is tartani.

A rajt előtt megfogalmaztam egy célt, hogy 2 órán belül szeretném lefutni a félmaratont. Ehhez kb 5:30-as átlagot kell futnom kilométerenként. De a végén is, az utolsó kanyarban is. Nem tűnik nehéznek, hiszen te magad döntöd el, hogyan futsz. Ha egyedül vagy. De külső hatások miatt sokszor lankad a figyelem, ezért kell ésszel futni és nem erővel. Fontos, hogy a rajtnál a tömeg lendülete ne ragadjon magával, vagy ha valamelyik szakaszon a hátad mögött, szinte a nyakadban érzed a másik versenyzőt, akkor ne kezdj el versenyezni, mert belemehetsz egy olyan hajszába, ahol idő előtt elfáradsz és a saját célkitűzésedet nem fogod elérni.

Ugyanez a nyomás érezhető egy projekt során is, ahol az ügyfél által meghatározott határidőre és budget-re is folyamatosan figyelned kell. Folyamatosan szállítanod kell, jó minőségű funkciókat, kevés bug-gal.

Könnyű beleesni abba a hibába, hogy ezt a nyomást átterheled a csapatra és termelési stressz alatt tarod őket, nem is feltétlenül szándékosan. Egy rövidebb projekt (4-5 sprint) alatt is tud káros lenni ez a munkamenet, de egy nagyobb lélegzetvételű (1 éves) projekt során nagyon nagy károkat tud okozni a csapatnak, a cégnek és az ügyfélnek is.

Ha ilyen nyomás alatt tartod a csapatot (és magadat), akkor az alábbi problémákkal, hibákkal találkozhatsz:

• planning, grooming elhagyása, elnagyolása
• tervezési feladatok kihagyása
• ezek következtében rossz minőségű funkciók lefejlesztése
• ennek következtében bug hegyek
• demotivált csapat
• nem jön létre a csapat hangulat
• funkciók, igények nem megfelelő felmérése
• refaktorálás hegyek (amire persze nem lesz idő)
• felmondások

Ilyen hibákkal és egy ilyen csapattal nehéz fenntartani az ügyfél elégedettséget, így mindenképpen azt javaslom, hogyha még ez több konfliktust is szül az ügyféllel, hogy a csapatot hagyd nyugodtan dolgozni, adj időt tervezésre, amíg nincs egy funkció rendesen követelmény elemezve, addig ne add oda a csapatnak (a csapat pedig ne fogadja be azt!).

Ahogy a félmaratonra, úgy egy projektnél sem tudsz mindig mindenre felkészülni, mindig lesznek váratlanul felmerülő problémák, de ilyenkor nagyon fontos, hogy azt tudd mondani, “Jó, most álljunk meg, gondoljuk át a problémát, állítsunk fel megoldási utakat.” Ésszel, racionálisan gondolkodva kell a helyzetet kezelni és nem elrohanni az elején a tömeggel.

A félmaraton alatt sokszor kellett észnél lennem és szándékosan visszafognom magam, mondani, hogy "Állj!", "Lassan!", hogy legyen erőm a teljes szakaszon. Tudatosan kell lépésről lépésre haladni, a külső tényezőket amennyire lehet kizárni, és akkor elérhető a cél. Akár még előbb is, nehézségek nélkül.

MVP a bútorgyártásban, avagy az agilis munkamódszer bemutatása egy hétköznapi példán keresztül

Környezetemben sokak számára néha nehéz elmagyarázni mit is csinálunk pontosan, mit jelent az agilis munkamódszer, amiben dolgozunk a fejlesztő csapattal. Alább egy hétköznapi példával szemléltetném, nagyjából mi a munka folyamat egy ilyen környezetben.

A legidősebb fiam szeptemberben iskolába fog ment, így már kirajzolódott a nyári események egy része: iskolatáska, füzetek, íróasztal vásárlás. Ezek közül a legutóbbi volt az egyik legfontosabb és a legnagyobb körültekintéssel kiválasztott dolog, hiszen sokkal könnyebb megfelelő környezetben alkotni.

Persze ennek az asztalnak helyet is kell találni, ami a jelenlegi gyerekszobában nem volt. Ennek egyik oka, hogy a fekvőhely és a ruhás/játékos szekrény az előző lakhelyünkről lett áthozva és nem passzolt a tetőtéri kialakításhoz. Így adta magát a feladat: új bútor kell a gyerekszobába. Az ágyat megvettük az IKEA-ba, pipa. De tetőtéri bútort nem nagyon árulnak, így vagy egy asztalost kérek meg vagy magam készítem el. A második mellett döntöttem, hiszen nem áll távol tőlem a barkácsolás.

A folyamat során próbáltam az agilis módszertanról tanultakat alkalmazni, nem lövöm le a poént, lássuk hogy sikerült.

1. Követelmény elemzés

Felmértük a szoba adottságait, hogyan lehetne a legoptimálisabban kihasználni a teret. Egy külső tényező, a megvásárolt ágy, amely kihúzható, korlátozta a szabad hely forrást. A jövőbeni külső tényezők növekedésével is számolnunk kellett, az íróasztalnak is kellett helyet találni, lehetőleg úgy, hogy természetes fény érje. Így a tetőtér beépítése mellett döntöttünk a szoba teljes hosszában.

Felmértük, hogy milyen célt szolgálna az új bútor: ruhák tárolása, játékok tárolása. Mivel a már meglévő ágy, főleg kihúzva, korlátozza a hozzáférhetőséget a szekrényhez, így olyan tárgyak tárolását is számba vettük, amihez ritkán kell hozzányúlni: pl. téli/nyári ágynemű, téli ruhák.

2. Tervezés

A követelmény elemzésből kiesett funkcionalitásoknak megfelelően megterveztem 3D-ben a szekrényt. IKEA-s kihúzható kosár és tároló dobozok, mint külső tényezők, szintén befolyásolták ezt a szakaszt, így az egyes fakkok, polcok méreteit ezekhez igazítottam. Elkészült a terv az elsődleges mérések alapján, amit jóváhagyott a stakeholder (kedves Feleségem).

3D model

A belső határoló elemeket úgy kellett megtervezni, hogy a polcok nagy része hozzáférhető legyen az ágytól.

3. MVP

Ezután meg kellett nézni, hogy az elképzelés megvalósítható-e, érdemes-e nagyobb beruházást eszközölni. Jelen esetben az MVP célja az volt, hogy ellenőrizzem a mérések alapján megvalósult tervet. Erre főleg a tető hajlásszöge miatt volt szükség, illetve lássuk, hogy értelmesen használható felület marad-e a szekrény teteje és a tető között. Erre létrehoztam a tervek alapján meghatározott méretek szerinti egyszerű váz szerkezetet meglévő léc darabokból:

MVP

Ezzel validáltam a tervet, hogy be fog férni a bútor a helyére, és a tetején is marad elegendő hely.

4. Becslés

A 3D-s modellből készítettem egy 2D-s tervet, abból pedig bútorlaponként egy-egy méretezett rajzot, darabszámmal. Ennek a költségét és az elkészítéséi idejét bebecsültettem a helyi lapszabászattal.

Terv

A végleges ár túlmutatott az eredetileg erre szánt keret összegénél, mivel a vasalatok és a bútorlap költségét én kevesebbre becsültem. A scope-ból úgy tudtam vágni, hogy a hátsó takaró bútorlapot lehúztam a listáról, hiszen zárt állapotban nem látszik, nincs hozzáadott értéke és funkcionalitását átveszi a tető. A vasalatból nem szerettem volna minőségben lejjebb adni, illetve a tolóajtó mérete indokolta a több görgőt és így a magasabb összeget. Stakeholder jóváhagyta.

A költség további csökkentését és az MVP kihangsúlyozását eredményezte, hogy az IKEA-s kosarakat és dobozokat majd később fogjuk megvenni és beszerelni. Ezek nélkül is használható marad a bútor, és elkészültekor így is értéket fog teremteni az ügyfeleknek.

5. Összeszerelés (fejlesztés)

A bútorlapok legyártását követően jöhetett az összeszerelés a tervek szerint.

Fejlesztés

Az első sprint után jött a demo: valóban a tervezettnek megfelelően fér el a bútor a tetőtérben? És vajon használható lesz kihúzható ágy mellett is a szekrény egyik fele?

Demo

Igen! A demo sikeres volt, jöhetett a következő sprint. Elkészült a bútor másik oldala is és felszerelésre kerültek a felső lapok is. Itt dönteni kellett, hogy az összeillesztés rejtett lesz-e, vagy felülről csavarozva. Mivel időben nem szerettem volna többet rászánni, illetve hiba lehetőséget is tartalmazott volna a rejtett megoldás (fa tiplikkel), így a kevésbé esztétikus, de egyszerűbb és gyorsabb megoldást választottuk a stakeholder-rel egyeztetve. Ettől függetlenül ezt a részt még nagyobb odafigyeléssel végeztem el, hogy a végeredmény a lehetőségekhez képest esztétikus legyen.

A tolóajtók szerelése közben észrevettem, hogy túl sok az interrupt. A görgők esetében,a melyekből ajtónként 4 db kellett:

- be kellett jelölni a pontos helyüket

- majd apró mélyedést csinálni, hogy ne másszon el a csavarok helye

- aztán 3-as fúrófejjel előfúrni a csavarok helyét (görgőnként 4 darab)

- becsavarozni a facsavarokat

- felrögzíteni a tartóra a görgőket

Tolóajtó: interrupt hegyek

Ennél a folyamatnál nagyon sokszor kellett szerszámot cserélni, és a fúróban fejet váltani. Így a második ajtónál már minden lépést az összes görgőnél végigcsináltam, nem pedig görgőnként váltogatva a taskokat, így sokkal kevesebb idő alatt elkészült a második ajtó.

6. Átadás, ügyfél elégedettség mérés

Végül elkészült a szekrény 2 nap alatt, az ügyfelek nagy megelégedettségére és azóta is szívesen használják.

7. Retrospective

Ha igazán MVP-t szerettem volna, akkor a tolóajtó is lehetett volna másidk körös fejlesztés, beruházás. Költség csökkentési lehetőség lett volna, ha a belső polcok nem közepes, hanem alacsonyabb minőségű bútorlapokból lett volna megrendelve és legyártatva.

Valódi MVP

Remélem sikerült ezzel az egyszerű és hétköznapi példával érthetőbbé tenni az agilis működés egy szeletét. Vegyük sorra a lényeget, átültetve az IT iparba:

- követelményelemzés: a vevő igények felmérése, külső tényezők megismerése

- tervezés (story-k megírása)

- ötlet validálása (MVP)

- fejlesztési költségek (sprintek) becslése

- fejlesztés

- demozás ügyfeleknek

Fontos az ügyfelekkel való szoros együttműködés, változtatások, felmerült problémák kommunikációja és jóváhagyása. Lényeges, hogy próbáljunk a scope-on vágni, mérjük fel, hogy adott funkciókra valóban szükség van-e? A demo és a fejlesztési szakasz ciklikusan követik egymást, míg el nem készül a termék.

Cél, hogy fejlesztés közben minél kevesebb interrupt legyen, és nem szabad elhanyagolni a retrospective fontosságát, ahol fel kel mérni a hibákat és a pozitívumokat a fejlesztési szakaszokban, hogy tanuljunk belőlük és sprintről sprintre jobbak, hatékonyabbak legyünk.

Apró finomságok sprint közben: ábrázolás

Már írtam arról, hogy milyen technikák vannak arra, hogy jobban kontroll alatt tudjunk tartani egy két hetes sprintet, és most pár apró finomságot szeretnék megosztani. Szinte alapvető dolgoknak tűnnek talán az olvasók egy részének triviális, mégis úgy gondolom hasznos lehet megosztani.

Sprint forduló napján az első esemény a demo. Bármennyire is volt tesztelve a lefejlesztett funkció, megírva a user story, mindig akad olyan hiba, ami demon jön elő, olyan funkció, amit a PO rosszul vagy nem egyértelműen fogalmazott meg. Ezeket az észrevételeket a vezető fejlesztő és én is, mint product owner fel szoktam jegyzetelni közben, hogy ne a demo folytonosságát akasszuk meg vele.

Sokszor olyan apróságokról van szó, amiért felesleges a Jira-ba storyt felvinni, így egy flipcahrtra vagy a mágnes táblára írom fel, hogy milyen apró észrevételeket tettünk a review során. Valahogy így:

Azt tudjuk, hogy aminek nincs gazdája, az elég lassan készül el, így még ott helyben felelősöket is rendel a csapat a feladatokhoz. Ami olyan nagyságú feladat, arról hozunk létre új storyt és csak planning után foglalkozunk vele, de amik szükségesek a megfelelő ügyfél demohoz, azokat még aznap el kell végezni. Erre általában a retro és a planning után kerül sor.

Ugyanezt az ábrázoló technikát alkalmazzuk a milestone napján is. Reggel a standup közben felírjuk az adott taskokat, amik nyitva vannak még és a milestone részét képezik. Majd az adott task mellé odaírjuk, hogy ki a felelőse, ad egy becslést a hátralevő időre, illetve megjegyzést is tehetünk oda, ha szükséges. Bár erre ott van a jira is, de az emberi agy mégis jobban befogadja, ha valamiről beszélünk és közben ábrázoljuk is.

Nem érünk oda

Az aktuális projektem közepe felé (5-7. sprint) a mérőszámok alapján már láttuk, hogy nem fogunk odaérni az aktuális velocityvel, ahova terveztük, időben. A csapat egy része számára ez nagy teher volt, a másik fele próbálta behozni, de csak kudarc lett belőle a sprintek végére. Az egész csapat stresszben volt, velem együtt, a demot nem ünnepnek éltük meg, a hétvégék is ennek a rossz érzésnek a hatalmába kerültek. Mit tehet ilyenkor egy PO vagy a csapat?

Kép forrása: stressz-m

A becslések nem voltak mindig pontosak, és a 2 hetes sprint nem adott elegendő kontrollt., tehát nem tudtunk időben beavatkozni, hogy sikeres legyen a sprint. A csapat mindig úgy látta, érezte, hogy a sprint végére össze fognak érni a szálak, be fogják hozni a storykat, de valahogy sosem sikerült. Egy-két story kihagyása végülis nem a világvége, de a sprintek számának növekedésével a le nem hozott storyk összege is emelkedett.

A másik probléma, hogy görcsösen ragaszkodtunk minden story elkezdéséhez. Így ha például 12 story volt betervezve a sprintbe, akkor a végén lett 10 darab 90%-ban kész story és két darab el sem kezdett story. De ha arra koncentráltunk volna inkább, hogy befejezett storykat hozzunk le, akkor lett volna 9 darab 100%-osan befejezett story, ami az ügyfél számára is nagyobb értékkel bír, mint több, de itt-ott sántikáló funkció.

Fontos volt valami akció tervet hozni, különben nagy baj lesz a végén. Két eszközt használtunk a sprint közbeni ellenőrzésre.

Meghatároztunk sprint közbenre egy milestone-t, ami a planningen definiált, és az előzetes becslés alapján addigra lehozható storykat tartalmazta. Ezeknek a storyknak a milestone-ra el kell készülnie, ha más külső akadályozó tényező nincsen.

A másik módosítás a feature freeze volt, ami arra irányult, hogy a sprint forduló előtt 1 nappal nincs több új task fejlesztés, hanem a meglévő bugok javítása, az addig elkészült storyk jobbítása volt a cél. Mivel a tesztelő 1 nappal a sprint forduló előtt kapja meg az összes storyt (vegyük figyelembe, hogy jelen esteben komoly függések voltak a storyk között), így kevés idő maradt a funkciók összefüggésében való tesztelésére és a feltárt hibák javítására, sajnos sokszor előfordult, hogy a demo előtt 10 percel még volt merge request.

A milestone beiktatása technikailag annyit jelentett, hogy kedd délután már csak bug javítás volt, új task fejlesztése nem, és szerda reggel tartott egy mini demot a tesztelő nekem.

Ugyan a milestone felfogható pótcselekvésnek a burndown chart helyett, de amíg nem működik jól egy csapat, addig nem ez nem ad pontos visszajelzést, és segít a csapatbak fokúszálni arra, hogy hol tratanak és valóban oda tudunk-e érni a sprint végére, a projekt végére.

A bevezetett intézkedések több kontrollt adtak a kezünkben és az elmúlt 3 sprint tapasztalata alapján elmondható, hogy pozitív hatással volt a csapat teljesítményére, az ügyfélnek szállított értékre.

És hogy ez mennyire agilis? Miért nem álltunk át inkább 1 hetes sprintekre?

A csapat félt attól, hogy a plusz agilis események annyi időt vesznek el, amit jelen szituációban a csapat nem vállalt be.

Mindenképpen szerencsésebb az a fajta hozzáállás, hogy kevesebb, de teljesen jól működő storykat hozzunk le egy sprintben, mint folyamatosan magunk előtt görgetünk minden storyt sprintről-sprintre.

Lehetne olcsóbb?

via GIPHY

Telekocsikázás: a túlóra megmentője, az agilitás halála

Környezetvédelmi szempontból nagyszerű lépés a telekocsikázás, mint rendszer elterjedése. Idehaza ugye az oszkár és a blablacar a legismertebb, de egyre több a saját, főleg munkatársak közötti szerveződés is.

A Virgo kihelyezett irodájában Balatonfüreden dolgozunk, de a legtöbbünk Veszprémből "jár be" dolgozni. Nem egy nagy távolság, kb. 20 perc autóval. Mivel sokan jövünk egy helyről így adja magát, hogy a kezdetekkor bevezettük a telekocsi rendszert, amíg nyár volt és nem kellett reggel a fiúkat az oviba vinni, addig még én is rendszeresen vittem a többieket.

Bár több kritika is érte az irodát, hogy nálunk fél 5-kor kiesik a billentyűzet a kezünkből, ezt betudtuk eddig annak, hogy Pesten más a munkarend (10-18), mint vidéken (8-16). Errefelé ugye nem annyira sűrű a tömegközlekedési infrastruktúra, így ha délután a sofőr már menni akart, akkor bizony az utasok is kénytelenek voltak, a Bakonyba még nem fúrtak metrót...

Eddig ezzel nem is volt gond, viszont egy komolyabb projekt kapcsán már a saját PO bőrömön tapasztaltam, hogy milyen hatással van a telekocsikázás a teljesítményre:

- be nem fejezett story

- elfelejtett commit

- bug

- csökkenő velocity

Hogy miért? Mint fent említettem, ha a sofőr indul, akkor menni kell. Ha egy csapaton belül lenne az egy autóhoz tartozó társaság, akkor nem lenne ilyen gond. De jelen esetben 2-3 csapatról van szó, sőt az épületben dolgozó másik cégből is van, aki a munkatársaimmal jár dolgozni, tehát ő hozzá is kell igazodni.

Mi a megoldás?

Jelen esetben most annyit tettünk csapaton belül, hogy kijelöltünk a sprinten belül két milestone-t és ahhoz tartozó 2 napot (értelemszerűen az egyik a demo előtti nap), amikor addig nem megyünk haza, amíg nincs minden vállalt story kész (ha az időn kívül más akadályozó tényező nincsen). Ezen a napon mindenki így készül, külön autóval jön.

Logolni vagy nem logolni, ez itt a kérdés

Számomra az egyik legkedveltebb része az agilis módszertannak, hogy a csapat saját maga határozza meg azt a szabály rendszert, amiben dolgozni szeretne sprintől sprintre. Ha a közösen megalkotott szabályok mégsem bizonyulnak megfelelőnek, akkor a csapat a retrospective keretében módosíthat rajta, elvethet egyet, hozzáadhat újat a listához. Jelenlegi csapatom egyik ilyen kitétele volt, hogy nem kötelező a logolás, vagyis nem fognak logolni. (ez amúgy céges szinten is sokszor vita tárgya)

Egy nagy projekt kezdetekor, tele lelkesedéssel és ekkora kihívással szemben állva PO-ként erre simán áldásomat adtam, hiszen úgysem ezen fog múlni egy sprint sikeressége. És valóban, nem is volt ezzel semmi gond, planningen megvolt a becslés és kész, jobban fókuszáltunk a SP-kra.

Az első problémák most adódtak, amikor realizáltuk, hogy csúszunk a projekttel és tudni kellene, hogy milyen sebességgel halad a csapat (óraszámmal) és a hátralevő taskok mennyi idő alatt hozhatóak le. Nem mindenki logolt, aki logolt az is össze-vissza, így nincs a kezünkben egy pontos mérőszám, így a jövőre vonatkozó kalkulációnk is csak becslés lehet. Meglepően alacsony napi óraszám jött ki, és nem csak a logolás miatt, hanem a lehozott storykra adott becsléseket összeadva is. A csapat elé tárva ezt az értéket ők is meglepődtek és realizálták, hogy ez valóban kevéske.

Úgy látszik a boardból, hogy rákapcsoltak, kíváncsi leszek ebben a sprintben mennyi lesz a vége.

Akcióként hoztuk, hogy mostantól mindenki pontosan logol a projekt végéig.

A jövőre vonatkozó tanulság, hogy sajnos nem mindenben lehet engedni a csapatnak, a mérőszámok fontosak a projekt egésze alatt. Megfelelő becslés, és következetes logolás mellett időben észre lehet venni a csúszást és időben reagálni, beavatkozni.

Tippek logoláshoz:

- backend és frontend külön subtaskra logoljon

- ha Jira-t használsz, akkor nézd át az exportot, mert nem mindig számol rendesen

- automatikus log tool használata

Felesleges sorban állás

Minden alkalommal jót nevetek magamban, amikor bejelentik a hírekben mint valami óriási dolgot, hogy 2 Ft-tal emelik a benzin árát és mindenki rohan tankolni, akár negyed óráig is sorba állva. Ha egy kicsit is tovább látunk a bejelentés manipulatív voltán, akkor számoljunk.

Miközben ott várakozik a sorban, leálltja az autót, újra indítja a motort, 5 méterrel arrébb gurul a másfél tonnával, majd tovább várakozik, kicsit megint előbbre gurul és így tovább. Ahogy nőztem, legalább 6-7 kocsi szokott így várakozni egymás után. Átlagos autó üzemanyagtartályát véve, ami mondjuk 50 liter, 2 Ft/liter kedvezményél 100 Ft megtakarítást jelent egy tankolás. Big deal! A sorbanállás alatt legalább fél liter elfogy, ami mai árakkal számolva 150-200 Ft. Megérte. Több benzint elpazarol, mint amit megspórol. És akkor az ott töltött semmibe veszett időről nem is beszéltem.

Ugyanilyen pazarlás olyan funkciók lefejlesztése, amit senki nem fog használni, vagy nem szolgál üzleti értéket. Sokszor tapasztaljuk azt, hogy egy ügyfél bele van szerelmesedve egy funkcióba vagy annyira vakon hisz valamiben, hogy mindenáron át akarja tolni annak fejlesztését a csapaton.

Mit tehetünk mi PO-k ilyenkor? Több módszer is a segítségünkre van.

5 whys

Használjuk a 5 whys technikát az adott funkcióval kapcsolatban és hamar ki fog derülni, hogy tényleg van értelme a kívánt funkciónak vagy nincs.

Üzleti érték

Puszta számokkal határozzuk meg, hogy mekkora üzleti értéke van az adott funkciónak, miben segíteni a ROI, a bevétel növekedését.

Konkurencia vizsgálat

Természetesen nem szentírás a konkurencia, de jó kiindulási alap lehet, ha az előnyben lévő versenytársnál sem használják az adott funkciót. Mivel én is voltam ügyfél szerepben, így jól tudom, hogy nehéz meggyőzni valakit annak az éllentétjéről amiben nagyon hisz. 

Viszont product ownerként az a feladatunk, hogy segítsük az ügyfelet, tudjuk nemet mondani neki, ha szükséges, és egy olyan termék létrehozásában támogassuk, ami valóban nyereséget fog termelni neki.

Amikor összeérnek a cégen belüli projektek

Jelenlegi ügyfelemhez gyárlátogatást szerveztünk csapatomnak és egyszer csak az alábbi kép fogadott:

Egyrészt fura, másrészt felemelő érzés látni, hogy a cégen belüli projektek, hogyan érnek össze. :-)

Feeling great!

Tartalom, tartalom, tartalom

Egy webfejlesztési projekt során az ügyfelek egy része azzal van elfoglalva, hogy a projekt alakulását követi nyomon, a felmerült kérdésekre válaszolgat, főleg, ha nem előzte meg a projekt indulását alapos követelményelemzés. Sokuk emellett a meglévő vállalkozás ügyvitelével is kénytelen foglalkozni, főleg, ha nincs abban a szerencsés helyzetben, hogy a saját oldaláról is dedikáljon egy belső product owner személyt.

Az élesítést megelőző időszak szintén elég sűrű szokott lenni, ráadásul ez hatványozódik, ha 3rd party rendszerekkel is össze kell kapcsolódni. Az átadás után jön a felismerés, hogy szép-szép, meg működik, de mégsem lehet az új oldalra forgalmat terelni, mivel azon semmilyen, vagy nagyon kevés tartalom érhető el. Ilyenkor, a nagyságtól függően, 1-2 hónap is lehet, míg teljesen felépül az oldal tartalmi része.

Éppen ezért nem gyűzzük hangsúlyozni, már a projekt felénén járva, hogy elő kell készülni az éles környezetre szabott tartalmakkal. Nem hagyhatjuk figyelmen kívül az admin rész megfelelő beállításait sem. Ez sosem tűnik vészesnek, de vegyünk egy egyszerű és általános listát:

- admin szerepkörök beállítása

- admin felhasználók oktatása

- termékek feltöltése

- termék képek előkészítése

- árak beállítása

- szállítási költségek beállítása

- ÁSZF, adatvédelmi nyilatkozat és egyéb statikus oldalak

- banner anyagok

- hírek

- főoldali képek

- kategória képek

- email szövegek és templatek

- analytics beállítsa, testreszabása

Ez nem teljes, és projektenként eltérő lista, de látható, hogy ez nem egy 1 napos munka és mindez hatványozódik, ha az oldal több nyelvű, vagy több különálló portált hozunk létre.

A másik előnye, ha ezeket az anyagokat időben elkészíti az ügyfél, hogy ezekkel tudjuk tesztelni az oldal kialakítását, működését és így valós tartalmakkal tudjuk ellenőrizni a folyamatok megfelelőségét, ha kell, akkor ezek alapján módosítani a designt vagy egy-egy funkciót.

Sok esetben kénytelenek vagyunk emiatt olyan funkcionalitások fejlesztését előbbre priorizálni, amelyek meghatározzák az adott tartalmak (pl. főoldali kép) méretét. Po-ként kötelességünk időben elkezdeni mantrázni az ügyfelünknek, hogy igenis el kell kezdeni a tartalmak gyártását.

Az élesítés utáni gondokról már írtam az alábbi posztban.

Veszprémi Technology Meetup előadásom témája: Startup buktatók

Jövő héten előadok a Veszprémi Technology Meetup-on:

Update (pár kép az előadásról):

Szabadulás

A mai napon összepakoltam a személyes holmijaimat, bepakoltam egy karton dobozba (mint az amcsi filmekben :-) ) és kisétáltam a gyárból. Az utolsó 50 méter olyan volt, mintha egy börtönből szabadulnék...felemelő. Könnyűnek éreztem magam és végtelenül boldognak. Végre magam mögött hagyhatom a süllyedő multit és elkezdhetek alkotni, értéket teremteni, dolgozni.

Beérett 5 év munkája, kitartása. Nem éppen úgy ahogy az elején terveztem, de változott a terv és talán még jobban is jöttem ki belőle.

Hétfőtől Product Owner leszek a Virgo System Kft-nél. :-)

Can't wait! Feeling motivated! :-)