Keresés

Hirdetés

Új hozzászólás Aktív témák

  • strogov

    senior tag

    A probléma, hogy az IT gyors változása (nem csak fejlődés) nehezen összeegyeztethető az egyetemen állandóságával. Ráadásul az IT munkakörök 99%-a szakmunka amihez fölösleges egyetemre járni. Megjegyzem minden szakma 99%-a szakmunka, és a maradék 1% 99%-a is favágás.
    A gyors változást az IT munkahelyek se tudják követni. Olyan feladatkörök jönnek létre amik korábban nem voltak, és nehéz megállapítani az alkalmasságot egy 20 éve ott dolgozónál ha nincs se képzés, se időszakos felmérés. Ha sikerült a ticket-et kipipálnia akkor ért ahhoz IS.
    A felmenő rendszer képzés nélkül komoly anomáliákat szül. pl. Kiadnak valakinek API tervezést mert ő már 10 éve senior fejlesztő, és ő a legtapasztaltabb fejlesztő a cégnél. Eleve hülyeség, hogy fejlesztési tapasztalat alapján bíznak meg valaki tervezéssel. Egy senior kőműves se jó ha nekiáll házat tervezni ... mégis nap mint nap használunk (szidjuk mint a bokrot) fejlesztők által kitalált interface-eket, látunk fejlesztő által tervezett DB-t (mer' ahhoz IS ért), sőt ha elég "senior" akkor még az UX-be is bele akar szólni.

    Az egyetem feladata szerintem az lenne, hogy mérnököket képezzen. Olyan embereket akik képesek egy adott szakterületen algoritmusokkal, definíciókkal bizonyíthatóan működő tervet készíteni egy adott feladat megoldására. Ez a bizonyíthatóság ma teljesen hiányzik az IT "tervezés" 99,99999%-ából. Ötletelés van, meg "valószínű", "jó esetben" és persze a tapasztalat: "Ez XYZ cégnél már működik, úgyhogy ez jó." Sok esetben még a józan paraszti ész is hiányzik belőle nemhogy a terv. Nem csak sufni cégeknél, hanem a világ legnagyobb vállalatainál is.

  • strogov

    senior tag

    válasz Ribi #91 üzenetére

    Fejlesztési elvek elég lassan avulnak el, tervezési elvek pedig még lassabban. Technológiák relatív gyorsan váltják egymást, de pl. aki 20 éve nekiugrott a java-nak az 20 év múlva is jól fog keresni vele ... és már akkor sem volt új technológia. A scrum lassan 30 éves, és 20 éve már mi is használtuk. Attól, hogy mutációi jönnek létre az alap ugyanaz marad ... vagy pillanatok alatt megérted miért kellett mutálódnia.

    Anno még középiskolás voltam, és nem értettük, hogy egy barátom apja (akit nagyon tiszteltem) hogyan tud 3 nap alatt megtanulni ~2 ezer oldalnyi anyagot egy pár hetes szakkönyvből. Azt mondta majd megértjük ha mi is 20+ éve csináljuk. Pár éve volt egy project amiben 12 ezer oldalnyi doksit kaptunk, hogy dolgozzuk fel, majd beszéljünk. 5-en voltunk senior-ok, hétfőn kaptuk az anyagot, csütörtökre mindenki feldolgozta, megbeszéltük, és mindenki még egy-egy prezentáció is belefért a saját a feladatáról, és a hogyanról.

    "Üzleti igényeket kell kielégíteni. Ha az elképzelésed alapján készülne a szoftver, akkor"

    Te arról beszélsz miért nem akarsz tervezni. Én meg arról, hogy a szakmunkások 99%-a nem is tud. Én is vettem részt sok-sok céltalan bolyongásban, csak tudom milyen az amikor értelmes PM-mel, értelmes BA-val dolgozok, és így láttam már, hogy lehet ezt jól is csinálni.
    Azóta nem szeretek igen emberekkel együtt dolgozni, legfeljebb muszáj. Kimegy ügyfélhez és mindenre igent mond. Az ilyen traktort vezessen ne project-et ... vagy inkább azt se.

  • strogov

    senior tag

    válasz cucka #102 üzenetére

    "meg lehet oldani, lehet olyan szerződést kötni, amiben a hibákért kötbért fizet a beszállító, szoftveriparban is. Két dolog miatt nem teszik"

    Én az elmúlt 20 évben mindig olyan cégnél dolgoztam amelyik bizonyos ideig garanciában javította a hibákat. Volt olyan project ahol 3 hónapig, volt ahol 2 évig. Mindegyik üzleti szoftver, nem űrrakéta.

    És mindegyik cégnél pszeudo kódban is kommunikáltunk. Volt amikor ügyfélel is. Folyamatábra nélkül meg elég nehéz workflow-t fejleszteni. Ha nem triviális a folyamat akkor mindig egyeztetek ügyfélel is folyamatot, és eddig mindenki megértette a folyamatábrát.

    [ Szerkesztve ]

Új hozzászólás Aktív témák