Tim Lister - liburuen egilekidea
- "Giza faktorea. Proiektu eta Talde arrakastatsuak" (jatorrizko liburua "Peopleware" izena du)
- "Hartekin Waltzing: arriskua kudeatzea software proiektuetan"
- «Adrenalina zoroa eta ereduen arabera zonbifikatuta. Proiektu-taldeen portaera-ereduak"
Liburu hauek guztiak klasikoak dira beren esparruan eta lankideekin batera idatzi ziren . Errusian, bere lankideak dira ospetsuenak - и , lan ospetsu asko ere idatzi zituena.
Timek 40 urteko esperientzia du software garapenean; 1975ean (habrapost hau idatzi zutenetako bat ez zen aurten jaio), Tim jada Yourdon Inc-eko presidenteorde exekutiboa zen. Orain aholkularitza, irakaskuntza eta idazten ematen du bere denbora, noizean behin bisitak eginez mundu osoko konferentziak.
Tim Listeri elkarrizketa bat egin genion bereziki Habr-entzat. DevOops 2019 hitzaldia irekiko du, eta galdera asko ditugu, liburuei eta gehiagori buruz. Elkarrizketa Mikhail Druzhinin eta Oleg Chirukhin-ek egin dute kongresuaren programaren batzordetik.
Mikel: Esan al ditzakezu hitz batzuk orain egiten ari zarenari buruz?
Tim: Atlantic Systems Gremioko burua naiz. Kofradian sei gara, nagusi deitzen diogu. Hiru AEBetan eta hiru Europan - horregatik gremioari Atlantikoa deitzen zaio. Hainbeste urte daramatzagu elkarrekin, ezen ezin dituzu zenbatu. Denok ditugu gure espezialitateak. Azken hamarkadan edo gehiagotan bezeroekin lan egin dut. Nire proiektuak kudeaketa ez ezik, eskakizunen ezarpena, proiektuen plangintza eta ebaluazioa ere barne hartzen ditu. Badirudi gaizki hasten diren proiektuak normalean gaizki amaitzen direla. Horregatik, merezi du jarduera guztiak ondo pentsatuta eta koordinatuta daudela ziurtatzea, sortzaileen ideiak uztartzen direla. Pentsatzea merezi du zertan ari zaren eta zergatik. Zein estrategia erabili proiektua burutzeko.
Urte asko daramatzat bezeroei hainbat modutan aholkularitza ematen. Adibide interesgarri bat belauneko eta aldakako ebakuntzarako robotak egiten dituen enpresa bat da. Zirujauak ez du erabat independentean funtzionatzen, robot bat erabiltzen du baizik. Hemen segurtasuna, egia esanda, garrantzitsua da. Baina arazoak konpontzera bideratzen diren pertsonekin eskakizunak eztabaidatzen saiatzen zarenean... Arraroa izango da, baina AEBetan badago (Federal Drug Administration), robot hauek bezalako produktuak lizentziatzen dituena. Ezer saldu eta bizi diren pertsonengan erabili aurretik, lizentzia lortu behar duzu. Baldintza bat da zure baldintzak erakustea, zeintzuk diren probak, nola probatu dituzun, zeintzuk diren proben emaitzak. Baldintzak aldatzen badituzu, proba-prozesu erraldoi hau behin eta berriz egin behar duzu. Gure bezeroek aplikazioen diseinu bisuala beren eskakizunetan sartzea lortu zuten. Pantaila-argazkiak zuzenean zituzten eskakizunen parte gisa. Atera behar ditugu eta azaldu behar dugu gehienetan programa guzti hauek ez dakitela ezer belaunez eta aldakez, kamerarekin gauza guzti hauek, etab. Baldintza-dokumentuak berridatzi behar ditugu, inoiz aldatu ez daitezen, azpiko baldintza benetan garrantzitsu batzuk aldatzen ez badira behintzat. Diseinu bisuala eskakizunetan ez badago, produktua eguneratzea askoz azkarragoa izango da. Gure lana da belauneko, aldaketako, bizkarreko ebakuntzak lantzen dituzten elementuak aurkitzea, dokumentu bereizietara ateratzea eta oinarrizko baldintzak horiek izango direla esatea. Egin dezagun belauneko operazioei buruzko eskakizun talde isolatu bat. Honek eskakizun multzo egonkorrago bat eraikitzeko aukera emango digu. Produktu-lerro osoari buruz hitz egingo dugu, eta ez robot zehatzei buruz.
Lan asko egin zen, baina, hala ere, aurretik asteak eta hilabeteak errepikatzen zituzten probetan zentzurik eta beharrik gabe pasatzen zituzten tokietara iritsi ziren, paperean azaldutako eskakizunak ez zetozelako bat sistemak eraiki ziren benetako eskakizunekin. FDAk esan zien aldi bakoitzean: zure baldintzak aldatu egin dira, orain hutsetik egiaztatu behar duzu dena. Produktu osoaren berriztapen osoak enpresa hiltzen ari ziren.
Beraz, zeregin zoragarriak daude zerbait interesgarri baten hasieran aurkitzen zarenean, eta lehen ekintzek jokoaren arau gehiago ezartzen dituzte. Ziurtatzen baduzu hasierako jarduera hau ondo funtzionatzen hasten dela zuzendaritzatik zein teknikotik, aukera dago proiektu bikainarekin amaitzeko. Baina zati hau errailetik joan bada eta nonbait gaizki joan bada, oinarrizko akordioak aurkitzen ez badituzu... ez, ez da zure proiektuak derrigor huts egingo duela. Baina jada ezin izango duzu esan: "Ondo egin dugu, dena benetan eraginkortasunez egin dugu". Hauek dira bezeroekin komunikatzean egiten ditudan gauzak.
Mikel: Hau da, proiektuak martxan jartzen dituzu, nolabaiteko sakea egin eta errailak norabide onean doazela egiaztatzea?
Tim: Puzzlearen pieza guztiak elkartzeko ideiak ere baditugu: zer trebetasun behar ditugun, noiz behar diren zehazki, taldearen muina nolakoa den eta oinarrizko beste gauza batzuk. Lanaldi osoko langileak behar ditugu edo lanaldi partzialeko norbait kontrata dezakegu? Plangintza, kudeaketa. Horrelako galderak: zer da garrantzitsuena proiektu honetarako? Nola lortu hori? Zer dakigu produktu edo proiektu honi buruz, zeintzuk diren arriskuak eta ezezagunak non dauden, nola egingo diogu aurre horri guztiari? Noski, momentu honetan norbait "Zer gertatzen da arin?!" oihukatzen hasten da. Ados, denak zarete malguak, baina zer? Zehazki nolakoa da proiektua, nola aterako duzu proiektuari egokitzen zaion moduan? Ezin duzu esan "gure ikuspegia edozertara zabaltzen dela, Scrum taldea gara!" Hau zentzugabekeria eta zentzugabekeria da. Nora joango zara hurrengoan, zergatik funtzionatu beharko luke, non dago kontua? Nire bezeroei galdera horiei guztiei buruz pentsatzen irakasten diet.
19 urte bizkorra
Mikel: Agile-n, jendea askotan saiatzen da aldez aurretik ezer ez zehazten, erabakiak ahalik eta beranduen hartzen baizik, esanez: handiegiak gara, ez dut arkitektura orokorrean pentsatuko. Ez dut beste gauza pilo batean pentsatuko; horren ordez, oraintxe bertan entregatuko diot bezeroari funtzionatzen duen zerbait.
Tim: Nik uste dut metodologia arin hori, hasita 2001ean, industriaren begiak ireki zituen. Baina, bestalde, ezer ez da perfektua. Garapen iteratiboaren alde nago. Iterazioak zentzu handia du proiektu gehienetan. Baina hausnartu behar duzun galdera hau da: produktua atera eta erabiltzen denean, zenbat irauten du? Beste zerbaitek ordezkatu baino sei hilabete iraungo duen produktua al da hau? Edo hau urte askotan eta askotarako balioko duen produktua da? Noski, ez dut izenik emango, baina... New Yorken eta bere finantza komunitatean, sistema oinarrizkoenak oso zaharrak dira. Hau harrigarria da. Haiei begiratzen diezu eta pentsatzen duzu, denboran atzera egin ahal izango bazenu, 1994ra, eta garatzaileei esaten diezu: «Etorkizunetik etorri naiz, 2019tik. Garatu sistema hau behar duzun bitartean. Zabalgarria egin, arkitekturan pentsatu. Gero, hogeita bost urte baino gehiagoz hobetuko da. Garapena pixka bat gehiago atzeratzen baduzu, gauzen eskema handian inork ez du ohartuko! Gauzak epe luzera kalkulatzen ari zarenean, kontuan hartu behar duzu zenbat kostatuko den guztira. Batzuetan ongi diseinatutako arkitekturak benetan merezi du, eta beste batzuetan ez. Ingurura begiratu eta geure buruari galdetu behar diogu: egoera egokian al gaude horrelako erabaki baterako?
Beraz, "Agileren alde gaude, bezeroak berak esango digu zer lortu nahi duen" bezalako ideia bat - oso inozoa da. Bezeroek ere ez dakite zer nahi duten, eta are gehiago ez dakite zer lor dezaketen. Batzuk adibide historikoak jartzen hasiko dira argudio gisa, hori jada ikusi dut. Baina teknikoki aurreratuek ez dute hori esaten normalean. Esaten dute: "2019a da, hauek ditugu ditugun aukerak, eta gauza hauei begiratzeko modua guztiz alda dezakegu!" Dauden konponbideak imitatu beharrean, apur bat politagoak eta orraztuagoak egin beharrean, batzuetan kalera irten behar da eta esan: “Erabat berrasma dezagun hemen egiten saiatzen ari garen hori!”.
Eta ez dut uste bezero gehienek arazoa horrela pentsa dezaketenik. Dagoeneko daukatena baino ez dute ikusten, hori da dena. Horren ostean, "egin dezagun hau apur bat errazagoa" bezalako eskaerak edo esaten dutena. Baina ez gara zerbitzariak edo zerbitzariak, beraz, eskaera bat hartu ahal izango dugu ergelak izan arren, eta gero sukaldean labean. Gu gara haien gidari. Begiak ireki eta esan behar diegu: aizu, hemen aukera berriak ditugu! Konturatzen al zara zure negozioaren zati hau egiteko modua benetan alda dezakegula? Agile-ren arazoetako bat zer den aukera, zer den arazoa, zer egin behar dugun, zein teknologia erabilgarri dauden egoera zehatz honetarako egokienak diren kontzientzia kentzen duela da.
Agian eszeptikoegi ari naiz hemen: gauza zoragarri asko gertatzen ari dira komunitate arinean. Baina arazo bat daukat, proiektu bat definitu beharrean jendea eskuak botatzen hasten direlako. Hemen galdetuko nuke: zer egiten ari gara, nola egingo dugu? Eta nolabait magikoki beti bihurtzen da bezeroak inork baino hobeto jakin behar duela. Baina bezeroak hobeto daki jada norbaitek eraikitako gauzetatik aukeratzen duenean bakarrik. Kotxe bat erosi nahi badut eta nire familiaren aurrekontuaren tamaina ezagutzen badut, orduan azkar hautatuko dut nire bizimoduari egokitzen zaion autoa. Hemen dena inork baino hobeto ezagutzen dut! Baina kontuan izan norbaitek dagoeneko egin dituela autoak. Ez dakit nola asmatu auto berri bat, ez naiz aditua. Produktu pertsonalizatuak edo bereziak sortzen ditugunean, bezeroaren ahotsa hartu behar da kontuan, baina hori jada ez da ahots bakarra.
Oleg: Agile manifestua aipatu duzu. Nolabait eguneratu edo berrikusi behar al dugu gaiaren ulermen modernoa kontuan hartuta?
Tim: Ez nuke ukituko. Dokumentu historiko bikaina dela uste dut. Esan nahi dut, bera dena dela. 19 urte betetzen ditu, zaharra da, baina bere garaian iraultza egin zuen. Ondo egin zuena izan zen erreakzio bat piztu zuela eta jendea hari buruz xuxurlatzen hasi zela. Ziurrenik, 2001ean oraindik ez zinen industrian lan egiten, baina gero denek prozesuen arabera lan egin zuten. Softwarearen Ingeniaritza Institutua, softwarearen osotasun ereduaren (CMMI) bost maila. Ez dakit antzinate sakoneko halako kondairek zerbait esaten dizuten, baina orduan aurrerapauso bat izan zen. Hasieran, jendeak uste zuen prozesuak behar bezala konfiguratuz gero, arazoak bere kabuz desagertuko zirela. Eta gero Manifestua dator eta zera dio: "Ez, ez, ez, pertsonetan oinarrituko gara, ez prozesuetan". Software garapenean maisuak gara. Prozesu ideala espejismo bat dela ulertzen dugu; ez da gertatzen. Proiektuetan idiosinkrasia gehiegi dago, proiektu guztietarako prozesu perfektu bakar baten ideiak ez du zentzurik. Arazoak konplexuegiak dira dena konponbide bakarra dagoela aldarrikatzeko (kaixo, nirvana).
Ez dut uste etorkizunera begiratzen duenik, baina esango dut orain jendea proiektuetan gehiago pentsatzen hasi dela. Uste dut Agile Manifesto oso ona dela jauzi eta esateko: “Hey! Itsasontzi batean zaude, eta zuk zeuk gidatzen ari zara ontzi hau. Erabaki bat hartu beharko duzu - ez dugu egoera guztietarako errezeta unibertsala proposatuko. Ontziaren tripulazioa zara, eta nahikoa ona bazara, helbururako bidea aurki dezakezu. Zure aurretik beste ontzi batzuk zeuden, eta beste ontzi batzuk izango dira zure ondoren, baina hala ere, zentzu batean, zure bidaia berezia da». Horrelako zerbait! Pentsatzeko modu bat da. Niretzat, ez dago ezer berririk eguzkiaren azpian, jendea aurretik ibili da eta berriro itsasoratuko da, baina zuretzat hau da zure bidaia nagusia, eta ez dizut esango zehazki zer gertatuko zaizun. Taldean koordinatutako lanerako gaitasunak izan behar dituzu, eta benetan badituzu, dena aterako da eta nahi zenuen lekura iritsiko zara.
Peopleware: 30 urte geroago
Oleg: Peopleware iraultza bat izan zen, baita Manifestua ere?
Tim: Peopleware... Tomek eta biok idatzi genuen liburu hau, baina ez genuen uste horrela gertatuko zenik. Nolabait jende askoren ideiekin oihartzuna izan zuen. Hauxe izan zen hau zioen lehenengo liburua: softwarearen garapena oso gizakiaren jarduera intentsiboa da. Gure izaera teknikoa izan arren, zerbait handia, are handia, oso konplexua eraikitzen duten pertsonen komunitate bat ere gara. Inork ezin ditu horrelakoak bakarrik sortu, ezta? Beraz, "taldearen" ideia oso garrantzitsua bihurtu zen. Eta ez kudeaketaren ikuspuntutik bakarrik, ezezagun mordo batekin arazo sakon benetan konplexuak konpontzeko elkartu ziren teknikarientzat ere. Niretzat pertsonalki, hau adimen proba izugarria izan da nire karreran zehar. Eta hemen esan behar duzu: bai, arazo hau nik bakarrik kudeatu dezakedana baino gehiago da, baina elkarrekin harro egoteko moduko irtenbide dotore bat aurki dezakegu. Eta uste dut ideia hori izan zela oihartzun handiena izan zuena. Denboraren zati bat gure kabuz lan egiten dugula, denboraren zati bat taldean, eta askotan erabakia taldeak hartzen du. Talde-arazoak ebaztea azkar bihurtu da proiektu konplexuen ezaugarri garrantzitsu bat.
Tim-ek hitzaldi kopuru handia eman duen arren, horietako oso gutxi jartzen dira YouTube-n. 2007ko “The Return of Peopleware” txostena ikus dezakezu. Kalitateak, noski, asko uzten du.
Mikel: Azken 30 urteotan zerbait aldatu al da liburua argitaratu zenetik?
Tim: Ikuspegi ezberdin askotatik ikus dezakezu. Soziologikoki hitz eginez... garai batean, garai sinpleagoetan, zu eta zure taldea bulego berean eseri ginen. Egunero gertu egon zaitezke, elkarrekin kafea edan eta lana eztabaidatu. Benetan aldatu dena da orain taldeak geografikoki banatu daitezkeela, herrialde eta ordu-eremu ezberdinetan, baina oraindik arazo berdinean ari dira lanean, eta horrek konplexutasun-geruza berri bat gehitzen du. Eskola zaharra dirudi, baina ez dago aurrez aurreko komunikazioa bezalakorik, non denak elkarrekin zauden, elkarrekin lanean, eta lankide batengana hurbildu eta esan dezakezu: begira zer aurkitu dudan, nola gustatzen zaizu hau? Aurpegiko elkarrizketek komunikazio informalera igarotzeko modu azkarra eskaintzen dute, eta uste dut zaletuek ere gustatu beharko luketela. Eta, gainera, kezkatuta nago, errealitatean mundua oso txikia bihurtu delako, eta orain dena banatutako taldeekin estalita dagoelako, eta dena oso konplexua da.
Denok DevOps-en bizi gara
Mikel: Jardunaldien programaren batzordearen ikuspuntutik ere, jendea dugu Kalifornian, New Yorken, Europan, Errusian... Singapurren ez dago oraindik inor. Geografian aldea nahiko handia da, eta jendea are gehiago zabaltzen hasi da. Garapenaz ari bagara, devops eta taldeen arteko oztopoak apurtzeari buruz gehiago esan al diguzu? Bada kontzeptu bat bakoitza bere bunkerretan eserita dagoela, eta orain bunkerrak erortzen ari direla, zer iruditzen zaizu analogia hau?
Tim: Iruditzen zait azken aurrerapen teknologikoen harira, devops-ak garrantzi handia duela. Aurretik, garatzaileen eta administratzaileen taldeak izan zenituen, lan egiten zuten, lan egin zuten, lan egin zuten, eta noizbait gauza bat agertu zen, administratzaileengana etorri eta produkziorako zabaltzeko. Eta hemen hasi zen bunkerraren inguruko elkarrizketa, administratzaileak aliatu modukoak direlako, ez etsaiak, behintzat, baina dena produkziora joateko prest zegoenean bakarrik hitz egiten zenuen haiekin. Zerbaitekin joan al zinen haiengana eta esan: begira zer aplikazio daukagun, baina aplikazio hau zabaldu al zenuke? Eta orain entregaren kontzeptu osoa hobera aldatu da. Esan nahi dut, aldaketak azkar egin ditzakezula ideia hau zegoen. Produktuak hegan egunera ditzakegu. Irribarre egiten dut beti nire ordenagailu eramangarrian Firefox agertzen denean eta esaten didanean, aizu, zure Firefox eguneratu dugu atzeko planoan, eta minutu bat izan bezain laster, axola zaizu hemen klik egitea eta azken bertsioa emango dizugu. Eta nik esan nuen: "Oh, bai, haurra!" Lo nengoela, ordenagailuan zuzenean bertsio berri bat emateko lanean ari ziren. Hau zoragarria da, sinestezina.
Baina hona hemen zailtasuna: ezaugarri hau softwarea eguneratzeko duzu, baina jendea integratzea askoz zailagoa da. DevOops-en agerraldian adierazi nahi dudana da orain inoiz izan ditugunak baino askoz jokalari gehiago ditugula. Talde bakarrean parte hartzen duten guztiengan pentsatzen baduzu... Talde gisa pentsatu zenuen, eta programatzaile talde bat baino askoz gehiago da. Hauek probatzaileak, proiektuen kudeatzaileak eta beste pertsona mordoa dira. Eta bakoitzak bere ikuspegia du munduari buruz. Produktuen kudeatzaileak proiektuen kudeatzaileetatik guztiz desberdinak dira. Administratzaileek beren zereginak dituzte. Zaila samarra bihurtzen da parte-hartzaile guztiak koordinatzea, gertatzen ari denaren berri izaten jarraitzeko eta ez erotzeko. Beharrezkoa da taldearen zereginak eta guztiontzat aplikatzen diren zereginak bereiztea. Oso lan zaila da. Bestalde, dena duela urte asko baino askoz hobea dela uste dut. Hau da, hain zuzen, jendea hazten den eta zuzen jokatzen ikasten duen bidea. Integrazioa egiten duzunean, ulertzen duzu ez dela lurpeko garapenik egon behar, azken momentuan softwarea ez dadin jack-in-the-box bat bezala arakatzen: adibidez, begira zer egin dugun hemen! Ideia da integrazioa eta garapena egiteko gai izango zarela, eta amaieran modu txukun eta errepikakor batean zabalduko duzu. Horrek guztiak asko esan nahi du niretzat. Horrek balio gehiago sortzea ahalbidetzen du sistemaren erabiltzaileentzat eta zure bezeroentzat.
Mikel: Devops-en ideia osoa garapen esanguratsuak ahalik eta azkarren ematea da. Mundua gero eta bizkortzen hasi dela ikusten dut. Nola egokitu halako azelerazioetara? Duela hamar urte hau ez zen existitzen!
Tim: Jakina, denek gero eta funtzionaltasun gehiago nahi dute. Ez da mugitu beharrik, gehiago pilatu besterik ez. Batzuetan, hurrengo eguneraketa gehigarrian moteldu behar duzu ezer erabilgarria ekartzeko, eta hori guztiz normala da.
Korrika, korrika, korrika egin behar duzula ideia ez da onena. Nekez da inork bere bizitza horrela bizi nahi izatea. Bidalketen erritmoak proiektuaren berezko erritmoa ezartzea nahiko nuke. Gauza txiki eta nahiko zentzugabeen jarioa sortzen baduzu, guztiak ez du zentzurik. Gauzak lehenbailehen kaleratzen saiatu beharrean, garatzaile nagusiekin eta produktu eta proiektuen arduradunekin eztabaidatzea merezi duena estrategia da. Horrek zentzurik ere ba al du?
Ereduak eta antipatroiak
Oleg: Eredu eta antipatroiez hitz egiten duzu normalean, eta hori da proiektuen bizitzaren eta heriotzaren arteko aldea. Eta orain, devops lehertzen da gure bizitzan. Ba al du proiektua bertan hil dezakeen eredu eta anti-eredurik?
Tim: Ereduak eta anti-ereduak uneoro gertatzen dira. Hitz egiteko zerbait. Bada, bada "gauza distiratsuak" deitzen dugun gauza hau. Jendeari izugarri gustatzen zaio teknologia berriak. Itxura polita eta dotorea den ororen distirak hipnotizatuta geratzen dira, eta galderak egiteari uzten diote: beharrezkoa al da ere? Zer lortuko dugu? Gauza hau fidagarria al da, zentzurik al du? Askotan ikusten dut jendea, nolabait esateko, teknologiaren abangoardian. Munduan gertatzen ari denarekin hipnotizatuta daude. Baina zer gauza erabilgarriak egiten dituzten gertutik begiratzen baduzu, askotan ez dago ezer erabilgarria!
Gure lagunekin eztabaidatzen ari ginen urteurren urtea dela, jendea ilargira iritsi zenetik berrogeita hamar urte. Hau 1969an izan zen. Jendeari bertara iristen lagundu zuen teknologia ez da 1969ko teknologia ere, 1960 edo 62koa baizik, NASAk fidagarritasunaren froga ona zuena bakarrik erabili nahi zuelako. Eta horrela begiratu eta ulertzen duzu - bai, eta egia ziren! Orain, ez, ez, baina teknologiarekin arazoetan sartzen zara dena gogorregi bultzatzen delako, pitzadura guztietatik salduta. Jendea oihuka ari da leku guztietatik: "Begira, zer gauza, hau da gauza berriena, munduko gauzarik ederrena, guztiz denontzat egokia!" Beno, hori da... normalean hau guztia engainu bat besterik ez da izaten, eta gero dena bota behar da. Beharbada dena da jada zahar bat naizelako eta halakoak eszeptizismo handiz begiratzen ditudalako, jendeak korrika atera eta Teknologia Onenak sortzeko Bide Bakarra eta Zuzenena aurkitu duela esaten duenean. Momentu honetan, nire barnean ahots bat esnatzen da eta esaten duena: "Ze nahaspila!"
Mikel: Izan ere, zenbatetan entzun dugu hurrengo zilarrezko balaren berri?
Tim: Zehazki, eta hau da gauzen ohikoa! Adibidez... badirudi hori jada txantxa bihurtu dela munduan zehar, baina hemen jendeak askotan hitz egiten du blockchain teknologiaz. Eta benetan zentzua dute zenbait egoeratan! Gertaeren froga fidagarriak behar dituzunean, sistemak funtzionatzen duela eta inork engainatu ez gaituela, segurtasun arazoak eta gauza horiek guztiak nahastuta dituzunean - blockchain-ak zentzua du. Baina Blockchain-ek orain munduan zehar zabalduko duela esaten dutenean, bere bidean dagoen guztia ezabatuko duela? Gehiago amets! Oso teknologia garestia eta konplexua da. Teknikoki konplexua eta denbora asko eskatzen du. Algoritmiko hutsa barne, matematika birkalkulatu behar duzun bakoitzean, aldaketa txikienekin... eta ideia bikaina da -baina kasu jakin batzuetarako bakarrik-. Nire bizitza eta ibilbide osoa honen ingurukoak izan dira: ideia interesgarriak oso egoera zehatzetan. Oso garrantzitsua da zure egoera zein den zehazki ulertzea.
Mikel: Bai, “bizitzaren, unibertsoaren eta guztiaren galdera” nagusia: teknologia edo planteamendu hau egokia da zure egoerarako ala ez?
Tim: Galdera hori dagoeneko eztabaidatu daiteke talde teknologikoarekin. Agian aholkulariren bat ere ekarri. Begiratu proiektuari eta ulertu - orain egingo al dugu zerbait zuzen eta erabilgarria, lehen baino hobeto? Agian moldatuko da, agian ez. Baina garrantzitsuena, ez hartu horrelako erabakirik lehenespenez, norbaitek bota zuelako besterik gabe: "Bloke-kate bat behar dugu! Berari buruz irakurri berri dut hegazkineko aldizkari batean!». Serio? Ez da barregarria ere.
"Devops ingeniari" mitikoa
Oleg: Orain denok devops inplementatzen ari dira. Norbaitek devopei buruz irakurtzen du Interneten, eta bihar beste lanpostu huts bat agertzen da kontratazio gune batean. "devops ingeniaria". Hemen zure arreta erakarri nahi nuke: uste al duzu termino honek, "devops ingeniaria", bizitzeko eskubidea duela? Badago iritzia devopsa kultura bat dela, eta hemen zerbait ez da bat egiten.
Tim: Hala-hala. Eman dezatela berehala termino honi buruzko azalpen batzuk. Berezia egiteko zerbait. Horrelako lanpostu huts baten atzean trebetasun konbinazio berezia dagoela frogatzen duten arte, ez dut erosiko! Esan nahi dut, ba, lan-titulua daukagula, "devops ingeniaria", titulu interesgarri bat, bai, zer hurrengo? Lanpostuen izenak, oro har, oso gauza interesgarriak dira. Esan dezagun "garatzailea" - zer da hala ere? Erakunde ezberdinek gauza guztiz desberdinak esan nahi dituzte. Zenbait enpresatan, kalitate handiko programatzaileek beste enpresa batzuetan probatzaile profesional bereziek idatzitako probek baino zentzu handiagoa duten probak idazten dituzte. Orduan, zer, orain programatzaileak edo probatzaileak al dira?
Bai, lanpostuen izenak ditugu, baina galderak nahikoa luze egiten badituzu, azkenean, denok arazoen konpontzaileak gara. Irtenbide bilatzaileak gara, eta batzuek gaitasun tekniko batzuk dituzte eta beste batzuk desberdinak. DevOps barneratu den ingurune batean bizi bazara, garapen eta administrazioaren integrazioan aritzen zara, eta jarduera honek helburu nahiko garrantzitsua du. Baina zehazki zer egiten duzun eta zertaz arduratzen zaren galdetzen bazaizu, ikusten da jendeak gauza horiek guztiak egiten dituela antzina-antzinatik. "Arkitekturaz arduratzen naiz", "datu-baseez arduratzen naiz" eta abar, dena den, ikusten duzu hori guztia "devops" aurretik zegoen.
Norbaitek bere lanaren izena esaten didanean, ez dut asko entzuten. Hobe da benetan zertaz arduratzen den esaten uztea, honek gaia askoz hobeto ulertzeko aukera emango digu. Nire adibiderik gogokoena pertsona batek "proiektu kudeatzailea" dela esaten duenean da. Zer? Ez du ezer esan nahi, oraindik ez dakit zer egiten duzun. Proiektu-kudeatzailea garatzaile bat izan daiteke, lau laguneko talde baten liderra, kodea idazten, lana egiten, talde-buru bihurtu dena, jendeak bere artean lider gisa aitortzen duena. Eta, gainera, proiektuaren kudeatzailea izan daiteke proiektu batean seiehun pertsona kudeatzen dituena, beste kudeatzaileak kudeatzen dituena, ordutegiak egiteaz eta aurrekontuak planifikatzeaz arduratzen dena, hori da dena. Hauek bi mundu guztiz desberdinak dira! Baina haien lanaren izenak berdina dirudi.
Eman diezaiogun buelta pixka bat ezberdinean. Zertan zara benetan ona, esperientzia handia duzu, talenturik baduzu? Zer ardura hartuko duzu zeregina kudeatu dezakezula uste duzulako? Eta hemen norbait berehala hasiko da ukatzen: ez, ez, ez, ez daukat proiektuko baliabideei aurre egiteko gogorik, ez da nire negozioa, tipo teknikoa naiz eta erabilgarritasuna eta erabiltzaile-interfazeak ulertzen ditut, ez dut jende armadak kudeatu nahi, hobe utz nazazu lanera joan.
Eta, bide batez, trebetasunen bereizketa mota honek ondo funtzionatzen duen planteamendu baten bultzatzaile handia naiz. Non teknikariek beren karrera hazi dezaketen nahi duten neurrian. Hala ere, oraindik ikusten ditut teknikariak kexatzen diren erakundeak: proiektuen kudeaketan sartu beharko dut, hori baita enpresa honetan bide bakarra. Batzuetan, horrek emaitza ikaragarriak ekartzen ditu. Teknikari onenak ez dira batere kudeatzaile onak, eta zuzendari onenek ezin dute teknologia maneiatu. Izan gaitezen honetaz zintzoak.
Eskari handia ikusten dut orain. Teknikari bat bazara, zure enpresak lagun zaitzake, baina edozein dela ere, benetan behar duzu zure karrera-ibilbidea aurkitu behar duzula, teknologiak aldatzen jarraitzen duelako eta horrekin batera zure burua berrasmatu behar duzulako! Hogei urtean soilik bost aldiz aldatu daitezke teknologiak. Teknologia gauza arraroa da...
"Guztietan adituak"
Mikel: Nola egin diezaioke aurre jendeak aldaketa teknologiko horren abiadurari? Haien konplexutasuna gero eta handiagoa da, haien kopurua hazten ari da, pertsonen arteko komunikazio-kopurua ere hazten ari da, eta ikusten da ezin duzula "denetan aditua" bihurtu.
Tim: Ondo! Teknologian lan egiten baduzu, bai, zalantzarik gabe, zerbait zehatza aukeratu eta horretan sakondu behar duzu. Zure erakundeak baliagarritzat jotzen dituen teknologia batzuk (eta agian benetan erabilgarriak izango dira). Eta jadanik interesatzen ez bazaizu -inoiz ez nuke sinetsiko hau esango nukeenik- tira, agian teknologia interesgarriagoa edo ikasteko erosoagoa den beste erakunde batera joan beharko zenuke.
Baina, oro har, bai, arrazoi duzu. Teknologiak norabide guztietan hazten ari dira aldi berean; inork ezin du esan "teknologo aditua naiz dauden teknologia guztietan". Bestalde, badaude ezaguera teknologikoa literalki xurgatzen duten belakiak eta horrekin zoratzen direnak. Horrelako pertsona pare bat ikusi ditut, literalki arnasa hartzen eta bizitzen dute, haiekin hitz egitea erabilgarria eta interesgarria da. Erakunde barruan zer gertatzen den aztertzen dute, oro har, horretaz hitz egiten dute, teknologo oso politak ere badira, oso kontzienteak eta helburudunak dira. Olatuaren gailurrean gelditzen saiatzen dira, euren lan nagusia zein den kontuan hartu gabe, euren pasioa Teknologiaren mugimendua delako, teknologiaren sustapena. Bat-batean horrelako pertsona bat topatzen baduzu, harekin bazkaltzera joan eta bazkarian hainbat gauza polit eztabaidatu beharko zenuke. Uste dut edozein erakundek gutxienez horrelako pertsona pare bat behar dituela.
Arriskuak eta ziurgabetasuna
Mikel: Ohorezko ingeniariak, bai. Ukitu diezaiogun arriskuen kudeaketa denbora daukagun bitartean. Elkarrizketa hau software medikoari buruzko eztabaida batekin hasi dugu, non akatsek ondorio latzak ekar ditzaketen. Gero Ilargi Programari buruz hitz egin genuen, non akats baten kostua milioika dolar den, eta agian hainbat giza bizitza. Baina orain kontrako mugimendua ikusten dut industrian, jendeak ez du arriskuetan pentsatzen, ez da iragartzen saiatu, ez ditu behatu ere egiten.
Oleg: Mugitu azkar eta hautsi gauzak!
Mikel: Bai, azkar mugitu, gauzak apurtu, gero eta gauza gehiago, zerbaitengatik hil arte. Zure ikuspuntutik, nola planteatu behar luke batez besteko garatzaileak ikaskuntza-arriskuen kudeaketa orain?
Tim: Marraz dezagun hemen bi gauzaren arteko muga: arriskuak eta ziurgabetasuna. Hauek gauza desberdinak dira. Ziurgabetasuna behin betiko erantzuna lortzeko une batean datu nahikorik ez duzunean gertatzen da. Adibidez, proiektu baten hasierako fasean, norbaitek "noiz amaituko duzu lana" galdetzen badizu, pertsona zintzo samarra bazara, "ez daukat ideiarik" esango duzu. Ez dakizu, eta ondo dago. Oraindik ez dituzu arazoak aztertu eta ez duzu taldea ezagutzen, ez dituzu ezagutzen haien trebetasunak, etab. Hau ziurgabetasuna da.
Arriskuak balizko arazoak dagoeneko identifikatu daitezkeenean sortzen dira. Gauza mota hau gerta daiteke, bere probabilitatea zero baino handiagoa da, baina ehuneko ehun baino txikiagoa, nonbait. Hori dela eta, edozer gerta daiteke, atzerapenak eta alferrikako lanak, baina baita proiektuaren emaitza hilgarrira ere. Emaitza, esaten duzunean - mutilak, tolestu ditzagun aterkiak eta utzi hondartza, ez dugu inoiz amaituko, amaitu da, puntua. Gauza honek funtzionatuko zuela uste genuen, baina ez du batere funtzionatzen, gelditzeko garaia da. Hauek dira egoerak.
Askotan, arazoak lehendik sortu direnean konpontzen dira errazenak, arazoa oraintxe bertan gertatzen denean. Baina arazo bat zure aurrean dagoenean, ez duzu arriskuen kudeaketa egiten ari, arazoak konpontzen ari zara, krisiaren kudeaketa egiten ari zara. Garatzaile nagusia edo kudeatzailea bazara, galdetu behar duzu zer gerta daitekeen atzerapenak, denbora galtzea, beharrezkoak ez diren kostuak edo proiektu osoaren kolapsoa ekarriko lukeena? Zerk egingo gaitu gelditu eta berriro hastea? Gauza hauek guztiak funtzionatzen dutenean, zer egingo dugu haiekin? Erantzun sinple bat dago egoera gehienetarako balio duena: arriskuetatik ez ihes egin, lan egin. Ikusi nola konpon dezakezun arrisku egoera bat, ezerezean murriztu, arazo batetik beste zerbait bihurtu. Esan beharrean: ba, arazoak sortzen diren heinean konponduko ditugu.
Ziurgabetasuna eta arriskua jorratzen duzun guztiaren aurrean egon behar dute. Proiektu-plan bat hartu dezakezu, aldez aurretik arrisku kritiko batzuk aztertu eta esan: honi aurre egin behar diogu orain, zeren eta ezer gaizki ateratzen bada, ez du ezerk axola izango. Ez zenuke mahai gainean dagoen mahai-zapiaren edertasunaz kezkatu behar afaria prestatu dezakezun argi ez badago. Lehenik eta behin, afari goxo bat prestatzeko arrisku guztiak identifikatu behar dituzu, aurre egin eta, ondoren, benetako mehatxurik ez duten beste gauza guztietan pentsatu.
Berriz ere, zerk egiten du zure proiektua berezia? Ea zerk eragin dezakeen gure proiektua bidetik ateratzea. Zer egin dezakegu hori gertatzeko probabilitatea gutxitzeko? Normalean, ezin dituzu %100ean neutralizatu eta kontzientzia garbiz adierazi: "Hori da, hau ez da arazo bat, arriskua konpondu da!" Niretzat hau helduen jokabidearen seinale da. Hau da haur baten eta helduaren arteko aldea: haurrak hilezinak direla uste dute, ezin dela ezer gaizki joan, dena ondo egongo da! Aldi berean, helduek ikusten dute nola hiru urteko haurrak jolastokira salto egiten diren, mugimenduak begiekin jarraitzen eta beren buruari esaten diote: “ooh-ooh, ooh-ooh”. Gertuko nago eta umea erortzen denean harrapatzeko prest nago.
Bestalde, negozio hau hainbeste gustatzen zaidan arrazoia arriskutsua delako da. Gauzak egiten ditugu, eta gauza horiek arriskutsuak dira. Helduen hurbilketa eskatzen dute. Ilusioak bakarrik ez ditu zure arazoak konponduko!
Helduen ingeniaritza-pentsamendua
Mikel: Umeekin adibidea ona da. Ingeniari arrunta banaiz, pozten naiz ume izateaz. Baina nola joan pentsamendu helduagorantz?
Tim: Hasiberri edo garatzaile finkatu batekin berdin funtzionatzen duen ideietako bat testuinguruaren kontzeptua da. Zer egiten ari garen, zer lortuko dugun. Zer da benetan garrantzitsua proiektu honetan? Berdin dio nor zaren proiektu honetan, bekaduna edo arkitekto nagusia izan, denek behar dute testuingurua. Bakoitzak bere lanak baino eskala handiago batean pentsa dezan lortu behar dugu. "Nire pieza egiten dut, eta nire piezak funtzionatzen duen bitartean, pozik nago". Ez eta ez berriro. Beti merezi du (zakarrik izan gabe!) jendeari lan egiten duen testuingurua gogoraraztea. Denok batera lortzen saiatzen ari garena. Zure proiektuko zatiarekin dena ondo dagoen bitartean haur bat izan zaitezkeen ideiak - mesedez, ez egin hori. Helmuga batere zeharkatzen badugu, elkarrekin bakarrik zeharkatuko dugu. Ez zaude bakarrik, denok elkarrekin gaude. Proiektuko pertsona guztiak, helduak zein gazteak, proiekturako zehazki zer den garrantzitsua hitz egiten hasi baziren, zergatik inbertitzen duen enpresak dirua denok lortzen saiatzen ari garen horretan... gehienak askoz hobeto sentituko dira, zeren eta. euren lana beste guztien lanarekin nola erlazionatzen den ikusiko du. Batetik, pertsonalki arduratzen naizen pieza ulertzen dut. Baina lana amaitzeko beste pertsona guztiak ere behar ditugu. Eta benetan amaitu duzula uste baduzu, beti daukagu lana egiteko proiektuan!
Oleg: Erlatiboki esanda, Kanban-en arabera lan egiten baduzu, proba batzuen lepoan topo egiten duzunean, bertan egiten ari zarena utzi dezakezu (adibidez, programazioa) eta probatzaileei laguntzera joan zaitezke.
Tim: Zehazki. Nik uste dut teknikari onenak, arretaz begiratuz gero, beren kudeatzaile modukoak direla. Nola formula dezaket hau...
Oleg: Zure bizitza zure proiektua da, zuk kudeatzen duzuna.
Tim: Zehazki! Esan nahi dut, ardura hartzen duzula, gaia ulertzen duzula eta jendearekin harremanetan jartzen zara zure erabakiek euren lanean eragina izan dezaketela ikusten duzunean, horrelakoak. Ez da zure mahaian esertzea, zure lana egitea eta inguruan gertatzen ari denaz ohartzea ere ez. Ez ez ez. Bide batez, Agileren gauzarik onenetakoa esprint laburrak proposatu zituztela da, horrela parte hartzaile guztien egoera argi ikusten delako, denak batera ikusi ahal izango direlako. Egunero hitz egiten dugu elkarri.
Arriskuen kudeaketan nola sartu
Oleg: Ba al dago ezagutza egitura formalik arlo honetan? Adibidez, Java garatzailea naiz eta arriskuen kudeaketa ulertu nahi dut hezkuntzaren arabera benetako proiektu-kudeatzaile bihurtu gabe. Seguruenik McConnell-en "Zenbat balio du software-proiektuak" irakurriko dut lehenik, eta gero zer? Zeintzuk dira lehen urratsak?
Tim: Lehenengoa proiektuko jendearekin komunikatzen hastea da. Honek lankideekiko komunikazio-kultura berehala hobetzen du. Lehenespenez dena irekiz hasi behar dugu, ezkutatu beharrean. Esan: hauexek dira molestatzen nautenak, hauek dira gauez esnatu egiten nautenak, gaur gauez esnatu naiz eta honela izan naiz: ene Jainkoa, hau pentsatu behar dut! Besteek gauza bera ikusten dute? Talde gisa, erantzun beharko genieke balizko arazo horiei? Gai hauei buruzko eztabaidari eusteko gai izan behar duzu. Ez dago aurrez prestatutako formularik lan egiteko. Ez da hanburgesak egitea, jendea baizik. “Gazta hanburgesa egin, gazta hanburgesa saldu” ez da batere gure gauza, eta horregatik asko maite dut lan hau. Gustatzen zait orain zuzendariek egiten zuten guztia taldearen jabetza bilakatzea.
Oleg: Liburuetan eta elkarrizketetan hitz egin duzu jendeari nola gehiago zaintzen duen zoriontasuna grafiko bateko zenbakiak baino. Bestetik, taldeari esaten diozunean: devopsera pasatzen ari gara, eta orain programatzaileak etengabe komunikatu behar du, baliteke hau bere erosotasun eremutik kanpo egotea. Eta momentu honetan, demagun, oso zorigaiztokoa izan daiteke. Zer egin egoera honetan?
Tim: Ez dakit zehazki zer egin. Garatzaile bat isolatuegia bada, ez dute ikusten zergatik egiten den lana lehenik, bere lanaren zatiari begiratzen diote, eta nik "testuingurua" deitzen diodan horretan sartu behar dute. Guztia elkarrekin nola lotzen den asmatu behar du. Eta noski, ez dut esan nahi aurkezpen formalak edo horrelakorik. Lankideekin lan osoari buruz komunikatu behar duzulaz ari naiz, eta ez bakarrik arduratzen zaren zatiari buruz. Hemen hasi zaitezke ideiak eztabaidatzen, zure lana ondo egokitzeko akordio komunak eta arazo komun bati elkarrekin nola aurre egin.
Egokitzen laguntzeko, askotan teknikariak bidali nahi dituzte entrenamenduetara, eta prestakuntzari buruz hitz egiten dute. Nire lagun bati entrenatzea txakurrentzat dela esatea gustatzen zaio. Pertsonentzako prestakuntza dago. Garatzaile gisa ikasteko gauzarik onenetako bat zure kideekin elkarreragina da. Norbait zerbaitetan benetan ona bada, lan egiten ikusi beharko zenuke edo berarekin hitz egin bere lanari buruz edo zerbaiti buruz. Kent Beck ohiko batzuek muturreko programazioaz hitz egiten zuten etengabe. Dibertigarria da XP ideia sinplea delako, baina arazo asko sortzen ditu. Batzuentzat, XP egitea lagunen aurrean biluztera behartuta egotea bezalakoa da. Ikusiko dute zer egiten dudan! Nire lankideak dira, ikusiko ez ezik, ulertuko dute! Ikaragarria! Pertsona batzuk larri urduri jartzen hasi dira. Baina hori ikasteko azken modua dela konturatzen zarenean, dena aldatzen da. Jendearekin estuan lan egiten duzu, eta batzuek zuk baino askoz hobeto ulertzen dute gaia.
Mikel: Baina horrek guztiak zure erosotasun gunetik ateratzera behartzen zaitu. Ingeniari gisa, zure erosotasun gunetik atera eta komunikatu behar duzu. Arazoen konpontzaile gisa, etengabe jarri behar duzu zure burua posizio ahul batean eta pentsatu zer egin dezakeen gaizki. Lan mota hau berez traba bat izateko diseinatuta dago. Estres egoeretan kontzienteki jartzen zara. Normalean jendeak ihes egiten du, jendeari ume zoriontsuak izatea gustatzen zaio.
Tim: Zer egin daitekeen, atera zaitezke eta argi eta garbi esan dezakezu: “Dena ondo dago, kudeatu dezaket! Ez naiz deseroso sentitzen den bakarra. Eztabaidatu ditzagun hainbat gauza deseroso, elkarrekin, taldean!». Hauek dira gure ohiko arazoak, horiei aurre egin behar diegu, badakizu? Uste dut jenio idiosinkratikoen garatzaileak mamutak bezalakoak direla, desagertu egin zirela. Eta haien garrantzia oso mugatua da. Ezin baduzu komunikatu, ezin duzu ondo parte hartu. Beraz, hitz egin besterik ez. Izan zintzoa eta irekia. Sentitzen dut hau norbaitentzat desatsegina izateak. Imajinatzen al duzu, duela urte asko Estatu Batuetan beldur nagusia heriotza ez den ikerketaren arabera, baina asmatu zer? Jendaurrean hitz egiteko beldurra! Horrek esan nahi du nonbait laudorio bat ozen esatea baino hil nahiago duten pertsonak daudela. Eta uste dut nahikoa dela oinarrizko gaitasun batzuk edukitzea, egiten duzunaren arabera. Hitz egiteko trebetasunak, idazteko trebetasunak, baina zure lanean benetan behar dena. Analista gisa lan egiten baduzu, baina ezin baduzu irakurri, idatzi edo hitz egin, orduan, zoritxarrez, ez duzu zer eginik izango nire proiektuetan!
Komunikazioaren prezioa
Oleg: Ez al da garestiago horrelako langileak enplegatzea hainbat arrazoirengatik? Azken finean, lan egin beharrean etengabe berriketan ari dira!
Tim: Taldearen muina esan nahi nuen, eta ez guztiona. Datu-baseak sintonizatzen oso ona den norbait baduzu, datu-baseak sintonizatzen dituena eta zure datu-baseak sintonizatzen jarraituko badu bere bizitza osoan zehar eta kitto, lasai, jarraitu horrela. Baina proiektuan bertan bizi nahi duen jendeaz ari naiz. Taldearen muina, proiektua garatzera zuzendua. Pertsona hauek etengabe komunikatu behar dute elkarren artean. Eta bereziki proiektuaren hasieran, arriskuak, helburu globalak lortzeko bideak eta antzekoak eztabaidatzen dituzunean.
Mikel: Hau proiektuan parte hartzen duten guztiei dagokie, espezializazioa, trebetasunak edo lan egiteko moduak gorabehera. Guztiok interesatzen zaituzte proiektuaren arrakasta.
Tim: Bai, proiektuan nahikoa murgilduta zaudela sentitzen duzu, zure zeregina proiektua egia bihurtzen laguntzea dela. Programatzailea, analista, interfaze-diseinatzailea, edonor zaren. Hauxe da goizero lanera etortzen naizen arrazoia eta hau da egiten duguna. Pertsona horien guztien erantzule gara, haien gaitasunak gorabehera. Helduentzako elkarrizketak dituzten pertsona talde bat da.
Oleg: Izan ere, langile berritsuei buruz hitz eginda, munduaren ikuspegi berri honen aurrean devopsera aldatzeko eskatzen zaien jendearen objekzioak simulatzen saiatu nintzen, batez ere kudeatzaileei. Eta zuk, aholkulari gisa, ni baino askoz hobeto ezagutu beharko zenuke objekzio horien berri, garatzaile gisa! Partekatu zerk kezkatzen ditu gehien kudeatzaileek?
Tim: Zuzendariak? Hm. Gehienetan, kudeatzaileak arazoen presioa jasaten dute, zerbait askatu eta entrega bat egin beharraren aurrean, eta antzekoak. Begiratzen dute nola etengabe eztabaidatzen eta eztabaidatzen dugun zerbaiti buruz, eta horrela ikusten dute: elkarrizketak, solasaldiak, elkarrizketak... Zer beste elkarrizketa? Itzuli lanera! Hizketan aritzeak ez duelako lan bat iruditzen. Ez duzu koderik idazten, ez duzu softwarerik probatzen, ez dirudi ezer egiten duzula - zergatik ez zara bidali zerbait egitera? Azken finean, hilabete barru entregatu da jada!
Mikel: Zoaz kode bat idaztera!
Tim: Iruditzen zait ez daudela lanagatik kezkatzen, aurrerapenaren ikusgarritasun faltagatik baizik. Arrakastatik gertuago gaudela badirudi, teklatuko botoiak sakatzen ikusi behar gaituzte. Egun osoa goizetik arratsaldera. Hau da lehen arazoa.
Oleg: Misha, zerbaitetan pentsatzen ari zara.
Mikel: Barkatu, pentsamenduetan galdu naiz eta flashback bat harrapatu dut. Horrek guztiak atzo gertatutako rally interesgarri bat ekarri dit gogora... Atzo rally gehiegi izan ziren... Eta oso ezaguna dirudi dena!
Soldatarik gabeko bizitza
Tim: Bide batez, ez da batere beharrezkoa komunikaziorako “rallyak” antolatzea. Esan nahi dut, garatzaileen arteko eztabaidarik erabilgarrienak elkarren artean hitz egiten dutenean gertatzen dira. Goizean kafetxo batekin ibiltzen zara, eta bost lagun daude bilduta eta amorruz zerbait teknikoari buruz eztabaidatzen. Niretzat, proiektu honen kudeatzailea banaiz, hobe da irribarre egitea eta nire negozioari nonbaitera joatea, eztabaida dezatela. Dagoeneko ahalik eta gehien parte hartzen dute. Hau seinale ona da.
Oleg: Bide batez, zure liburuan ohar mordoa duzu zer den ona eta zer den txarra. Zuk zeuk erabiltzen al duzu horietakoren bat? Erlatiboki esanda, orain enpresa bat duzu, eta oso modu ez-ortodoxoan egituratuta dagoena...
Tim: Ortodoxoa, baina gailu hau primeran datorkigu. Aspalditik ezagutzen dugu elkar. Elkarrengan konfiantza dugu, elkarrengan konfiantza handia izan genuen bazkide egin aurretik. Eta adibidez, ez dugu inolako soldatarik. Guk lan egiten dugu, eta adibidez, nire bezeroekin dirua irabazten banuen, orduan diru guztia niregana joaten zen. Horren ostean, bazkidetza kuotak ordaintzen dizkiogu erakundeari, eta hori nahikoa da enpresari berari laguntzeko. Gainera, guztiok gauza ezberdinetan espezializatuta gaude. Esaterako, kontulariekin lan egiten dut, zerga aitorpenak betetzen ditut, enpresari era guztietako administrazioak egiten ditut eta inork ez dit ordaintzen. James eta Tomek gure webgunean lan egiten dute eta inork ere ez die ordaintzen. Zure kuotak ordaintzen dituzun bitartean, inori ez zaio pentsatuko zer egin behar duzun esatea. Adibidez, Tomek lehen baino askoz gutxiago lan egiten du orain. Orain beste interes batzuk ditu; Kofradiarentzat ez diren gauza batzuk egiten ditu. Baina bere kuotak ordaintzen dituen bitartean, ez zaio inor hurbilduko eta esango: "Ai, Tom, zoaz lanera!" Oso erraza da lankideekin tratua zure artean dirurik ez dagoenean. Eta orain gure harremana oinarrizko ideietako bat da espezialitate ezberdinei dagokienez. Funtzionatzen du eta oso ondo funtzionatzen du.
Aholkurik onena
Mikel: "Aholkurik onena"ra itzuliz gero, ba al dago zure bezeroei behin eta berriz esaten diezun zerbait? 80/20 buruzko ideia bat dago, eta ziurrenik aholku batzuk maizago errepikatzen dira.
Tim: Behin pentsatu nuen Waltzing with Bears bezalako liburu bat idatziz gero, historiaren ibilbidea aldatuko zela eta jendea geldituko zela, baina... Tira, begira, enpresek askotan dena ondo dagoela iruditzen zaie. Zerbait txarra gertatu bezain laster, harridura eta sorpresa bat da beraientzat. “Begira, sistema probatu dugu, eta ez du sistemaren probarik gainditzen, eta hau beste hiru hilabeteko lan planifikatua da, nola gerta liteke hau? Nork zekien? Zer egin liteke gaizki? Serio, hau sinesten al duzu?
Azaltzen saiatzen ari naiz ez zarela gehiegi haserretu behar egungo egoerarekin. Hitz egin behar dugu, benetan ulertu zer izan zitekeen gaizki, eta nola saihestu etorkizunean horrelako gauzak gerta ez daitezen. Arazo bat agertzen bada, nola borrokatuko dugu, nola eutsiko diogu?
Niretzat, honek guztiak beldurgarria iruditzen zait. Jendeak arazo konplexu eta nazkagarriei aurre egiten die eta behatzak gurutzatu eta onena espero badute, "onena" benetan gertatuko dela ematen jarraitzen dute. Ez, ez du horrela funtzionatzen.
Praktikatu arriskuen kudeaketa!
Mikel: Zure ustez, zenbat erakunde aritzen dira arriskuen kudeaketan?
Tim: Haserretzen nauena da jendeak arriskuak idaztea, ondoriozko zerrenda begiratu eta lanera joatea. Izan ere, haientzako arriskuak identifikatzea arriskuen kudeaketa da. Baina niri hau galdetzeko arrazoi bat iruditzen zait: ados, zerrenda bat dago, zer aldatuko duzu zehazki? Arrisku horiek kontuan hartuta, zure ekintza-sekuentzia estandarrak aldatu behar dituzu. Lanaren zatirik zailena baldin badago, horri aurre egin behar diozu, eta gero zerbait sinpleagora pasa. Lehenengo esprintetan, hasi problema konplexuak konpontzen. Honek dagoeneko arriskuen kudeaketa dirudi. Baina normalean jendeak ezin du esan zer aldatu duten arriskuen zerrenda osatu ondoren.
Mikel: Eta, hala ere, enpresa horietako zenbat parte hartzen dute arriskuen kudeaketan, ehuneko bost?
Tim: Zoritxarrez, gorroto dut hau esatea, baina hau oso zati hutsala da. Baina bost baino gehiago, benetan proiektu handiak daudelako, eta ezin dira existitu gutxienez zerbait egiten ez badute. Esan dezagun asko harrituko naizela gutxienez %25 bada. Proiektu txikiek normalean honela erantzuten diete horrelako galderei: arazoak guri eragiten badigu, orduan konponduko dugu. Ondoren, arazoetan arrakastaz sartzen dira eta arazoen kudeaketan eta krisiaren kudeaketan aritzen dira. Arazo bat konpontzen saiatzen zarenean eta arazoa konpontzen ez denean, ongi etorri krisiaren kudeaketara.
Bai, askotan entzuten dut, "arazoak sortzen diren heinean konponduko ditugu". Seguru egingo dugu? Benetan erabakiko dugu?
Oleg: Inozoki egin dezakezu eta proiektuaren gutunean aldagai garrantzitsuak idatzi, eta aldagaiak hausten badira, berrabiarazi proiektua. Oso piembucky bihurtzen da.
Mikel: Bai, gertatu zitzaidan arriskuak abiarazten zirenean proiektua berriro definitzea besterik ez zela. Polita, bingoa, arazoa konponduta, ez kezkatu gehiago!
Tim: Sakatu dezagun berrezarri botoia! Ez, ez du horrela funtzionatzen.
Hitzaldia DevOops 2019-n
Mikel: Elkarrizketa honen azken galderara gatoz. Hurrengo DevOops-era hitzaldi batekin zatoz, altxa al zenezake kontatuko duzunaren sekretuaren oihala?
Tim: Oraintxe bertan, sei lan-kulturari buruzko liburu bat idazten ari dira, erakundeen esan gabeko arauei buruz. Kultura erakundearen oinarrizko balioek zehazten dute. Normalean jendea ez da horretaz ohartzen, baina urte askoan aholkularitzan lan eginda, ohartzera ohituta gaude. Enpresa batean sartzen zara, eta, literalki, minutu gutxiren buruan hasten zara gertatzen ari dena sentitzen. Horri "zaporea" deitzen diogu. Batzuetan usain hau oso ona da, eta beste batzuetan, tira, aupa. Gauzak oso desberdinak dira erakunde ezberdinentzat.
Mikel: Nik ere urteak daramatzat aholkularitzan lanean eta ondo ulertzen dut zertaz ari zaren.
Tim: Egia esan, hitzaldian hitz egitea merezi duen gauzetako bat da dena ez duela enpresak zehazten. Zuk eta zure taldeak, komunitate gisa, zure talde-kultura propioa duzu. Hau enpresa osoa izan daiteke, edo aparteko sail bat, aparteko talde bat. Baina esan baino lehen, hona zer sinesten dugun, hona zer den garrantzitsua... Ezin duzu kultura bat aldatu ekintza zehatzen atzean dauden balio eta sinesmenak ulertu aurretik. Jokabidea behatzeko erraza da, baina sinesmenak bilatzea zaila da. DevOps gauzak gero eta konplexuagoak direnaren adibide bikaina besterik ez da. Elkarreraginak gero eta konplexuagoak dira, ez dira gero eta garbiagoak edo batere argiagoak, beraz, pentsatu behar duzu zertan sinesten duzun eta zure inguruko guztiak isilik daudenean.
Emaitza azkarrak lortu nahi badituzu, hona hemen gai on bat zuretzat: ikusi al dituzu inork "ez dakit" esaten ez duen enpresak? Badaude lekuak non pertsona bat literalki torturatzen duzun, hark zerbait ez dakiela aitortu arte. Denek dakite dena, denak izugarrizko eruditoa da. Edozein pertsona hurbiltzen zara, eta berehala erantzun behar dio galderari. "Ez dakit" esan beharrean. Aupa, erudito mordoa kontratatu zuten! Eta kultura batzuetan, oro har, oso arriskutsua da "ez dakit" esatea; ahultasun seinale gisa hauteman daiteke. Badira, aitzitik, denek «ez dakit» esan dezaketen erakundeak ere. Hor guztiz legezkoa da, eta norbait galdera bati erantzunez zaborra egiten hasten bada, guztiz normala da erantzutea: “Ez dakizu zertaz ari zaren, ezta?”. eta dena txantxa bihurtu.
Egokiena, etengabe pozik egon zaitezkeen lan bat eduki nahiko zenuke. Ez da erraza izango, egun guztiak ez dira eguzkitsuak eta atseginak, batzuetan gogor lan egin behar duzu, baina balantzea egiten hasten zarenean aterako da: wow, hau leku zoragarria da, ondo sentitzen naiz hemen lanean, bai emozionalki bai intelektualki. Eta badira aholkulari gisa joan eta berehala konturatzen zaren enpresak ezin duzula hiru hilabetez jasan eta izututa ihes egingo zenukeela. Horri buruz hitz egin nahi dudan erreportajean.
Tim Lister hitzaldi batekin helduko da 2019ko urriaren 29tik 30era San Petersburgon egingo den DevOops 2019 konferentziara. Sarrerak erosi ditzakezu . Zure zain gaude DevOops-en!
Iturria: www.habr.com