Agilis alapelvek: Változás vs tervezés

Az ügyfél-elégedettség mellett az agilitás fontos központi gondolata a változásra való felkészülés. Ügyfélként, megrendelőként ez talán a legvonzóbb ajánlata az agilitásnak, a fejlesztési oldalon ugyanakkor legalább ennyire ijesztő a gondolat: a követelmények a termékfejlesztés késői fázisában is változhatnak. Hol az igazság? Az ügyfél tényleg bármikor meggondolhatja magát? Hogyan tud erre felkészülni a termékfejlesztés?

Nézzük, mit mondanak erről az agilis alapelvek.

A változás fontossága

A hagyományos projektmenedzsmentben változáskezelésként ismert tevékenység, a változások követése és kezelése az agilitásban nem külön tevékenységként, hanem a napi működés részeként jelenik meg.

A második agilis alapelv így hangzik: „Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.” (Eredetiben: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”)

A magyar fordítás sajnos ezesetben sem teljesen pontos, az „elfogadjuk” ige inkább jelent beletörődést, szemben az angol „to welcome”, üdvözöld, fogadd örömmel igével. Persze a gyakorlatban a kényszerű beletörődés gyakoribb reakció a változásra, mint az őszinte öröm, de erről nem feltétlen a változás tehet.

Bontsuk ketté a termékfejlesztés során potenciálisan felmerülő változásokat, vezessük be a pozitív és negatív változások fogalmát.

Negatívnak tekintünk egy változást, ha a már elkészült terméken, termékrészleten azért kell változást eszközölni, akár kidobni a korábbi munkánk eredményét, mert pl.: félreértettük egymást, nem gondoltuk át rendesen a feladatot, nem volt megfelelő szintű a kommunikáció az ügyféloldal és a termékfejlesztési oldal között, stb. A termékfejlesztés rémtörténeteinek és legendáinak jelentős része efféle változásokból fakad, kiváló példák erre az ingatlanfelújítós fail fotók (ide akár egy vicces kép), és általában efféle párbeszédek kísérik:

– Hogy nem gondoltad végig, hogy …?
– Dehát nem mondtátok, hogy …!

Forrás: https://www.awesomeinventions.com/bad-stair-designs/

Ezeket a negatív változásokat kivédhető változásoknak is nevezhetjük. Bármennyire is biztat az agilitás a változás pozitív fogadására, az ebbe a kategóriába eső változásoknak nem kell örülni. Jogos a frusztráció, és nemhogy nem cél örülni ezeknek, de kiemelten fontos az ilyen változások minimalizálása, hisz ezek nem csupán frusztrálóak, hanem költségesek is.

Vannak azonban pozitív változások is. Pozitív egy változás, ha az elkészült termékrészlet alapján olyan információhoz, tudáshoz jutunk, aminek segítségével jobbá tudjuk tenni a terméket. A pozitív változások megteremtésének, serkentésének kulcsa: felmérni, mi az, amit nem tudunk, és megtalálni a legkisebb termékdarabot, aminek elkészítésével már eldönthető, hogy mi a megfelelő irány a folytatásra. Az efféle változások a kutatás-fejlesztés jellegű projektek esetében a legnyilvánvalóbbak, hiszen ott a legkönnyebb felismerni, mennyi mindent nem tudunk. Fontos tehát, hogy a termékfejlesztés során meg tudjuk különböztetni a biztos tudásunkat a feltételezésektől, és utóbbiakat teszteljük, ellenőrizzük, mielőtt ezekre alapozva komoly fejlesztésbe kezdenénk.

Gyorsan változó világunkban egy harmadik változáskategória is megjelenik: a külső, tőlünk független változásoké. Folyamatosan változik a piaci, ipari, politikai, ellenőrzői-szabályozói környezet, jó eséllyel versenytársak is vannak a piacon, stb. Bár ezek a változások nem minden esetben örömteliek, a siker érdekében elengedhetetlen, hogy ezekre is képes legyen gyorsan reagálni a termékfejlesztés.

Ahogy Az agilis jelentése cikkünkben kifejtettük, az egyik legfontosabb szempont, ami segíthet eldönteni, hogy egy szervezetben szükség lehet-e az agilitásra, az, hogy milyenek az esélyei, hogy a termékfejlesztés során nagy mennyiségű változás merül fel.

Az ügyfél tényleg bármikor meggondolhatja magát?

Igen. Mindaddig, amíg elfogadják a változtatások következményeit és költségeit, extrém esetben azt, hogy a teljes elkészült terméket ki kell dobni és nulláról újrakezdeni a fejlesztést. Saját érdekük azonban a változások megfelelő kezelése: a negatív vagy kivédhető változások minimalizálása, lehetőségek szerint felkészülni a külső változásokra, és serkenteni a pozitív változásokat.

A negatív változások kivédésére ad nagyon fontos tippet a negyedik agilis alapelv: „Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában.” (“Business people and developers must work together daily throughout the project.”)

Minden cikkünkben jelezzük, hogy bár az agilitás az IT-ben született, számos más iparágban is használható. Ezért IT-n kívül érdemes szoftverfejlesztő helyett a termékfejlesztő kifejezést használni. A szoftverfejlesztő kifejezés IT-s környezetben sem szerencsés, hiszen itt nemcsak az üzleti szakértők és a programozók együttműködéséről van szó, hanem a teljes üzleti oldal és a teljes termékfejlesztési oldal (minőségbiztosítás, tesztelés, támogatás, tech writerek, üzemeltetők, stb.) együttműködéséről.

A szoftverfejlesztés tapasztalatai szerint a kivédhető változások jelentős része kommunikációs hibákból, gyakran az írásbeli kommunikáció félreérthetőségéből származik. Ezt védi ki a napi szintű együttműködés az összes résztvevő között. Bár rövidtávon ez a megnövekedett kommunikáció növeli a termékfejlesztés költségeit, hosszútávon, pont a kivédhető hibák csökkenése miatt, ez a befektetés megtérül.

Az üzleti oldal és a termékfejlesztés kommunikációjáról bővebben az Advanced Product Owner tréningünkön tanulhatsz.

Hogyan tud felkészülni a termékfejlesztés a változásokra?

„Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete”, mondja a tizedik alapelv. (“Simplicity – the art of maximizing the amount of work not done – is essential.”)

Ez az alapelv arra buzdít, hogy sose készítsünk bonyolultabb terméket, mint ami az adott pillanatban ismert igények kielégítésére elegendő. Természetes mérnöki attitűd a probléma kiterjesztése, általánosítása, elegáns, a következő ötven év során potenciálisan felmerülő problémákra is választ adó megoldás készítése, mégis, a tapasztalatok szerint az ilyen túltervezett megoldások általában feleslegesek.

Minél egyszerűbb (technikailag) a termék, annál könnyebb változásokat eszközölni rajta. Természetesen a már pontosan ismert jövőbeli igényekre fel lehet készülni, nyitvahagyni a megfelelő ajtókat. Mivel ennek az elvnek a megvalósítása nagyon iparágfüggő, az agilis tervezés koncepcióját egy hétköznapi példával tudjuk csak szemléltetni: az agilis termékfejlesztés elején a teljes megoldás előzetes megtervezése helyett, ahogy egy puzzle kirakásakor is, először a sarokpontokat, a kereteket találjuk meg, aztán a részletek a fejlesztés során, az üzleti oldallal történő folyamatos egyeztetés mellett történnek.