A digitalizáció elképesztően gyorsan fogja az üzlet és a vásárló közötti személyes kontaktust eltörölni. Manapság egyre többen intéznek például minden banki ügyet vagy nagy bevásárlást online. Az adott banki applikáció, vagy hipermarket webshop lesz a vállalat és az ügyfél egyetlen összekötő csatornája. Ezért a digitális termékek kerülnek a reflektorfénybe, és első számú szerepük lesz a cég sikereiben vagy bukásában.
Kiélezett verseny zajlik tehát a virtuális piacokon az ügyfelekért. Ki tud minél népszerűbb, jobban használható, gazdagabb funkcionalitású applikációkkal, weboldalakkal ügyfeleket megtartani és toborozni. Nem véletlen, hogy a vállalatok komoly technológiai szakértőkkel dolgoznak együtt a saját digitális termékeiken: UX designerekkel, Frontend fejlesztőkkel, Data scientistekkel. Futótűzként terjednek a SCRUM bevezetési projektek minden ágazatban, ami jól illeszkedik a gyorsan változó, vásárló központú piaci trendekhez és a digitális termékek fejlesztéséhez.
A Scrum guide így kezdődik: Scrum is a framework for developing and sustaining complex products. Új termékek kifejlesztésére hozták létre, és az agilis működési modelleket alkalmazó vállalatok 94%-a használja valamilyen formában.
Látszólag minden a helyén van, megvannak a megfelelő szakemberek, és a működési modell is a termékfejlesztéshez. Ehhez képest még is sokan küzdenek a jól ismert kihívásokkal: időbeli csúszások, éles szoftverhibák, hiányzó innováció és alacsony megtérülési mutatók.
Miért van ez így és lehetne-e másképp is csinálni?
Ahhoz, hogy a teljes képet lássuk, kezdjük az első és legfontosabb kérdéssel: mi a termék?
A Scrum guide erről nem beszél, talán azért mert nyilvánvaló? Több okból sem az:
· A vásárló közel sem biztos, hogy azt a terméket vásárolja meg, amiről a cég azt gondolja, hogy eladja a vásárlónak. Nem véletlen, hogy az agilis metodológiák arra bátorítják a termékek fejlesztőit, hogy hozzák olyan közel a vásárlókat a fejlesztőkhöz, amennyire csak lehetséges (a kommunikációs lánc jó esetben ennyire rövid: Vásárló -> Product Owner -> Fejlesztő csapat),
· Nagyvállalatoknál, skálázott agilis környezetben, ahol több csapat dolgozik egy azonos digitális terméken, sok esetben „spagetti” architektúrával és kódbázissal, nem nyilvánvaló, hogy mi egy termék, az hol végződik és ezt követően hol kezdődik egy következő,
· A digitális termék egy élő organizmus, folyamatosan fejlődik, változik és emiatt nehéz definiálni és formát adni a definíciónak,
· A felsővezetés nem kommunikálja világosan, hogy milyen üzleti célokat, milyen időzítéssel és prioritásban szeretne elérni,
Miért fontos, hogy definiáljuk a terméket?
A digitális termékek egyre nagyobb térnyerése miatt elkerülhetetlen, hogy egy átfogó, erős definíciót építsünk fel, amelyet aztán az aktuális piaci trendeknek megfelelően lehet finomhangolni.
A termék definíciója fogja meghatározni a:
- fókuszált és folyamatosan fejlődő termékvíziót, ami a teljes csapatot viszi előre,
- Product Backlogban az elemeken felül a szintezést, és a méretét is,
- pontosan kik a vásárlók, és miért ezt a terméket választják,
- ki a megfelelő Product Owner és mi a megfelelő csapat struktúra,
- mi a jól körülhatárolt technológiai infrastruktúra, ami kizárólag ezt a terméket szolgálja ki,
- mi a költségvetés termék szinten.
A fentiek megfelelő formába öntése segít a sales, marketing és más egyéb csapatoknak is a közös megértésben és a közös célért való elköteleződésben.
A termék és pontos határainak kijelölése jelentik az egyik legfontosabb döntést, amit a szervezet meg fog hozni. Azt ne felejtsük el, hogy a nem döntés is egy döntés.
Hogyan határozzuk meg a terméket?
Lehet a termék egy csapat által leszállított munka? Egy IT fejlesztési projekt? Egy sor egy excelben? Egy komponens? Egy platform? Egy keretrendszer? Elméletben a válasz igen, ugyanakkor ezek egyike sem szállít valódi értéket a vásárlónak. Érdemes tehát olyan módon meghatározni a terméket, hogy az egyes részeket összeillesztve önmagában is használható értéket teremtsen a vásárlóknak. Egy jó módszer lehet feltenni a kérdést: Mit válaszolnának a vásárlóink, ha megkérdeznénk őket, hogy mi a termékünk?
Az agilis transzformációkban számos esetben láttam a nem elégséges és nem tiszta termék definíciókból adódó problémákat:
- ahol több Product Owner dolgozott egy terméken, ott gyakran elveszett a csapatok felett átívelő teljes termék fókusz, hiányzott a teljes termékért felelős PO,
- ha több Product Backlogban volt egy termék kezelve, akkor előfordult, hogy bizonyos csapatok bár hatékonyan szállítottak a csapat szintjén, de a teljes termék szempontjából nem kiemelkedően fontos funkciókat,
- termék komponenseket termékként kezelve bekerültek egyéb szerepkörök és komplexitás a szervezetbe, ahelyett hogy a több komponens egy teljes termékként lett volna menedzselve,
- duplikált funkciókat készítettek a csapatok, ahelyett hogy egy közös megoldás született volna,
- nem termékek köré szervezték a stratégiai célokat, csapatokat, költségvetést, szállítási terveket, ezáltal a termékek fókusza alárendelt szerepet kapott,
- a digitális termékek egy IT szoftverfejlesztési igényként (rosszabb esetben költségként) jelentkeztek egy nagy üzleti igény listában, amit a felsővezetőség állított össze a költségkeretek és az aktuális stratégia alapján,
„MANAGING WORK AS PRODUCTS RATHER THAN PROJECTS CHANGES STRUCTURES, DECISIONS, BEHAVIORS IN PRODUCT DEVELOPMENT” Craig Larman
PRODUCT vs PROJECT szemlélet
Ha meghatároztuk a digitális termékünket, és minden résztvevő csapat számára jól érthető a vízió azaz a miért, akkor jöhet a következő lépés a siker irányába: a hogyan.
A termékek illetve a projektek menedzselésében jelentős szemléletbeli különbségek vannak. Az, hogy milyen szemléletben fejlesztünk egy terméket, a sikert vagy bukást is jelentheti. A legtöbb nagyvállalati környezetben, ahol eddig láttam működni Scrum szerinti digitális termékfejlesztést, azt tapasztalom, hogy összemosták a scrum által javasolt fejlesztést klasszikus projektmenedzsment elemekkel és folyamatosan egymást követő projektek formájában történik a termékek fejlesztése és szállítása. Pedig a Scrum metodológiában a Product Backlognak és Product Ownernek kulcsszerepe van, míg a Projektmenedzsert és Projekttervet szándékosan eliminálja a rendszerből. Azt látjuk, hogy a tradicionális projektmenedzsment eszközöket használó digitális termékfejlesztések többségében el kell tolni a határidőket és változtatni kell a tartalmat. Tehát a klasszikus projekttervek elbuknak.
„WHAT GOT YOU HERE WON’T GET YOU THERE.” Marshall Goldsmith
Miért alkalmazzuk a projekt alapú tervezést mégis, ha tapasztalati úton is igazolódik, hogy a tervekben vállaltak nem tarthatók?
Ha kalapács van a kezünkben, mindent szögnek fogunk látni. Nem ismerünk más tervezési alternatívát. Erősen kondicionálva vagyunk a projekttervek követésére, mert ha a múltban bármikor egy komplex, ismeretlen, nagy feladat volt előttünk, ezzel az eszközzel oldottuk meg. Számottevő ok lehet, hogy egy terv abba a hamis biztonságérzetbe ringatja a terveket készítőket, hogy a termék fejlesztése a terveknek megfelelően fog haladni. “Egy hosszú távú tervnek mindig lenni kell!” hallom ezt sokszor felsővezetőktől. Ez a mai kiszámíthatatlan piaci viszonyok között legtöbbször önámítás. Mindezek mellett domináns gondolkodásmód még sok helyen az, hogy ha nem teszünk a csapatok elé határidőket, akkor hátradőlnek. Ezzel az a probléma, hogy ez mindig egy külső nyomás lesz rajtuk. Ráadásul ez az alacsony szintű motiváció sem éri el a célját, hiszen el kell tolni a határidőt, és így hitelét veszti ez a fajta tervezés a csapatok előtt.
Hogyan cserélhetjük fel a külső motivációt belsőre?
A hosszú távú tervekben a határidők helyett sokkal fontosabbá válnak azok az innovatív funkciók, amikkel igazi rocksztár terméket építünk. A vízió kommunikálására és a haladás vizualizálására egy szuper eszköz lehet a termék roadmap. Így az előrehaladást már nem projektterv mentén, hanem a roadmapen követjük. Ez egyébként betöltheti a felsővezetőségben az eltűnő projektterv hiányával okozott űrt is. Látható, hogy ha van erős termék vízió, amivel a csapatok rezonálnak, akkor belső indíttatásból köteleződnek el. Ha a víziót és a termék fejlődését a Product Ownerek megfelelően vizualizálni tudják, akkor minden stakeholderben ez a belső motiváció fenntarhatóvá válik. A terméken dolgozók könnyebben tudnak kapcsolódni a célokhoz, és sokkal inkább magukénak kezdik érezni a terméket. Ennek pedig jelentős hatása lesz a szállítások sebességére és minőségére is.
„IF YOU ARE WORKING ON SOMETHING EXCITING THAT YOU REALLY CARE ABOUT, YOU DON’T HAVE TO BE PUSHED. THE VISION PULLS YOU.” Steve Jobs
Az alábbi táblázatban jól látható, hogy ugyanazon szempontokat tekintve mekkora a differencia termék és projekt szemlélet között:
Mik a hátrányai, ha leszállítandó projektekként kezeljük a digitális termékfejlesztést?
- rövid távú érdekek (projekt cél) háttérbe szorítják a hosszú távú érdekeket (vízió)
- projektek indításának, menedzselésének és befejezésének költségei
- folyamatosan változó projekt csapatok gátolják a stabilan, magas minőségben szállító csapatok kialakulását
Lehet projektek nélkül is terméket fejleszteni?
Igen! Az agilis metodológiák nagy része, így például a Scrum is azt javasolja, hogy a termékfejlesztést termékszemlélettel menedzseljük:
- rövid időre tervez előre, így felszabadítja a csapatokat a nagy volumenű, klasszikus projekt tervezéstől és annak összes költségétől
- gyakran ellenőrzi, hogy megfelelő irányba és sebességgel halad-e a termék fejlesztése
- megfelelő perspektívát biztosít a rövid és hosszú távú érdekek mérlegeléséhez
- erős termék víziót állít fel, de abban rugalmas, hogyan jutnak el a csapatok oda
- stabilan tartja menet közben is a terméken a fókuszt
- a csapatok pontosabban, jobb minőségben szállíthatnak
Ez persze nem jelenti azt, hogy egy agilis csapatnak nincsenek szállítási határidői vagy ne lehetne hosszabb távra tervezni a szállításokat, például egy negyedévre előre. A tervek viszont teljesen máshogy születnek, erről majd egy következő blogposztban írok nektek.
„PLANNING IS USEFUL. BLINDLY FOLLOWING PLANS IS STUPID.” Jeff Sutherland
Mielőtt a projektmenedzserek meglincselnek, szeretném leszögezni, hogy a projektek hasznos eszközök, és egy nagyvállalatban számos esetben ez a leghatékonyabb módszer a céljaink eléréséhez. Azonban digitális termékek fejlesztésénél számos kockázattal és lassító tényezővel számolhatunk, ha projektekként tekintünk a termékeinkre. Komoly változás, amikor a hosszú távú projektterveket felváltja egy erős vízión alapuló roadmap, ami sokkal hatékonyabban mozgatja előre a csapatokat. Ehhez azonban a szervezet minden szintjén szemléletmódbeli változás szükséges. A vezetőség, a termékért felelős szakemberek (PO, PM) és az agilis szakemberek (SM, AC) szoros együttműködésével azonban a körülmények támogatóvá alakíthatóak. Agilis környezetben fejlesztett termékek esetén a Scrum szerinti tervezés – megfelelően alkalmazva – működőképes alternatíva lehet abban az esetben, ha a projekt szemlélet nem válik be.
A piacvezető, innovatív digitális termékek mögött mindig ott van egy csapat, aki össze tudott állítani egy erős termék víziót és el is hitte hogy megvalósítható az, amiről más csapatok csak álmodtak. Ne féljünk definiálni a terméket és artikulálni ezt a szervezeten belül. Ez segít majd meghatározni a víziót, a roadmapet és minden nélkülözhetetlen információt a fejlesztéshez. Bátran szervezzük a termék köré a csapatokat, folyamatokat, költségvetést, ez kódolja a rendszerbe a kellő termék fókuszt. Az agilis termékfejlesztéssel pedig gyorsan és hatékonyan piacra tudjuk vinni a terméket, és extra költségek nélkül irányt is változtathatunk, ha szükséges.
szerző: Liska István
Comments