Teljesen jogos a felháborodásunk. Miért is kellene minden vonatkozásban mély ismeretekkel rendelkeznünk?
Megfigyelhető trend a szoftverfejlesztésben, hogy a fejlesztőknek egyre több mindenhez kell érteniük. A meghirdetett fejlesztői pozíciók címében ugyan egyetlen fókuszterület szerepel (pl. „senior Java backend fejlesztő”), a leírásból azonban gyakran kiderül, hogy egy igazi ezermesternek és polihisztornak kell lennünk, aki közben kiváló soft skillekkel is bír. Fullstack, devops, TDD, adatbázisok, konténerek, elosztott rendszerek, jó kommunikációs készség, DDD – ezekhez hasonló buzzwordök kombinációját találhatjuk a kiírásokban.
Az, hogy egy fejlesztőnek sok technológiához kell értenie, mindig is alapvető elvárás volt, nincs ebben semmi meglepő. Legfeljebb a technológiák sokasodtak meg. Ami viszont sokkal érdekesebb, az az, hogy más szakterületekkel (termékfelelős, tesztelő, üzleti elemző, üzemeltető, UX designer, másik fejlesztő) is szorosan együtt kell tudnunk működni a problémák megoldása érdekében.
A trend hátterében – nem meglepően – a hatékonyságnövelés áll. A különböző szakterületek egyesítése mindig valamilyen cél érdekében történik, ami így egy közös céllé válik megosztott felelősség mellett.
Például devops esetén a release-folyamatért az üzemeltető és a fejlesztő is felel. Vagy: a „hibamentes” szoftverért a tesztelő és a fejlesztő együttesen felel. Vagy: scrumban a termékfelelős és a fejlesztő is felelős azért, hogy egy jól kitalált szoftver valósuljon meg; a PO képviseli az üzleti/piaci igényt, feature-ötleteket hoz, a fejlesztő pedig segít letisztázni a koncepciót, és ügyel arra, hogy a komplexitás kezelhető mértékű maradjon, esetleg ő is megosztja a saját feature-ötleteit a fejlesztés során, amit ugyanúgy közösen megvitatnak.
A kihívás
De hogyan tudnak megosztott felelősség mellett a különböző szakterületeken mély tudással rendelkező egyének egyezségre jutni? Mindenkivel szemben elvárás már (nem csak a fejlesztőkkel szemben), hogy valamennyire értse a munkatársai nyelvét, gondolkodásmódját, így bárkinek bármilyen téma kapcsán lehetősége nyílik challenge-elni a többieket a szervezetben, ez pedig kellemetlen szituációkhoz vezethet.
Példa: A PO nem érti, miért olyan drága egy sztori
➔ Például egy sprinttervezésen azt szavazza meg a csapat, hogy 8 sztoripont az egyik sztori, a PO viszont nem érti, hogy miért ilyen sok, miért nem csak 3, hiszen ez csak ennyi meg annyi feladat, nem is nehéz, bárki meg tudja csinálni, meg egyébként is, egy korábbi csapata ezt a problémát már megoldotta egyszerűen ezzel és azzal az eszközzel, nem is kell fejleszteni, majd szól nekik, hogy mutassák meg nekünk.
Nos, az ilyen beszélgetések sokszor nem kellemesek, mert úgy érezhetjük, hogy nem bíznak eléggé a szakértelmünkben. Miért szólnak bele abba, hogy hogyan kell valamit megcsinálnunk, amikor mi vagyunk a fejlesztők, akiknek a felelőssége a rendszer implementálása? Nem tudunk mit tenni, meg kell próbálnunk túltenni magunkat ezen a sérelmen, és inkább úgy tekinteni a nehézséget okozó helyzetre, mint egy fejlődési lehetőségre.
A másik valószínűleg egyszerűen csak nem ért valamit, vagy az is lehet, hogy tényleg van egy jó ötlete. Jó szándékot kell feltételeznünk, és nyitottsággal kell a másik felé fordulnunk. Kaptunk egy ötletet, legyünk hálásak érte, lehet, hogy jó, és fel tudjuk használni. De ha nem jó, akkor abból is tanulhatunk. Az is lehet, hogy ez egy kiváló alkalom arra, hogy valakivel megértessünk valamit, és ő is tanuljon belőle. De miért is nem tudom vele megértetni? Einstein szerint ha nem vagyunk képesek elég egyszerűen elmagyarázni valamit, akkor azt még mi sem igazán értjük. Tehát abból, hogy a másikat tanítani vagy meggyőzni próbáljuk, mi magunk is tanulunk.
Több pozitív hozadékkal is jár, ha a beszélgetésnek sikerül nyugvópontra kerülnie:
- egy sokkal jobb megoldással a zsebünkben állunk fel az asztaltól, mint ha külön-külön dolgoztunk volna;
- valami újat tanultunk a másiktól;
- mind a ketten a folyamat részesének érezzük magunkat, a bevonódás pedig növeli a megbecsültség érzését;
- a másikat meghallgattuk, megtiszteltük a figyelmünkkel, ami így kölcsönösen jó érzéssel tölt el minket, ezáltal pedig növekszik az egymásba vetett bizalom.
Példa: Nekem, fejlesztőnek fontos a UI
➔ A fordított helyzetet is érdemes megvizsgálni, amikor számomra fontos valami, de nem én vagyok érte a felelős. Például nézzünk egy UX designert, akinek az a feladata, hogy képernyőterveket készítsen egy készülő funkcióhoz. Mint fejlesztő hagyhatnám, hogy egyedül ő készítse el a terveket, hiszen nekem ez nem feladatom. Ekkor azonban a sprinttervezésen – amikor először találkozom a tervekkel, és nincs sok lehetőség már az érdemi változtatásra – elkezdek kötözködni, mert nem tetszik a felvázolt terv.
Jobb megoldás lehet ennél, ha jóval korábban megkeresem a designert, és elbeszélgetek vele. Elmondhatom az ötleteimet, ő is elmondja az övét, és egy jó szándékú, konstruktív beszélgetés kerekedik közöttünk, amelynek a végén egy olyan megoldással állhatunk közösen elő, amivel én is teljes mértékben egyet tudok érteni. Ebben az esetben fontos tisztában lennünk azzal is, hogy a designer is érezheti úgy, hogy a szakértelmét kritizáljuk a megjegyzéseinkkel, és nem bízunk benne eléggé. Persze az a jó munkahelyi környezet, ahol a véleményét bárki bátran elmondhatja, de azért azt nem szabad elfelejtenünk, hogy mi sem mindig viseljük jól, ha nekünk mondják meg, hogyan valósítsuk meg a ránk bízott feladatot. Ha bízunk a UX designerben, nem biztos, hogy mindenbe bele kell szólnunk. Próbáljuk inkább azt a lényegi dolgot megtalálni a UX designer elképzelésében, ami a mi meglátásunkkal szöges ellentétben áll, és próbáljuk meg azt feloldani.
Az eredmény hasonló lesz, mint az előző esetben: jobb megoldás, a megbecsültség érzése és a munkatársak között egyre mélyülő bizalom.
Konklúzió
➔ Sokkal reálisabb az az elvárás, hogy egy fejlesztő tanuljon meg egy nem fejlesztő agyával is gondolkodni, mint az, hogy egy nem fejlesztő ismerje meg a kód belső működését. Ezért a fejlesztőkre hárul az a sokszor nem túl kellemes feladat, hogy lebeszéljenek másokat egy „remek” ötletről, de persze úgy, hogy közben nyitottak is maradjanak, ugyanis bármikor előfordulhat, hogy tényleg egy jó ötlettel fordulnak hozzá.
Nagyon nehéz ezt az egyensúlyt megtartani. Meddig „álljunk ellen” egy ötletnek? Mikor van az a pont, amikor inkább hagyjuk magunkat meggyőzni? És miért pont akkor? Ezeknek a kérdéseknek a feszegetése a személyes elköteleződés mértékének vizsgálatához vezet.
Ha ugyanis hiszünk egy közös célban, és van egy közös problémánk, akkor az adott probléma megoldásában mi magunk is részt fogunk venni. Ha viszont nem érezzük magunkénak a közös célt, és csak a munkánkat szeretnénk jól elvégezni, akkor azt érezhetjük, hogy csak akadályoznak ebben a „remek” ötletekkel, amitől pedig egyre frusztráltabbá válunk. Mindenhez ellenségesen viszonyulunk majd, negativitást sugárzunk, és a felelősségünket még inkább lekorlátozzuk a szűkebb szakterületünkre. A megosztott felelősség csak abban az esetben jó megoldás, ha tudunk és ha akarunk is egy közös célban hinni. Jó tisztában lenni azzal, milyen mértékben is vagyunk elkötelezettek, és pontosan mi okozza bennünk a rossz érzéseket.
Marc Andreessen kockázatitőke-befektető szerint a szoftverek bekebelezik a világot, és egy cég sem tudja elkerülni a sorsát, hogy végül szoftverfejlesztő céggé váljon.
Nyilvánvaló, hogy a világ sokszínűségét nem lehetséges csupán programozói attitűddel kezelni, elkerülhetetlen a nyitottság és önmagunk fejlesztése is, hogy a szoftveres világot másokkal is megértessük. Ez hosszabb távon egy karrierlehetőség is lehet a senior fejlesztők számára.
Egy fejlesztő számára most már nem csupán egy lehetőség az, hogy egy másik szakterületen is jártasságot szerezzen, hanem egyenesen elvárás. Nem kell a másik terület szakértőjévé válnia, de meg kell tudnia érteni a másik gondolkodásmódját. Ezt hívják T alakú képességnek. A T hosszú szára reprezentálja a fejlesztő mély programozói szaktudását, míg a T teteje jelzi a programozó széles látókörét. Így válik lehetővé a hatékony és fenntartható fejlesztés egy olyan környezetben, ahol a munkatársak nyitottan állnak egymáshoz, és emberi módon, közösen egy cél érdekében dolgoznak együtt.
