Nincs nagyképû programozó, vagyis aki nagyképû az nem programozó, nem tudok elképzelni egy olyan területen valakit mint a programozás, ahol mindennap újabb problémákkal találkozik az ember és ahol a tudása villámgyorsan elavul, hogy nagyképû legyen, mert egyszerûen a programozónak nincs erre ideje.
Komolytalan...
A nagyképûség az ostobaság elsõ számú bizonyítéka, ezért szerintem soha nincs miért nagyképû lenni.
szombi...
Alpajában a programozás egy komoly intelektuális munka, és ezért nagyon fontos, hogy az egyén vagyis a programozó képes legyen egy magasfokú önnálóságra, de nagyon veszélyes, ha ez az önnálósága a csoportmunkába ütközik. Azért mert ahogy Xantia is elmondta a szoftverfejlesztés ma kimondottan csapatmunka, másképpen nem is lehet csinálni. De ezzel egyidõben azt is figyelem elõtt kell tartani, hogy a programozás nem egyenlõ a szoftverfejlesztéssel. Ha a programozást kiegyenlítsük a kopasz kódolással akkor inkább az önnálóságra tenném a hangsúlyt, de megfelelõ mennyiségû csapatmunkával, vagyis nem lehet a vákuumban programozni, általában szeretem ha a programozó képes specifikáció szerinti munkát önnálóan elvégezni, de nem szeretem ha nincs tölle feedback, vagyis ha nem ajánl modifikációkat és ha nem tanál optimizáltabb megoldást, általában azért mert maga a szoftver architekturája és a specifikáció nem foglalja magába az alacsonyabb szintû dolgokat, vagyis van amikor jobb architektúrát lehet összedobni ha a mérnökök minõséges információkkal rendelkeznek a kódolóktól, mert azok közelebb álnak a dolgokhoz. Persze ez nem jelenti, hogy a specifikációt kikerülhetik (még véletlenül sem), de amikor a programozó csak megírja a kódot és nem szól semmit, akkor általában tudom, hogy rossz programozóval van dolgom, mert, annak az esélye, hogy a mérnökök tökéletes specifikációt alkottak sokkal kisebb mint annak, hogy a programozó nem tud gondolkodni vagy nem egyésszen ismeri az adott technológiát, protokolt stb. Tehát, hogy egy csapat mennyire képes jól mûködni az általában két dologtól függ, 1. mennyire összetett az adott project és 2. mennyire jók a csapat tagjai szakmailag és csapatjátékosként.
Különben a programozók - szoftverfejlesztõk általában nem szeretik ha mikrómanagement alatt vannak, ez két okból van így, mert képessek önnálóan gondolkodni a másik meg, hogy ha a kezükbe adnak valamit akkor az 1005-ban legyen a saját tulajdonuk. Ezért amikor elkapják a munkát akkor maguk döntenek, arról, hogyan oldják meg a problémát és õk a felelõssek a munkáért. Persze ez csak akkor mûködik ha a fõnök ismeri a problematikát, ha a fejlesztõ tudja a megoldást és ha õszinte, vagyis ha megmondja a valós helyzetet. Ezért fontos, hogy a fõnök és a csapat a lehetõ leghamarább tudja ha valami probléma van, nem szabad gyugni a dolgokat, idõt nyerni stb. Ez egyébként a legnehezebb dolog a szoftverfejlesztõknél, mert nem szeretik ha valaki azt gondolja, hogy nem tudják megoldani a problémát és ezért halgatnak az utolsó pillanatig, és akkor már késõ, a kis probléma amit a csapat többi tagjával együttmûködve vagy akár külsõ tanácsadással gyorsan meg lehetne oldani, nagy problémává dagad...
Életemben néhány szoftverfejlesztõ csapatot vezettem kis, közepes és nagy projekteken is, és azt tapasztaltam, hogy a legfontosabb dolog a csapatot összehozni úgy, hogy a csapattagoknak hasonló szintû tudásuk és tapasztalatuk legyen, hogy õszinték legyenek egymáshoz, hogy a csapatvezetõ NE legyen a csapat tagja, mert akkor megbomlik az egyensúly, ugyanis a csapatvezetõ magasabb beosztásban van. Ugyanakkor fontos, hogy a csapat tagok egymást értékeljék és egymást befogadják a csapatba, ezért amikor új tagot veszek be, mindég kérem az egész csapat véleményét. A csapat nem szabad nagy legyen, max 7-10 ember, ha a project nagyobb akkor fel kell darabolni több kisebb csapatra és akkor az együttmûködés több szinten történik. És még valami nagyon fontos, a napi értekezletek megfontoltak és szükségessek kell, hogy legyenek, sokszor csak divatból tartják meg és csak idõvesztés lesz belõlle, mert nincs elõkészítve, ez a csapatvezetõ munkája, az értekezletek összpontosítottak kell, hogy legyenek. Ezenkívül fontos még, hogy a csapattagok csapatvezetõ nélküli értekezleteket is tartsanak, de ezek nem formális munkaértekezletek, ezeken általában a csapat problémáit vitatják meg, és ez csak akkor mûködik, ha csak az egyenrangú beosztású tagok vannak jelen, tehát NINCS csapatvezetõ.
Na de errõl irhatnák még könyveket ide... mindenesetre aki ezzel foglalkozik az legalább részben tudja, mirõl beszélek.
krsz...
ha egy véleményt elfogadásán gondolkodsz akkor azt ne az alapján döntsd el, hogy a véleménymondó kicsoda, hanem, hogy amit mond annak van e értelme és, hogy a véleménymondó tapasztalt e és tudja e a dolgokat, iskolai végzetsége az egyáltalán nem fontos ebben az esetben. Különben a szoftverfejlesztést három oldalról kell megközelíteni, szakmai szempontból és itt a vezetés a szakmából kell, hogy legyen, alkalmazási szempontból itt a kõszülõ szoftver alkalmazási területérõl kell legyen a vezetés, és a pénzügyi oldal, tehát a kivitelezés ellenörzése a fejlesztés költségvetése stb. Szükség van ezeknek az oldalaknak az együttmûködésére, hogy sikeres legyen a project. De alapjában fontos, hogy ismerjük a csapatunkat, és ha jó csapatunk van akkor a legokosabb megoldás, szaladgálni körülöttük és lükdüsni fére az akadályokat, mert ha tényleg jó a csapat akkor önnálóan megoldják a problémákat, csak ne legyen elõttük valami hülye akadály. Persze az más kérdés, hogy egy jó csapatot nehéz osszehozni, és általában a jó csapatok méregdrágák ezért kevesen tudják megfizetni, viszont ha megvan akkor minden erõvel meg kell õrizni, mert sokkal többet ér mint amennyibe kerül.
Különben alapjában egyetértek Xantiával, egy dolgon kívül, az pedig, hogy szerintem egy fejlesztõ nem 3-5 évente kell a tudását felújítsa, hanem folytonossan... persze van amikor technológiai váltás van, de az inkább marketing által újrapakolt dolog amit általában késõ ha akkor tanulják, ezért én követelem a csapatomtól, hogy már a kezdõ bétákon ismerkedjenek az új dolgokkal, persze nem a produkciós környezetben, hogy ne legyen tévedés. És még valami, folytonossan nyelni kell a szakirodalmat, ezért amikor interjút tartok, általában kérdezem melyik könyveket olvasta a jelölt az elmúlt 3 hónapban, ha nincs rendes válasz akkor tudom, hogy olyan emberrel van dolgom aki nem szereti a változást, az informatikában és fõleg a szoftverfejlesztésben pedig az ilyeneknek nincs helyük.
Informatika és tudomány
