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á.

Az én miértem újragondolva

Hiszek abban, hogy folyamatos tanulással, önfejlesztéssel segíteni tudom a munkájában és a céljai elérésében a csapatomat, a szervezetemet és ezen keresztül az ügyfeleimet.

Hiszek abban, hogy értéket teremtünk, értékes tagja vagyok a szervezetnek és fordulhatnak hozzám az emberek, ha tanács, segítség kell.

Célom, hogy hosszú távon jó követelmény elemző, tanácsadó váljon belőlem, vezetői képességeim folyamatosan javuljanak és bízzanak bennem az emberek. Magabiztos tudásommal irányt mutassak a folyamatosan fejlődő és változó online világban az üygfeleinknek.

Ahogy egy szoftver sincs kész soha, úgy egy szervezet és a szervezet tagjai is mindig tudnak fejlődni, és célom ebben részt venni, munkámon kívül plusz ismeretek megszerzésével és átadásával segíteni munkatársaimat.

Hiszem, hogy egyensúlyt tudok teremteni a munkám és a családom között, hogy a körülöttem lévők jól érezzék magukat.

“Karnyújtásnyi körben felelős vagy a világért, önmagadért és önvalódért.” - kortárs költő

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.

Növekedéssel járó ügyfél kezelési problémák online és offline

Mikor valaki sokat jár a piacra, a pékségbe, és mindig ugyanarra a helyre, akkor egy idő után szinte ismerősként kezeli az eladó a vevőt. Az ismerősöknek pedig több vagy jobb jár. Először csak kedves köszönés, aztán már szól az eladó, hogy ne abból a tojásból vegyél, hanem a pult alól kapsz frisset vagy szól, hogy ebből a paradicsomból ma inkább ne vigyél. Kialakul egy bizalmi kapcsolat és biztos, hogy továbbra is ott fogsz vásárolni, nem fogod a piacot körbe járni, hogy hol olcsóbb a paradicsom 10 Ft-tal.

Második fiamnak közeledik a születésnapja és megérett a nagyobb biciklire, így neki is elkezdtem keresgélni a neten ugyanazt a típust, amit a nagyobbik fiamnak vettünk, de más színben. Találtam is, jó áron. Megrendeltem. Két nap után kaptam az emailt, hogy az még sincs raktáron és már nem is forgalmazzák. Sebaj, megyünk a következő "boltba". Hasonlóan jártam. Már morogtam, de még időben elkezdtük a beszerzési projektet, így nem volt aggódni való, mentem a következő webshop-ba. Itt is kosárba tudtam tenni a terméket, azt írta ki, hogy raktáron van, de végül itt sem került kiszállításra a kerékpár.

Közel jártam ahhoz, hogy vevő megtévesztése miatt hatóságoknak kezdjek el írogatni. Megrendült a bizalom. Átváltottam troll üzemmódba. Ahol lehetett adtam le rendelést az adott kerékpárra, makacsságom nem hagyta veszni a dolgot, kell az a bicikli. AZ a bicikli kell! Az egyik helyről szintén visszajelzést kaptam, hogy jelenleg nem elérhető az áhított tárgy, de 2-3 hét alatt be tudják szerezni. Mondom nosza, az még belefér. A héten járt le a határidő és jelentkezett is a vállalkozó, hogy sajnos a szállítmány nem volt teljes (nem is fogadtam volna rá, hogy lesz), így a kért árú nem érkezett meg. BUT! Ugyanaz a márka, típus más színben van, amiben az első villa teleszkópos és a kellemetlenségért cserébe ezt a másik rendelés árában, vagyis kedvezményesen oda tudja adni, ha megfelel. Fiam a színt jóváhagyta, műszakilag nyerünk, és végre találkoztam egy Kereskedővel.

Jól esett, hogy törődtek az igényünkkel, foglalkoznak velünk (ego), és vannak olyanok, akik ennyire odafigyelnek a vásárlóikra. Anno a saját webáruházamban is az egyik legjobb rész volt, amikor személyesen ismertem a vásárlókat, tudtunk segíteni nekik, megoldást találni az esetleges problémáikra.

Egy darabig. A példaként említett offline piacon van egy korlátozott számú felhasználó, akik napi szinten visszatérnek, és mivel egy város nem szokott éves szinten 20-30%-kal növekedni lakosságilag, így a visszatérők száma sem fog ugrásszerűen, kezelhetetlenül növekedni. Az online minőségi kerékpárt vásárlók száma is korlátozott, ahogy a saját esetemben is, így sokkal könnyebb helyzeteben, előnyben vagyunk a nagyobb vagy tömegcikkeket értékesítő webshopokkal szemben.

Viszont a nagyoknak is kezelni kell az ügyfeleket, viszonylag gyorsan és jól. Itt nincs közvetlen viszony, itt egy-egy user csak egy-egysor az adatbázisban, és nem is a felhasználókat nézik, hanem a rendeléseket. Ekkora mennyiséget már nem is lehet máshogy, ezt el kell fogadni. Nem reális elvárás, hogy a tulajdonos, ügyvezető minden ügyfelet ismerjen, dolga a cég építése, fejlődésének, növekedésének biztosítása. Nem vehetünk fel userenként sem ügyfélszolgálatost, így olyan megoldásokhoz folyamodnak, mint például a

- chatbot (itt egy remek leírás róla)

- gyíkdzsungel*

- automatizálások

Azonban egy chatbot, vagy egy kihelyezett ügyfélszolgálatos sosem fog olyan jogokkal és döntési lehetőséggel  rendelkezni, hogy pl. egy kerékpárból jókora kedvezményt biztosítson, csak azért mert a beígért termék nem érkezett meg adott színben. De azt sem fogja megérteni, hogy a karácsonyra megrendelt sál hiánya a karácsony fa alól milyen vitát fog generálni. Elég csak az edigital facebook oldalát megnézni Black Friday akció után.

A személytelen kommunikáció, a korlátozott emberi erőforrás és az automatizált folyamatok a növekedés velejárója.

De mit tehet egy nagyobb webshop a bizalom felépítéséért és annak megtartásáért, a vevői reklamációk csökkentéséért?

Egy normális checkout kialakítása ma már nem atomtudomány, vehetjük alapnak, rengeteg helyen leírták már hány oldal legyen, mi szerepeljen rajta, hogyan, stb.

Hogy mitől lesz egy webshop megjelenésében bizalomgerjesztő szintén külön műfaj, és elég szubjektív.

Miért is jön a vásárló a webshopunkba? Hogy megvegye a kívánt terméket. Gyorsan, probléma mentesen. Tehát ha már becsalogattuk az ár összehasonlító oldalakról vagy a hirdetésekből és kosárba is engedjük tenni a kívánt terméket, akkor legyen az a nyomorult termék valóba raktáron, vagy 2-3 napon belül elérhető.

De mi van akkor ha tényleg reklamációra kerül a sor.

Talán épp a fenti okfejtésnek mond ellen, de itt jönnek képbe az okos megoldások, automatizálások, amelyek már túl mutatnak egy átlagos webshopon, amitől több lesz.

Az első kommunikációs pont a rendelés státuszról kiküldött értesítő levél, amelynek informatívnak kell lennie, a változásokat kövesse nyomon. De ne így!

Ha egyedi reklamációs esettel van dolgunk, akkor azt a rendszerben tudjuk kezelni, jelölni, akár kiemelt ügyfélszolgálatost rá állítani. SEO szempontból elengedhetetlen ma már  termékek alatt megtalálható értékelések, és egy elégedett reklamáló ügyfél szívesebben ad visszajelzést az oldalunkon. A csalódott ügyfél a tékozló homárra fog írni.

Hogy megkönnyítsük az ügyfélszolgálatosok helyzetét, akkor automatizált opciókat is létrehozhatunk, amelyekből válogathatnak a károk enyhítése céljából.

Az már csak plusz pont, ha a vevő jogait kihangsúlyozva, egyértelműen és könnyen elérhető módon közzé tesszük (pl. elállással kapcsolatos jogok), már a rendelés visszaigazoló levélben is.

Attól, hogy online felületre viszük át a termék eladást/szolgáltatást, ez még kereskedelem és az alapvető elvárások megmaradnak az ügyfelek részéről. Talán az ego, talán a nosztalgia, de mégis jól esik az embernek, ha kedvesebben köszönnek neki a pékségben, vagy frissebb árút kap a piacon, így mindig lesz egy olyan szegmens, ami offline maradhat, és ahol mindig első osztályú lesz az ügyfél kezelés.

*gyíkdzsungel: a gyakran ismételt kérdések olyan útvesztője, ahol sosem fogod megtalálni a telefonos elérhetőséget, mert nem az a cél. :-)

Hogyan keltsünk életre egy Xiaomi asztali LED lámpát 5 perc alatt?

Otthonunkba került egy Xiaomi asztali LED lámpa, amiről kinézete alapján nem sokat vártam, de kellemesen csalódtam. Amikor kezembe kaptam a készüléket nem tudtam róla semmit, csak azt hogy okos lámpa.

De kezdjük az elején.

Design, csomagolás

Szép fehér dobozban érkezett a lámpa, de aki Apple és Nest termékek csomagoláshoz van szokva, kicsit csalódni fog. Semmi extra, de más az érzés.

A lámpa kapott egy fólia csomagolást is, illetve a doboz tartalmazott még egy kicsi adaptert, hogy itthoni hálózaton is lehessen használni.

A lámpa viszonylag súlyos darab (800g), de csak a talpa, így nagyon stabilan áll. A kábel elegendő hosszúságú, szép vékony fehér.

Csupán egy gomb található rajta (illetve az alján egy reset gomb, erre később visszatérek), így nem is értettem mitől lenne okos, használati útmutató nem volt a dobozban (frissítés: nekem hiányzott a dobozból, de amúgy van benne).

A külső kialakítás nekem nagyon tetszik, letisztult forma, kompakt méret, a világító rész teljesen lehajtható a tartó oszlop mellé. A zsanér a gyártói oldal szerint nagyon bonyolult szerkezet és tartósnak is tűnik, szépen mozog, nem akad, stabilan áll az adott helyzetben. A tartó oszlop magassága 45 cm és maga a fej és ugyanennyi. A talapzat 15 cm átmérőjű.

Beüzemelés

A termék gyártói oldalán kezdtem el keresgélni esetleges applikáció után, de a szép termék bemutató oldalon sehol nem volt app link.

Egy kis kutakodás után találtam két appot, az egyik a Yeelight a másik a Xiaomi cég saját alkalmazása a Mi Home. Ez utóbbi kínai nyelvű app ikon aláírással jelenik meg az appok között.

Feltelepítés után végig vezet a setup folyamaton, ahol:

1. első lépésként ki kell választani a terméket, amit használni szeretnénk

2. kapcsoljuk be a lámpát a rajta levő gomb megnyomásával (ezt jelzi az app)

3. adjuk meg a wifi hálózatunk belépési adatait, majd kicsit várni kell

4. lépjünk át a Settings-be és az elérhető wifi hálózatok között meg fog jelenni a lámpa saját hálózata

5. ezt válasszuk ki majd lépjünk vissza az appba és már ott lesz az elérhető készülékek között a lámpánk

Érdemes megjegyzeni, hogy 2.4 GHz-es hálózatra képes csatlakozni és jobb megoldás a wifi használata, mint a Bluetooth, hiszen így a lakás bármely pontjáról vezérelhetjük, nincs gond a hatótávolsággal.

Én először a kínai appal kezdtem, majd utána próbáltam ki a Yeelight appot. Viszont mivel a készülék már hozzá volt adva az első apphoz, így resetelni kellett a lámpát. Ezt a talpán található bemélyedésban lévő apró gomb 5 mp-ig tartó megnyomásával érhetjük el. Ezután újra végig kell menni a beállításon.

Nos, készen volt az okos LED lámpa a használatra.

Használat

A smart lámpán található oldschool gomb használatával be- és kikapcsolni tudjuk, illetve a fényerőt szabályozni.

Az appon keresztül ennél már jóval több lehetőségünk van, amivel elég sokat lehet játszani (a gyerekektől alig tudtam visszakérni a telefont...) :-).

- szabályozható a fényerősség

- szabályozható a színhőmérséklet

- választhatunk előre definiált mode-ok között (olvasás, gyertyaláng, számítógépezés) vagy létrehozhatunk mi is sajátokat

- elláthatjuk "gyerekzárral" (korlátozhatjuk a színhőmérsékletet)

Mi Home app - szín beállítás

Az alap funkciókon kívül lehetőség van külső szolgálattókhoz való csatlakozásra (Amazon Alexa, Google Home), illetve IFTTT parancsok (ha X esemény bekövetkezett, akkor Y lép életbe) tervezésére.

Nagyon jó ötletnek tartom a Pomodoro módszer integrálását, vagyis beállítható, hogy pl. 45 perc után automatikusan lekapcsoljon a lámpa és 15 perc után kapcsol csak vissza, így kényszerítve minket egy kis szünet tartására, illetve segít beosztani az időnként, anélkül, hogy erre figyelnünk kéne.

Összeségében egy egyszerű, látványos, de mégis letisztult formavilágot felmutató okos lámpát kapunk, teljesen normális összegért. Maga az applikáció (Yeelight) is jól használható, így bátran ajánlom ezt a LED lámpát, nem csak kütyü bolondoknak.

Tapasztalat:
- masszív kialakítás, szép design

- nagyon jó erős fénye van a lámpának

- jól használhatóak az előre definiált beállítások

- nincs egyértelmű utalás, hogy milyen appal használható

- kicsit keszekusza az app navigációja

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.

A PO, az SM és a Csapat

Megbeszéléseken, emailekben, standupokon sokszor elhangzik a számból, hogy a csapat, vagy PO és a csapat. Egyéb kommunikációkban is gyakran úgy jön le ez a két megnevezés, mint két különálló dolog. És mindig furán érzem magam ettől.

Szakirodalomban is sokan úgy tartják, hogy van a fejlesztő csapat és van mellette külön álló szerepben a product owner. Lássuk az Agile manifesto egyik pontját:

"Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában."

Együtt dolgoznak, de vajon egy csapatként?

A Lean Startup könyvben is megtalálható az a felállás, amikor a megrendelő (customer) áll az egyik oldalon, a fejlesztő csapat (development team) a másik oldalon.

Tovább nehezíti a megfelelő definíció kialakítását az a kettősség is, hogy a product owner sok időt tölt az ügyféllel (stakeholder), az ő érdekeit is képviselnie kell, a csapat érdekei mellett.

Munkám során előfordult olyan szituáció is, amikor PO-ként több csapat irányítása is feladatom volt. Mondhatjuk, hogy egy csapat tagja sem voltam ebben az esetben. Vagy például a kezdeti időszakban, amikor technikailag még nem voltam olyan szinten, akkor kívülállónak éreztem magam sokszor a fejlesztői beszélgetések közben.

Illusztráció: Werner Nóri

De miért is foglalkozok ezzel?

Mert ezek ellenére én úgy gondolom, hogy PO-ként a csapat szerves része vagyok, amit létrehozunk az közös munka. Ugyanígy a felelősségben is osztozunk. Ha azt mondom scrum csapat, akkor abba PO-ként én is beletartozok. Ez a gyakorlatban annyit tesz, hogy

- részt veszek a csapatszabályok kialakításában

- részt veszek a retrospective-ken

- a csapatot megvédem az ügyféllel és a vezetőséggel szemben, ha szükséges

- a hibák következményeit együtt viseljük

- szorosabb együttműködést és gyorsabb visszacsatolást tesz lehetővé

Illusztráció: Werner Nóri

Ha kívülállóként, üzleti szakértőként viselkednék, akkor csak a stakeholderek érdekeit kellene néznem, és minden felelősség a fejlesztő csapaté lenne. Ettől nem gondolom, hogy könnyebb dolgom lenne, illetve nem hiszem azt, hogy produktívabb lenne a fejlesztés. A fejlesztő csapat szemében nem biztos hogy jól veszi ki magát, ha kívülállónak, csúnyán kifejezve,  felsőbbrendűnek gondolom magamat.

Az igazsághoz hozzá tartozik, hogy a jelenlegi projektem első egy-két retrospective-jén nem voltam jelen, de utána már behívott a csapat és együtt elemeztük ki mi volt a jó/rossz a sprintben és milyen területen tudnánk fejlődni. Sokkal tisztább és egyértelműbb volt így, mintha utána olvastam volna el a confluence-be felvitt jegyzőkönyvet és találgattam volna ki, hogy ki mire gondolt pontosan.

Akad persze ellenvélemény is:

"A potential risk is that with the presence of the PO the daily scrum can revert to a status meeting. Updating the PO rather than collaborating on getting another day closer to the sprint goal." - Duan

Jogos a felvetés, de a scrum master feladata megfelelő kordában tartani a standup eseményt.

Azt is látnunk kell, hogy ha a csapat úgy érzi, hogy a PO nem integrálódott teljesen a csapat napi működésébe, akkor egy idő után a csapat sem fog teljes odaadással részt venni ezen eseményeken, az érték teremtésben és kommunikációs gap jöhet létre.

Ha már szóba hoztuk, akkor beszéljünk kicsit a SM-ről. Neki sem csak az események szervezése, vagy a problémák megoldása, akadályok elhárítása a feladata. Hiszen bizonyos problémák feltárásához szoros kapcsolatban kell lennie a csapattagokkal (lásd 1on1). Nem tankönyvszerű, de az élet adta helyzethez idomulva már előfordult nálunk olyan is, hogy a a fejlesztők a scrum masternek tartottak sprint végi demot.
Kicsit olyan, mint egy család, ahol mindenkinek megvan a maga szerepe, de ha a szükség úgy hozza, akkor segítünk egymásnak, átveszünk feladatokat.

És miért fontos nekem ennyire ez?

Mert az alá/fölé rendelt viszonyban ott van a hibázási lehetőség. Ha pl. a PO az SM-en keresztül kap csak visszajelzést a csapattól.

Összegezve, úgy gondolom, hogy amikor egy projekt kapcsán csapatról beszélünk, abba beletartozik a PO és az SM is, ez az ökoszisztéma adja a teljességet. Az egymástól való függés határozza meg a csapat sebességét, a lefejlesztett funkciók értékét, használhatóságát és végül az ügyfél elégedettséget.