2018. január 23., kedd

A vezető fejlesztővé válás rögös útja

Épp a minap futottam bele az alábbi blogbejegyzésbe:

https://simpleprogrammer.com/2018/01/22/accidentally-lead-developer/

Nekem nagyon "betalált" ez az írás, mert egy ilyen jellegű "átalakuláson" haladok már én is jó néhány éve, csak én, a cég (kis) mérete miatt még messzebb kerültem a fejlesztőtől, nemcsak vezető fejlesztői irányba, hanem architect és business analyst irányokba is (ezeknek a szerepköröknek sajnos nem ismerek jól értelmezhető magyarítást, bocsi).

Fejlesztői szemmel tekintve a mostani feladataimra, időnként úgy érzem, hogy nem is dolgozom, hiszen a tevékenységeim egy jelentős részének nincs közvetlenül látható jele a készülő rendszerekben. Ez az egyik oka annak, hogy néha nagyon nehéz meghatározni a következő feladatokat és lépéseket. Magamnak kell kitalálni, hogy mit kell ahhoz tennem, hogy a projekt határidőre elkészüljön, az adott időkereteken belül elvárható minőségben, és a projektcsapaton belül mindenki kellő mennyiségű és típusú feladattal bírkózzon (ne túl kevéssel, de ne is túl sokkal; jelentsen kihívást neki, de ne megoldhatatlan szintű ugrással; a feladatok segítségével is legyen lehetősége a szakmai fejlődésre stb.).

Egyébként messze ez a legnehezebb feladat, a megfelelő "erőforráskezelés" (ezúton is elnézést kérve a kollégáktól, hogy őket is beleértem ebbe a gyűjtőszóba). De ezen kívül is számos olyan kérdés van, amelyre a végső választ a projekt vezető fejlesztőjének kell kimondania, még akkor is, ha közben azért kap segítséget a többiektől (nálunk szerencsére kap :) ).

Néhány példa az "egyéb", a fejben zsongó kérdésekre:
  • Ha egy már élesben futó projekten van egy nagyobb továbbfejlesztés, lehet-e olyan "technical debt" csökkentést is bevenni a feladatok közé, amely segítségével legalább szinten lehet tartani a problémásabb gócpontokat, vagy - ha szerencsénk van - csökkenteni lehet azokat?
  • Eljött-e már az ideje a rendszer által használt technológiák frissítésének? Ha igen, melyiknek, és mennyivel ugorhatunk előbbre? Az sem jó, ha nagyon elmaradunk a frissítésekkel, de az sem feltétlenül az üdvözítő út, ha mindig mindenből a legfrissebb verziókat használja az ember. Főleg akkor, ha nem tarthatja kézben az éles környezetet és nincs lehetősége nagyon gyakori, kvázi "funkciónkénti" élesítésre.
  • Ha az új funkciókat (vagy akár egy új rendszert) nézünk, akkor a már meglevő és ismert technológiai eszköztár elegendő és megfelelő rá? Ha nem, akkor mi az, aminek a megismerése a projekttel együtt szükséges (új keretrendszer, új lib, új nyelv, új fejlesztőeszköz, ...)? Mennyi időt és energiát kellene fordítani az ismerkedésre, mielőtt a döntés meg kell hozni, és van-e ennyire lehetőségünk?
  • Mennyi időt lehet és érdemes fordítani a csapat mentorálására közösen illetve egyedileg is? Hiszen, ha mondjuk öten dolgoznak egy munkán, és sikerül a hatékonyságukat növelni némi időbefektetéssel, akkor lehet, hogy megéri a dolog. Tőlem ugyan időt vesz el, de összességében a projektben bőségesen megtérül ez a befektetés.
  • Kinél mi az a tényező, ami motiválja? Van, akit az motivál, ha látszólag "agyonnyomják" feladatokkal, mert ilyenkor "érzi, hogy él", és fel tud pörögni. Van, aki viszont pont az ellenkező módon reagált egy ilyen "agyonnyomásra", így nála másképp érdemes a feladatkiosztásokat végezni. Van, aki egészen megbízható időbecsléseket tud adni a feladatokra, de van, aki tipikus alábecslő, tudni kell ezt is a helyén kezelni.
Nem egyszerű kérdések, és sajnos nincsenek rájuk egyértelmű válaszok sem. De ez természetes is, hiszen sokszor jóval egyszerűbb programozási kérdések esetén sincs egyértelműen jó vagy rossz válasz, hanem létezik sokféle megoldás, mindegyik saját erősségekkel és gyengeségekkel felvértezve.

Igazából azt, hogy sikerült-e jól elvégezni a házi feladatot, nem is lehet objektíven mérni, hanem a környezet visszajelzései azok, amelyek rámutathatnak a problémákra, vagy amelyek jelezhetik, ha valami jó úton halad:
  • Az ügyfél visszajelzések száma és minősége.
  • A teljesítés paraméterei (időben megtörtént-e, megfelelő minőségben megtörtént-e).
  • A kollégák direkt és indirekt visszajelzései a feladatok, a projekt és a vezető fejlesztő tevékenységeinek tekintetében.
  • Ha megy már a rendszer 3-4-6-8-10 éve, és folyamatosan vannak igazítások rajta, de azok még mindig építhetők a korábbi elvi vázra, vagy egyértelműen meghatározható, hol kell az elvi vázon bővíteni/módosítani anélkül, hogy "kettétörnénk" a rendszert.
Így, ha sikerül tartani a határidőt és azon belül egy elfogadható rendszerminőséget, és a kollégák részéről, valamint az ügyfél részéről sincs nagy elégedetlenkedés / visszhang, akkor jöhet a vállonveregetés, és a következő feladatra koncentrálás... :)