Egy­két­há

Akkor egykéthá…. Ez mennyi? Hányat mutattál? Ez tizenhárom, te meg Dávid huszonegyet? Akkor beszéljünk róla.

Tipikus, mindennapos beszélgetés náluk. Egyúttal a működésünket, bevételeinket, munkáinkat alapvetően befolyásoló kis szösszenet, a becslés, az ún. Planning Poker eszközzel. Az Integral Vision-ben mi nem órákat, hanem a sokak által ismert story pointokat használjuk becslésre, és nem a feladat elvégzési idejét, hanem a komplexitását becsüljük meg. Az adott funkció fejlesztése egy junior fejlesztőnek több idő (akár kétszer, háromszor annyi), mint egy senior fejlesztőnek, de ettől a funkció nem lesz bonyolultabb.

A becslés számomra, mint a megrendelővel szoros kapcsolatot tartó munkatársnak nagyon fontos. Ezzel az információval tudok segíteni az ügyfélnek azzal, hogy el tudja dönteni, hogy egy adott fejlesztés (például egy új listanézet, egy új rendezési mód a listában, akár csak egy gomb a főoldalra) megéri-e neki, fontos-e annyira, hogy erre pénzt költsön. Vagy abban, hogy a fejlesztéseket egymáshoz képest súlyozni tudja és mindig olyan feladatokkal haladjunk, ami ár-érték arányban a legoptimálisabb.

Ügyfeleinkkel egymást partnernek tekintjük, a döntéseket közösen hozzuk, mindannyian a fontos információk birtokában. Ez elméletben jól hangzik, mégis számtalan nehéz helyzetben találtam már magam a becslések kapcsán, amik olykor rombolták a bizalmat, vagy kellemetlen kompromisszumokra kényszerítettek bennünket.

A becslés nem volt pontos

Persze sosem az a baj, hogy ha túlbecsültük. A nehézség inkább akkor szokott keletkezni, amikor egy komplex rendszer egy eleméhez hozzányúlunk, esetleg harmadik félhez való kapcsolódást érint a fejlesztés (például CRM, banki fizetés). Vannak olyan feladatok, melyek komplexitása vagy csak nagyon sok energia-befektetéssel tárható fel előre (azaz nagyon sok időt kellene a becslésre fordítani), vagy fejlesztés közben előkerül egy olyan nem várt akadály, amit csak nagyobb idő-energia ráfordítással lehet kezelni. Ilyenkor az előzőleg becsültnél költségesebb lehet a megvalósítás.

A funkcióba az ügyfél olyat is belértett, amit mi nem

Vannak tipikus témakörök, amik az internetet gyakran használók adottnak vesznek és kimondatlanul beleértenek más funkciókba. Alap, hogy webshop levelet küld a vásárlásról. Természetesen az oldalon az adminok statisztikákat nézhetnek meg a felhasználókkal kapcsolatban. Említésre sem méltó, hogy az egész alkalmazás reszponzív, minden funkció működik mobilon, tableten is. 

Nem volt elég információ

A migrálni kívánt adatbázis tele van hibás adattal. Az előző fizetési szolgáltató máshogy kezelte a kerekítéseket, mint az, amire váltottunk. Mégis több nyelven van szükség az oldalra. Egyes termékek méretét leíró paraméter mégsem csak egy szám. 

Az ügyféllel együtt egy bizonytalan problématérben egyensúlyozunk. Mindkettőnk pénze múlik rajta, hogy elegendő információt tudunk-e előre feltárni ahhoz, hogy a becslésünk nagyságrendileg pontos legyen. Én azzal tudok segíteni, ha kérdezek, próbálom feltárni, amennyire lehet előre a fontosabb funkciókat, az elképzeléseket. Gondolok arra is, ami implicit, merítek a tapasztalataimból, rákérdezek. Az ügyfelek pedig segítenek nekem, magyaráznak a termékükről, a témájukról, én pedig megértem egyre jobban és jobban, hogy mi lehet fontos egy régésznek, egy tetőfedőnek, vagy egy pályavasút-üzemeltetőnek.

Egy webalkalmazás sosincs teljesen kész. Még egy fejlesztést sem zártunk azzal, hogy ne lettek volna még ötletek a továbbfejlesztésre, hogy lehetne még kényelmesebbé, még biztonságosabbá, még felhasználóbarátabbá tenni az oldalt. Minden élesítésben benne vannak a megkötött kompromisszumok, egyszerűsítések. Egy ilyen kompromisszumokban gazdag munkakörnyezetben a bizalmatlanságnak nagy ára van. Akkor tudjuk a megfelelő eredményt elérni, akkor hatékony az együttműködés, ha kölcsönösen megbízunk egymásban. Ha az ügyfelek meggyőződnek arról, hogy amit mondunk, az megfelel a valóságnak. Annak a valóságnak, amit abban a pillanatban tudunk. És a projekt érdekében együtt utazunk a hullámokon.