Dicstelen irodai túlélőkészlet sorozatunk új erőre kapva mászik ki az árokból, csak mert ideje pár szót ejteni a termékfejlesztésről is.
Vannak az igazán praktikus kis szoftvergyárak, ahol ez a probléma nem létezik, mert az üzleti képlet az, hogy a máshol már bevált terméket egy az egyben koppintják, hiszen az már bizonyítottan egyenlő a sokpénzzel. A termék ilyenkor az összeguberált-összelopkodott kódok totemoszlopa, aminek a tetején vidáman csilingel a pénztárgép. Ilyen helyeken gyakran panaszkodnak a kóderek, hogy nem lehet innoválni, de csak azért mondják ezt, mert nem tudják még, hogy milyen az, amikor kell is.
Na de hogy kell egy új szoftvert megálmodni és formába önteni?
Több iskola is van erre, itt van kezdésnek az ‘I have a dream’ nevű hitvezérelt módszer. Ebben a felállásban az ötlet már megszületett, kétségnek helye nincs. Sem előzetes piaci felmérés nem készül, se validáció, se SWOT analízis, a megvalósíthatósági tanulmány pedig maradjon csak a hitetleneknek. Nagyban gondolkodik a tulajdonos - általában valami szerencsétlen befektető pénzéből - és elkezd fejlesztőket keresni, akik megvalósítják a kvantumhálózatos körömlakkszín elemző hanghullámdetektort, windowsos fejőgépekre. Persze az összes szakértő lepattintja, hogy ez nem lehetséges. Ám a vágyvezérelt ötletgazda erre nem elgondolkozik, hanem inkább addig keres tovább, míg felvesz valakit, aki azt mondja, hogy de lehet.
Ez nagyjából fel is rajzolja a projekt ívét.
A termékfejlesztés addig tart, amíg a pénz.
Mondjuk itt azért meg kell jegyeznem, hogy néha ezek a projektek is sikeresek, már ha a vevőnek több pénze van, mint amennyire ért a fejőgépekhez. Vagy úgy bármihez.
Vagy ha állami a projekt.
Valódi piaci alapú termékfejlesztést szeretnénk inkább? Akkor kikerülhetetlen módszertan az MVP, azaz Minimum Viable Product.
Ha nem volt ezzel még dolgod, hát kb annyi lenne az elképzelés, hogy építünk valami kezdetleges, de működő dolgot, épp csak annyi funkcióval, hogy megoldást jelentsen valami alapvető igényre. Odaadjuk a felhasználóknak, aztán majd építgetjük meg módosítgatjuk az ő visszajelzéseik alapján. Jól hangzik, mi?
Lássuk hát a gyakorlatot.
Valakinek természetszerűleg irányítani kell egy ilyen nagyszabású tervet. Néhány nagyvállalat hisz a technológia erejében. És felsőbbrendűségében.
Hát melyik ért jobban egy rendszerhez, a vezető fejlesztő vagy az aluliskolázott felhasználó?! Na ugye.
Ezzel pedig el is dől, hogy ez egy tech irányította termék lesz. Szabadon lehet a legmodernebb technológiákat végigpróbálgatni, régen vágyott cuccokkal játszani. A backend fejlesztő majd megmondja, hogy mit akar a júzer és a végeredmény pont annyira lesz felhasználóbarát, mint Olga néni a NAV ügyfélszolgálatán pénteken 16:59-kor.
A termék akkor van kész, amikor… hát, tulajdonképpen egy kicsit még refaktorálni kell, meg kiderült, hogy erre az új frameworkre pont nincs integrációs támogatás, és át kell migrálni az egészet egy más adatbázis struktúra szerint, de még három-négy hónap és talán lesz működő login.
Van, aki viszont az üzlet irányította megoldások híve, mert rájött, hogy a felhasználó adja a pénzt.
Az ilyen nagyvállalati környezetben a termékfejlesztés az a tágas virágos rét, ahol a sales munkatársak meg a marketingesek kioldott nyakkendővel, önfeledten szaladgálnak, megszédülve a végtelen lehetőségek bárányfelhős horizontba vesző távlataitól és hagymázas víziókat kergetnek vadabbnál vadabb fícsörökről. Ezeket gondolatban már mind mind eladták. Sőt. Olykor gyakorlatban is.
Némely funkciók egyenesen a sales megbeszéléseken születnek, ahol a kedvesügyfelet ezzel sikerült meggyőzni és már alá is írták a szerződést.
A programozók meg a rét szélén kapaszkodnak a józan ész csenevész kis fájába, mert ők tudják, hogy ezek a funkciók nem léteznek és az se biztos, hogy egyáltalán lehetséges ezeket megépíteni.
A termékfejlesztés addig tart, ameddig az értékesítőket sikerül meggyőzni, hogy ez már az.
Ekkor boldogan beírják a brosúrába és ráígérik a következő funkciót.
Van persze olyan cég is, amelyik a tech driven és a business driven módszer hibáit is szeretné kiküszöbölni és felvesz egy projekt ownert. Aki aztán nekiáll együtt dolgozni a UX designerrel, meg a fejlesztőkkel és a qa-val és nagyon igyekszik, hogy tényleg legyen valamiféle követelménylista, meg kontakt az üzleti oldallal is, meg a felhasználókkal.
Ekkor látja az üzleti oldal, hogy egész összeszedett kis MVP lista van már, úgyhogy biztos van ott még kapacitás és nekiáll átalakítani az MVP hatáskörét. Ha láttad a Barbapapa című mesét, na pont olyan lesz a scope. Akár órákon belül többször is sikerül teljesen új alakot öltenie. Hogy, hogy nem, a tervezett erőforrásigény méretfüggetlen: akár csak két egyszerű funkció, akár 15 atombonyolult cucc, mindig pont annyi fejlesztő kell hozzá, ugyanannyi napra.
Ha valami csoda folytán sikerül megállítani az elszabadult metamorfózist, és alakot ölt A Terv, végre elkezdődhet az érdemi munka.
Itt a fejlesztők már nagyon kínosan szoktak ügyelni, hogy nehogy bárkivel szóba álljanak vagy feltegyenek bárkinek bármilyen ártatlan kérdést, mert akkor a gépezet újra mozgásba lendül, úgyhogy a következő pár hónapban a halk billentyűzetkattogás és elégedett merge sóhajok hangja lengi be az irodát.
Egészen a tesztelési fázisig, amikor kiderül, hogy a végeredmény és a terv nem osztoznak közös dimenzión. Ilyenkor újratervezés közben lecserélik szerencsétlen PO-t és új kör jön.
A termékfejlesztés addig tart, míg végre valaki rá nem jön, hogy ha az eredmény nem tud megfelelni a tervnek, akkor egyszerűen át kell írni a tervet, ‘kuss, én így szállok le’ jeligére.
Tipp:
A harc nem segít. De megosztok veled egy bevált védelmi mágiát arra az esetre, ha valaki újabb ötlettel rukkol elő a termékfejlesztés közepén. Köpj a hátad mögé, vess keresztet és mondd el a következő varázsigét: “Ez egy új követelmény. Írd be a backlogba és majd beütemezzük.”
Az ártó szellem a rémisztő procedúra meg a backlog említésétől általában hanyatt homlok menekülőre fogja.
