2018. október 24., szerda

2019-es "álom" fejlesztői eszköztáram :)

Lassan eljön 2018 év vége és beköszönt 2019. És immáron legalább 5 éve, hogy a "mainstream" fejlesztési feladatokból "kiestem", helyette főleg architekt ill. business analyst jellegű feladatokat látok el néhány projektünknél. Viszont próbáltam azért minél kevésbé "visszaesni", bár a Pat Kua által említett "még foglalkozzunk programkód írással" (https://www.thekua.com/atwork/2018/02/5-tips-for-being-an-effective-tech-lead/ 2. pontja) nem nagyon megy, főleg, mivel a tech lead mellett más szerepkörökben is helytállok (business analyst ill. 2. és 3. szintű ügyféltámogatás egyes projektekben). Viszont arra ügyelek, hogy minél jobban lelassítsam a teljes kiesést, így azért néhány szituációban még programozom, ill. olvasok kódot, azaz nem szakadtam el teljesen a kódbázistól:

  • néhány kiosztott feladatnál én vagyok a reviewer (elsősorban olyan feladatoknál, ahol nem az API használat a lényeges, hanem bizonyos algoritmikus / üzleti megoldások, így ugyanis, hogy napi szinten nem kódolok, a forráskód elviségét tudom elsősorban áttekinteni és véleményezni, nem a helyes külső API paraméterezéseket)
  • főleg nagy átadások során (akár UAT, akár éles átadás után), ahol az első hetekben azért sok apróság tekintetében jön visszajelzés, egy-egy, az adott projektnél teljesen "lokális" probléma esetén én végzem el a javítást (szintén általában ott, ahol elvi probléma volt a korábbi megvalósítással, és nem valamilyen rossz paraméterezés)
  • időről időre felmerül kisebb, belső használatú, vagy projektnél egyszer lefutó kis utility-k készítése, ahol messze nem feszítő a határidő, azok közül is van, amit még bevállalok
  • van egy nagy álmom is :) bár alapvetően a projektjeink dokumentálva vannak, még érzek "fehér foltokat" kifejezetten a belső fejlesztői dokumentáció tekintetében (azaz, kellene egy olyan anyag, ami mélyebb/más jellegű, mint az ügyfelek felé átadott informatikai specifikáció, viszont továbbra is főleg a felső szintű áttekintést biztosítja, viszont ezt fejlesztői oldalról, segítve az adott projektben új embereket a minél gyorsabb bekapcsolódásban)

Persze, amellett, hogy igyekszem azért "kódközelben maradni", viszonylag rendszeresen figyelem azokat a változásokat, újításokat, amelyek segítségével az eszköztárunkat hatékonyan lehet bővíteni / fejleszteni. Mi JVM alapú rendszereket készítünk, középméretű (néhány százezer "saját kódsor") nagyvállalati szoftvereket, ahol vagy webszolgáltatás alapú API-t biztosítunk, vagy webes felhasználói felületet, és jellemzően kell más rendszerekkel kommunikálni, ill. oda kell figyelni a nagyvállalati biztonsági és egyéb előírásokra. Java-ban (most már a 8-as verzióban is), illetve Spring keretrendszer, Hibernate, JOOQ viszonylag nagy tapasztalattal rendelkezünk, de, mivel a projektek közül sok már jó néhány éve kezdődött és azóta is működik (rendszeres finomítással/továbbfejlesztéssel), már sok külső könyvtárral ismerkedtünk meg, amelyeknél most már vannak ügyesebbek / jobbak / "teljesebbek".

Ha most, 2018 év végén, 2019-ben kellene új rendszert kezdeni a fenti területen, akkor szívem szerint a következő technológiai stack-et használnám (amiről úgy érzem, hogy nem hátráltatna, és a mostanában nálunk futó nagyvállalati projektkörnyezetben is kiválóan alkalmazható lenne):


A közeljövőben jobban bele szeretném / fogom ásni magam a Kotlin és a kapcsolódó eszköztár környezetbe, hogy lássam, mennyire jól mértem fel, hogy ezzel a nyelvvel hatékonyan előreléphetünk a JVM alapú feljesztésben a Java-hoz képest :)

2018. augusztus 1., szerda

Pengeélen

Nemrég egy igen komoly rendszerfejlesztés/átalakítás első fázisát fejeztük be. Komoly volt az alábbi értelemben:

  • Egy, már öt éve működő (és ezen időszak alatt is folyamatosan bővülő, finomodó) rendszer került szinte teljesen új alapokra, de NEM újraírásra
  • Az öt év tapasztalataiból nagyon sok mindent felhasználtunk és a legfontosabb struktúrális és elvi problémákat sikerült is kezelnünk
  • A rendszer teljes mértékben támogatja a korábbi folyamatokat, ugyanakkor teljesen új folyamatokat és irányvonalat is alkalmaz (pl. elektronikus dokumentumkezelés, érintőképernyős aláírások kezelése, teljes tablet- és mobiltámogatás, ami még nem volt a rendszerben a 2012-es indulásakor)
  • A számos új lehetőség és folyamat miatt az adatmodell (táblák és mezők) száma kb. 40%-kal, a kódbázis pedig kb. 50%-kal nőtt (így lett kb. 440e sornyi saját kód a rendszer aktuális állapotában), ugyanakkor a teljesítmény nem csökkent, sőt több helyen nőtt (a struktúrális átalakítások következtében)
Minden naptári időben kb. 15 hónapot vett igénybe, 5-6 kollégával. Az eddigi pályafutásom talán legkomplexebb feladata volt. Szerencsére sikerrel vettük az akadályt, gyakorlatilag határidőre és egészen jó minőségben sikerült leszállítani a rendszert.

Maga a projekt ütemezési/belső technikai része is érdekes volt: pl. milyen metodikával tudtuk elérni, hogy "nem törtük szanaszét" a rendszert a teljes átalakítás során, erről később írok.

Ami a projekt kapcsán leginkább megmaradt bennem, az, hogy mennyire sokféle területen van szükség "egyensúlyozásra" annak érdekében, hogy a projekt sikeres legyen, és sokszor mennyire nehéz ezen egyensúlyozás végrehajtása. Gyakorlatilag több dimenzióban is folyamatosan "pengeélen" táncol az ember, és bármelyik irányba lép nagyot, abból tuti zakózás lesz.

Ebben a fejlesztésben - mai divatos szavakat használva - voltam business analyst, architect, product owner, tesztelő és ügyfélszolgálatos is (utóbbiak leginkább a kollégák tehermentesítése céljából, hogy legyen idejük és lehetőségük az elmélyült és alapos munkára, legalábbis annyira, amennyire az ütemezés és a feladatok komplexitása ezt lehetővé tette).

Mindegyik szerepkörben voltak nagyon érdekes kérdések, amelyek felmerültek, és nagyon nem volt egyértelmű, hogy mit kezdjen vele az ember. Ennek oka elsősorban a "tipikus nagyvállalati szoftverfejlesztés" háttere volt:
  • A megrendelő részéről nem volt egy dedikált projektfelelős, aki kézben tartotta és priorizálta volna a feladatokat, hanem több üzleti területnek voltak delegált tagjai, akiknek - az egyébként is túlzsúfolt és adminisztrációval telített - napi operatív feladataik mellett kellett (volna), hogy a rendszerrel kapcsolatos elvárásaikat meghatározzák, és olyan szinten dokumentálják, ami alapján már értelmezhető a feladat. Látszott, hogy igyekeznek megfelelni a feladatnak, de erős hátrányból indultak már eleve ezen körülmények miatt.
  • Több üzleti területtől voltak olyan delegált tagok, akik gyakorlatilag nem is ismerték a rendszer aktuális változatát, mivel az még az ő tevékenységüket nem támogatta, de az átalakítás és bővítés után már nekik is ebben a rendszerben kell dolgozniuk. Ez egyrészt kihívás volt (teljesen más fogalomrendszer használata, számunkra sokszor ismeretlen üzleti folyamatok), másrészt jó volt abban az értelemben, hogy kiderült, hogy a támogatott üzleti folyamatok sem úgy vannak teljesen a valóságban, ahogy az a rendszerben működik (mertháthogy nem nagy az eltérés, és erre az adaptációra, amikor a folyamatunk megváltozott, nem akartunk pénzt költeni).
  • Láthatóan mindenkinek a célja a saját elvárásainak kielégítése volt, és nem igazán voltak olyan megrendelői egyeztetések, ahol az egyes üzleti területek egymással tisztázták volna a prioritásokat. Így időnként
  • A napi munka melletti tevékenységnek és a korábbi rendszer "nem ismeretének" volt egy olyan mellékhatása is, amitől egyes megbeszéléseknél egyértelműen az 50 első randi című film jutott eszembe. Voltak olyan folyamatok, amelyeket a tervezési fázisban négyszer, a fejlesztési fázisban szintén négyszer alakítottunk ki/át teljesen, majd a tesztelési fázisban is sikerült alaposan felforgatni egyes területeket. És nem azért, mert az üzleti folyamat változott, hanem azért, mert igazából nincs definiált üzleti folyamat, hanem a szereplők nagyjából így és így dolgoznak, de igazából minden nap egy kicsit másképp. Hiába volt bármi leírva, ha a napi munka mellett nincs idő elolvasni, így, ha egy kérdés újra felmerült, már más volt a válasz, mint korábban (akár egy héttel azelőtt).
  • Mindezek mellett ugyanakkor a teljes projekt egy, a projekt elején készített specifikáció alapján fix határidős, fix költségvetésű projektként ment. Ezért egy idő után a közös érdek mellett (ti. hogy legyen egy jól használható, hatékonyan működő rendszer, ami az üzleti elvárásokat megvalósítja és a felhasználók is szeretik használni a célszerűsége miatt) megjelentek a saját érdekek is (beszállítói oldalon értelemszerűen, hogy ne nyújtsuk túl a projektet, megrendelői oldalon pedig a "ezért a projektért sokat fizetünk, így ez még bele kellene, hogy férjen" merült fel teljesen természetes emberi hozzáállásként).

A fenti körülmények által létrehozott univerzumban minden szerepkörömben érdekes "pengeéles" szituációk voltak. Ezek közül amelyek a legjobban megmaradtak bennem, az alábbiak voltak:
  • business analyst-ként:
    • Ha már letárgyaltunk és specifikáltunk valamit, majd attól elkezdünk eltérni, mennyire hívjam fel erre a figyelmet és kérdezzek vissza, hogy mi az oka a változásnak? Vagy inkább figyeljem meg, hogy mik azok a területek, amelyek "folyamatosan változnak" és ott specifikáljuk úgy a folyamatokat, hogy rugalmasan kezelhető/módosítható legyen?
    • Mennyire kérdezzem ki a valós üzleti folyamatot, mennyire erőltessem a nem tiszta / nem egyértelmű megfogalmazások letisztázását? Látszólag erre a kérdésre egyszerű a válasz, mert legyen minden egyértelmű, ugyanakkor teljesen más az a szint, ami egy, az adott üzleti területen gyakorlott embernek "egyértelmű", és más az, amikor egy, az adott üzleti területen relatíve kevés tapasztalattal bíró fejlesztő számára "egyértelmű".
      • Ez egyébként két irányban is problémát jelentett. A megrendelővel való kommunikációban én voltam a "gyenge láncszem", nekem voltak hiányos háttérismereteim az üzleti folyamatról. A fejlesztő kollégákkal való kommunikációban viszont fordított volt a helyzet, hozzájuk képest én rengeteget tudtam az üzleti folyamatról, amit ők (joggal) nem tudtak.
    • A különböző üzleti területek keveset egyeztettek egymással, és mivel nem volt üzleti oldalon priorizálási felelős, a beszállítónak (nekünk) kellett ellátni ezt a meglehetősen hálátlan feladatot (hiszen itt valakinek mindig "rossz lesz", ha egymással ellentétes elvárásokból kell kihozni "valami jót"). Ugyanakkor muszáj volt ezt megtenni, másképp könnyen halastóvá válhatott volna a projekt, és az még rosszabb lett volna. Viszont ezt a szerepet sem szabad túltolni, mert akkor nagyon rossz híre lesz a beszállítónak a megrendelőnél ("azok a kötözködősök már megint...").
  • architekt-ként:
    • Hogyan legyen az alap úgy felépítve, hogy az üzleti igények folyamatos változása és átalakulása a legtöbb esetben ne alapjaiban rengesse meg a felépítményt, hanem még beleférjen a koncepcionális modellbe? De ne legyen túltolva ez sem, mert akkor meg sosem lesz konkrét rendszer belőle...
    • Lépjünk előre mindig mind a rendszerfelépítés, mind a felhasznált eszköztár tekintetében (cél, hogy ne váljunk "dinoszaurusszá" azzal, hogy görcsösen a már megismert környezetekhez és lib-ekhez ragaszkodunk), de ugyanakkor ne túl nagy lépésben, mert akkor a projekt helyett eszköztanulással töltjük az összes időt.
    • Fontos az üzleti folyamat támogatása, de (majdnem) ugyanilyen fontos a rendszerben a "transzparencia" (problémafelderítésre, auditálásra és belső ellenőrzési feladatokra is alkalmas log-ok), a biztonság (mindenki csak ahhoz férjen hozzá, amihez kell) és a minél egyszerűbb üzemeltethetőség/frissíthetőség. Ja, és persze a teljesítmény is jó legyen :) Szóval ezen területek között is érdekesen lehet "lavírozni", és nagyon könnyű elcsábulni valamelyik faktor erősítése felé a többiek rovására.
  • product owner-ként (bár itt kicsit többről/másról van szó, egy kicsit projekt menedzserként, egy kicsit vezető fejlesztőként és egy kicsit Scrum master-ként is tevékenykedtem ebben a projektben):
    • Hogyan legyenek a feladatok úgy szétosztva a kollégák között, hogy mindenkinek legyen feladata; ne legyen túlterhelve de ne is tudjon "takubakuzni"; miközben figyeljünk az egyes személyek kompetenciájára, aktuális tapasztalatára, erősségeire is, építsünk rá, de engedjük továbbfejlődni/kiteljesedni is - de persze nem a feladatvégzés kárára. És persze, nem utolsósorban, a prioritásoknak és a felépítésnek megfelelő sorrendben végezzük a feladatokat.
    • Ha valamit úgy lát az ember, hogy "nem megfelelő", az kivel milyen módon, formában, lehetőleg előremutatóan legyen kommunikálva.
Szóval, érdekes volt. Sokat tanultam magamról is, meg a világról is, és sikerült továbbfejlődni kommunikáció terén is (bár, néha nem vagyok biztos abban, hogy a továbbfejlődés a megfelelő szó... :) ). De az biztos, hogy ez a projekt is megmutatta, hogy a szoftverfejlesztés egy bizonyos szint felett (amikor komplex feladatokat kell több embernek sok hónapon keresztül megfelelően elvégeznie, folyamatosan változó követelmények mellett) meglehetősen embert próbáló feladat. 
Le a kalappal azok előtt, akik a következő komplexitási szinten (több millió soros projektek, több tucat szereplővel, több éves átfutás alatt) képesek irányítói szerepkörben megfelelően teljesíteni.

2018. április 5., csütörtök

Így lettem anyagilag (és más téren is) sikeresebb

Nemrég olvastam az egyik követett blog-on egy bejegyzést és a kapcsolódó kommenteket arról, hogy lehetünk anyagilag (is) sikeresebbek.

Ennek kapcsán átgondoltam, hogy a saját életemben sikeres vagyok-e, vagy sem. Végül arra jutottam, hogy sikeres vagyok, mert:

  • szerető családban élek, a napi összezörrenéseken túl nincs konfliktus :)
  • alapvetően az egészség is megvan, bár a kor már mintha kezdene látszódni...
  • szép helyen élünk, megfelelő infrastruktúrával, hitel nélkül
  • a család havi bevételei fedezik a kiadásokat, van lehetőség megtakarítani is, és közben egy, számunkra teljesen normális életszínvonalat tudunk biztosítani magunknak, amelyben megvan mindenünk, amelyre igényünk van (igaz, nincsenek luxus igényeink)
  • normális munkahelyen dolgozom, a főnökeim és a kollégáim is megbecsülnek, és én is őket, abszolút működik a közös munka és teljesen ismeretlen a "másik fúrása"
  • azt gondolom, hogy azon emberek többsége, akiket akár a magánéletben, akár a munkán keresztül megismertem, normális és korrekt embernek tart, legalábbis ezeket a visszajelzéseket kapom :)


No, de mit tettem én ezért? Jó kérdés, és nem is nagyon tudnék rá válaszolni, mert sok esetben tyúk-tojás kérdésről van szó (példa: azért tudok olyan ember lenni, amilyen, mert jó munkahelyem van, vagy azért lehet jó munkahelyen, mert olyan ember vagyok, amilyen?). Ezért csak úgy, abszolút véletlenszerű sorrendben, ahogy eszembe jutott, leírok pár dolgot, amiről azt gondolom, hogy hozzájárultak az én utamon ahhoz, hogy elérjek oda, ahol jelenleg vagyok:

  • rendszeres sport, legalább gyerek- és fiatalkorban: szerencsére szüleim ragaszkodtak hozzá, hogy sportoljak kb. 8 éves koromtól kezdve suli mellett, és addig próbálkoztunk, amíg nem találtunk olyan sportágat, amit nagyon megszerettem. Nekem ez a kajakozás volt, 6 éven keresztül suli előtt és suli után edzésre jártam. Valószínűleg sokat segített abban, hogy a sulit is jobban bírtam, illetve a szervezetem kellően megedződött. Később volt még harcművészet, néptánc, súlyzós edzések, futás, úszás, egészen kb. 26 éves koromig legalább heti 4-5 alkalommal edzettem. Sajnos azóta visszaesett a dolog, és érzem is...
  • hitelesség: ha valamit megígérek, azt betartom. Ha esetleg nem sikerül és már látom, hogy nem fog, akkor jelzek róla annak, akinek megígértem. Ezt nagyon-nagyon fontosnak tartom, két okból is:
    • egyrészt viszonylag kevesen művelik (sajnos), ezért csak ezzel az egy dologgal nagyon "ki lehet emelkedni" a tömegből,
    • másrészt ha valaki hiteles, akkor tényleg bízni fognak benne, annak minden előnyével (és felelősségével) együtt
  • problémamegoldási hajlam: ha feladat van, akkor arra megoldást kell találni, és nem azon gondolkodni, hogy miért nem én, miért nem most és miért nem úgy. Nem tudom, mi kell hozzá, hogy ez ki tudjon alakulni (én sokat olvastam, ez biztosan segített), de ez is egy nagyon fontos tulajdonság.
    • kilépés a komfortzónából: az előzőhöz szorosan kapcsolódik. Olyan feladatunk van, amit még előtte nem csináltunk? Nem berezelni kell tőle, hanem utánamenni :)
  • prioritások kezelése: sajnos sokszor hajlamosak vagyunk a leggyorsabban és legkényelmesebben intézhető dolgokat intézni először, és a nehéz (és sokszor nagyon fontos) dolgokat halogatjuk. Aki ezt képes megfordítani, és először a valóban fontos feladatokkal végezni, az minden normális munkáltató számára kincset ér :)
  • gyermeki nyitottság, érdeklődés fenntartása: minden nap érjen úgy véget, hogy tanultunk aznap valami olyat (bármit, akármilyen témában), amit aznap reggel még nem tudtunk. Lehet ez családi dolog, munkával kapcsolatos, bármilyen hobbival kapcsolatos, a lényeg, hogy dolgoztassuk meg minden nap a kis buksinkat.
  • empátia, figyelmesség, odafigyelés a másikra: ugye nekünk is jól esik, ha valaki törődik velünk, figyelmes és észreveszi, ha valami, számára apró dologgal nekünk nagy segítséget tud adni (akár csak azzal, hogy figyelmesen meghallgat bennünket)? Legyünk mi is ilyenek a számunkra fontos emberek számára, de akár bármilyen hétköznapi helyzetben is lehetünk figyelmesek. 
Van még persze egy csomó dolog biztosan, de a fentieket érzem talán a legfontosabbnak. 

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... :)