Tim Lister - mede-outeur van boeke
- “Menslike faktor. Suksesvolle projekte en spanne" (die oorspronklike boek heet "Peopleware")
- "Wals met die bere: bestuur van risiko in sagtewareprojekte"
- “Adrenalien-gek en gezombifiseer deur patrone. Gedragspatrone van projekspanne"
Al hierdie boeke is klassieke in hul veld en is saam met kollegas in . In Rusland is sy kollegas die bekendste - и , wat ook baie bekende werke geskryf het.
Tim het 40 jaar ondervinding in sagteware-ontwikkeling; in 1975 (nie een van diegene wat hierdie habrapos geskryf het is vanjaar gebore nie), was Tim reeds die uitvoerende vise-president van Yourdon Inc. Hy bestee nou sy tyd aan konsultasie, onderrig en skryf, met af en toe besoeke aan konferensies regoor die wêreld.
Ons het spesiaal vir Habr 'n onderhoud met Tim Lister gevoer. Hy sal die DevOops 2019-konferensie open, en ons het baie vrae, oor boeke en meer. Die onderhoud word gevoer deur Mikhail Druzhinin en Oleg Chirukhin van die konferensieprogramkomitee.
Michael: Kan jy 'n paar woorde sê oor wat jy nou doen?
Tim: Ek is die hoof van die Atlantic Systems Guild. Daar is ses van ons in die Gilde, ons noem onsself skoolhoofde. Drie in die VSA en drie in Europa - daarom word die Gilde Atlantic genoem. Ons is al soveel jare saam dat jy hulle net nie kan tel nie. Ons het almal ons spesialiteite. Ek werk al die afgelope dekade of meer met kliënte. My projekte sluit nie net bestuur in nie, maar ook vereistesstelling, projekbeplanning en evaluering. Dit blyk dat projekte wat swak begin gewoonlik swak eindig. Daarom is dit die moeite werd om seker te maak dat alle aktiwiteite regtig goed deurdink en gekoördineer is, dat die idees van die skeppers gekombineer word. Dit is die moeite werd om te dink oor wat jy doen en hoekom. Watter strategieë om te gebruik om die projek tot voltooiing te bring.
Ek gee al jare lank berading aan kliënte op verskeie maniere. 'n Interessante voorbeeld is 'n maatskappy wat robotte maak vir knie- en heupchirurgie. Die chirurg opereer nie heeltemal onafhanklik nie, maar gebruik 'n robot. Veiligheid hier, eerlik gesproke, is belangrik. Maar wanneer jy probeer om vereistes te bespreek met mense wat daarop ingestel is om probleme op te los... Dit sal vreemd klink, maar in die VSA is daar (Federal Drug Administration), wat produkte soos hierdie robotte lisensieer. Voordat jy iets verkoop en dit op lewende mense gebruik, moet jy 'n lisensie kry. Een van die voorwaardes is om jou vereistes te wys, wat die toetse is, hoe jy dit getoets het, wat die toetsresultate is. As jy die vereistes verander, moet jy weer en weer deur hierdie hele groot toetsproses gaan. Ons kliënte het daarin geslaag om visuele ontwerp van toepassings by hul vereistes in te sluit. Hulle het direk skermkiekies gehad as deel van die vereistes. Ons moet hulle uittrek en verduidelik dat al hierdie programme vir die grootste deel niks weet van knieë en heupe, al hierdie dinge met die kamera, ens. Ons moet die vereistesdokumente herskryf sodat dit nooit verander nie, tensy 'n paar baie belangrike onderliggende toestande verander. As visuele ontwerp nie in die vereistes is nie, sal die opdatering van die produk baie vinniger wees. Ons werk is om daardie elemente te vind wat handel oor operasies aan die knie, heupe, rug, dit in aparte dokumente uit te trek en te sê dat dit die fundamentele vereistes sal wees. Kom ons stel 'n geïsoleerde groep vereistes oor knieoperasies. Dit sal ons in staat stel om 'n meer stabiele stel vereistes te bou. Ons sal praat oor die hele produkreeks, en nie oor spesifieke robotte nie.
Baie werk is gedoen, maar hulle het steeds by plekke uitgekom waar hulle voorheen weke en maande se herhaalde toetse sonder betekenis of behoefte deurgebring het, want hul vereistes wat op papier beskryf is, het nie saamgestem met die werklike vereistes waarvoor die stelsels gebou is nie. Die FDA het elke keer vir hulle gesê: jou vereistes het verander, nou moet jy alles van nuuts af nagaan. Volledige herkontrolering van die hele produk was besig om die onderneming dood te maak.
So, daar is sulke wonderlike take wanneer jy jouself aan die begin van iets interessants bevind, en die heel eerste aksies bepaal die verdere reëls van die spel. As jy seker maak dat hierdie vroeë aktiwiteit goed begin werk vanuit beide 'n bestuurs- en tegniese oogpunt, is daar 'n kans dat jy met 'n wonderlike projek sal eindig. Maar as hierdie deel van die spoor af gegaan het en iewers verkeerd gegaan het, as jy nie die fundamentele ooreenkomste kan vind nie... nee, dit is nie dat jou projek noodwendig sal misluk nie. Maar jy sal nie meer kan sê: "Ons het puik gevaar, ons het alles regtig effektief gedoen." Dit is die dinge wat ek doen wanneer ek met kliënte kommunikeer.
Michael: Dit wil sê, jy loods projekte, doen een of ander afskop en kyk of die relings in die regte rigting op pad is?
Tim: Ons het ook idees oor hoe om al die stukkies van die legkaart bymekaar te sit: watter vaardighede ons benodig, wanneer presies dit nodig is, hoe die kern van die span lyk en ander sulke fundamentele dinge. Het ons voltydse werknemers nodig of kan ons iemand deeltyds aanstel? Beplanning, bestuur. Vrae soos: Wat is die belangrikste vir hierdie spesifieke projek? Hoe om dit te bereik? Wat weet ons van hierdie produk of projek, wat is die risiko's en waar die onbekendes lê, hoe gaan ons dit alles hanteer? Natuurlik, op hierdie oomblik begin iemand skree "Wat van rats?!" Goed, julle is almal buigsaam, maar so wat? Hoe presies lyk die projek, hoe gaan jy dit uithaal op 'n manier wat by die projek pas? Jy kan nie net sê dat "ons benadering tot enigiets strek nie, ons is 'n Scrum-span!" Dit is nonsens en nonsens. Waarheen gaan jy volgende, hoekom moet dit werk, waar is die punt? Ek leer my kliënte om oor al hierdie vrae te dink.
19 jaar van rats
Michael: In Agile probeer mense dikwels om niks vooraf te definieer nie, maar om so laat as moontlik besluite te neem en sê: ons is te groot, ek sal nie aan die algehele argitektuur dink nie. Ek sal nie aan 'n klomp ander dinge dink nie; In plaas daarvan sal ek iets lewer wat op die oomblik werk aan die kliënt.
Tim: Ek dink dat ratse metodologieë, begin met in 2001, het die bedryf se oë oopgemaak. Maar aan die ander kant is niks perfek nie. Ek is almal vir iteratiewe ontwikkeling. Iterasie maak baie sin in die meeste projekte. Maar die vraag waaroor jy moet dink, is: sodra die produk uit en in gebruik is, hoe lank hou dit? Is dit 'n produk wat ses maande sal hou voordat dit deur iets anders vervang word? Of is dit 'n produk wat vir baie, baie jare sal werk? Natuurlik sal ek nie name noem nie, maar... In New York en sy finansiële gemeenskap is die mees fundamentele stelsels baie oud. Dit is ongelooflik. Jy kyk na hulle en dink, as jy maar net in tyd kan teruggaan, na 1994, en vir die ontwikkelaars sê: “Ek het uit die toekoms gekom, van 2019 af. Ontwikkel net hierdie stelsel vir so lank as wat jy nodig het. Maak dit uitbreibaar, dink aan die argitektuur. Dit sal dan vir meer as vyf-en-twintig jaar verbeter word. As jy ontwikkeling ’n bietjie langer uitstel, sal niemand in die groot skema van dinge agterkom nie!” Wanneer jy dinge oor die lang termyn skat, moet jy oorweeg hoeveel dit in totaal sal kos. Soms is goed ontwerpte argitektuur regtig die moeite werd, en soms is dit nie. Ons moet rondkyk en onsself afvra: is ons in die regte situasie vir so 'n besluit?
So 'n idee soos "Ons is vir rats, die kliënt sal self vir ons sê wat hy wil kry" - dit is super naïef. Kliënte weet nie eens wat hulle wil hê nie, en selfs meer so weet hulle nie wat hulle kan kry nie. Sommige mense sal historiese voorbeelde as argumente begin noem, ek het dit al gesien. Maar tegnies gevorderde mense sê dit gewoonlik nie. Hulle sê: "Dit is 2019, dit is die geleenthede wat ons het, en ons kan die manier waarop ons na hierdie dinge kyk heeltemal verander!" In plaas daarvan om bestaande oplossings na te boots, hulle 'n bietjie mooier en meer gekam te maak, moet jy soms uitgaan en sê: "Kom ons herontdek heeltemal wat ons hier probeer doen!"
En ek dink nie die meeste kliënte kan so oor die probleem dink nie. Hulle sien net wat hulle reeds het, dis al. Daarna kom hulle met versoeke soos "kom ons maak dit 'n bietjie eenvoudiger," of wat hulle ook al gewoonlik sê. Maar ons is nie kelners of kelnerinne nie, so ons kan 'n bestelling neem, maak nie saak hoe dom dit uitdraai nie en dit dan in die kombuis bak. Ons is hulle gidse. Ons moet hulle oë oopmaak en sê: hey, ons het nuwe geleenthede hier! Besef jy dat ons die manier waarop hierdie deel van jou besigheid gedoen word werklik kan verander? Een van die probleme met Agile is dat dit die bewustheid verwyder van wat 'n geleentheid is, wat 'n probleem is, wat moet ons selfs doen, watter beskikbare tegnologieë die beste geskik is vir hierdie spesifieke situasie.
Miskien is ek te skepties hier: daar is baie wonderlike dinge wat in die ratse gemeenskap gebeur. Maar ek het 'n probleem met die feit dat in plaas daarvan om 'n projek te definieer, begin mense hul hande opsteek. Ek sou hier vra - wat doen ons, hoe gaan ons dit doen? En op een of ander manier op magiese wyse blyk dit altyd dat die kliënt beter as enigiemand behoort te weet. Maar die kliënt weet net die beste wanneer hy kies uit dinge wat reeds deur iemand gebou is. As ek 'n motor wil koop en ek ken die grootte van my gesinsbegroting, dan sal ek vinnig 'n motor kies wat by my leefstyl pas. Hier weet ek alles beter as enigiemand! Maar let asseblief daarop dat iemand reeds die karre gemaak het. Ek het geen idee hoe om 'n nuwe motor uit te vind nie, ek is nie 'n kenner nie. Wanneer ons pasgemaakte of spesiale produkte skep, moet die kliënt se stem in ag geneem word, maar dit is nie meer die enigste stem nie.
Oleg: Jy het die Agile Manifes genoem. Moet ons dit op een of ander manier opdateer of hersien met inagneming van die moderne begrip van die kwessie?
Tim: Ek sou nie aan hom raak nie. Ek dink dit is 'n wonderlike geskiedkundige dokument. Ek bedoel, hy is wat hy is. Hy word 19 jaar oud, hy is oud, maar in sy tyd het hy 'n rewolusie gemaak. Wat hy goed gedoen het, is dat hy 'n reaksie ontlok het en mense oor hom begin fluister het. Jy het heel waarskynlik nog nie in 2001 in die bedryf gewerk nie, maar toe het almal volgens prosesse gewerk. Software Engineering Institute, vyf vlakke van die sagteware volledigheidsmodel (CMMI). Ek weet nie of sulke legendes van die diep oudheid jou iets vertel nie, maar toe was dit 'n deurbraak. Mense het eers geglo dat as die prosesse reg opgestel is, dan sal die probleme vanself verdwyn. En dan kom die Manifes en sê: “Nee, nee, nee – ons sal gebaseer wees op mense, nie prosesse nie.” Ons is meesters in sagteware-ontwikkeling. Ons verstaan dat die ideale proses 'n lugspieëling is; dit gebeur nie. Daar is te veel eiesinnigheid in projekte, die idee van een enkele perfekte proses vir alle projekte maak nie sin nie. Die probleme is te kompleks om te beweer dat daar net een oplossing vir alles is (hallo, nirvana).
Ek neem nie aan om in die toekoms te kyk nie, maar ek sal sê dat mense nou meer oor projekte begin dink het. Ek dink die Agile Manifes is baie goed om uit te spring en te sê: "Haai! Jy is op 'n skip, en jy self bestuur hierdie skip. Jy sal 'n besluit moet neem - ons sal nie 'n universele resep vir alle situasies voorstel nie. Jy is die bemanning van die skip, en as jy goed genoeg is, kan jy 'n pad na jou doel vind. Daar was ander skepe voor jou, en daar sal ander skepe ná jou wees, maar tog is jou reis in ’n sekere sin uniek.” Iets soos dit! Dit is 'n manier van dink. Vir my is daar niks nuuts onder die son nie, mense het al voorheen gevaar en sal weer vaar, maar vir jou is dit jou hoofreis, en ek sal nie vir jou sê wat presies met jou gaan gebeur nie. Jy moet die vaardighede van gekoördineerde werk in 'n span hê, en as jy dit regtig het, sal alles uitwerk en jy sal kom waar jy wou.
Menseware: 30 jaar later
Oleg: Was Peopleware 'n revolusie sowel as die Manifes?
Tim: Peopleware... Ek en Tom het hierdie boek geskryf, maar ons het nie gedink dit sou so gebeur nie. Op een of ander manier het dit by baie mense se idees aanklank gevind. Dit was die eerste boek wat gesê het: sagteware-ontwikkeling is 'n baie mens-intensiewe aktiwiteit. Ten spyte van ons tegniese aard, is ons ook 'n gemeenskap van mense wat iets groots bou, selfs groot, baie kompleks. Niemand kan sulke goed alleen skep nie, reg? So die idee van "span" het baie belangrik geword. En nie net vanuit 'n bestuursoogpunt nie, maar ook vir tegniese mense wat saamgekom het om werklik komplekse diep probleme met 'n klomp onbekendes op te los. Vir my persoonlik was dit 'n groot toets van intelligensie deur my loopbaan. En hier moet jy kan sê: ja, hierdie probleem is meer as wat ek op my eie kan hanteer, maar saam kan ons ’n elegante oplossing vind waarop ons trots kan wees. En ek dink dit was hierdie idee wat die meeste aanklank gevind het. Die idee dat ons deel van die tyd op ons eie werk, deel van die tyd as deel van 'n groep, en dikwels word die besluit deur die groep geneem. Groepprobleemoplossing het vinnig 'n belangrike kenmerk van komplekse projekte geword.
Ten spyte van die feit dat Tim 'n groot aantal praatjies gehou het, word baie min daarvan op YouTube geplaas. Jy kan kyk na die verslag "The Return of Peopleware" van 2007. Die kwaliteit laat natuurlik veel te wense oor.
Michael: Het enigiets verander in die afgelope 30 jaar sedert die boek gepubliseer is?
Tim: Jy kan vanuit baie verskillende hoeke hierna kyk. Sosiologies gesproke... eens op 'n tyd, in eenvoudiger tye, het jy en jou span in dieselfde kantoor gesit. Julle kan elke dag naby wees, saam koffie drink en werk bespreek. Wat regtig verander het, is dat spanne nou geografies versprei kan word, in verskillende lande en tydsones, maar steeds werk hulle aan dieselfde probleem, en dit voeg 'n hele nuwe laag van kompleksiteit by. Dit klink dalk ouskool, maar daar is niks soos van aangesig tot aangesig kommunikasie waar julle almal saam is, saamwerk, en julle na 'n kollega kan stap en sê, kyk wat het ek ontdek, hoe hou jy hiervan? Gesprekke van aangesig tot aangesig bied 'n vinnige manier om na informele kommunikasie oor te skakel, en ek dink ratse entoesiaste moet ook daarvan hou. En ek is ook bekommerd, want in werklikheid het die wêreld baie klein geblyk te wees, en nou is dit alles bedek met verspreide spanne, en dit is alles baie kompleks.
Ons woon almal in DevOps
Michael: Selfs uit die oogpunt van die konferensieprogramkomitee het ons mense in Kalifornië, in New York, Europa, Rusland... daar is nog niemand in Singapoer nie. Die verskil in geografie is redelik groot, en mense begin selfs meer uitsprei. As ons oor ontwikkeling praat, kan jy ons meer vertel oor devops en die afbreek van hindernisse tussen spanne? Daar is 'n konsep dat almal in hul bunkers sit, en nou stort die bunkers in duie, wat dink jy van hierdie analogie?
Tim: Dit lyk vir my dat in die lig van onlangse tegnologiese deurbrake, devops van groot belang is. Voorheen het jy spanne ontwikkelaars en administrateurs gehad, hulle het gewerk, gewerk, gewerk, en op 'n stadium het 'n ding verskyn waarmee jy na die admins kon kom en dit vir produksie uitrol. En hier het die gesprek oor die bunker begin, want die admins is soort van bondgenote, ten minste nie vyande nie, maar jy het eers met hulle gepraat toe alles gereed was om na produksie te gaan. Het jy met iets na hulle toe gegaan en gesê: kyk watter toepassing het ons, maar kan jy hierdie toepassing uitrol? En nou het die hele konsep van aflewering ten goede verander. Ek bedoel, daar was hierdie idee dat jy veranderinge vinnig kon deurdruk. Ons kan produkte dadelik opdateer. Ek glimlag altyd wanneer Firefox op my skootrekenaar opduik en sê, hey, ons het jou Firefox in die agtergrond opgedateer, en sodra jy 'n minuut het, sal jy omgee om hier te klik en ons sal jou die nuutste weergawe gee. En ek was soos: "O ja, skat!" Terwyl ek geslaap het, het hulle gewerk om vir my 'n nuwe weergawe direk op my rekenaar af te lewer. Dit is wonderlik, ongelooflik.
Maar hier is die moeilikheid: jy het hierdie kenmerk met die opdatering van die sagteware, maar die integrasie van mense is baie moeiliker. Wat ek wil uitspreek by die DevOops keynote is dat ons nou baie meer spelers het as wat ons ooit gehad het. As jy net dink aan almal wat betrokke is in net een span... Jy het daaraan gedink as 'n span, en dit is veel meer as net 'n span programmeerders. Dit is toetsers, projekbestuurders en 'n klomp ander mense. En elkeen het hul eie sienings oor die wêreld. Produkbestuurders is heeltemal anders as projekbestuurders. Admins het hul eie take. Dit word 'n taamlik moeilike probleem om alle deelnemers te koördineer om aan te hou om bewus te wees van wat gebeur en nie mal te raak nie. Dit is nodig om die take van die groep te skei en take wat op almal van toepassing is. Dit is 'n baie moeilike taak. Aan die ander kant dink ek dit is alles baie beter as wat dit baie jare gelede was. Dit is presies die pad waarop mense groei en leer om reg te gedra. Wanneer jy integrasie doen, verstaan jy dat daar geen ondergrondse ontwikkeling moet wees nie, sodat die sagteware op die heel laaste oomblik nie soos 'n jack-in-the-box uitkruip nie: soos, kyk wat het ons hier gedoen! Die idee is dat jy integrasie en ontwikkeling sal kan doen, en aan die einde sal jy op 'n netjiese en iteratiewe manier uitrol. Dit alles beteken baie vir my. Dit maak dit moontlik om meer waarde vir die gebruikers van die stelsel en vir jou kliënt te skep.
Michael: Die hele idee van devops is om betekenisvolle ontwikkelings so vroeg as moontlik te lewer. Ek sien die wêreld het al hoe meer begin versnel. Hoe om by sulke versnellings aan te pas? Tien jaar gelede het dit nie bestaan nie!
Tim: Natuurlik wil almal meer en meer funksionaliteit hê. Nie nodig om te beweeg nie, stapel net meer op. Soms moet jy selfs stadiger ry vir die volgende inkrementele opdatering om enigiets nuttigs te bring - en dit is heeltemal normaal.
Die idee dat jy moet hardloop, hardloop, hardloop is nie die beste nie. Dit is onwaarskynlik dat iemand hul lewe so wil leef. Ek wil graag hê dat die ritme van aflewerings die projek se eie ritme bepaal. As jy net 'n stroom van klein, relatief betekenislose dinge produseer, het dit alles niks betekenis nie. In plaas daarvan om gedagtesloos te probeer om dinge so vroeg as moontlik vry te stel, is strategie wat die moeite werd is om met die hoofontwikkelaars en produk- en projekbestuurders te bespreek. Maak dit selfs sin?
Patrone en antipatrone
Oleg: Jy praat gewoonlik oor patrone en antipatrone, en dit is die verskil tussen die lewe en dood van projekte. En nou bars devops in ons lewens in. Het dit enige van sy eie patrone en anti-patrone wat die projek op die plek kan doodmaak?
Tim: Patrone en anti-patrone gebeur heeltyd. Iets om oor te praat. Wel, daar is hierdie ding wat ons "blink dinge" noem. Mense hou regtig baie van nuwe tegnologie. Hulle word eenvoudig betower deur die glans van alles wat koel en stylvol lyk, en hulle hou op om vrae te vra: is dit selfs nodig? Wat gaan ons bereik? Is hierdie ding betroubaar, maak dit enige sin? Ek sien dikwels mense, so te sê, op die voorpunt van tegnologie. Hulle word gehipnotiseer deur wat in die wêreld gebeur. Maar as jy nader kyk na watter nuttige dinge hulle doen, is daar dikwels eenvoudig niks nuttig nie!
Ons het net met ons kamerade gesels dat hierdie jaar 'n herdenkingsjaar is, vyftig jaar sedert mense op die maan geland het. Dit was in 1969. Die tegnologie wat mense gehelp het om daar te kom, is nie eers 1969-tegnologie nie, maar eerder 1960 of 62, want NASA wou net gebruik wat goeie bewyse van betroubaarheid gehad het. En so kyk jy daarna en verstaan - ja, en hulle was waar! Nou nee, nee, maar jy kry probleme met tegnologie bloot omdat alles te hard gedruk word, uit al die krake verkoop word. Mense skree van oral: "Kyk, wat 'n ding, dit is die nuutste ding, die mooiste ding in die wêreld, geskik vir absoluut almal!" Wel, dit is dit ... gewoonlik blyk dit alles net 'n lokmiddel te wees, en dan moet dit alles weggegooi word. Miskien is dit alles omdat ek reeds 'n ou man is en met 'n groot mate van skeptisisme na sulke dinge kyk, wanneer mense uithardloop en sê dat hulle die enigste, mees korrekte manier gevind het om die beste tegnologie te skep. Op hierdie oomblik word 'n stem in my wakker wat sê: "Wat 'n gemors!"
Michael: Inderdaad, hoe gereeld het ons gehoor van die volgende silwer koeël?
Tim: Presies, en dit is die gewone gang van sake! Byvoorbeeld ... dit blyk dat dit reeds 'n grap oor die wêreld geword het, maar hier praat mense gereeld oor blokkettingtegnologie. En hulle maak eintlik sin in sekere situasies! Wanneer jy regtig betroubare bewyse van gebeure nodig het, dat die stelsel werk en dat niemand ons bedrieg het nie, wanneer jy sekuriteitsprobleme het en al daardie goed saam gemeng – maak blockchain sin. Maar wanneer hulle sê dat Blockchain nou oor die wêreld sal vee en alles in sy pad sal wegvee? Droom meer! Dit is 'n baie duur en komplekse tegnologie. Tegnies kompleks en tydrowend. Insluitend suiwer algoritmies, elke keer as jy die wiskunde moet herbereken, met die geringste veranderinge ... en dit is 'n goeie idee - maar net vir sekere gevalle. My hele lewe en loopbaan het hieroor gegaan: interessante idees in baie spesifieke situasies. Dit is baie belangrik om presies te verstaan wat jou situasie is.
Michael: Ja, die hoofvraag van die lewe, die heelal en alles: is hierdie tegnologie of benadering geskik vir jou situasie of nie?
Tim: Hierdie vraag kan reeds met die tegnologiegroep bespreek word. Bring dalk selfs een of ander konsultant in. Kyk na die projek en verstaan – sal ons nou iets reg en nuttig doen, beter as voorheen? Miskien sal dit pas, miskien nie. Maar die belangrikste is, moenie so 'n besluit by verstek neem nie, bloot omdat iemand uitgeblaker het: "Ons het 'n blokketting broodnodig! Ek het sopas van hom in ’n tydskrif op die vliegtuig gelees!” Ernstig? Dis nie eers snaaks nie.
Die mitiese "devops-ingenieur"
Oleg: Nou is almal besig om devops te implementeer. Iemand lees van devops op die internet, en môre verskyn nog 'n vakature op 'n werwingswerf. "devops ingenieur". Hier wil ek jou aandag vestig: dink jy hierdie term, "devops engineer," het 'n reg op lewe? Daar is 'n mening dat devops 'n kultuur is, en iets klop nie hier nie.
Tim: So-so. Laat hulle dan dadelik 'n verduideliking van hierdie term gee. Iets om dit uniek te maak. Totdat hulle bewys dat daar 'n unieke kombinasie van vaardighede agter 'n vakature soos hierdie is, sal ek dit nie koop nie! Ek bedoel, wel, ons het 'n postitel, "devops engineer," 'n interessante titel, ja, wat volgende? Postitels is oor die algemeen 'n baie interessante ding. Kom ons sê "ontwikkelaar" - wat is dit in elk geval? Verskillende organisasies beteken heeltemal verskillende dinge. In sommige maatskappye skryf programmeerders van hoë gehalte toetse wat meer sin maak as toetse wat deur spesiale professionele toetsers in ander maatskappye geskryf word. So wat, is hulle nou programmeerders of toetsers?
Ja, ons het werkstitels, maar as jy lank genoeg vrae vra, blyk dit uiteindelik dat ons almal probleemoplossers is. Ons is oplossingsoekers, en sommige het 'n paar tegniese vaardighede en sommige het verskillendes. As jy in 'n omgewing woon waar DevOps deurgedring het, is jy besig met die integrasie van ontwikkeling en administrasie, en hierdie aktiwiteit het 'n redelik belangrike doel. Maar as jy gevra word wat presies jy doen en waarvoor jy verantwoordelik is, blyk dit dat mense al hierdie dinge van ouds af doen. "Ek is verantwoordelik vir die argitektuur", "Ek is verantwoordelik vir die databasisse" en so aan, wat ook al, jy sien - dit alles was voor "devops".
As iemand vir my hul werkstitel vertel, luister ek nie regtig baie nie. Dit is beter om hom te laat vertel waarvoor hy eintlik verantwoordelik is, dit sal ons toelaat om die kwessie baie beter te verstaan. My gunsteling voorbeeld is wanneer 'n persoon beweer dat hy 'n "projekbestuurder" is. Wat? Dit beteken niks, ek weet steeds nie wat jy doen nie. 'n Projekbestuurder kan 'n ontwikkelaar wees, die leier van 'n span van vier mense, wat kode skryf, werk doen, wat 'n spanleier geword het, wat mense self onder mekaar as 'n leier erken. En ook, 'n projekbestuurder kan 'n bestuurder wees wat seshonderd mense op 'n projek bestuur, ander bestuurders bestuur, verantwoordelik is vir die opstel van skedules en beplanning van begrotings, dis al. Dit is twee heeltemal verskillende wêrelde! Maar hul werkstitel klink dieselfde.
Kom ons draai dit 'n bietjie anders om. Waarmee is jy regtig goed, het jy baie ondervinding, het jy talent? Waarvoor sal jy verantwoordelikheid neem omdat jy dink jy kan die taak hanteer? En hier sal iemand dadelik begin ontken: nee, nee, nee, ek het glad nie begeerte om met projekhulpbronne te handel nie, dit is nie my besigheid nie, ek is 'n tegniese ou en ek verstaan bruikbaarheid en gebruikerskoppelvlakke, ek verstaan nie wil enigsins leërs van mense bestuur, laat ek beter gaan werk.
En terloops, ek is 'n groot voorstander van 'n benadering waarin hierdie soort skeiding van vaardighede goed werk. Waar tegnici hul loopbane kan laat groei so ver hulle wil. Ek sien egter steeds organisasies waar tegnici kla: ek sal in projekbestuur moet gaan, want dit is die enigste manier in hierdie maatskappy. Soms lei dit tot verskriklike uitkomste. Die beste tegnici is glad nie goeie bestuurders nie, en die beste bestuurders kan nie tegnologie hanteer nie. Kom ons wees eerlik hieroor.
Ek sien nou baie aanvraag hiervoor. As jy 'n tegnikus is, kan jou maatskappy jou help, maar ongeag, jy moet regtig jou eie loopbaanpad vind, want tegnologie bly verander en jy moet jouself daarmee saam herontdek! Binne net twintig jaar kan tegnologieë minstens vyf keer verander. Tegnologie is 'n vreemde ding...
"Kenners van alles"
Michael: Hoe kan mense sulke spoed van tegnologiese verandering hanteer? Hul kompleksiteit groei, hul getal groei, die totale hoeveelheid kommunikasie tussen mense groei ook, en dit blyk dat jy nie 'n "kenner in alles" kan word nie.
Tim: Reg! As jy in tegnologie werk, ja, moet jy beslis iets spesifiek kies en daarin delf. Sommige tegnologie wat jou organisasie nuttig vind (en dalk eintlik nuttig sal wees). En as jy nie meer daarin belangstel nie – ek sou nooit geglo het dat ek dit sou sê nie – wel, miskien moet jy na een of ander organisasie skuif waar die tegnologie interessanter of geriefliker is om te studeer.
Maar oor die algemeen, ja, jy is reg. Tegnologieë groei in alle rigtings gelyktydig; niemand kan sê "Ek is 'n kundige tegnoloog in al die tegnologieë wat bestaan nie." Aan die ander kant is daar sponsmense wat letterlik tegnologiese kennis absorbeer en mal daaroor is. Ek het al 'n paar sulke mense gesien, hulle haal letterlik asem en leef dit uit, dit is nuttig en interessant om met hulle te praat. Hulle bestudeer nie net wat binne die organisasie gebeur nie, maar oor die algemeen praat hulle daaroor, hulle is ook baie cool tegnoloë, hulle is baie bewus en doelgerig. Hulle probeer net op die kruin van die golf bly, ongeag wat hul hooftaak is, want hul passie is die beweging van Tegnologie, die bevordering van tegnologie. As jy skielik so iemand ontmoet, moet jy saam met hom middagete gaan eet en verskeie oulike dinge oor middagete bespreek. Ek dink enige organisasie het ten minste 'n paar van sulke mense nodig.
Risiko's en onsekerheid
Michael: Geëerde ingenieurs, ja. Kom ons raak aan risikobestuur terwyl ons tyd het. Ons het hierdie onderhoud begin met 'n bespreking van mediese sagteware, waar foute tot ernstige gevolge kan lei. Toe het ons gepraat oor die Lunar Program, waar die koste van 'n fout miljoene dollars is, en moontlik verskeie menselewens. Maar nou sien ek die teenoorgestelde beweging in die bedryf, mense dink nie aan risiko's nie, probeer dit nie voorspel nie, neem dit nie eens waar nie.
Oleg: Beweeg vinnig en breek dinge!
Michael: Ja, beweeg vinnig, breek dinge, meer en meer dinge, totdat jy doodgaan van iets. Vanuit jou oogpunt, hoe moet die gemiddelde ontwikkelaar leerrisikobestuur nou benader?
Tim: Kom ons trek hier 'n lyn tussen twee dinge: risiko's en onsekerheid. Dit is verskillende dinge. Onsekerheid vind plaas wanneer jy nie genoeg data op enige gegewe tydstip het om by 'n definitiewe antwoord uit te kom nie. Byvoorbeeld, in die baie vroeë stadium van 'n projek, as iemand jou vra "wanneer sal jy die werk klaarmaak," as jy 'n redelik eerlike persoon is, sal jy sê: "Ek het geen idee nie." Jy weet net nie, en dit is goed. Jy het nog nie die probleme bestudeer nie en is nie vertroud met die span nie, jy ken nie hul vaardighede nie, ensovoorts. Dit is onsekerheid.
Risiko's ontstaan wanneer potensiële probleme reeds geïdentifiseer kan word. Hierdie soort ding kan gebeur, die waarskynlikheid daarvan is groter as nul, maar minder as honderd persent, iewers tussenin. As gevolg daarvan kan enigiets gebeur, van vertragings en onnodige werk, maar selfs tot 'n noodlottige uitkoms vir die projek. Die uitkoms, as julle sê – ouens, kom ons vou ons sambrele op en verlaat die strand, ons sal dit nooit klaarmaak nie, dit is alles verby, punt. Ons het die aanname gemaak dat hierdie ding sou werk, maar dit werk glad nie, dit is tyd om op te hou. Dit is die situasies.
Dikwels is probleme die maklikste om op te los wanneer hulle reeds na vore gekom het, wanneer die probleem op die oomblik gebeur. Maar wanneer 'n probleem reg voor jou is, doen jy nie risikobestuur nie - jy doen probleemoplossing, krisisbestuur. As jy 'n hoofontwikkelaar of -bestuurder is, wonder jy seker wat kan gebeur wat sal lei tot vertragings, tydmors, onnodige koste of die ineenstorting van die hele projek? Wat sal ons laat stop en oor begin? Wanneer al hierdie dinge werk, wat sal ons daarmee doen? Daar is 'n eenvoudige antwoord wat vir die meeste situasies geldig is: moenie weghardloop van risiko's nie, werk daaraan. Kyk hoe jy 'n riskante situasie kan oplos, dit tot niks kan verminder, dit van 'n probleem in iets anders kan verander. In plaas daarvan om te sê: wel, ons sal probleme oplos soos hulle opduik.
Onsekerheid en risiko behoort op die voorpunt te wees van alles waarmee jy te doen het. Jy kan 'n projekplan neem, voor die tyd na sekere kritieke risiko's kyk en sê: ons moet dit nou hanteer, want as enige hiervan verkeerd loop, sal niks anders saak maak nie. Jy moenie bekommerd wees oor die skoonheid van die tafeldoek op die tafel as dit onduidelik is of jy aandete kan kook nie. Eerstens moet jy al die risiko's identifiseer om 'n heerlike aandete voor te berei, dit te hanteer, en eers dan dink aan al die ander dinge wat nie 'n werklike bedreiging inhou nie.
Weereens, wat maak jou projek uniek? Kom ons kyk wat ons projek van die spoor kan laat gaan. Wat kan ons doen om die waarskynlikheid dat dit sal gebeur te verminder? Gewoonlik kan jy hulle nie net 100% neutraliseer en met 'n skoon gewete verklaar: "Dit is dit, dit is nie meer 'n probleem nie, die risiko is opgelos!" Vir my is dit 'n teken van volwasse gedrag. Dit is die verskil tussen 'n kind en 'n volwassene – kinders dink dat hulle onsterflik is, dat niks verkeerd kan gaan nie, alles sal regkom! Terselfdertyd kyk volwassenes hoe driejarige kinders op die speelgrond spring, die bewegings met hul oë volg en vir hulself sê: "ooh-ooh, ooh-ooh." Ek staan naby en maak gereed om te vang wanneer die kind wel val.
Aan die ander kant, die rede hoekom ek so baie van hierdie besigheid hou, is omdat dit riskant is. Ons doen dinge, en daardie dinge is riskant. Hulle vereis 'n volwasse benadering. Entoesiasme alleen sal nie jou probleme oplos nie!
Volwasse ingenieursdenke
Michael: Die voorbeeld met kinders is goed. As ek 'n gewone ingenieur is, dan is ek bly om 'n kind te wees. Maar hoe beweeg jy na meer volwasse denke?
Tim: Een van die idees wat ewe goed werk met óf 'n beginner óf 'n gevestigde ontwikkelaar, is die konsep van konteks. Wat ons doen, wat ons gaan bereik. Wat is regtig belangrik vir hierdie projek? Dit maak nie saak wie jy op hierdie projek is nie, of jy 'n intern of die hoofargitek is, almal het konteks nodig. Ons moet almal kry om op 'n groter skaal te dink as hul eie stukke werk. "Ek maak my stuk, en solank my stuk werk, is ek gelukkig." Nee en weer nee. Dit is altyd die moeite werd (sonder om onbeskof te wees!) om mense te herinner aan die konteks waarin hulle werk. Wat ons almal saam probeer bereik. Idees dat jy 'n kind kan wees solank alles in orde is met jou deel van die projek - asseblief, moenie dit doen nie. As ons enigsins die wenstreep oorsteek, sal ons dit net saam oorsteek. Jy is nie alleen nie, ons is almal saam. As al die mense in die projek, oud en jonk, begin praat oor wat presies belangrik is vir die projek, hoekom die maatskappy geld belê in wat ons almal probeer bereik... sal die meeste van hulle baie beter voel omdat hulle sal sien hoe hul werk korreleer met die werk van almal anders. Aan die een kant verstaan ek die stuk waarvoor ek persoonlik verantwoordelik is. Maar om die werk klaar te maak, het ons al die ander mense ook nodig. En as jy regtig dink jy is klaar, het ons altyd werk om te doen in die projek!
Oleg: Relatief gesproke, as jy volgens Kanban werk, wanneer jy die bottelnek van een of ander toetsing tref, kan jy ophou wat jy daar gedoen het (byvoorbeeld, programmering) en die toetsers gaan help.
Tim: Presies. Ek dink die beste tegnici, as jy mooi na hulle kyk, is hulle soort van hul eie bestuurders. Hoe kan ek dit formuleer...
Oleg: Jou lewe is jou projek, wat jy bestuur.
Tim: Presies! Ek bedoel, jy neem verantwoordelikheid, jy verstaan die kwessie, en jy kom in aanraking met mense wanneer jy sien dat jou besluite hul werk kan beïnvloed, dinge soos dit. Dit gaan nie daaroor om net by jou lessenaar te sit, jou werk te doen en nie eers te besef wat om jou aangaan nie. Nee nee nee. Terloops, een van die beste dinge van Agile is dat hulle kort naellope voorgestel het, want op hierdie manier is die stand van sake van alle deelnemers duidelik waarneembaar, hulle kan dit alles saam sien. Ons praat elke dag oor mekaar.
Hoe om in risikobestuur te kom
Oleg: Is daar enige formele kennisstruktuur op hierdie gebied? Ek is byvoorbeeld 'n Java-ontwikkelaar en wil risikobestuur verstaan sonder om 'n regte projekbestuurder te word deur onderwys. Ek sal waarskynlik eers McConnell se "How Much Does a Software Project Cost" lees, en wat dan? Wat is die eerste stappe?
Tim: Die eerste is om met mense in die projek te begin kommunikeer. Dit bied 'n onmiddellike verbetering in die kultuur van kommunikasie met kollegas. Ons moet begin deur alles by verstek oop te maak, in plaas daarvan om dit weg te steek. Sê: dit is die dinge wat my pla, dit is die dinge wat my snags wakker hou, ek het vandag snags wakker geword en was soos: my God, ek moet hieroor dink! Sien ander dieselfde ding? Moet ons as 'n groep op hierdie potensiële probleme reageer? Jy moet 'n bespreking oor hierdie onderwerpe kan ondersteun. Daar is geen vooraf opgestelde formule waarvolgens ons werk nie. Dit gaan nie oor die maak van hamburgers nie, dit gaan alles oor mense. “Made a cheeseburger, sell a cheeseburger” is glad nie ons ding nie, en daarom is ek so lief vir hierdie werk. Ek hou daarvan as alles wat bestuurders vroeër gedoen het, nou die eiendom van die span word.
Oleg: Jy het in boeke en onderhoude gepraat oor hoe mense meer omgee vir geluk as oor syfers op 'n grafiek. Aan die ander kant, wanneer jy vir die span sê: ons beweeg na devops, en nou moet die programmeerder voortdurend kommunikeer, kan dit ver buite sy gemaksone wees. En op hierdie oomblik kan hy, kom ons sê, diep ongelukkig wees. Wat om te doen in hierdie situasie?
Tim: Ek is nie seker presies wat om te doen nie. As 'n ontwikkelaar te geïsoleer is, sien hulle nie hoekom die werk in die eerste plek gedoen word nie, hulle kyk net na hul deel van die werk, en hulle moet ingaan in wat ek "konteks" noem. Hy moet uitvind hoe alles saamhang. En natuurlik bedoel ek nie formele aanbiedings of so iets nie. Ek praat van die feit dat jy met kollegas moet kommunikeer oor die werk as geheel, en nie net oor die deel daarvan waarvoor jy verantwoordelik is nie. Dit is waar jy idees, algemene ooreenkomste kan begin bespreek om jou werk goed in mekaar te laat pas, en hoe om 'n gemeenskaplike probleem saam aan te pak.
Om hulle te help aanpas, wil hulle dikwels tegnici na opleiding stuur, en hulle bespreek opleiding. ’n Vriend van my sê graag opleiding is vir honde. Daar is opleiding vir mense. Een van die beste dinge om as 'n ontwikkelaar te leer, is interaksie met jou eweknieë. As iemand regtig goed in iets is, moet jy kyk hoe hulle werk of met hulle praat oor hul werk of iets. Sommige konvensionele Kent Beck het voortdurend oor ekstreme programmering gepraat. Dit is snaaks omdat XP so 'n eenvoudige idee is, maar dit veroorsaak soveel probleme. Vir sommige is om XP te doen soos om gedwing te word om kaal uit te trek voor vriende. Hulle sal sien wat ek doen! Hulle is my kollegas, hulle sal nie net sien nie, maar ook verstaan! Verskriklik! Sommige mense begin ernstig senuweeagtig raak. Maar wanneer jy besef dat dit die uiteindelike manier is om te leer, verander alles. Jy werk nou saam met mense, en sommige mense verstaan die onderwerp baie beter as jy.
Michael: Maar dit alles dwing jou om uit jou gemaksone te stap. As ingenieur moet jy uit jou gemaksone kom en kommunikeer. As 'n probleemoplosser moet jy jouself voortdurend in 'n swak posisie plaas en dink oor wat verkeerd kan gaan. Hierdie tipe werk is inherent ontwerp om 'n oorlas te wees. Jy plaas jouself bewustelik in stresvolle situasies. Gewoonlik hardloop mense van hulle af weg, mense hou daarvan om gelukkige kinders te wees.
Tim: Wat gedoen kan word, kan jy uitkom en openlik sê: “Alles is oukei, ek kan dit hanteer! Ek is nie die enigste een wat ongemaklik voel nie. Kom ons bespreek verskeie ongemaklike dinge, almal saam, as ’n span!” Dit is ons algemene probleme, ons moet dit hanteer, weet jy? Ek dink idiosinkratiese genie-ontwikkelaars is soos mammoete, hulle het verdwyn. En hul betekenis is baie beperk. As jy nie kan kommunikeer nie, kan jy nie goed deelneem nie. Daarom, praat net. Wees eerlik en oop. Ek is baie jammer dat dit vir iemand onaangenaam is. Kan jy jou voorstel, baie jare gelede was daar 'n studie waarvolgens die belangrikste vrees in die Verenigde State nie die dood is nie, maar raai wat? Vrees vir openbare redevoering! Dit beteken dat daar iewers mense is wat eerder sal sterf as om 'n kompliment hardop te sê. En ek dink dit is genoeg vir jou om basiese vaardighede te hê, afhangend van wat jy doen. Praatvaardighede, skryfvaardighede – maar net soveel as wat werklik nodig is in jou werk. As jy as 'n ontleder werk, maar nie kan lees, skryf of praat nie, dan sal jy ongelukkig niks in my projekte te doen hê nie!
Die prys van kommunikasie
Oleg: Is dit nie om verskeie redes duurder om sulke uitgaande werknemers in diens te neem nie? Hulle gesels immers gedurig in plaas van om te werk!
Tim: Ek het die kern van die span bedoel, en nie net almal nie. As jy iemand het wat baie gaaf is om databasisse in te stel, daarvan hou om databasisse in te stel, en gaan aanhou om jou databasisse vir die res van sy lewe in te stel en dit is dit, cool, hou so aan. Maar ek praat van mense wat in die projek self wil woon. Die kern van die span, gemik op die ontwikkeling van die projek. Hierdie mense moet regtig voortdurend met mekaar kommunikeer. En veral aan die begin van die projek, wanneer jy risiko's bespreek, maniere om globale doelwitte te bereik en dies meer.
Michael: Dit geld vir almal wat by die projek betrokke is, ongeag spesialisasie, vaardighede of werkswyses. Julle is almal geïnteresseerd in die sukses van die projek.
Tim: Ja, jy voel dat jy genoegsaam in die projek verdiep is, dat jou taak is om die projek te help bewaarheid. Of jy nou 'n programmeerder, ontleder, koppelvlakontwerper, enigiemand is. Dit is die rede hoekom ek elke oggend werk toe kom en dit is wat ons doen. Ons is verantwoordelik vir al hierdie mense, ongeag hul vaardighede. Dit is 'n groep mense wat volwasse gesprekke voer.
Oleg: Trouens, oor spraaksame werknemers gepraat, ek het probeer om die besware van mense, veral bestuurders, wat gevra word om oor te skakel na devops, na hierdie hele nuwe visie van die wêreld te simuleer. En jy as konsultante behoort baie beter bewus te wees van hierdie besware as ek as ontwikkelaar! Deel wat bestuurders die meeste bekommer?
Tim: Bestuurders? Hm. Dikwels is bestuurders onder druk van probleme, gekonfronteer met die behoefte om dringend iets vry te stel en 'n aflewering te maak, en dies meer. Hulle kyk hoe ons gedurig iets bespreek en daaroor stry, en hulle sien dit so: gesprekke, gesprekke, gesprekke... Watter ander gesprekke? Keer terug na jou werk! Want praat voel nie vir hulle soos werk nie. Jy skryf nie kode nie, toets nie sagteware nie, lyk of jy niks doen nie - hoekom stuur jy nie om iets te doen nie? Aflewering is immers reeds oor 'n maand!
Michael: Gaan skryf 'n kode!
Tim: Dit lyk vir my of hulle nie bekommerd is oor werk nie, maar oor die gebrek aan sigbaarheid van vordering. Om dit te laat lyk asof ons nader aan sukses kom, moet hulle sien hoe ons knoppies op die sleutelbord druk. Die hele dag van oggend tot aand. Dit is probleem nommer een.
Oleg: Misha, jy dink aan iets.
Michael: Jammer, ek het in gedagte geraak en 'n terugflits gekry. Dit alles het my laat dink aan 'n interessante saamtrek wat gister gebeur het... Daar was te veel saamtrekke gister... En dit klink alles baie bekend!
Lewe sonder salarisse
Tim: Terloops, dit is glad nie nodig om "saamtrekke" vir kommunikasie te organiseer nie. Ek bedoel, die nuttigste besprekings tussen ontwikkelaars vind plaas wanneer hulle net met mekaar praat. Jy stap soggens in met 'n koppie koffie, en daar is vyf mense wat saamgedrom en verwoed iets tegnies bespreek. Vir my, as ek die bestuurder van hierdie projek is, is dit beter om net te glimlag en iewers te gaan oor my besigheid, laat hulle dit bespreek. Hulle is reeds sover moontlik betrokke. Dit is 'n goeie teken.
Oleg: Terloops, in jou boek het jy 'n klomp notas oor wat goed en wat sleg is. Gebruik jy self enige van hulle? Relatief gesproke, nou het jy 'n maatskappy, en een wat op 'n baie onortodokse manier gestruktureer is ...
Tim: Onortodoks, maar hierdie toestel pas ons perfek. Ons ken mekaar al lank. Ons vertrou mekaar, ons het mekaar baie vertrou voordat ons vennote geword het. En byvoorbeeld, ons het glad nie salarisse nie. Ons werk net, en as ek byvoorbeeld geld by my kliënte verdien het, dan is al die geld na my toe. Daarna betaal ons ledegeld aan die organisasie, en dit is genoeg om die maatskappy self te ondersteun. Boonop spesialiseer ons almal in verskillende dinge. Ek werk byvoorbeeld met rekenmeesters, vul belastingopgawes in, doen allerhande administratiewe goed vir die maatskappy, en niemand betaal my daarvoor nie. James en Tom werk op ons webwerf en niemand betaal hulle ook nie. Solank jy jou ledegeld betaal, sal niemand daaraan dink om vir jou te sê wat jy moet doen nie. Tom werk byvoorbeeld nou baie minder as wat hy vroeër gedoen het. Nou het hy ander belangstellings; hy doen sommige dinge nie vir die Gilde nie. Maar solank hy sy ledegeld betaal, sal niemand na hom toe kom en sê: "Haai, Tom, gaan werk toe!" Dit is baie maklik om met kollegas te handel as daar nie geld tussen julle is nie. En nou is ons verhouding een van die fundamentele idees met betrekking tot verskillende spesialiteite. Dit werk en dit werk baie goed.
Beste raad
Michael: Om terug te keer na "beste advies," is daar iets wat jy oor en oor vir jou kliënte vertel? Daar is 'n idee oor 80/20, en sommige raad word waarskynlik meer gereeld herhaal.
Tim: Ek het eenkeer gedink as jy ’n boek soos Waltzing with Bears skryf, sal dit die verloop van die geskiedenis verander en mense sal ophou, maar... Wel, kyk, maatskappye maak dikwels asof alles reg is met hulle. Sodra iets sleg gebeur, is dit vir hulle 'n skok en 'n verrassing. “Kyk, ons het die stelsel getoets, en dit slaag geen stelseltoetse nie, en dit is nog drie maande se ongeskeduleerde werk, hoe kon dit gebeur? Wat geweet het? Wat kan verkeerd gaan? Ernstig, glo jy dit?
Ek probeer verduidelik dat jy nie te kwaad moet word oor die huidige situasie nie. Ons moet dit uitpraat, regtig verstaan wat verkeerd kon gegaan het, en hoe om te verhoed dat sulke dinge in die toekoms gebeur. As 'n probleem wel opduik, hoe sal ons dit beveg, hoe sal ons dit bekamp?
Vir my lyk dit alles skrikwekkend. Mense hanteer komplekse, ergerlike probleme en hou aan om voor te gee dat as hulle net hul vingers kruis en vir die beste hoop, die "beste" werklik sal gebeur. Nee, dit werk nie so nie.
Oefen risikobestuur!
Michael: Na jou mening, hoeveel organisasies is betrokke by risikobestuur?
Tim: Wat my kwaad maak, is dat mense bloot risiko's neerskryf, na die gevolglike lys kyk en werk toe gaan. Trouens, die identifisering van risiko's vir hulle is risikobestuur. Maar vir my klink dit na 'n rede om te vra: goed, daar is 'n lys, wat presies sal jy verander? Jy moet jou standaard volgordes van aksies verander met inagneming van hierdie risiko's. As daar een of ander moeilikste deel van die werk is, moet jy dit aanpak, en dan eers aanbeweeg na iets eenvoudiger. Begin in die eerste naellope om komplekse probleme op te los. Dit lyk reeds na risikobestuur. Maar gewoonlik kan mense nie sê wat hulle verander het nadat hulle 'n lys van risiko's saamgestel het nie.
Michael: En tog, hoeveel van hierdie maatskappye is betrokke by risikobestuur, vyf persent?
Tim: Ongelukkig haat ek dit om dit te sê, maar dit is 'n baie onbeduidende deel. Maar meer as vyf, want daar is werklik groot projekte, en hulle kan eenvoudig nie bestaan as hulle nie ten minste iets doen nie. Kom ons sê net dat ek baie verbaas sal wees as dit ten minste 25% is. Klein projekte beantwoord sulke vrae gewoonlik so: as die probleem ons raak, dan sal ons dit oplos. Dan beland hulle hulself suksesvol in die moeilikheid en is betrokke by probleembestuur en krisisbestuur. Wanneer jy probeer om 'n probleem op te los en die probleem is nie opgelos nie, welkom by krisisbestuur.
Ja, ek hoor dikwels, "ons sal probleme oplos soos hulle opduik." Ons sal sekerlik? Sal ons regtig besluit?
Oleg: Jy kan dit naïef doen en eenvoudig belangrike invariante in die projekhandves skryf, en as die invariante breek, herbegin net die projek. Dit blyk baie piembucky.
Michael: Ja, dit het met my gebeur dat wanneer risiko's geaktiveer is, die projek eenvoudig herdefinieer is. Lekker, bingo, probleem opgelos, moenie meer bekommerd wees nie!
Tim: Kom ons druk die reset-knoppie! Nee, dit werk nie so nie.
Keynote by DevOops 2019
Michael: Ons kom by die laaste vraag van hierdie onderhoud. Jy kom na die volgende DevOops met 'n keynote, kan jy die gordyn van geheimhouding lig oor wat jy gaan vertel?
Tim: Op die oomblik skryf ses van hulle 'n boek oor werkskultuur, die onuitgesproke reëls van organisasies. Kultuur word bepaal deur die kernwaardes van die organisasie. Gewoonlik sien mense dit nie raak nie, maar nadat ons jare lank in konsultasie gewerk het, is ons gewoond daaraan om dit raak te sien. Jy betree 'n maatskappy, en letterlik binne 'n paar minute begin jy voel wat gebeur. Ons noem dit "geur". Soms is hierdie geur regtig goed, en soms is dit, wel, oops. Dinge is baie anders vir verskillende organisasies.
Michael: Ek werk ook al jare in konsultasie en verstaan goed waarvan jy praat.
Tim: Eintlik is een van die dinge wat die moeite werd is om oor te praat by die hoofnota, dat nie alles deur die maatskappy bepaal word nie. Jy en jou span, as 'n gemeenskap, het jou eie spankultuur. Dit kan die hele maatskappy wees, of 'n aparte afdeling, 'n aparte span. Maar voor jy gesê het, hier is wat ons glo, hier is wat belangrik is ... Jy kan nie 'n kultuur verander voordat die waardes en oortuigings agter spesifieke aksies verstaan word nie. Gedrag is maklik om waar te neem, maar dit is moeilik om na oortuigings te soek. DevOps is net 'n goeie voorbeeld van hoe dinge meer en meer kompleks word. Interaksies word net meer kompleks, dit word glad nie skoner of duideliker nie, so jy moet dink waarin jy glo en waaroor almal rondom jou swyg.
As jy vinnige resultate wil behaal, is hier 'n goeie onderwerp vir jou: het jy maatskappye gesien waar niemand sê "Ek weet nie"? Daar is plekke waar jy 'n persoon letterlik martel totdat hy erken dat hy iets nie weet nie. Almal weet alles, almal is 'n ongelooflike erudiete. Jy nader enige persoon, en hy moet dadelik die vraag beantwoord. In plaas daarvan om te sê "Ek weet nie." Hoera, hulle het 'n klomp erudiete aangestel! En in sommige kulture is dit oor die algemeen baie gevaarlik om te sê "Ek weet nie"; dit kan as 'n teken van swakheid beskou word. Daar is ook organisasies waarin almal, inteendeel, kan sê "Ek weet nie." Daar is dit heeltemal wettig, en as iemand in reaksie op 'n vraag begin mors, is dit heeltemal normaal om te antwoord: "Jy weet nie waarvan jy praat nie, reg?" en verander dit alles in 'n grap.
Ideaal gesproke sal jy graag 'n werk wil hê waar jy voortdurend gelukkig kan wees. Dit sal nie maklik wees nie, nie elke dag is sonnig en lekker nie, soms moet jy hard werk, maar as jy begin om voorraad op te neem, sal dit blyk: sjoe, dit is regtig 'n wonderlike plek, ek voel goed om hier te werk, beide emosioneel en intellektueel. En daar is maatskappye waarheen jy as konsultant gaan en dadelik besef dat jy dit vir drie maande nie kon uithou nie en met afgryse sou weghardloop. Dit is waaroor ek by die verslag wil praat.
Tim Lister sal opdaag met 'n toespraak na die DevOops 2019-konferensie, wat op 29-30 Oktober 2019 in St. Jy kan kaartjies koop . Ons wag vir jou by DevOops!
Bron: will.com