A frissen felvett kolléga speciális kérései – tanulságokkal.

A frissen felvett kolléga speciális kérései – tanulságokkal.

A nem is olyan régen felvett kolléga – nevezzük Andrew-nak – két különleges kéréssel állt elő:
1) Péntekenként vonattal hazautazna a családjához, ezért hamarabb szeretne elmenni. Cserébe a többi napon tovább marad bent.
2) Szerinte túl sok adminisztrációt végzünk, és hát ő ugye fejlesztő. Szóval mi lenne, ha kihagynánk a bürokráciát a szoftver fejlesztésből?

Mindkét kérdésben értem az elgondolást, és mindkettőre nemet mondtam. Miért is?

Ha a munkaidőről van szó, akkor számomra világos, hogy a ráfordított idő nem feltétlenül arányos az elvégzett munkával. Ezért nem az időt, hanem a teljesítményt – azaz lezárt projektet, lezárt change request-et - díjazom. Ha valaki elvégzi a dolgát és hamarabb hazamegy, semmi gond. Úgyis lesznek olyan helyzetek (IT-ban mindig vannak), amikor közeleg az átadás és bent kell éjszakázni, esetleg hétvégén kell élesbe tolni valamit.

De egészen más tészta az, ha valaki menetrend szerint hamarabb megy haza. Ugyebár ez már jogi kérdés is, hogyan is van a munkaidő megfogalmazva a munkaszerződésben. Mint főnök, nekem be kell tartanom a szabályokat, és nem szabad a munkatársakat a munkaidőn túl dolgoztatni. (legalábbis nem formálisan)

Na most az adott fejlesztő központ, ahol Andrew is dolgozik, a cégünk egyik gyára mellett van. Emiatt a gyári munkásokra és a szoftver fejlesztőkre ugyanazok a szabályok vonatkoznak. Például a fejlesztőknek tilos öltönyben dolgozniuk. Ugyanúgy kapnak kezeslábast, mint a szalagmunkások, és ez a javasolt irodai viselet. Ugyanabba az étkezdébe járnak az emberek, ugyanott parkolnak, és ugyanazokat a hirdetményeket olvassák.
ÉS ugyanannyira kötött a munkaidő is. Ha a gyári munkás nem maradhat bent minden nap 15 perccel tovább, hogy pénteken 1 órával hamarabb hazamehessen, akkor egy fejlesztő sem teheti ezt meg.
Ha egyvalakivel kivitelezek, akkor bárki bármikor előállhat hasonló kérdéssel – mert precedenst teremtettünk. Azután pedig csak idő kérdése, hogy a gyári munkások (és a szakszervezet) ezt megtudja, és következményei legyenek az ügynek.

Úgyhogy nem, nem lehet, nem csinálunk precedenst. A fejlesztő és a gyári munkás egyenlő, ugyanazok a jogaik, mégha a munkájuk különböző is.

Andrew másik kérése a folyamatokra és az adminisztrációra vonatkozik. Nálunk kötelező evidenciákat gyűjteni a fejlesztés különböző szakaszaiban. Például nem állunk neki egy olyan igénynek, amit az üzleti oldalon egy manager jóvá nem hagyott. Nem kezdjük el a fejlesztést addig, amíg én rá nem bólintottam. Nem tesszük ki élesbe a változtatást, amíg az üzlet le nem ellenőrizte, és bele nem egyezett az éles indításba. Utána pedig visszajelzést kérünk a telepítés eredményéről.
Azt értem, hogy egy fejlesztő a problémára szeret összpontosítani. De a terep ingoványos: mi van, ha egymásnak ellentmondó igények érkeznek? Mi van, ha az egyik felhasználó szerint szükség van egy változtatásra, benyújtja az igényt, de a többiek szerint nincs rá szükség? Hogyan priorizálunk a különböző fejlesztések között? Mi van, ha egy változtatás üzleti kárt okoz, akkor ki a felelős? Mi van, ha lezárjuk a fejlesztést, aztán kiderül, hogy jól el lett szúrva minden? És végül, de nem utolsósorban: hogyan tud a fejlesztő manőverezni a céges politikai viszonyok között?
Na ezért szükségesek a fejlesztési folyamatba ellenőrző pontokat illeszteni, hogy megvédjük magunkat, és erről papírunk is legyen.

Nem utolsósorban pedig azért, mert a rendszer elég nagy, komoly pénzekről van szó, nem lehet csak úgy hasraütésszerűen változtatni rajta. Mert vannak auditorok, akik árgus szemekkel figyelik a kezünket, és megkérdezik: azt ott ki hagyta jóvá, ki ellenőrizte, miért lett megváltoztatva?

Ha nem tudunk válaszolni és hitelt érdemlően előadni a bizonyítékokat, akkor a rendszer, a rendszer által kezelt adat nem lesz hiteles, és ennek súlyos következményei lehetnek.
Egy tőzsdén szereplő cégnél nem lehet félvállról venni ezeket a dolgokat.