Joel on Software

Joel on Software   Joel, szoftverekről

 

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

 

Mezei Programozóként Dolgokat Véghezvinni


Szerző: Joel Spolsky
Fordította: Sztupák Attila
Szerkesztette: Orlovacz Peter
25.12.2001

Ez a weboldal elvileg szoftver-fejlesztések irányításáról szól. Esetenként azonban nincs meg a hatalmad, hogy vezetői rendeletekkel változtass a rendszeren. Amíg csak egy mezei programozó vagy a ranglétra alján, nyilvánvalóan nem tudsz csak úgy utasítani másokat, hogy kezdjenek el ütemtervet írni vagy hibakövető rendszert használni. Ha pedig vezető vagy, akkor már valószínűleg észrevetted, hogy fejlesztőket irányítani körülbelül annyira lehet, mint macskákat összefogdosni, csak kevésbé szórakozató. Attól, hogy azt mondod "csináld ezt ", még nem lesz úgy.

A Joel Teszten alacsony eredményt elérő szervezetben dolgozni elég frusztráló tud lenni. Mindegy hogy milyen jó kódot írsz, ha kollégáid olyat adnak ki a kezükből, hogy szégyellned kell magad, amiért közöd van a projekthez. Esetleg a vezetés szépen eldönti, hogy milyen kódot fogsz írni, és a tehetségedet egy gyerekeknek szóló nyudíjtervezési játék AS/400-as verziójának debuggolására kényszerülsz pazarolni.

Gondolom egyszerűen el is mehetnél a cégtől. Valószínűleg azonban van valami okod arra, hogy ott ragadtál. A részvénycsomagodat még nem kaptad meg teljesen, Rátót Cityben nincs ennél jobb munka, vagy valamelyik szerettedet túszként tartja a főnököd. Mindegy, egy rossz csapattal együtt élni roppant dühítő lehet. Léteznek azonban olyan stratégiák, amelyekkel a csapatodat alulról te magad fejlesztheted: ezekből osztanék meg néhányat.

Sokat olyan dolog van ami lendíthet egy projekten, és egy ember is el tudja végezni. Nincsen napi build? Csinálj. Készíts egy éjszakánként futó alkalmazást a saját gépeden, ami megcsinálja a napi buildet és kiküldi az eredményeket emailben. Túl sok lépésbe kerül a buildet elkészíteni? Írd meg a makefile-t. Senki sem csinál használhatósági teszteket? Végezd el a saját használhatósági tesztjeidet a folyosón bóklászó, ráérő embereken, papír vagy egyszerű VB prototípusok használatával.

2. Stratégia: Használd ki a szóbeszéd erejét

Egyetlen ember elég a Joel Teszt sok javaslatának megvalósításához, még a részvételt megtagadó csapaton belül is. Néhány, ha jól csinálod, szét fog terjedni a csapat többi részében is.

Tegyük fel, hogy a csapatban senkit sem lehet meggyőzni arról, hogy hibakövetést használjon. Ne zavartasd magad. Neked azért legyen sajátod. Írd bele a hibákat, amiket a saját kódodban találsz. Ha olyan hibát találsz, amit másoknak kellene kijavítaniuk, rendeld hozzájuk a hibát. Amennyiben jó hibakövető rendszert használsz, emailt fog nekik küldeni. Sőt, folyamatosan küldözgethetsz nekik leveleket, ha nem javítják a hibákat. Végül mások is rájönnek a hibakövetés hasznosságára és elkezdik használni a rendszert. Ha a tesztelőcsapat elutasítja hogy felvigyék a hibákat a hibakövető rendszerbe, egyszerűen csak hagyd figyelmen kívül a más csatornákon érkező hibajelzéseket. Miután úgy háromezerszer elmondtad nekik, hogy "Nézd, boldogan kijavítanám ezt, de el fogom felejteni. Nem tudnád felvenni a hibakövető rendszerbe?", ők is elkezdik használni a rendszert.

A csapatodon belül nincs senki, aki hajlandó verziókövetést használni? Csinálj magadnak egy CVS tárat, akár a saját gépeden ha szükséges. Még ha együttműködés nincs is, te felrakhatod rá a kódjaidat, másoktól függetlenül is. Amikor előjönnek azok a problémák, amiket a verzió-követés megoldhatna (valaki véletlenül rm * ~-t üt be rm *~helyett), akkor eljött a te időd. A végén a többiek rájönnek, hogy ők is használhatnák a saját másolataikat a rendszerről.

3. Stratégia: Létesíts Kiváló Részleget

A csapatod nem csinál ütemterveket? Vagy specifikációkat? Írd meg a sajátodat. Senki sem fog reklamálni, ha egy-két napot az elvégzendő munkád specijének és ütemtervének írásával töltesz.

Szerezz jobb embereket a csapatba. Vegyél részt a munkaerő-felvételben és az interjúztatásban, és vedd be a jó jelentkezőket a csapatba.

Keresd meg azokat az embereket, akik hajlandóak és képesek fejlődni, és állítsd őket magad mellé. Még gyenge csapatokban is valószínű, hogy találsz okos embereket, akiknek még nincs elég tapasztalatuk. Segíts nekik. Vedd rá őket a tanulásra. Olvasd el a kódjaikat. Ha valami hülyeséget csinálnak, ne küldj nekik felvágós levelet, kifejtve, hogy milyen marhaságok vannak a kódjaikban. Inkább számolj be ártatlanul nekik a hibákról, amiket a kódjuk eredményez. Hagyd hogy kitalálják, pontosan mi is okozza. Ha maguktól találják meg a hibát, jobban fognak emlékezni a tanulságra.

4. Stratégia: Semlegesítsd a Hülyéket

Még a legjobb csapatban is lehet egy-két hülye. A rossz programozók jelenlétének az a legidegesítőbb része, mikor a rossz kódjuk tönkrevágja a jó kódotokat, vagy ha a jó programozóknak időt kell pazarolniuk a rossz programozók utáni takarításra.

Mint egyszeri programozó, a célod a károk minimalizálása, másképp megfogalmazva a karantén lehet. Előfordul, hogy egyszer az egyik ilyen atomfizikus zseni két hetet tölt el egy kódrész megírásával, ami olyan hihetetlenül rossz, hogy sohasem lesz működőképes. Ilyenkor nagy kísértés fog el, hogy rászánd azt a negyedórát, amibe a kód nulláról újraírása kerülne. Küzdd le a kísértést. Íme itt a tökéletes alkalom, hogy több hónapra kivond a hülyét a forgalomból. Egyszerűen csak írj hibajelentéseket a kódjáról. Nem lesz más lehetősége, minthogy hónapokig küszködjön vele, amíg már nem tudsz több hibát találni. Ezek azok a hónapok amikor nem tud más károkat okozni.

5. Stratégia: Kerüld el a megszakításokat

Az összes kellemes munkakörnyezet hasonló (egyéni irodák, csendes munkakörülmények, kiváló eszközök, kevés megszakítás, és még kevesebb nagy értekezlet). Minden kellemetlen munkakörnyezet a maga módján kellemetlen.

A rossz hír, hogy szinte nincs olyan cég, ahol lehetséges lenne a munkakörnyezetet megváltoztatni. A hosszú távú bérleti szerződésekkel általában még a vezérigazgató sem tud mit kezdeni. Ezért kap olyan kevés fejlesztő saját irodát. Ez a cégeknek legalább két szempontból rossz. Először is, nehezebb lesz első osztályú fejlesztőket felvenni, akik előnyben részesítik azokat a cégeket (ha más vonatkozásokban egyformák), amelyek kényelmesebb körülményeket biztosítanak. Másodszor, a megszakítások szintje drámaian csökkentheti a fejlesztők termelékenységét, akinek lehetetlennek találják, hogy bekerüljenek a "zónába",ahol hatékonyan tudnak dolgozni és ott is maradjanak.

Keress lehetőségeket hogy kikerülj az ilyen környezetből. Vigyél egy laptopot az étkezőbe, ahol a nap legnagyobb részében egy csomó üres asztal van (és senki sem talál meg). Foglalj le egy tárgyalótermet egész napra, írd ott a kódot, és a checkin-ek tömegével értesd meg, hogy milyen sokat is tudsz dolgozni, ha egyedül vagy a szobában. Ha nagy a hajtás körülötted és a főnököd megkérdezi, hogy mire van szükséged, hogy Ez Kész Legyen Holnapra, tudni fogod, mit mondj. Találni fognak neked arra a napra egy irodát. És rövidesen elkezdenek gondolkodni arról, hogy mit is tudnának tenni hogy egész évben így dolgozz..

Későn érkezz munkába, és későn menj haza. A legproduktívabb órák azok lehetnek, amikor a többiek már hazamentek. Vagy - ha a csapat fejlesztői későn szoktak munkába jönni - járj be reggel 9-re. Az alatt a két óra alatt, amíg a többiek nincsenek bent és nem piszkálnak téged, többet fogsz tudni elvégezni, mint a nap teljes hátralévő részében.

Ne tartsd az email vagy az üzenő kliensedet nyitva. Nézd meg a leveleidet óránként, ha akarod, de ne fusson folyamatosan.

6. Stratégia: Válj nélkülözhetetlenné

Egyik stratégia sem működik, ha nem vagy igazán jó. Ha nem írsz jó kódot, és jó sokat is, akkor csak haragszanak majd rád, hogy hibakövető rendszerrel babrálgatsz, amikor kódolással "kellene" törődnöd. Semmi sem rosszabb a karrierednek mint ha arról vagy híres, hogy olyan sokat törődsz mindenféle folyamattal, hogy semmit sem végzel el.

Egyszer, mikor új állást kaptam mint mezei programozó egy cégnél, felfedeztem, hogy a cég nagyjából 2 pont körül járhat a Joel Teszten, és eldöntöttem, hogy ezt rendbe rakom. Azonban tudtam azt is, hogy fontos, hogy először jó benyomást keltsek. Ezért minden nap első hét óráját csak kódolással töltöttem, ahogy azt elvárták tőlem. A fejlesztőcsapat többi tagja szemében semmi sem vethet rád jobb fényt, mint ha záporoznak a checkin-ek. De egy órát minden délutánra fenntartottam, mielőtt hazamentem volna, hogy a folyamatokat fejlesszem. Ezt az időt arra szántam, hogy rendbe szedjem azokat a dolgokat, amelyek megnehezítették a termék debuggolását. Napi buildet és hibaadatbázist állítottam fel. Kiiktattam az összes, régóta fennálló zavaró tényezőt, amitől nehézkes volt a fejlesztés. Specifikációkat írtam az aznap elvégzett munkámról. Egy dokumentumban lépésről lépésre leírtam, hogyan kell egy fejlesztői gépet nulláról felkészíteni. Teljesen ledokumentáltam egy fontos belső nyelvet, ami teljesen dokumentálatlan volt. Lassanként a folyamat egyre jobb és jobb lett. Rajtam kívül (illetve a csapatomon kívül, ha éppen a felügyeletemre bíztak egyet) senki sem írt ütemtervet vagy specit, de ezektől eltekintve úgy 10 pont körül teljesítettünk a Joel Teszten.

Jobbá tudod tenni a dolgokat, még ha nem is vagy vezető pozícióban, de mindig gyanún felül kell állnod. Máskülönben ellenségeket fogsz szerezni magadnak ezen az úton.



A fordítás alapjául szolgáló angol cikk címe: Getting Things Done When You're Only A Grunt  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky