Tim Lister - medforfatter til bøger
- "Menneskelig faktor. Succesfulde projekter og teams" (den originale bog hedder "Peopleware")
- "Waltzing with the Bears: Håndtering af risiko i softwareprojekter"
- "Adrenalin-gal og zombificeret af mønstre. Opførselsmønstre for projektteams"
Alle disse bøger er klassikere inden for deres felt og er skrevet sammen med kolleger i . I Rusland er hans kolleger mest berømte - и , som også skrev mange kendte værker.
Tim har 40 års erfaring med softwareudvikling; i 1975 (ingen af dem, der skrev denne habrapost blev født i år), var Tim allerede executive vice president for Yourdon Inc. Han bruger nu sin tid på at rådgive, undervise og skrive, med lejlighedsvise besøg på konferencer rundt om i verden.
Vi lavede et interview med Tim Lister specielt for Habr. Han åbner DevOops 2019-konferencen, og vi har en masse spørgsmål, om bøger og meget mere. Interviewet er udført af Mikhail Druzhinin og Oleg Chirukhin fra konferencens programkomité.
Michael: Kan du sige et par ord om, hvad du laver nu?
Tim: Jeg er leder af Atlantic Systems Guild. Vi er seks i lauget, vi kalder os selv rektorer. Tre i USA og tre i Europa - det er derfor, Guilden hedder Atlantic. Vi har været sammen i så mange år, at man bare ikke kan tælle dem. Vi har alle vores specialiteter. Jeg har arbejdet med kunder i det sidste årti eller mere. Mine projekter omfatter ikke kun ledelse, men også kravopstilling, projektplanlægning og evaluering. Det ser ud til, at projekter, der starter dårligt, normalt ender dårligt. Derfor er det værd at sørge for, at alle aktiviteter er virkelig gennemtænkte og koordinerede, at idéerne fra skaberne forenes. Det er værd at tænke over, hvad du laver og hvorfor. Hvilke strategier skal bruges til at bringe projektet til afslutning.
Jeg har i mange år rådgivet klienter på forskellige måder. Et interessant eksempel er en virksomhed, der laver robotter til knæ- og hofteoperationer. Kirurgen opererer ikke helt selvstændigt, men bruger en robot. Sikkerhed her, ærlig talt, er vigtig. Men når man forsøger at diskutere krav med folk, der er fokuserede på at løse problemer... Det vil lyde mærkeligt, men i USA er der (Federal Drug Administration), som licenserer produkter som disse robotter. Før du sælger noget og bruger det på levende mennesker, skal du have en licens. En af betingelserne er at vise dine krav, hvad testene er, hvordan du testede dem, hvad testresultaterne er. Hvis du ændrer kravene, så skal du igennem hele denne enorme testproces igen og igen. Vores kunder formåede at inkludere visuelt design af applikationer i deres krav. De havde screenshots direkte som en del af kravene. Vi er nødt til at trække dem ud og forklare, at for det meste ved alle disse programmer ikke noget om knæ og hofter, alle disse ting med kameraet osv. Vi er nødt til at omskrive kravdokumenterne, så de aldrig ændrer sig, medmindre nogle virkelig vigtige underliggende forhold ændres. Hvis visuelt design ikke er i kravene, vil opdatering af produktet være meget hurtigere. Vores opgave er at finde de elementer, der omhandler operationer på knæ, hofter, ryg, trække dem ud i separate dokumenter og sige, at disse vil være de grundlæggende krav. Lad os stille en isoleret gruppe krav om knæoperationer. Dette vil give os mulighed for at opbygge et mere stabilt sæt krav. Vi vil tale om hele produktlinjen, og ikke om specifikke robotter.
Der blev gjort en del arbejde, men de kom alligevel til steder, hvor de tidligere brugte uger og måneder med gentagne tests uden mening eller behov, fordi deres krav beskrevet på papir ikke faldt sammen med de reelle krav, som systemerne var bygget til. FDA fortalte dem hver gang: dine krav har ændret sig, nu skal du tjekke alt fra bunden. Fuldstændig genkontrol af hele produktet dræbte virksomheden.
Så der er så vidunderlige opgaver, når du befinder dig i begyndelsen af noget interessant, og de allerførste handlinger sætter de videre spilleregler. Hvis du sørger for, at denne tidlige aktivitet begynder at fungere godt fra både et ledelsesmæssigt og teknisk synspunkt, er der en chance for, at du ender med et godt projekt. Men hvis denne del er gået af sporet og er gået galt et sted, hvis du ikke kan finde de grundlæggende aftaler... nej, det er ikke sådan, at dit projekt nødvendigvis vil fejle. Men du vil ikke længere være i stand til at sige: "Vi gjorde det godt, vi gjorde alt virkelig effektivt." Det er de ting, jeg gør, når jeg kommunikerer med kunder.
Michael: Det vil sige, at du igangsætter projekter, laver en form for kickoff og tjekker, at skinnerne er på vej i den rigtige retning?
Tim: Vi har også ideer til, hvordan vi sætter alle brikkerne i puslespillet sammen: hvilke færdigheder vi har brug for, hvornår præcist er der brug for dem, hvordan kernen i teamet ser ud og andre sådanne grundlæggende ting. Har vi brug for fuldtidsansatte eller kan vi ansætte nogen på deltid? Planlægning, ledelse. Spørgsmål som: Hvad er vigtigst for netop dette projekt? Hvordan opnår man dette? Hvad ved vi om dette produkt eller projekt, hvad er risiciene, og hvor de ukendte ligger, hvordan skal vi håndtere alt dette? Selvfølgelig begynder nogen i dette øjeblik at råbe "Hvad med agile?!" Okay, I er alle fleksible, men hvad så? Hvordan ser projektet helt præcist ud, hvordan vil du tage det ud på en måde, der passer til projektet? Du kan ikke bare sige, at "vores tilgang strækker sig til hvad som helst, vi er et Scrum-team!" Det her er nonsens og nonsens. Hvor skal du hen næste gang, hvorfor skulle det virke, hvor er meningen? Jeg lærer mine kunder at tænke over alle disse spørgsmål.
19 år med agil
Michael: I Agile forsøger folk ofte ikke at definere noget på forhånd, men at træffe beslutninger så sent som muligt og sige: vi er for store, jeg vil ikke tænke på den overordnede arkitektur. Jeg vil ikke tænke på en masse andre ting, i stedet vil jeg levere noget, der virker til kunden lige nu.
Tim: Jeg tror, at agile metoder, begyndende med i 2001 åbnede branchens øjne. Men på den anden side er intet perfekt. Jeg er helt for iterativ udvikling. Iteration giver meget mening i de fleste projekter. Men spørgsmålet du skal tænke over er: når produktet er ude og i brug, hvor længe holder det så? Er dette et produkt, der holder seks måneder, før det bliver erstattet af noget andet? Eller er dette et produkt, der vil fungere i mange, mange år? Selvfølgelig vil jeg ikke nævne navne, men... I New York og dets finansielle samfund er de mest fundamentale systemer meget gamle. Dette er forbløffende. Du ser på dem og tænker, hvis bare du kunne gå tilbage i tiden, til 1994, og fortælle udviklerne: "Jeg kom fra fremtiden, fra 2019. Bare udvikle dette system, så længe du har brug for det. Gør det udvideligt, tænk på arkitekturen. Det vil derefter blive forbedret i mere end femogtyve år. Hvis du forsinker udviklingen lidt længere, vil ingen i den store sammenhæng bemærke det!” Når du estimerer ting på lang sigt, skal du overveje, hvor meget det vil koste i alt. Nogle gange er veldesignet arkitektur virkelig det værd, og nogle gange er det ikke. Vi skal se os omkring og spørge os selv: er vi i den rigtige situation til sådan en beslutning?
Så en idé som “Vi er til agile, kunden vil selv fortælle os, hvad han vil have” - den er super naiv. Kunder ved ikke engang, hvad de vil have, og endnu mere, så de ved ikke, hvad de kan få. Nogle mennesker vil begynde at citere historiske eksempler som argumenter, det har jeg allerede set. Men det plejer teknisk avancerede folk ikke at sige. De siger: "Det er 2019, det er de muligheder, vi har, og vi kan fuldstændig ændre den måde, vi ser på disse ting!" I stedet for at efterligne eksisterende løsninger, gøre dem lidt smukkere og mere kæmmede, er du nogle gange nødt til at gå ud og sige: "Lad os fuldstændig genopfinde det, vi prøver at gøre her!"
Og jeg tror ikke, de fleste kunder kan tænke over problemet på den måde. De ser kun, hvad de allerede har, det er alt. Hvorefter de kommer med forespørgsler som "lad os gøre det her lidt enklere," eller hvad de nu plejer at sige. Men vi er ikke tjenere eller servitricer, så vi kan tage imod en bestilling uanset hvor dum den bliver og så bage den i køkkenet. Vi er deres guider. Vi er nødt til at åbne deres øjne og sige: hej, vi har nye muligheder her! Er du klar over, at vi virkelig kan ændre den måde, denne del af din virksomhed udføres på? Et af problemerne med Agile er, at det fjerner bevidstheden om, hvad der er en mulighed, hvad der er et problem, hvad skal vi overhovedet gøre, hvilke tilgængelige teknologier der er bedst egnede til netop denne situation.
Måske er jeg alt for skeptisk her: der sker en masse vidunderlige ting i det agile samfund. Men jeg har et problem med, at i stedet for at definere et projekt, begynder folk at kaste hænderne op. Jeg vil spørge her - hvad laver vi, hvordan skal vi gøre det? Og på en magisk måde viser det sig altid, at klienten burde vide bedre end nogen anden. Men klienten ved kun bedst, når han vælger fra ting, der allerede er bygget af nogen. Hvis jeg vil købe en bil, og jeg kender størrelsen på mit familiebudget, så vil jeg hurtigt udvælge en bil, der passer til min livsstil. Her ved jeg alt bedre end nogen anden! Men vær opmærksom på, at nogen allerede har lavet bilerne. Jeg aner ikke, hvordan man opfinder en ny bil, jeg er ikke ekspert. Når vi laver special- eller specialprodukter, skal kundens stemme tages i betragtning, men dette er ikke længere den eneste stemme.
Oleg: Du nævnte Agile Manifesto. Skal vi på en eller anden måde opdatere eller revidere det under hensyntagen til den moderne forståelse af problemet?
Tim: Jeg ville ikke røre ham. Jeg synes, det er et fantastisk historisk dokument. Jeg mener, han er, hvad han er. Han fylder 19 år, han er gammel, men i sin tid lavede han en revolution. Det, han gjorde godt, var, at han udløste en reaktion, og folk begyndte at hviske om ham. Du arbejdede højst sandsynligt endnu ikke i branchen i 2001, men så arbejdede alle efter processer. Software Engineering Institute, fem niveauer af software fuldstændighedsmodellen (CMMI). Jeg ved ikke, om sådanne legender fra dyb oldtid fortæller dig noget, men så var det et gennembrud. Først troede folk, at hvis processerne var sat rigtigt op, så ville problemerne forsvinde af sig selv. Og så kommer Manifestet og siger: "Nej, nej, nej - vi vil være baseret på mennesker, ikke processer." Vi er mestre i softwareudvikling. Vi forstår, at den ideelle proces er et fatamorgana; det sker ikke. Der er for meget idiosynkrasi i projekter, ideen om en enkelt perfekt proces for alle projekter giver ingen mening. Problemerne er for komplekse til at hævde, at der kun er én løsning på alt (hej, nirvana).
Jeg formoder ikke at se ind i fremtiden, men jeg vil sige, at folk nu er begyndt at tænke mere på projekter. Jeg synes, Agile Manifesto er meget god til at springe ud og sige: "Hey! Du er på et skib, og du fører selv dette skib. Du bliver nødt til at træffe en beslutning - vi vil ikke foreslå en universel opskrift til alle situationer. Du er besætningen på skibet, og hvis du er god nok, kan du finde en vej til dit mål. Der var andre skibe før dig, og der vil være andre skibe efter dig, men alligevel er din rejse på en måde unik." Noget i den stil! Det er en måde at tænke på. For mig er der ikke noget nyt under solen, folk har sejlet før og vil sejle igen, men for dig er dette din hovedrejse, og jeg vil ikke fortælle dig, hvad der præcist vil ske med dig. Du skal have evnerne til koordineret arbejde i et team, og hvis du virkelig har dem, vil alt lykkes, og du når, hvor du ville.
Peopleware: 30 år senere
Oleg: Var Peopleware en revolution såvel som Manifestet?
Tim: Peopleware... Tom og jeg skrev denne bog, men vi troede ikke, det ville ske sådan her. På en eller anden måde resonerede det med mange menneskers ideer. Dette var den første bog, der sagde: softwareudvikling er en meget menneskeintensiv aktivitet. På trods af vores tekniske karakter er vi også et fællesskab af mennesker, der bygger noget stort, endda enormt, meget komplekst. Ingen kan skabe sådanne ting alene, vel? Så ideen om "hold" blev meget vigtig. Og ikke kun fra et ledelsesmæssigt synspunkt, men også for tekniske folk, der gik sammen om at løse virkelig komplekse dybe problemer med en flok ubekendte. For mig personligt har dette været en kæmpe test af intelligens gennem hele min karriere. Og her skal du kunne sige: ja, dette problem er mere, end jeg selv kan klare, men sammen kan vi finde en elegant løsning, som vi kan være stolte af. Og jeg tror, det var denne idé, der gav mest genklang. Tanken om, at vi arbejder en del af tiden på egen hånd, en del af tiden som en del af en gruppe, og ofte træffes beslutningen af gruppen. Gruppeproblemløsning er hurtigt blevet en vigtig del af komplekse projekter.
På trods af at Tim har holdt et stort antal foredrag, er meget få af dem lagt på YouTube. Du kan se rapporten "The Return of Peopleware" fra 2007. Kvaliteten lader selvfølgelig meget tilbage at ønske.
Michael: Har noget ændret sig i de sidste 30 år, siden bogen udkom?
Tim: Du kan se på dette fra mange forskellige vinkler. Sociologisk set... engang, i enklere tider, sad du og dit team på det samme kontor. I kunne være tæt på hver dag, drikke kaffe sammen og diskutere arbejde. Det, der virkelig har ændret sig, er, at teams nu kan fordeles geografisk, i forskellige lande og tidszoner, men stadig arbejder de med det samme problem, og det tilføjer et helt nyt lag af kompleksitet. Det lyder måske gammeldags, men der er intet som ansigt-til-ansigt kommunikation, hvor I er alle sammen, arbejder sammen, og I kan gå hen til en kollega og sige, se, hvad jeg opdagede, hvordan kan I lide det her? Ansigt til ansigt-samtaler giver en hurtig overgang til uformel kommunikation, og jeg tror, at agile entusiaster også burde kunne lide det. Og jeg er også bekymret, for i virkeligheden har verden vist sig at være meget lille, og nu er det hele dækket af distribuerede hold, og det hele er meget komplekst.
Vi bor alle i DevOps
Michael: Selv fra konferencens programkomités synspunkt har vi folk i Californien, i New York, Europa, Rusland... der er ingen i Singapore endnu. Forskellen i geografi er ret stor, og folk begynder at sprede sig endnu mere. Hvis vi taler om udvikling, kan du så fortælle os mere om devops og nedbrydning af barrierer mellem teams? Der er et koncept om, at alle sidder i deres bunkere, og nu falder bunkerne sammen, hvad synes du om denne analogi?
Tim: Det forekommer mig, at i lyset af de seneste teknologiske gennembrud, er devops af stor betydning. Tidligere havde man teams af udviklere og administratorer, de arbejdede, arbejdede, arbejdede, og på et tidspunkt dukkede der en ting op, som man kunne komme til administratorerne og rulle det ud til produktion. Og her begyndte samtalen om bunkeren, for admins er en slags allierede, i hvert fald ikke fjender, men man talte først med dem, da alt var klar til at gå i produktion. Gik du til dem med noget og sagde: se hvilken ansøgning vi har, men kunne du rulle denne ansøgning ud? Og nu har hele konceptet med levering ændret sig til det bedre. Jeg mener, der var en ide om, at man hurtigt kunne gennemskue ændringer. Vi kan opdatere produkter på farten. Jeg smiler altid, når Firefox på min bærbare computer dukker op og siger, hej, vi har opdateret din Firefox i baggrunden, og så snart du har et minut, vil du have noget imod at klikke her, så giver vi dig den seneste udgivelse. Og jeg tænkte: "Åh ja, skat!" Mens jeg sov, arbejdede de på at levere mig en ny udgivelse direkte på min computer. Det her er vidunderligt, utroligt.
Men her er vanskeligheden: du har denne funktion med at opdatere softwaren, men det er meget vanskeligere at integrere mennesker. Det, jeg vil sige til DevOops keynote, er, at vi nu har mange flere spillere, end vi nogensinde har haft. Hvis du bare tænker på alle involverede i kun ét hold... Du tænkte på det som et team, og det er meget mere end blot et team af programmører. Det er testere, projektledere og en masse andre mennesker. Og alle har deres egne syn på verden. Produktledere er helt anderledes end projektledere. Admins har deres egne opgaver. Det bliver et ret svært problem at koordinere alle deltagere, så man bliver ved med at være opmærksom på, hvad der sker og ikke går amok. Det er nødvendigt at adskille gruppens opgaver og opgaver, der gælder for alle. Dette er en meget vanskelig opgave. Til gengæld synes jeg, det hele er meget bedre, end det var for mange år siden. Det er præcis den vej, hvorpå folk vokser og lærer at opføre sig korrekt. Når man laver integration, forstår man, at der ikke skal være nogen underjordisk udvikling, så softwaren i allersidste øjeblik ikke kravler ud som en jack-in-the-box: sådan set, se hvad vi lavede her! Tanken er, at du bliver i stand til at lave integration og udvikling, og til sidst ruller du ud på en pæn og iterativ måde. Alt dette betyder meget for mig. Dette gør det muligt at skabe mere værdi for brugerne af systemet og for din klient.
Michael: Hele ideen med devops er at levere meningsfulde udviklinger så tidligt som muligt. Jeg kan se, at verden er begyndt at accelerere mere og mere. Hvordan tilpasser man sig til sådanne accelerationer? For ti år siden eksisterede dette ikke!
Tim: Selvfølgelig vil alle have mere og mere funktionalitet. Ingen grund til at flytte, bare bunke mere. Nogle gange er du endda nødt til at sænke farten til den næste trinvise opdatering for at bringe noget nyttigt – og det er helt normalt.
Ideen om, at du skal løbe, løbe, løbe er ikke den bedste. Det er usandsynligt, at nogen ønsker at leve deres liv sådan. Jeg vil gerne have, at leveringsrytmen sætter projektets egen rytme. Hvis du bare producerer en strøm af små, relativt meningsløse ting, giver det hele ingen mening. I stedet for tankeløst at forsøge at frigive ting så tidligt som muligt, er det, der er værd at diskutere med de ledende udviklere og produkt- og projektledere, strategi. Giver dette overhovedet mening?
Mønstre og antimønstre
Oleg: Man taler normalt om mønstre og antimønstre, og det er forskellen på projekters liv og død. Og nu bryder devops ind i vores liv. Har den nogle af sine egne mønstre og anti-mønstre, der kan dræbe projektet på stedet?
Tim: Mønstre og anti-mønstre sker hele tiden. Noget at tale om. Nå, der er denne ting, vi kalder "skinnende ting." Folk kan virkelig godt lide ny teknologi. De bliver simpelthen fascineret af glansen af alt, der ser cool og stilfuldt ud, og de holder op med at stille spørgsmål: er det overhovedet nødvendigt? Hvad skal vi opnå? Er denne ting pålidelig, giver det nogen mening? Jeg ser ofte folk, så at sige, på forkant med teknologien. De hypnotiseres af, hvad der sker i verden. Men hvis du ser nærmere på, hvilke nyttige ting de gør, er der ofte simpelthen ikke noget brugbart!
Vi diskuterede netop med vores kammerater, at i år er et jubilæumsår, halvtreds år siden, folk landede på månen. Dette var i 1969. Den teknologi, der hjalp folk med at komme dertil, er ikke engang 1969-teknologi, men snarere 1960 eller 62, fordi NASA kun ønskede at bruge det, der havde gode beviser for pålidelighed. Og så ser man på det og forstår – ja, og de var sande! Nu, nej, nej, men du får problemer med teknologien, simpelthen fordi alt bliver presset for hårdt, solgt fra alle sprækker. Folk råber alle vegne: "Se, sikke noget, det her er den nyeste ting, den smukkeste ting i verden, egnet til absolut alle!" Nå, det er det... normalt viser alt dette sig bare at være et lokkemiddel, og så skal det hele smides væk. Måske er det alt sammen, fordi jeg allerede er en gammel mand og ser på sådanne ting med en stor portion skepsis, når folk løber ud og siger, at de har fundet den eneste, mest korrekte måde at skabe de bedste teknologier på. I dette øjeblik vågner en stemme inde i mig, der siger: "Sikke noget rod!"
Michael: Faktisk, hvor ofte har vi hørt om den næste sølvkugle?
Tim: Præcis, og det er det sædvanlige! For eksempel... det ser ud til, at dette allerede er blevet en joke rundt om i verden, men her taler man ofte om blockchain-teknologi. Og de giver faktisk mening i visse situationer! Når du virkelig har brug for pålidelige beviser for hændelser, at systemet fungerer, og at ingen har bedraget os, når du har sikkerhedsproblemer og alt det der blandet sammen - giver blockchain mening. Men når de siger, at Blockchain nu vil feje over hele verden og feje alt på dens vej? Drøm mere! Dette er en meget dyr og kompleks teknologi. Teknisk kompleks og tidskrævende. Inklusiv rent algoritmisk, hver gang du skal genberegne matematikken, med de mindste ændringer... og det er en god idé - men kun i visse tilfælde. Hele mit liv og min karriere har handlet om dette: interessante ideer i meget specifikke situationer. Det er meget vigtigt at forstå præcis, hvad din situation er.
Michael: Ja, det vigtigste "spørgsmål om livet, universet og alting": er denne teknologi eller tilgang egnet til din situation eller ej?
Tim: Dette spørgsmål kan allerede diskuteres med teknologigruppen. Måske endda få en konsulent ind. Tag et kig på projektet og forstå – vil vi nu gøre noget rigtigt og nyttigt, bedre end før? Måske passer det, måske gør det ikke. Men vigtigst af alt, tag ikke en sådan beslutning som standard, simpelthen fordi nogen udbrød: "Vi har desperat brug for en blockchain! Jeg har lige læst om ham i et blad på flyet!” Helt seriøst? Det er ikke engang sjovt.
Den mytiske "devops-ingeniør"
Oleg: Nu implementerer alle devops. Nogen læser om devops på internettet, og i morgen dukker endnu en ledig stilling op på en rekrutteringsside. "devops ingeniør". Her vil jeg gerne henlede din opmærksomhed: tror du, at dette udtryk "devops engineer" har ret til liv? Der er en opfattelse af, at devops er en kultur, og noget hænger ikke sammen her.
Tim: Så så. Lad dem så straks give en forklaring på dette udtryk. Noget der gør det unikt. Indtil de beviser, at der er en unik kombination af færdigheder bag en ledig stilling som denne, køber jeg den ikke! Jeg mener, ja, vi har en jobtitel, "devops engineer", en interessant titel, ja, hvad så? Jobtitler er generelt en meget interessant ting. Lad os sige "udvikler" - hvad er det overhovedet? Forskellige organisationer betyder helt forskellige ting. I nogle virksomheder skriver programmører af høj kvalitet test, der giver mere mening end test skrevet af specielle professionelle testere i andre virksomheder. Så hvad, er de nu programmører eller testere?
Ja, vi har jobtitler, men hvis du stiller spørgsmål længe nok, viser det sig til sidst, at vi alle er problemløsere. Vi er løsningssøgende, og nogle har nogle tekniske færdigheder og nogle har andre. Hvis du bor i et miljø, hvor DevOps er trængt ind, er du engageret i integrationen af udvikling og administration, og denne aktivitet har et ret vigtigt formål. Men hvis du bliver spurgt, hvad du præcist gør, og hvad du er ansvarlig for, viser det sig, at folk har gjort alle disse ting i umindelige tider. "Jeg er ansvarlig for arkitekturen", "Jeg er ansvarlig for databaserne" og så videre, uanset hvad du ser - alt dette var før "devops".
Når nogen fortæller mig deres jobtitel, lytter jeg ikke rigtig meget. Det er bedre at lade ham fortælle dig, hvad han faktisk er ansvarlig for, dette vil give os mulighed for at forstå problemet meget bedre. Mit foretrukne eksempel er, når en person hævder at være en "projektleder." Hvad? Det betyder ikke noget, jeg ved stadig ikke, hvad du gør. En projektleder kan være en udvikler, leder af et team på fire personer, der skriver kode, laver arbejde, som er blevet en teamleder, som folk selv genkender indbyrdes som en leder. Og også en projektleder kan være en leder, der leder seks hundrede mennesker på et projekt, leder andre ledere, er ansvarlig for at udarbejde tidsplaner og planlægge budgetter, det er alt. Det er to helt forskellige verdener! Men deres jobtitel lyder det samme.
Lad os vende det her lidt anderledes. Hvad er du rigtig god til, har meget erfaring, har du talent for? Hvad vil du tage ansvar for, fordi du tror, du kan klare opgaven? Og her vil nogen straks begynde at benægte: nej, nej, nej, jeg har slet ikke lyst til at beskæftige mig med projektressourcer, det er ikke min sag, jeg er en teknisk fyr og jeg forstår brugervenlighed og brugergrænseflader, det ved jeg ikke ønsker at styre hære af mennesker overhovedet, lad mig hellere gå på arbejde.
Og i øvrigt er jeg en stor fortaler for en tilgang, hvor denne form for adskillelse af kompetencer fungerer fint. Hvor teknikere kan vokse deres karriere så langt, som de vil. Jeg ser dog stadig organisationer, hvor teknikere klager: Jeg bliver nødt til at gå ind i projektledelse, fordi det er den eneste måde i denne virksomhed. Nogle gange fører dette til forfærdelige resultater. De bedste teknikere er slet ikke gode ledere, og de bedste ledere kan ikke håndtere teknologi. Lad os være ærlige om dette.
Jeg ser en stor efterspørgsel efter dette nu. Hvis du er en tekniker, kan din virksomhed hjælpe dig, men uanset hvad har du brug for virkelig at finde din egen karrierevej, fordi teknologien bliver ved med at ændre sig, og du skal genopfinde dig selv sammen med den! På bare tyve år kan teknologier ændre sig mindst fem gange. Teknologi er en mærkelig ting...
"Eksperter i alt"
Michael: Hvordan kan folk klare en sådan hurtig teknologisk forandring? Deres kompleksitet vokser, deres antal vokser, den samlede mængde af kommunikation mellem mennesker vokser også, og det viser sig, at man ikke kan blive "ekspert i alt."
Tim: Højre! Hvis du arbejder med teknologi, ja, så skal du helt sikkert vælge noget specifikt og dykke ned i det. Noget teknologi, som din organisation finder nyttig (og måske faktisk vil være nyttig). Og hvis du ikke længere er interesseret i det - jeg ville aldrig have troet, at jeg ville sige det - ja, måske skulle du flytte til en anden organisation, hvor teknologien er mere interessant eller mere praktisk at studere.
Men generelt, ja, du har ret. Teknologier vokser i alle retninger på én gang; ingen kan sige "Jeg er en ekspert teknolog i alle de teknologier, der findes." På den anden side er der svampefolk, der bogstaveligt talt suger teknologisk viden til sig og er vilde med det. Jeg har set et par af sådanne mennesker, de bogstaveligt talt ånder og lever det, det er nyttigt og interessant at tale med dem. De studerer ikke kun, hvad der sker inde i organisationen, men generelt taler de om det, de er også rigtig seje teknologer, de er meget bevidste og målrettede. De prøver bare at blive på toppen af bølgen, uanset hvad deres hovedopgave er, fordi deres passion er teknologiens bevægelse, fremme af teknologi. Hvis du pludselig møder sådan en, bør du tage til frokost med ham og diskutere forskellige fede ting over frokosten. Jeg tror, at enhver organisation har brug for mindst et par af sådanne mennesker.
Risici og usikkerhed
Michael: Ærede ingeniører, ja. Lad os berøre risikostyring, mens vi har tid. Vi startede dette interview med en diskussion af medicinsk software, hvor fejl kan føre til alvorlige konsekvenser. Så talte vi om Lunar Program, hvor omkostningerne ved en fejl er millioner af dollars, og muligvis flere menneskeliv. Men nu ser jeg den modsatte bevægelse i branchen, folk tænker ikke på risici, forsøger ikke at forudsige dem, observerer dem ikke engang.
Oleg: Bevæg dig hurtigt og knæk tingene!
Michael: Ja, bevæg dig hurtigt, knæk ting, flere og flere ting, indtil du dør af noget. Fra dit synspunkt, hvordan skal den gennemsnitlige udvikler gribe ind i risikostyring nu?
Tim: Lad os her trække en grænse mellem to ting: risici og usikkerhed. Det er forskellige ting. Usikkerhed opstår, når du ikke har nok data på et givet tidspunkt til at nå frem til et endeligt svar. For eksempel, på det meget tidlige stadie af et projekt, hvis nogen spørger dig "hvornår vil du afslutte arbejdet", hvis du er en ret ærlig person, vil du sige: "Jeg aner ikke." Du ved det bare ikke, og det er okay. Du har endnu ikke studeret problemerne og er ikke bekendt med holdet, du kender ikke deres færdigheder og så videre. Dette er usikkerhed.
Der opstår risici, når potentielle problemer allerede kan identificeres. Denne slags ting kan ske, dens sandsynlighed er større end nul, men mindre end hundrede procent, et sted midt imellem. På grund af det kan alt ske, lige fra forsinkelser og unødvendigt arbejde, men endda til et fatalt udfald for projektet. Resultatet, når I siger – gutter, lad os folde vores paraplyer sammen og forlade stranden, vi bliver aldrig færdige, det hele er slut, punktum. Vi antog, at denne ting ville fungere, men den virker slet ikke, det er tid til at stoppe. Det er situationerne.
Ofte er problemer nemmest at løse, når de allerede er dukket op, når problemet opstår lige nu. Men når et problem er lige foran dig, laver du ikke risikostyring – du laver problemløsning, krisestyring. Hvis du er en ledende udvikler eller leder, må du undre dig over, hvad der kunne ske, der ville føre til forsinkelser, spildtid, unødvendige omkostninger eller kollaps af hele projektet? Hvad får os til at stoppe op og starte forfra? Når alle disse ting virker, hvad vil vi så gøre med dem? Der er et simpelt svar, der er gyldigt i de fleste situationer: løb ikke væk fra risici, arbejd på dem. Se, hvordan du kan løse en risikabel situation, reducere den til ingenting, gøre den fra et problem til noget andet. I stedet for at sige: jamen, vi vil løse problemer, efterhånden som de opstår.
Usikkerhed og risiko bør være i højsædet i alt, hvad du beskæftiger dig med. Du kan tage en projektplan, se på visse kritiske risici på forhånd og sige: Vi er nødt til at håndtere det her nu, for hvis noget af dette går galt, vil intet andet have betydning. Du skal ikke bekymre dig om skønheden ved dugen på bordet, hvis det er uklart, om du kan lave aftensmad. Først skal du identificere alle risiciene ved at forberede en lækker middag, håndtere dem og først derefter tænke på alle de andre ting, der ikke udgør en reel trussel.
Igen, hvad gør dit projekt unikt? Lad os se, hvad der kan få vores projekt til at gå af sporet. Hvad kan vi gøre for at minimere sandsynligheden for, at dette sker? Normalt kan du ikke bare neutralisere dem 100% og erklære med god samvittighed: "Det er det, det er ikke længere et problem, risikoen er løst!" For mig er dette et tegn på voksenadfærd. Dette er forskellen mellem et barn og en voksen - børn tror, at de er udødelige, at intet kan gå galt, alt bliver godt! Samtidig ser voksne, hvordan tre-årige børn hopper på legepladsen, følger bevægelserne med øjnene og siger til sig selv: "åh-øh, åh-øh." Jeg står i nærheden og gør mig klar til at fange, når barnet falder.
På den anden side er grunden til, at jeg kan lide denne forretning så meget, fordi den er risikabel. Vi gør ting, og de ting er risikable. De kræver en voksen tilgang. Entusiasme alene vil ikke løse dine problemer!
Voksen ingeniørtænkning
Michael: Eksemplet med børn er godt. Hvis jeg er en almindelig ingeniør, så er jeg glad for at være barn. Men hvordan bevæger man sig mod mere voksentænkning?
Tim: En af de ideer, der fungerer lige godt med enten en nybegynder eller en etableret udvikler, er begrebet kontekst. Hvad vi gør, hvad vi skal opnå. Hvad er egentlig vigtigt i dette projekt? Det er lige meget, hvem du er på dette projekt, om du er praktikant eller chefarkitekt, alle har brug for kontekst. Vi skal få alle til at tænke i større målestok end deres eget stykke arbejde. "Jeg laver mit stykke, og så længe mit stykke virker, er jeg glad." Nej og igen nej. Det er altid værd (uden at være uforskammet!) at minde folk om den kontekst, de arbejder i. Hvad vi alle sammen forsøger at opnå. Idéer til, at du kan være barn, så længe alt er i orden med din del af projektet - lad være med at gøre det. Hvis vi overhovedet krydser målstregen, krydser vi den kun sammen. Du er ikke alene, vi er alle sammen. Hvis alle mennesker i projektet, både gamle og unge, begyndte at tale om, hvad der præcist er vigtigt for projektet, hvorfor virksomheden investerer penge i det, vi alle forsøger at opnå... de fleste af dem vil have det meget bedre, fordi de vil se, hvordan deres arbejde hænger sammen med alle andres arbejde. På den ene side forstår jeg det stykke, som jeg er personligt ansvarlig for. Men for at afslutte arbejdet har vi også brug for alle de andre mennesker. Og hvis du virkelig tror, du er færdig, har vi altid arbejde at gøre i projektet!
Oleg: Relativt set, hvis du arbejder i henhold til Kanban, når du rammer flaskehalsen i nogle test, kan du stoppe med det, du lavede der (for eksempel programmering) og hjælpe testerne.
Tim: Nemlig. Jeg tror, de bedste teknologer, hvis man ser nærmere på dem, er de lidt deres egne ledere. Hvordan kan jeg formulere det...
Oleg: Dit liv er dit projekt, som du styrer.
Tim: Nemlig! Jeg mener, du tager ansvar, du forstår problemet, og du kommer i kontakt med folk, når du ser, at dine beslutninger kan påvirke deres arbejde, sådan noget. Det handler ikke om bare at sidde ved dit skrivebord, udføre dit arbejde og ikke engang indse, hvad der foregår omkring dig. Nej Nej Nej. En af de bedste ting ved Agile er i øvrigt, at de foreslog korte spurter, for på denne måde er tingenes tilstand for alle deltagere tydeligt observerbar, de kan se det hele samlet. Vi taler om hinanden hver dag.
Sådan kommer du ind i risikostyring
Oleg: Er der nogen formel videnstruktur på dette område? Jeg er fx Java-udvikler og vil gerne forstå risikostyring uden at blive en rigtig projektleder af uddannelse. Jeg skal nok læse McConnells "Hvor meget koster et softwareprojekt" først, og hvad så? Hvad er de første skridt?
Tim: Den første er at begynde at kommunikere med folk i projektet. Dette giver en øjeblikkelig forbedring af kulturen for kommunikation med kolleger. Vi er nødt til at starte med at åbne alt ud som standard, i stedet for at skjule det. Sig: det er de ting, der generer mig, det er de ting, der holder mig vågen om natten, jeg vågnede om natten i dag og tænkte: min Gud, jeg skal tænke over det her! Ser andre det samme? Bør vi som gruppe reagere på disse potentielle problemer? Du skal kunne støtte en diskussion om disse emner. Der er ingen på forhånd forberedt formel, som vi arbejder efter. Det handler ikke om at lave hamburgere, det handler om mennesker. "Made a cheeseburger, sell a cheeseburger" er slet ikke vores ting, og det er derfor, jeg elsker dette job så højt. Jeg kan godt lide, når alt, hvad ledere plejede at gøre, nu bliver holdets ejendom.
Oleg: Du har i bøger og interviews talt om, hvordan folk bekymrer sig mere om lykke end om tal på en graf. På den anden side, når du fortæller teamet: vi flytter til devops, og nu skal programmøren konstant kommunikere, det kan være langt uden for hans komfortzone. Og i dette øjeblik kan han, lad os sige, være dybt ulykkelig. Hvad skal man gøre i denne situation?
Tim: Jeg er ikke sikker på præcis, hvad jeg skal gøre. Hvis en udvikler er for isoleret, kan de ikke se, hvorfor arbejdet bliver udført i første omgang, de ser bare på deres del af arbejdet, og de skal ind i det, jeg kalder "kontekst". Han skal finde ud af, hvordan alting hænger sammen. Og selvfølgelig mener jeg ikke formelle præsentationer eller lignende. Jeg taler om, at du skal kommunikere med kollegerne om arbejdet som helhed, og ikke kun om den del af det, du har ansvaret for. Det er her, I kan begynde at diskutere ideer, fælles aftaler for at få jeres arbejde til at passe godt sammen, og hvordan I sammen tackler et fælles problem.
For at hjælpe dem med at tilpasse sig ønsker de ofte at sende teknikere til træning, og de diskuterer træning. En af mine venner kan godt lide at sige, at træning er for hunde. Der er træning for mennesker. En af de bedste ting ved at lære som udvikler er at interagere med dine jævnaldrende. Hvis nogen er rigtig god til noget, bør du se dem arbejde eller tale med dem om deres arbejde eller noget. Nogle konventionelle Kent Beck talte konstant om ekstrem programmering. Det er sjovt, fordi XP er så simpel en idé, men det giver så mange problemer. For nogle er XP som at blive tvunget til at klæde sig nøgen foran venner. De vil se, hvad jeg laver! De er mine kolleger, de vil ikke kun se, men også forstå! Forfærdeligt! Nogle mennesker begynder at blive alvorligt nervøse. Men når du indser, at dette er den ultimative måde at lære på, ændrer alt sig. Du arbejder tæt sammen med mennesker, og nogle mennesker forstår emnet meget bedre end dig.
Michael: Men alt dette tvinger dig til at træde ud af din komfortzone. Som ingeniør skal du ud af din komfortzone og kommunikere. Som problemløser skal du hele tiden sætte dig selv i en svag position og tænke over, hvad der kan gå galt. Denne type arbejde er i sagens natur designet til at være til gene. Du sætter dig bevidst i stressede situationer. Normalt løber folk væk fra dem, folk kan lide at være glade børn.
Tim: Hvad der kan gøres, kan du komme ud og åbenlyst sige: ”Alt er okay, jeg kan klare det! Jeg er ikke den eneste, der føler sig utilpas. Lad os diskutere forskellige ubehagelige ting, alle sammen som et team!" Det er vores fælles problemer, vi skal håndtere dem, ved du? Jeg tror, at idiosynkratiske geniale udviklere er som mammutter, de forsvandt. Og deres betydning er meget begrænset. Hvis du ikke kan kommunikere, kan du ikke deltage godt. Derfor skal du bare tale. Vær ærlig og åben. Jeg er meget ked af, at dette er ubehageligt for nogen. Kan du forestille dig, at der for mange år siden var en undersøgelse, ifølge hvilken hovedfrygten i USA ikke er døden, men gæt hvad? Frygt for at tale offentligt! Det betyder, at der et eller andet sted er mennesker, der hellere vil dø end at sige et kompliment højt. Og jeg tror, det er nok for dig at have nogle basale færdigheder, alt efter hvad du laver. Talefærdigheder, skrivefærdigheder - men kun så meget, som der virkelig er brug for i dit arbejde. Hvis du arbejder som analytiker, men ikke kan læse, skrive eller tale, så har du desværre ikke noget at lave i mine projekter!
Prisen for kommunikation
Oleg: Er det ikke dyrere at ansætte sådanne udgående medarbejdere af forskellige årsager? De chatter jo konstant i stedet for at arbejde!
Tim: Jeg mente kernen af holdet, og ikke kun alle. Hvis du har nogen, der er rigtig sej til at tune databaser, elsker at tune databaser og vil fortsætte med at tune dine databaser resten af sit liv, og det er det, cool, fortsæt. Men jeg taler om folk, der gerne vil bo i selve projektet. Kernen i teamet, rettet mod at udvikle projektet. Disse mennesker har virkelig brug for konstant at kommunikere med hinanden. Og især i starten af projektet, når man diskuterer risici, måder at nå globale mål og lignende.
Michael: Det gælder for alle, der er involveret i projektet, uanset specialisering, kompetencer eller måde at arbejde på. I er alle interesserede i projektets succes.
Tim: Ja, du føler, at du er tilstrækkeligt fordybet i projektet, at din opgave er at hjælpe projektet til at gå i opfyldelse. Uanset om du er programmør, analytiker, interface designer, hvem som helst. Det er grunden til, at jeg kommer på arbejde hver morgen, og det er det, vi gør. Vi er ansvarlige for alle disse mennesker, uanset deres færdigheder. Dette er en gruppe mennesker, der har voksne samtaler.
Oleg: Faktisk, når jeg taler om snakkesalige medarbejdere, forsøgte jeg at simulere indvendinger fra mennesker, især ledere, der bliver bedt om at skifte til devops, mod denne helt nye vision af verden. Og du som konsulenter burde være meget bedre opmærksom på disse indvendinger end jeg som udvikler! Del, hvad der bekymrer ledere mest?
Tim: Ledere? Hm. Oftest er ledere pressede af problemer, stillet over for behovet for akut at frigive noget og lave en levering og lignende. De ser, hvordan vi konstant diskuterer og skændes om noget, og de ser det sådan her: samtaler, samtaler, samtaler... Hvilke andre samtaler? Tilbage til arbjedet! Fordi at tale føles ikke som arbejde for dem. Du skriver ikke kode, tester ikke software, lader ikke til at gøre noget - hvorfor ikke sende dig til at gøre noget? Når alt kommer til alt, er levering allerede om en måned!
Michael: Skriv noget kode!
Tim: Det forekommer mig, at de ikke er bekymrede for arbejdet, men over den manglende synlighed af fremskridt. For at få det til at virke som om, vi nærmer os succes, skal de se os trykke på knapper på tastaturet. Hele dagen fra morgen til aften. Dette er problem nummer et.
Oleg: Misha, du tænker på noget.
Michael: Undskyld, jeg fortabte mig i tanker og fangede et flashback. Alt dette mindede mig om et interessant stævne, der fandt sted i går... Der var for mange stævner i går... Og det lyder alt sammen meget bekendt!
Livet uden løn
Tim: Forresten er det slet ikke nødvendigt at organisere "stævner" til kommunikation. Jeg mener, de mest nyttige diskussioner mellem udviklere sker, når de bare taler med hinanden. Man går ind om morgenen med en kop kaffe, og der er fem personer samlet og rasende diskuterer noget teknisk. For mig, hvis jeg er leder af dette projekt, er det bedre bare at smile og gå et sted hen om min virksomhed, lade dem diskutere det. De er allerede involveret så meget som muligt. Dette er et godt tegn.
Oleg: I din bog har du i øvrigt en masse noter om, hvad der er godt og hvad der er dårligt. Bruger du selv nogle af dem? Relativt set har du nu en virksomhed, og en der er struktureret på en meget uortodoks måde...
Tim: Uortodoks, men denne enhed passer os perfekt. Vi har kendt hinanden længe. Vi stoler på hinanden, vi stolede meget på hinanden, før vi blev partnere. Og for eksempel har vi slet ingen lønninger. Vi arbejder bare, og hvis jeg for eksempel tjente penge fra mine kunder, så gik alle pengene til mig. Herefter betaler vi kontingent til organisationen, og det er nok til at støtte virksomheden selv. Derudover er vi alle specialiserede i forskellige ting. Jeg arbejder for eksempel med revisorer, udfylder selvangivelser, laver alle mulige administrative ting for virksomheden, og ingen betaler mig for det. James og Tom arbejder på vores hjemmeside, og ingen betaler dem heller. Så længe du betaler dit kontingent, vil ingen finde på at fortælle dig, hvad du skal gøre. For eksempel arbejder Tom nu meget mindre, end han gjorde engang. Nu har han andre interesser; nogle ting gør han ikke for lauget. Men så længe han betaler sit kontingent, vil ingen komme hen til ham og sige: "Hej, Tom, gå på arbejde!" Det er meget nemt at have med kolleger at gøre, når der ikke er penge imellem jer. Og nu er vores forhold en af de grundlæggende ideer i forhold til forskellige specialer. Det virker, og det fungerer meget godt.
Bedste råd
Michael: For at komme tilbage til "bedste råd", er der noget, du fortæller dine kunder igen og igen? Der er en idé om 80/20, og nogle råd gentages sikkert oftere.
Tim: Jeg troede engang, at hvis man skrev en bog som Waltzing with Bears, ville det ændre historiens gang, og folk ville stoppe, men... Nå, se, virksomheder lader ofte som om, at alt er godt med dem. Så snart der sker noget slemt, er det et chok og en overraskelse for dem. "Se, vi testede systemet, og det består ingen systemtest, og det her er endnu tre måneders uplanlagt arbejde, hvordan kunne det ske? Der kan man bare se? Hvad kunne gå galt? Seriøst, tror du på det?
Jeg prøver at forklare, at du ikke skal blive for vred over den nuværende situation. Vi er nødt til at tale om det, virkelig forstå, hvad der kunne være gået galt, og hvordan man forhindrer sådanne ting i at ske i fremtiden. Hvis et problem dukker op, hvordan vil vi bekæmpe det, hvordan vil vi begrænse det?
For mig ser det hele skræmmende ud. Folk håndterer komplekse, irriterende problemer og fortsætter med at lade som om, at hvis de bare krydser fingre og håber på det bedste, vil det "bedste" faktisk ske. Nej, sådan fungerer det ikke.
Øv risikostyring!
Michael: Hvor mange organisationer beskæftiger sig efter din mening med risikostyring?
Tim: Det, der irriterer mig, er, at folk simpelthen skriver risici ned, ser på den resulterende liste og går på arbejde. Faktisk er det risikostyring at identificere risici for dem. Men for mig lyder det som en grund til at spørge: Okay, der er en liste, hvad vil du præcist ændre? Du skal ændre dine standardsekvenser af handlinger under hensyntagen til disse risici. Hvis der er den sværeste del af arbejdet, skal du tackle det og først derefter gå videre til noget enklere. I de første spurter skal du begynde at løse komplekse problemer. Dette ligner allerede risikostyring. Men normalt kan folk ikke sige, hvad de ændrede efter at have udarbejdet en liste over risici.
Michael: Og alligevel, hvor mange af disse virksomheder er involveret i risikostyring, fem procent?
Tim: Desværre hader jeg at sige dette, men dette er en meget ubetydelig del. Men mere end fem, for der er virkelig store projekter, og de kan simpelthen ikke eksistere, hvis de ikke laver i det mindste noget. Lad os bare sige, at jeg vil blive meget overrasket, hvis det er mindst 25%. Små projekter svarer normalt på sådanne spørgsmål på denne måde: Hvis problemet påvirker os, så løser vi det. Så kommer de med succes i problemer og engagerer sig i problemhåndtering og krisehåndtering. Når du forsøger at løse et problem, og problemet ikke er løst, velkommen til krisehåndtering.
Ja, jeg hører ofte, "vi løser problemer, efterhånden som de opstår." Sikkert vil vi? Vil vi virkelig bestemme?
Oleg: Du kan gøre det naivt og blot skrive vigtige invarianter ind i projektcharteret, og hvis invarianterne går i stykker, skal du bare genstarte projektet. Det viser sig meget piembucky.
Michael: Ja, det skete for mig, at når risici blev udløst, blev projektet simpelthen omdefineret. Dejligt, bingo, problem løst, bare rolig!
Tim: Lad os trykke på nulstillingsknappen! Nej, sådan fungerer det ikke.
Keynote ved DevOops 2019
Michael: Vi kommer til det sidste spørgsmål i dette interview. Du kommer til det næste DevOops med en keynote, kunne du løfte tavshedspligten for, hvad du vil fortælle?
Tim: Lige nu skriver seks af dem en bog om arbejdskultur, organisationers uudtalte regler. Kultur er bestemt af organisationens kerneværdier. Det lægger folk normalt ikke mærke til, men efter at have arbejdet med rådgivning i mange år, er vi vant til at lægge mærke til det. Du kommer ind i en virksomhed, og bogstaveligt talt inden for et par minutter begynder du at mærke, hvad der sker. Vi kalder dette "smag". Nogle gange er denne duft virkelig god, og nogle gange er den, ja, ups. Tingene er meget forskellige for forskellige organisationer.
Michael: Jeg har også arbejdet med rådgivning i årevis og forstår godt, hvad du taler om.
Tim: Faktisk er en af de ting, der er værd at tale om ved keynoten, at ikke alt er bestemt af virksomheden. Du og dit team har som fællesskab din egen teamkultur. Dette kan være hele virksomheden eller en separat afdeling, et separat team. Men før du sagde, her er hvad vi tror på, her er hvad der er vigtigt... Du kan ikke ændre en kultur før værdierne og overbevisningerne bag specifikke handlinger er forstået. Adfærd er let at observere, men det er svært at søge efter overbevisninger. DevOps er bare et godt eksempel på, hvordan tingene bliver mere og mere komplekse. Interaktioner bliver kun mere komplekse, de bliver slet ikke renere eller klarere, så du bør tænke over, hvad du tror på, og hvad alle omkring dig tier om.
Hvis du vil opnå hurtige resultater, er her et godt emne til dig: har du set virksomheder, hvor ingen siger "Jeg ved det ikke"? Der er steder, hvor du bogstaveligt talt torturerer en person, indtil han indrømmer, at han ikke ved noget. Alle ved alt, alle er utrolige lærde. Du henvender dig til enhver person, og han skal øjeblikkeligt besvare spørgsmålet. I stedet for at sige "Jeg ved det ikke." Hurra, de hyrede en flok lærde! Og i nogle kulturer er det generelt meget farligt at sige "jeg ved det ikke"; det kan opfattes som et tegn på svaghed. Der er også organisationer, hvor alle tværtimod kan sige "jeg ved det ikke." Der er det helt lovligt, og hvis nogen begynder at sludre som svar på et spørgsmål, er det helt normalt at svare: "Du ved ikke, hvad du taler om, vel?" og gør det hele til en joke.
Ideelt set vil du gerne have et job, hvor du kunne være glad hele tiden. Det bliver ikke nemt, ikke hver dag er solrig og behagelig, nogle gange skal du arbejde hårdt, men når du begynder at gøre status, vil det vise sig: wow, det er et virkelig vidunderligt sted, jeg har det godt med at arbejde her, både følelsesmæssigt og intellektuelt. Og der er virksomheder, hvor du går som konsulent og med det samme indser, at du ikke kunne holde det ud i tre måneder og ville stikke af med rædsel. Det er det, jeg vil tale om i betænkningen.
Tim Lister ankommer med en keynote til DevOops 2019-konferencen, som finder sted den 29.-30. oktober 2019 i St. Du kan købe billetter . Vi venter på dig hos DevOops!
Kilde: www.habr.com