Mindig terméket szállítok, bármit is kértek.

Tételezzük fel, hogy van egy olyan hihetetlenül szerencsés állapot, amikor a megrendelő nem egy projektre szerződik velünk, hanem Ő mondja ki, hogy termékszállítást kér. Ez azért nagyon kivételes állapot, mert a projektalapú működés összes buktatóját ilyenkor lehetőségünk van pénzért, tisztán, transzparens működés mellett elkerülni, kijavítani.

Arra kérdésemre, hogy ha a “projektszállítás eredményeképpen előálló digitális termék nem váltja be a hozzá fűzött üzleti reményeket, a megrendelő szerint ki lesz a hibás?” tízből kilencszer azt a választ kapom, hogy “a szállító”.

Tehát a szomorú valóság az, hogy  bármennyire is szeretnénk azt hinni, hogy szoftverfejlesztő cégként projektre szerződünk, a megrendelők fejében valójában mindig terméket szálltunk, és a termékért tesznek minket felelőssé.

Ha az ügyfél rossz üzleti modellt választ, vagy ami még rosszabb, azt hiszi(!) hogy kidolgozott egy üzleti modellt, miközben nem tudja hogyan kell valójában digitális terméket fejlesztetni, akkor valójában az összes olyan kockázat, ami ezeknek a kérdéseknek a nem kezeléséből fakad, a szoftverfejlesztő-beszállító asztalán landol.

Amikor (és nem “ha”) eljut odáig a helyzet, hogy a szoftverfejlesztő-beszállítónak elő kell vennie a szerződést, mert az ügyfél miatt már ott tart, hogy a projektszállítást azzal kell megvédeni, hogy mire szerződött, akkor valójában megette az egészet a fene.

Ez az ügyfél többet rendelni tőle nem fog, és mindig felmegy a vérnyomása, ha a beszállító neve előkerül.

Ez exponenciálisan igaz, ha ráadásul a fejlesztések során kialakult függőségek miatt értelmetlenül drágává és nehézzé vált a beszállító cseréje… nehezen tud tőle a megbízó megszabadulni.

A szerződés nem fog megvédeni egyetlen beszállítót sem attól, hogy hogyan érzi magát az ügyfél, amikor a beszállító nevét kell kiejtenie.

Egyetlenegy dolog tud segíteni, Mi magunk.

Már az ajánlattétel előtt alaposan elő kell készíteni  azt a három stratégiát, amit egy szoftver termékfejlesztés során folyamatosan jelenlevő és párhuzamosan működtetni szükséges területeken érvényesíteni kell.

A három stratégiai dimenzió

Nem egymást lineárisan követő lépésekről van szó, hanem egymásba fonódó folyamatos tevékenységekről.

• Folyamatos tervezés: Milyen stratégiát követek, amikor a tervezéssel foglalkozom
• Folyamatos szoftver szállítás: Milyen stratégiát követek, amikor fejlesztem a szoftvert, átadom a szoftvert, élesítem a szoftvert
• Folyamatos Utógondozás >>> piaci visszajelzésekre reagálás, garanciális időszak, utánkövetés: bármilyen élesítés után, milyen stratégiát kell követnem ahhoz, hogy a lehető legjobb szolgáltatást nyújtsam

Mondhatnánk, hogy a projektszállítás a projekt átadása után véget ér. De nem, nem ér véget. Akkor ér véget, amikor az átadott projekt garanciális ideje lejárt. Ráadásul a garanciális időszakban elég komoly fejlesztési igények kerülhetnek elő. Ezek esetében mikor kezdődik a garanciális idő? Amikor az eredeti projektet átadtam vagy amikor ezeket a további fejlesztéseket átadtam?

A hibajavítások esetében a  garanciális időszak hogyan alakul?

Ha javítottam egy később észrevett hibát, az adott javításra vonatkozó garanciális időszak hogyan alakul?

Egyáltalán, gondolkodtunk arról, hogy egy szoftvertermék várható élettartama mennyi idő, vagy milyen feltételekhez kötött?

Ha még nem válaszoltunk ezekre a kérdésekre, akkor itt az ideje összeülnie a fejlesztői és jogi területeknek és pótolni ezt a hiányosságot, frissíteni az ASZF-et.

Legelső tennivalók az egyes stratégiai dimenziókban

Az, hogy mi hogyan szeretnénk dolgozni, az egy dolog. Hogy bele tudjuk-e venni a szerződésbe, már izgalmasabb, de még mindig mellékes ahhoz képest, hogy az ajánlatadási szakasz legelején el tudom-e az ügyfélnek magyarázni, hogy ahogy mi szeretnénk működni, abban neki mi a value proposition? (megfogalmaztuk ezeket magunknak?)

A három működési dimenziót, három teljesen különböző stratégiával kell lefedni.

Egy általános stratégia a teljes értékláncon értelmezett működést nem tudja önmagában lefedni, kiszolgálni.

Ennek részben az az oka, hogy nagyon különböző emberekre, nagyon különböző erőterekben van szükség.

Pl.: A fejlesztői csapatot magasabb szintű üzleti tervezési feladatokba közvetlenül nem biztos, hogy bevonjuk. Az üzleti döntéshozókat a csapat szinten történő feladatok bontásába, tervezésébe, architekturális kérdések megvitatásába megintcsak nem valószínű, hogy bevonnánk.

A szoftvertermék szállítói stratégiák ott kezdődnek, hogy kik a szereplők, akikkel számolhatok, mert eldönthetem, és kik azok, akikkel számolnom kell, mert adottság.

Ha nem ismerem igazán(!) a szereplők körét, akikre szükségem van ahhoz, hogy a tervezési folyamatokban, a szállítási folyamatokban, illetve az utógondozási folyamatokban eredményesek tudjunk lenni, akkor a stratégiáink valójában ábrándok, vágyak halmaza tud csak lenni, függetlenül attól, hogy szakmailag és logikailag hibátlan munkák-e. Strategizálunk, vagy évfolyamdolgozatot írunk?

Ugyanez igaz azokra, akik az adott lépésben akadályozók(!) tudnak lenni. Mindig fel kell tárnunk, hogy annak, aki kapcsolatba kerül a szállítási helyzettel, mik a motivátorai:

• mikor akasztaná meg,
• miért akasztaná meg,
• hogyan akasztaná meg a folyamatot ha egy helyzet előáll.

Artifaktok, fizikai eszközök

Az egyes szereplőkön túl, mindhárom működési terület stratégiáját alapvetően fogja befolyásolni azoknak az Artifaktoknak a köre, amiket muszáj létrehozni és működtetni.

Ezek az artifaktok konkrét, kézzel fogható, bármilyen termékfejlesztési üzleti környezetben önálló értéket képviselő itemek.

Pl.: business model és lean canvas-ok, backlogok, kanban falak, chartok, üzleti logikai folyamatábrák, user journey-k.

A használni kívánt artifaktokat még az ajánlatadási szakasz előtt értelmeznünk kell és aktívan figyelembe kell vennünk a működési dimenziók strategizálása során.

A három működési dimenzió és a hozzájuk tartozó stratégia működtetése és finomítása minden szinten mindennapos tevékenység kell legyen!

És végül

“Tedd, vagy ne tedd. De ne próbáld!”

A fentiekben végtelenül határozottnak kell lenni. A magunk és megbízóink érdekében egyaránt.

Próbálgatni azért nem szabad, mert ilyen esetekben szinte mindig a megbízói akarat fog érvényesülni, ami többnyire azonos a rövidlátó üzleti gondolkodással (nem rosszindulatból, hanem a speciális tudás és tapasztalat hiánya miatt), és ez a szövetségeseinket, és saját kollégáinkat könnyen csalódottsággal töltheti el.

Ugyanakkor karakán kiállással és jól felkészült szakemberekkel, a megbízás lehetőségének legelső pillanatától kezdve alkalmazott tudás és value proposition átadásával, már reális esélyünk van fejleszteni a megbízóinkat mindannyiunk érdekében.

Tornai Balázs

Több mint 15 év tapasztalattal rendelkezik folyamatmenedzsment, termék-, illetve szervezetfejlesztés és módszertani tranzíció területeken. Dolgozott telekommunikációs, kereskedelmi, egészségügyi és gyártó szektorban, startupokkal és software-fejlesztő cégekkel.
Az agilis módszertani átállás során a szervezetek egységnyi időre vetített termelő képessége átlagosan 150-300%-kal nőtt. A HVG Akadémia, Agile Recruiter sorozatának módszertani vezetője.