Tim Lister - medforfatter av bøker
- "Menneskelig faktor. Vellykkede prosjekter og team" (den originale boken heter "Peopleware")
- "Waltzing with the Bears: Managing Risk in Software Projects"
- «Adrenalin-gal og zombifisert av mønstre. Atferdsmønstre for prosjektteam"
Alle disse bøkene er klassikere innen sitt felt og er skrevet sammen med kolleger i . I Russland er kollegene hans mest kjente - и , som også skrev mange kjente verk.
Tim har 40 års erfaring innen programvareutvikling i 1975 (ingen av de som skrev denne habraposten ble født i år), Tim var allerede konserndirektør for Yourdon Inc. Han bruker nå tiden sin på rådgivning, undervisning og skriving, med sporadiske besøk til konferanser rundt om i verden.
Vi gjorde et intervju med Tim Lister spesielt for Habr. Han skal åpne DevOops 2019-konferansen, og vi har mange spørsmål, om bøker og mer. Intervjuet er utført av Mikhail Druzhinin og Oleg Chirukhin fra konferansens programkomité.
Michael: Kan du si noen ord om hva du gjør nå?
Tim: Jeg er leder for Atlantic Systems Guild. Vi er seks i lauget, vi kaller oss rektorer. Tre i USA og tre i Europa - det er derfor lauget heter Atlantic. Vi har vært sammen i så mange år at du bare ikke kan telle dem. Vi har alle våre spesialiteter. Jeg har jobbet med kunder det siste tiåret eller mer. Mine prosjekter inkluderer ikke bare ledelse, men også kravsetting, prosjektplanlegging og evaluering. Det ser ut til at prosjekter som starter dårlig vanligvis ender dårlig. Derfor er det verdt å sørge for at alle aktiviteter virkelig er gjennomtenkt og koordinert, at ideene til skaperne er kombinert. Det er verdt å tenke på hva du gjør og hvorfor. Hvilke strategier skal brukes for å fullføre prosjektet.
Jeg har gitt råd til klienter på en rekke måter i mange år. Et interessant eksempel er et selskap som lager roboter for kne- og hofteoperasjoner. Kirurgen opererer ikke helt selvstendig, men bruker en robot. Sikkerhet her, ærlig talt, er viktig. Men når du prøver å diskutere krav med folk som er fokusert på å løse problemer... Det vil høres rart ut, men i USA er det (Federal Drug Administration), som lisensierer produkter som disse robotene. Før du selger noe og bruker det på levende mennesker, må du få en lisens. En av betingelsene er å vise dine krav, hva testene er, hvordan du testet dem, hva testresultatene er. Hvis du endrer kravene, må du gå gjennom hele denne enorme testprosessen igjen og igjen. Våre kunder klarte å inkludere visuell design av applikasjoner i sine krav. De hadde skjermbilder direkte som en del av kravene. Vi må trekke dem ut og forklare at for det meste vet ikke alle disse programmene noe om knær og hofter, alle disse tingene med kamera osv. Vi må omskrive kravdokumentene slik at de aldri endres, med mindre noen virkelig viktige underliggende forhold endres. Hvis visuell design ikke er i kravene, vil oppdatering av produktet gå mye raskere. Vår jobb er å finne de elementene som omhandler operasjoner i kne, hofter, rygg, trekke dem ut i separate dokumenter og si at dette vil være de grunnleggende kravene. La oss lage en isolert gruppe krav om kneoperasjoner. Dette vil tillate oss å bygge et mer stabilt sett med krav. Vi skal snakke om hele produktlinjen, og ikke om spesifikke roboter.
Det ble gjort mye arbeid, men de kom likevel til steder hvor de tidligere brukte uker og måneder med gjentatte tester uten mening eller behov, fordi kravene deres beskrevet på papir ikke stemte overens med de reelle kravene som systemene ble bygget for. FDA fortalte dem hver gang: kravene dine har endret seg, nå må du sjekke alt fra bunnen av. Fullstendig nykontroll av hele produktet tok livet av bedriften.
Så, det er så fantastiske oppgaver når du befinner deg helt i begynnelsen av noe interessant, og de aller første handlingene setter de videre spillereglene. Hvis du sørger for at denne tidlige aktiviteten begynner å fungere bra både fra et ledelsesmessig og et teknisk synspunkt, er det en sjanse for at du ender opp med et flott prosjekt. Men hvis denne delen har gått av sporet og gått et sted galt, hvis du ikke finner de grunnleggende avtalene... nei, det er ikke det at prosjektet ditt nødvendigvis vil mislykkes. Men du vil ikke lenger kunne si: "Vi gjorde det bra, vi gjorde alt veldig effektivt." Dette er de tingene jeg gjør når jeg kommuniserer med kunder.
Michael: Det vil si at du setter i gang prosjekter, gjør en slags kickoff og sjekker at skinnene går i riktig retning?
Tim: Vi har også ideer om hvordan vi skal sette sammen alle brikkene i puslespillet: hvilke ferdigheter vi trenger, når akkurat de trengs, hvordan kjernen i teamet ser ut og andre slike grunnleggende ting. Trenger vi heltidsansatte eller kan vi ansette noen på deltid? Planlegging, ledelse. Spørsmål som: Hva er viktigst for akkurat dette prosjektet? Hvordan oppnå dette? Hva vet vi om dette produktet eller prosjektet, hva er risikoen og hvor de ukjente ligger, hvordan skal vi håndtere alt dette? Selvfølgelig, i dette øyeblikket begynner noen å rope "Hva med smidig?!" Ok, dere er fleksible, men hva så? Hvordan ser egentlig prosjektet ut, hvordan skal du ta det ut på en måte som passer prosjektet? Du kan ikke bare si at "vår tilnærming strekker seg til hva som helst, vi er et Scrum-team!" Dette er tull og tull. Hvor skal du gå videre, hvorfor skal det fungere, hvor er poenget? Jeg lærer kundene mine å tenke på alle disse spørsmålene.
19 år med smidig
Michael: I Agile prøver folk ofte å ikke definere noe på forhånd, men å ta avgjørelser så sent som mulig og si: vi er for store, jeg vil ikke tenke på den generelle arkitekturen. Jeg vil ikke tenke på en haug med andre ting i stedet, jeg skal levere noe som fungerer til kunden akkurat nå.
Tim: Jeg tror at smidige metoder, starter med i 2001, åpnet bransjens øyne. Men på den annen side er ingenting perfekt. Jeg er helt for iterativ utvikling. Iterasjon gir mye mening i de fleste prosjekter. Men spørsmålet du må tenke på er: når produktet er ute og i bruk, hvor lenge varer det? Er dette et produkt som varer seks måneder før det erstattes av noe annet? Eller er dette et produkt som vil fungere i mange, mange år? Jeg vil selvfølgelig ikke nevne navn, men... I New York og finansmiljøet er de mest grunnleggende systemene svært gamle. Dette er utrolig. Du ser på dem og tenker, hvis du bare kunne gå tilbake i tid, til 1994, og fortelle utviklerne: «Jeg kom fra fremtiden, fra 2019. Bare utvikle dette systemet så lenge du trenger. Gjør det utvidbart, tenk på arkitekturen. Den vil da bli forbedret i mer enn tjuefem år. Hvis du utsetter utviklingen litt lenger, er det ingen som vil legge merke til det!» Når du estimerer ting på lang sikt, må du vurdere hvor mye det vil koste totalt. Noen ganger er veldesignet arkitektur virkelig verdt det, og noen ganger er det ikke det. Vi må se oss rundt og spørre oss selv: er vi i riktig situasjon for en slik beslutning?
Så en idé som "Vi er for smidig, kunden vil selv fortelle oss hva han vil ha" - det er supernaivt. Kunder vet ikke engang hva de vil ha, og enda mer så de ikke vet hva de kan få. Noen vil begynne å trekke frem historiske eksempler som argumenter, dette har jeg allerede sett. Men teknisk avanserte folk pleier ikke å si det. De sier: "Det er 2019, dette er mulighetene vi har, og vi kan fullstendig endre måten vi ser på disse tingene!" I stedet for å etterligne eksisterende løsninger, gjøre dem litt penere og mer kjemmet, må du noen ganger gå ut og si: «La oss gjenoppfinne det vi prøver å gjøre her!»
Og jeg tror ikke de fleste kunder kan tenke på problemet på den måten. De ser bare det de allerede har, det er alt. Deretter kommer de med forespørsler som "la oss gjøre dette litt enklere," eller hva de vanligvis sier. Men vi er ikke servitører eller servitriser, så vi kan ta en bestilling uansett hvor dum den blir og så bake den på kjøkkenet. Vi er deres guider. Vi må åpne øynene deres og si: hei, vi har nye muligheter her! Er du klar over at vi virkelig kan endre måten denne delen av virksomheten din gjøres på? Et av problemene med Agile er at det fjerner bevisstheten om hva som er en mulighet, hva som er et problem, hva må vi til og med gjøre, hvilke tilgjengelige teknologier som er best egnet for akkurat denne situasjonen.
Kanskje jeg er altfor skeptisk her: det er mange fantastiske ting som skjer i det smidige samfunnet. Men jeg har et problem med at i stedet for å definere et prosjekt, begynner folk å kaste opp hendene. Jeg vil spørre her - hva gjør vi, hvordan skal vi gjøre det? Og på en magisk måte viser det seg alltid at klienten burde vite bedre enn noen. Men klienten vet best når han velger fra ting som allerede er bygget av noen. Hvis jeg ønsker å kjøpe en bil og jeg vet størrelsen på familiebudsjettet mitt, vil jeg raskt velge en bil som passer min livsstil. Her vet jeg alt bedre enn noen andre! Men vær oppmerksom på at noen allerede har laget bilene. Jeg aner ikke hvordan jeg skal finne opp en ny bil, jeg er ingen ekspert. Når vi lager tilpassede eller spesialprodukter, må kundens stemme tas i betraktning, men dette er ikke lenger den eneste stemmen.
Oleg: Du nevnte Agile Manifesto. Trenger vi på en eller annen måte å oppdatere eller revidere det med tanke på den moderne forståelsen av problemet?
Tim: Jeg ville ikke rørt ham. Jeg synes det er et flott historisk dokument. Jeg mener, han er det han er. Han fyller 19 år, han er gammel, men i sin tid gjorde han en revolusjon. Det han gjorde bra var at han utløste en reaksjon og folk begynte å hviske om ham. Du jobbet mest sannsynlig ikke i bransjen ennå i 2001, men da jobbet alle etter prosesser. Software Engineering Institute, fem nivåer av programvarefullstendighetsmodellen (CMMI). Jeg vet ikke om slike legender fra den dype antikken forteller deg noe, men så var det et gjennombrudd. Først trodde folk at hvis prosessene ble satt opp riktig, så ville problemene forsvinne av seg selv. Og så kommer manifestet og sier: "Nei, nei, nei - vi vil være basert på mennesker, ikke prosesser." Vi er mestere i programvareutvikling. Vi forstår at den ideelle prosessen er en luftspeiling, den skjer ikke. Det er for mye idiosynkrasi i prosjekter, ideen om en enkelt perfekt prosess for alle prosjekter gir ingen mening. Problemene er for komplekse til å hevde at det bare finnes én løsning på alt (hei, nirvana).
Jeg antar ikke å se inn i fremtiden, men jeg vil si at folk nå har begynt å tenke mer på prosjekter. Jeg synes Agile Manifesto er veldig flinke til å hoppe ut og si: «Hei! Du er på et skip, og du selv kjører dette skipet. Du må ta en avgjørelse - vi vil ikke foreslå en universell oppskrift for alle situasjoner. Du er mannskapet på skipet, og er du god nok kan du finne en vei til målet. Det var andre skip før deg, og det vil være andre skip etter deg, men likevel, på en måte, er reisen din unik.» Noe sånt! Det er en måte å tenke på. For meg er det ikke noe nytt under solen, folk har seilt før og vil seile igjen, men for deg er dette hovedreisen din, og jeg vil ikke fortelle deg hva som vil skje med deg. Du må ha ferdighetene til koordinert arbeid i et team, og hvis du virkelig har det, vil alt ordne seg og du kommer dit du ville.
Peopleware: 30 år senere
Oleg: Var Peopleware en revolusjon så vel som Manifestet?
Tim: Peopleware... Tom og jeg skrev denne boken, men vi trodde ikke det skulle skje slik. På en eller annen måte ga det gjenklang med mange folks ideer. Dette var den første boken som sa: programvareutvikling er en veldig menneskeintensiv aktivitet. Til tross for vår tekniske natur, er vi også et fellesskap av mennesker som bygger noe stort, til og med enormt, veldig komplekst. Ingen kan lage slike ting alene, ikke sant? Så ideen om "team" ble veldig viktig. Og ikke bare fra et ledelsessynspunkt, men også for tekniske folk som kom sammen for å løse virkelig komplekse dype problemer med en haug med ukjente. For meg personlig har dette vært en enorm test av intelligens gjennom hele karrieren min. Og her må du kunne si: ja, dette problemet er mer enn jeg kan håndtere på egen hånd, men sammen kan vi finne en elegant løsning som vi kan være stolte av. Og jeg tror det var denne ideen som ga mest gjenklang. Tanken om at vi jobber en del av tiden på egenhånd, en del av tiden som en del av en gruppe, og ofte er avgjørelsen tatt av gruppen. Gruppeproblemløsning har raskt blitt en viktig del av komplekse prosjekter.
Til tross for at Tim har holdt et stort antall foredrag, er svært få av dem lagt ut på YouTube. Du kan se på rapporten «The Return of Peopleware» fra 2007. Kvaliteten overlater selvfølgelig mye å være ønsket.
Michael: Har noe endret seg de siste 30 årene siden boken ble utgitt?
Tim: Du kan se på dette fra mange forskjellige vinkler. Sosiologisk sett... en gang, i enklere tider, satt du og teamet ditt på samme kontor. Dere kan være nær hver dag, drikke kaffe sammen og diskutere jobb. Det som virkelig har endret seg er at team nå kan distribueres geografisk, i forskjellige land og tidssoner, men fortsatt jobber de med det samme problemet, og dette legger til et helt nytt lag av kompleksitet. Dette høres kanskje gammeldags ut, men det er ingenting som ansikt-til-ansikt kommunikasjon der dere er alle sammen, jobber sammen, og dere kan gå bort til en kollega og si, se hva jeg oppdaget, hvordan liker dere dette? Ansikt-til-ansikt-samtaler gir en rask måte å gå over til uformell kommunikasjon, og jeg tror smidige entusiaster bør like det også. Og jeg er også bekymret fordi verden i virkeligheten har vist seg å være veldig liten, og nå er det hele dekket med distribuerte team, og det hele er veldig komplekst.
Vi bor alle i DevOps
Michael: Selv fra konferansens programkomités synspunkt, har vi folk i California, i New York, Europa, Russland... det er ingen i Singapore ennå. Forskjellen i geografi er ganske stor, og folk begynner å spre seg enda mer. Hvis vi snakker om utvikling, kan du fortelle oss mer om devops og å bryte ned barrierer mellom team? Det er et konsept om at alle sitter i sine bunkere, og nå kollapser bunkerne, hva synes du om denne analogien?
Tim: Det virker for meg som i lys av de siste teknologiske gjennombruddene, er devops av stor betydning. Tidligere hadde du team av utviklere og administratorer, de jobbet, jobbet, jobbet, og på et tidspunkt dukket det opp en ting som du kunne komme til administratorene og rulle den ut for produksjon. Og her begynte samtalen om bunkeren, fordi admins er slags allierte, ikke fiender, i det minste, men du snakket med dem først når alt var klart for å gå til produksjon. Har du gått til dem med noe og sagt: se hvilken applikasjon vi har, men kunne du rulle ut denne applikasjonen? Og nå har hele konseptet med levering endret seg til det bedre. Jeg mener, det var denne ideen om at du kunne presse gjennom endringer raskt. Vi kan oppdatere produkter på farten. Jeg smiler alltid når Firefox på den bærbare datamaskinen min dukker opp og sier, hei, vi har oppdatert Firefox i bakgrunnen, og så snart du har et minutt, vil du gjerne klikke her, så gir vi deg den nyeste utgivelsen. Og jeg sa: "Å ja, baby!" Mens jeg sov, jobbet de med å levere meg en ny utgivelse rett på datamaskinen min. Dette er fantastisk, utrolig.
Men her er vanskeligheten: du har denne funksjonen med å oppdatere programvaren, men det er mye vanskeligere å integrere folk. Det jeg vil gi uttrykk for på DevOops keynote er at vi nå har mange flere spillere enn vi noen gang har hatt. Hvis du bare tenker på alle involverte i bare ett lag... Du tenkte på det som et team, og det er mye mer enn bare et team av programmerere. Dette er testere, prosjektledere og en haug med andre mennesker. Og alle har sitt eget syn på verden. Produktledere er helt forskjellige fra prosjektledere. Administratorer har sine egne oppgaver. Det blir et ganske vanskelig problem å koordinere alle deltakerne for å fortsette å være klar over hva som skjer og ikke bli gal. Det er nødvendig å skille gruppens oppgaver og oppgaver som gjelder alle. Dette er en veldig vanskelig oppgave. På den annen side synes jeg det hele er mye bedre enn det var for mange år siden. Det er akkurat denne veien folk vokser og lærer å oppføre seg riktig. Når du gjør integrasjon, forstår du at det ikke skal være noen underjordisk utvikling, slik at programvaren i siste øyeblikk ikke kryper ut som en jack-in-the-box: liksom, se hva vi gjorde her! Tanken er at du skal kunne drive med integrering og utvikling, og på slutten skal du rulle ut på en ryddig og iterativ måte. Alt dette betyr mye for meg. Dette gjør det mulig å skape mer verdi for brukerne av systemet og for din klient.
Michael: Hele ideen med devops er å levere meningsfull utvikling så tidlig som mulig. Jeg ser at verden har begynt å få fart mer og mer. Hvordan tilpasse seg slike akselerasjoner? For ti år siden eksisterte ikke dette!
Tim: Selvfølgelig vil alle ha mer og mer funksjonalitet. Du trenger ikke å flytte, bare haug på mer. Noen ganger må du til og med bremse for neste trinnvise oppdatering for å bringe noe nyttig – og det er helt normalt.
Ideen om at du trenger å løpe, løpe, løpe er ikke den beste. Det er usannsynlig at noen ønsker å leve livet sitt slik. Jeg vil at leveringsrytmen skal sette prosjektets egen rytme. Hvis du bare produserer en strøm av små, relativt meningsløse ting, gir det hele ingen mening. I stedet for tankeløst å prøve å frigjøre ting så tidlig som mulig, er det strategi som er verdt å diskutere med ledende utviklere og produkt- og prosjektledere. Gir dette i det hele tatt mening?
Mønstre og antimønstre
Oleg: Du snakker vanligvis om mønstre og antimønstre, og dette er forskjellen mellom liv og død til prosjekter. Og nå bryter devops inn i livene våre. Har den noen av sine egne mønstre og anti-mønstre som kan drepe prosjektet på stedet?
Tim: Mønstre og anti-mønstre skjer hele tiden. Noe å snakke om. Vel, det er denne tingen vi kaller "skinnende ting". Folk liker virkelig ny teknologi. De blir rett og slett fascinert av glansen til alt som ser kult og stilig ut, og de slutter å stille spørsmål: er det i det hele tatt nødvendig? Hva skal vi oppnå? Er dette pålitelig, gir det noen mening? Jeg ser ofte folk, så å si, i forkant av teknologien. De hypnotiseres av det som skjer i verden. Men hvis du ser nærmere på hvilke nyttige ting de gjør, er det ofte rett og slett ikke noe nyttig!
Vi diskuterte nettopp med kameratene våre at dette året er et jubileumsår, femti år siden folk landet på månen. Dette var i 1969. Teknologien som hjalp folk å komme dit er ikke engang 1969-teknologi, men snarere 1960 eller 62, fordi NASA bare ønsket å bruke det som hadde gode bevis på pålitelighet. Og så ser du på det og forstår - ja, og de var sanne! Nå, nei, nei, men du får problemer med teknologien rett og slett fordi alt presses for hardt, selges fra alle sprekker. Folk roper fra overalt: "Se, for en greie, dette er den nyeste tingen, den vakreste tingen i verden, passer for absolutt alle!" Vel, det er det ... vanligvis viser alt dette seg å være et lokkemiddel, og så må alt kastes. Kanskje det hele er fordi jeg allerede er en gammel mann og ser på slike ting med stor skepsis når folk går tom og sier at de har funnet den eneste, mest korrekte måten å skape de beste teknologiene på. I dette øyeblikket våkner en stemme inni meg som sier: «For et rot!»
Michael: Faktisk, hvor ofte har vi hørt om den neste sølvkulen?
Tim: Akkurat, og dette er det vanlige forløpet! For eksempel... det ser ut til at dette allerede har blitt en spøk rundt om i verden, men her snakker man ofte om blokkjedeteknologi. Og de gir faktisk mening i visse situasjoner! Når du virkelig trenger pålitelige bevis på hendelser, at systemet fungerer og at ingen lurte oss, når du har sikkerhetsproblemer og alt det der blandet sammen - gir blockchain mening. Men når de sier at Blockchain nå vil feie over hele verden, og feie bort alt i sin vei? Drøm mer! Dette er en veldig kostbar og kompleks teknologi. Teknisk kompleks og tidkrevende. Inkludert rent algoritmisk, hver gang du trenger å regne ut matematikken på nytt, med de minste endringer... og dette er en god idé - men bare for visse tilfeller. Hele mitt liv og karriere har handlet om dette: interessante ideer i veldig spesifikke situasjoner. Det er veldig viktig å forstå nøyaktig hvordan situasjonen din er.
Michael: Ja, det viktigste "spørsmålet om livet, universet og alt": er denne teknologien eller tilnærmingen egnet for din situasjon eller ikke?
Tim: Dette spørsmålet kan allerede diskuteres med teknologigruppen. Kanskje til og med få inn en konsulent. Ta en titt på prosjektet og forstå – vil vi nå gjøre noe riktig og nyttig, bedre enn før? Kanskje passer det, kanskje ikke. Men viktigst av alt, ikke ta en slik avgjørelse som standard, rett og slett fordi noen sa: «Vi trenger desperat en blokkjede! Jeg leste nettopp om ham i et magasin på flyet!» Alvor? Det er ikke engang morsomt.
Den mytiske "devops-ingeniøren"
Oleg: Nå implementerer alle devops. Noen leser om devops på Internett, og i morgen dukker det opp en ny ledig stilling på en rekrutteringsside. "devops ingeniør". Her vil jeg trekke oppmerksomheten din: tror du at dette begrepet, «devops engineer», har rett til liv? Det er en oppfatning om at devops er en kultur, og noe stemmer ikke her.
Tim: Så så. La dem da umiddelbart gi en forklaring på dette begrepet. Noe som gjør det unikt. Før de beviser at det er en unik kombinasjon av ferdigheter bak en ledig stilling som dette, vil jeg ikke kjøpe den! Jeg mener, vel, vi har en stillingstittel, «devops engineer», en interessant tittel, ja, hva neste? Stillingstitler er generelt en veldig interessant ting. La oss si "utvikler" - hva er det likevel? Ulike organisasjoner betyr helt forskjellige ting. I noen selskaper skriver programmerere av høy kvalitet tester som gir mer mening enn tester skrevet av spesielle profesjonelle testere i andre selskaper. Så hva, er de nå programmerere eller testere?
Ja, vi har stillingstitler, men stiller du spørsmål lenge nok, viser det seg etter hvert at vi alle er problemløsere. Vi er løsningssøkende, og noen har noen tekniske ferdigheter og noen andre. Hvis du bor i et miljø der DevOps har penetrert, er du engasjert i integrering av utvikling og administrasjon, og denne aktiviteten har en ganske viktig hensikt. Men hvis du blir spurt om hva du egentlig gjør og hva du er ansvarlig for, viser det seg at folk har gjort alle disse tingene i uminnelige tider. "Jeg er ansvarlig for arkitekturen", "Jeg er ansvarlig for databasene" og så videre, uansett hva du ser - alt dette var før "devops".
Når noen forteller meg jobbtittelen sin, lytter jeg egentlig ikke så mye. Det er bedre å la ham fortelle deg hva han faktisk er ansvarlig for, dette vil tillate oss å forstå problemet mye bedre. Mitt favoritteksempel er når en person hevder å være en "prosjektleder." Hva? Det betyr ingenting, jeg vet fortsatt ikke hva du gjør. En prosjektleder kan være en utvikler, leder av et team på fire personer, skriver kode, gjør arbeid, som har blitt en teamleder, som folk selv kjenner seg imellom som en leder. Og også, en prosjektleder kan være en leder som leder seks hundre personer på et prosjekt, administrerer andre ledere, er ansvarlig for å utarbeide tidsplaner og planlegge budsjetter, det er alt. Dette er to helt forskjellige verdener! Men jobbtittelen deres høres den samme ut.
La oss snu dette litt annerledes. Hva er du egentlig god på, har mye erfaring, har du talent for? Hva vil du ta ansvar for fordi du tror du kan håndtere oppgaven? Og her vil noen umiddelbart begynne å benekte: nei, nei, nei, jeg har ikke noe ønske om å håndtere prosjektressurser i det hele tatt, det er ikke min sak, jeg er en teknisk fyr og jeg forstår brukervennlighet og brukergrensesnitt, jeg vet ikke ønsker å administrere hærer av mennesker i det hele tatt, la meg bedre gå på jobb.
Og forresten, jeg er en stor tilhenger av en tilnærming der denne typen separasjon av ferdigheter fungerer bra. Hvor teknikere kan vokse karrieren så langt de vil. Imidlertid ser jeg fortsatt organisasjoner der teknologer klager: Jeg må gå inn i prosjektledelse fordi det er den eneste måten i dette selskapet. Noen ganger fører dette til forferdelige utfall. De beste teknologene er ikke gode ledere i det hele tatt, og de beste lederne kan ikke håndtere teknologi. La oss være ærlige om dette.
Jeg ser stor etterspørsel etter dette nå. Hvis du er en teknolog, kan bedriften din hjelpe deg, men uansett trenger du virkelig å finne din egen karrierevei fordi teknologien fortsetter å endre seg og du må finne opp deg selv på nytt sammen med den! På bare tjue år kan teknologier endres minst fem ganger. Teknologi er en merkelig ting...
"Eksperter på alt"
Michael: Hvordan kan folk takle en slik hastighet av teknologiske endringer? Deres kompleksitet vokser, antallet vokser, den totale mengden kommunikasjon mellom mennesker vokser også, og det viser seg at du ikke kan bli en "ekspert på alt."
Tim: Ikke sant! Hvis du jobber med teknologi, ja, du må definitivt velge noe spesifikt og fordype deg i det. Noe teknologi som din organisasjon finner nyttig (og kanskje faktisk vil være nyttig). Og hvis du ikke lenger er interessert i det - jeg hadde aldri trodd at jeg ville si dette - vel, kanskje du burde flytte til en annen organisasjon hvor teknologien er mer interessant eller mer praktisk å studere.
Men generelt sett, ja, du har rett. Teknologier vokser i alle retninger på en gang, ingen kan si "Jeg er en ekspert på alle teknologiene som finnes." På den annen side er det svampefolk som bokstavelig talt absorberer teknologisk kunnskap og er gale etter det. Jeg har sett et par slike mennesker, de bokstavelig talt puster og lever det, det er nyttig og interessant å snakke med dem. De studerer ikke bare hva som skjer inne i organisasjonen, men generelt snakker de om det, de er også veldig kule teknologer, de er veldig bevisste og målbevisste. De prøver bare å holde seg på toppen av bølgen, uavhengig av hovedjobben deres, fordi deres lidenskap er bevegelse av teknologi, fremme av teknologi. Hvis du plutselig møter en slik person, bør du gå til lunsj med ham og diskutere forskjellige kule ting over lunsjen. Jeg tror enhver organisasjon trenger minst et par slike mennesker.
Risiko og usikkerhet
Michael: Ærede ingeniører, ja. La oss berøre risikostyring mens vi har tid. Vi startet dette intervjuet med en diskusjon om medisinsk programvare, der feil kan føre til alvorlige konsekvenser. Så snakket vi om Lunar Program, hvor kostnaden for en feil er millioner av dollar, og muligens flere menneskeliv. Men nå ser jeg den motsatte bevegelsen i bransjen, folk tenker ikke på risiko, prøver ikke å forutsi dem, ikke engang observere dem.
Oleg: Beveg deg fort og knekk ting!
Michael: Ja, gå fort, knekk ting, flere og flere ting, til du dør av noe. Fra ditt synspunkt, hvordan bør den gjennomsnittlige utvikleren nærme seg læring av risikostyring nå?
Tim: La oss her trekke en grense mellom to ting: risiko og usikkerhet. Dette er forskjellige ting. Usikkerhet oppstår når du ikke har nok data på et gitt tidspunkt til å komme frem til et definitivt svar. For eksempel, på et veldig tidlig stadium av et prosjekt, hvis noen spør deg "når vil du fullføre arbeidet", hvis du er en ganske ærlig person, vil du si: "Jeg aner ikke." Du vet bare ikke, og det er greit. Du har ennå ikke studert problemene og er ikke kjent med teamet, du kjenner ikke ferdighetene deres, og så videre. Dette er usikkerhet.
Risikoer oppstår når potensielle problemer allerede kan identifiseres. Denne typen ting kan skje, sannsynligheten er større enn null, men mindre enn hundre prosent, et sted i mellom. På grunn av det kan alt skje, fra forsinkelser og unødvendig arbeid, men til og med til et fatalt utfall for prosjektet. Resultatet, når dere sier - folkens, la oss brette opp paraplyene våre og forlate stranden, vi blir aldri ferdige, det er over, punktum. Vi antok at denne tingen ville fungere, men den fungerer ikke i det hele tatt, det er på tide å stoppe. Dette er situasjonene.
Ofte er problemer lettest å løse når de allerede har dukket opp, når problemet oppstår akkurat nå. Men når et problem er rett foran deg, driver du ikke med risikostyring – du driver med problemløsning, krisehåndtering. Hvis du er en ledende utvikler eller leder, må du lure på hva som kan skje som kan føre til forsinkelser, bortkastet tid, unødvendige kostnader eller kollaps av hele prosjektet? Hva vil få oss til å stoppe og begynne på nytt? Når alle disse tingene fungerer, hva skal vi gjøre med dem? Det er et enkelt svar som er gyldig for de fleste situasjoner: ikke løp fra risikoer, jobb med dem. Se hvordan du kan løse en risikabel situasjon, redusere den til ingenting, gjøre den fra et problem til noe annet. I stedet for å si: vel, vi vil løse problemer etter hvert som de oppstår.
Usikkerhet og risiko bør være i forkant av alt du forholder deg til. Du kan ta en prosjektplan, se på visse kritiske risikoer på forhånd og si: vi må håndtere dette nå, for hvis noe av dette går galt, vil ingenting annet ha betydning. Du bør ikke bekymre deg for skjønnheten til duken på bordet hvis det er uklart om du kan lage middag. Først må du identifisere alle risikoene ved å tilberede en deilig middag, håndtere dem, og først da tenke på alle de andre tingene som ikke utgjør en reell trussel.
Igjen, hva gjør prosjektet ditt unikt? La oss se hva som kan få prosjektet vårt til å gå av stabelen. Hva kan vi gjøre for å minimere sannsynligheten for at dette skjer? Vanligvis kan du ikke bare nøytralisere dem 100% og erklære med god samvittighet: "Det er det, dette er ikke lenger et problem, risikoen har løst seg!" For meg er dette et tegn på voksenoppførsel. Dette er forskjellen mellom et barn og en voksen - barn tror at de er udødelige, at ingenting kan gå galt, alt blir bra! Samtidig ser voksne på hvordan tre år gamle barn hopper på lekeplassen, følger bevegelsene med øynene og sier til seg selv: «ååååååååååååååååååååååå. Jeg står i nærheten og gjør meg klar til å fange når barnet faller.
På den annen side er grunnen til at jeg liker denne virksomheten så mye fordi den er risikabel. Vi gjør ting, og de tingene er risikable. De krever en voksen tilnærming. Entusiasme alene vil ikke løse dine problemer!
Voksen ingeniørtenkning
Michael: Eksempelet med barn er bra. Hvis jeg er en vanlig ingeniør, så er jeg glad for å være barn. Men hvordan beveger man seg mot mer voksentenkning?
Tim: En av ideene som fungerer like godt med enten en nybegynner eller en etablert utvikler er konseptet kontekst. Hva vi gjør, hva skal vi oppnå. Hva er egentlig viktig i dette prosjektet? Det spiller ingen rolle hvem du er på dette prosjektet, enten du er praktikant eller sjefsarkitekt, alle trenger kontekst. Vi må få alle til å tenke i større skala enn sine egne arbeider. "Jeg lager stykket mitt, og så lenge stykket mitt fungerer, er jeg fornøyd." Nei og igjen nei. Det er alltid verdt (uten å være frekk!) å minne folk på konteksten de jobber i. Hva vi alle prøver å oppnå sammen. Ideer om at du kan være et barn så lenge alt er bra med din del av prosjektet - vær så snill, ikke gjør det. Hvis vi i det hele tatt krysser målstreken, krysser vi den bare sammen. Du er ikke alene, vi er alle sammen. Hvis alle menneskene i prosjektet, både gamle og unge, begynte å snakke om hva som er viktig for prosjektet, hvorfor selskapet investerer penger i det vi alle prøver å oppnå... de fleste av dem vil føle seg mye bedre fordi de vil se hvordan arbeidet deres korrelerer med arbeidet til alle andre. På den ene siden forstår jeg stykket jeg er personlig ansvarlig for. Men for å fullføre jobben trenger vi alle de andre menneskene også. Og hvis du virkelig tror du er ferdig, har vi alltid arbeid å gjøre i prosjektet!
Oleg: Relativt sett, hvis du jobber i henhold til Kanban, når du treffer flaskehalsen til en testing, kan du slutte med det du gjorde der (for eksempel programmering) og hjelpe testerne.
Tim: Nøyaktig. Jeg tror de beste teknologene, hvis du ser nøye på dem, er de på en måte deres egne ledere. Hvordan kan jeg formulere dette...
Oleg: Livet ditt er ditt prosjekt, som du styrer.
Tim: Nøyaktig! Jeg mener, du tar ansvar, du forstår problemet, og du kommer i kontakt med folk når du ser at avgjørelsene dine kan påvirke arbeidet deres, sånne ting. Det handler ikke om å bare sitte ved skrivebordet, gjøre jobben din, og ikke engang innse hva som skjer rundt deg. Nei nei nei. Forresten, noe av det beste med Agile er at de foreslo korte spurter, for på denne måten er tingenes tilstand til alle deltakerne tydelig observerbar, de kan se det hele samlet. Vi snakker om hverandre hver dag.
Hvordan komme inn i risikostyring
Oleg: Finnes det noen formell kunnskapsstruktur på dette området? For eksempel er jeg en Java-utvikler og ønsker å forstå risikostyring uten å bli en ekte prosjektleder av utdannelse. Jeg kommer nok til å lese McConnells "Hvor mye koster et programvareprosjekt" først, og hva så? Hva er de første trinnene?
Tim: Den første er å begynne å kommunisere med folk i prosjektet. Dette gir en umiddelbar forbedring i kommunikasjonskulturen med kollegaer. Vi må starte med å åpne alt som standard, i stedet for å skjule det. Si: dette er de tingene som plager meg, dette er de tingene som holder meg våken om natten, jeg våknet om natten i dag og tenkte: herregud, jeg må tenke på dette! Ser andre det samme? Bør vi som gruppe reagere på disse potensielle problemene? Du må kunne støtte en diskusjon om disse temaene. Det er ingen forhåndsforberedt formel som vi arbeider etter. Det handler ikke om å lage hamburgere, det handler om mennesker. "Laget en cheeseburger, selg en cheeseburger" er ikke vår greie i det hele tatt, og det er derfor jeg elsker denne jobben så mye. Jeg liker det når alt som ledere pleide å gjøre nå blir lagets eiendom.
Oleg: Du har snakket i bøker og intervjuer om hvordan folk bryr seg mer om lykke enn om tall på en graf. På den annen side, når du forteller teamet: vi flytter til devops, og nå må programmereren hele tiden kommunisere, kan dette være langt utenfor komfortsonen hans. Og i dette øyeblikket kan han, la oss si, være dypt ulykkelig. Hva skal man gjøre i denne situasjonen?
Tim: Jeg er ikke sikker på nøyaktig hva jeg skal gjøre. Hvis en utvikler er for isolert, ser de ikke hvorfor arbeidet blir gjort i utgangspunktet, de ser bare på sin del av arbeidet, og de må komme inn i det jeg kaller «kontekst». Han må finne ut hvordan alt henger sammen. Og selvfølgelig mener jeg ikke formelle presentasjoner eller noe sånt. Jeg snakker om at du må kommunisere med kolleger om arbeidet som helhet, og ikke bare om den delen av det du har ansvar for. Det er her du kan begynne å diskutere ideer, felles avtaler for å få arbeidet ditt til å passe godt sammen, og hvordan du kan takle et felles problem sammen.
For å hjelpe dem med å tilpasse seg ønsker de ofte å sende teknologer på trening, og de diskuterer trening. En venn av meg liker å si at trening er for hunder. Det er trening for folk. Noe av det beste med å lære som utvikler er å samhandle med jevnaldrende. Hvis noen er veldig flinke til noe, bør du se dem jobbe eller snakke med dem om arbeidet sitt eller noe. Noen konvensjonelle Kent Beck snakket konstant om ekstrem programmering. Det er morsomt fordi XP er en så enkel idé, men det forårsaker så mange problemer. For noen er XP som å bli tvunget til å kle seg naken foran venner. De får se hva jeg gjør! De er mine kolleger, de vil ikke bare se, men også forstå! Fryktelig! Noen mennesker begynner å bli alvorlig nervøse. Men når du innser at dette er den ultimate måten å lære på, endres alt. Du jobber tett med mennesker, og noen forstår temaet mye bedre enn deg.
Michael: Men alt dette tvinger deg til å gå ut av komfortsonen. Som ingeniør må du komme deg ut av komfortsonen og kommunisere. Som problemløser må du hele tiden sette deg selv i en svak posisjon og tenke på hva som kan gå galt. Denne typen arbeid er iboende utformet for å være til sjenanse. Du setter deg bevisst i stressende situasjoner. Vanligvis flykter folk fra dem, folk liker å være glade barn.
Tim: Det som kan gjøres, kan du komme ut og si åpent: «Alt er greit, jeg klarer det! Jeg er ikke den eneste som føler meg ukomfortabel. La oss diskutere ulike ubehagelige ting, alle sammen, som et team!» Dette er våre vanlige problemer, vi må håndtere dem, vet du? Jeg tror idiosynkratiske geniale utviklere er som mammuter, de forsvant. Og deres betydning er svært begrenset. Hvis du ikke kan kommunisere, kan du ikke delta godt. Derfor er det bare å snakke. Vær ærlig og åpen. Jeg er veldig lei meg for at dette er ubehagelig for noen. Kan du forestille deg at det for mange år siden var en studie hvor hovedfrykten i USA ikke er døden, men gjett hva? Frykt for offentlige taler! Det betyr at det et eller annet sted er mennesker som heller vil dø enn å si et kompliment høyt. Og jeg tror det er nok for deg å ha noen grunnleggende ferdigheter, avhengig av hva du gjør. Taleferdigheter, skriveferdigheter - men bare så mye som virkelig trengs i arbeidet ditt. Hvis du jobber som analytiker, men ikke kan lese, skrive eller snakke, så har du dessverre ingenting å gjøre i prosjektene mine!
Prisen på kommunikasjon
Oleg: Er det ikke dyrere å ansette slike utadvendte ansatte av ulike årsaker? De chatter tross alt hele tiden i stedet for å jobbe!
Tim: Jeg mente kjernen i laget, og ikke bare alle. Hvis du har noen som er veldig flinke til å tune databaser, elsker å tune databaser og kommer til å fortsette å tune databasene dine resten av livet, og det er det, kult, fortsett med det. Men jeg snakker om folk som ønsker å bo i selve prosjektet. Kjernen i teamet, rettet mot å utvikle prosjektet. Disse menneskene trenger virkelig å kommunisere med hverandre hele tiden. Og spesielt i starten av prosjektet, når man diskuterer risiko, måter å nå globale mål og lignende.
Michael: Dette gjelder alle som er involvert i prosjektet, uavhengig av spesialisering, ferdigheter, eller arbeidsmåter. Dere er alle interessert i prosjektets suksess.
Tim: Ja, du føler at du er tilstrekkelig fordypet i prosjektet, at din oppgave er å hjelpe prosjektet til å gå i oppfyllelse. Enten du er programmerer, analytiker, grensesnittdesigner, hvem som helst. Dette er grunnen til at jeg kommer på jobb hver morgen, og det er dette vi gjør. Vi har ansvar for alle disse menneskene, uavhengig av deres ferdigheter. Dette er en gruppe mennesker som har voksne samtaler.
Oleg: Faktisk, når jeg snakket om snakkesalige ansatte, prøvde jeg å simulere innvendingene til folk, spesielt ledere, som blir bedt om å bytte til devops, mot denne helt nye visjonen om verden. Og du som konsulenter burde være mye bedre klar over disse innvendingene enn jeg som utvikler! Del hva som bekymrer ledere mest?
Tim: Ledere? Hm. Som oftest er ledere presset av problemer, stilt overfor behovet for å hasteutløse noe og foreta en leveranse og lignende. De ser på hvordan vi hele tiden diskuterer og krangler om noe, og de ser det slik: samtaler, samtaler, samtaler... Hvilke andre samtaler? Kom deg tilbake til jobb! Fordi å snakke føles ikke som jobb for dem. Du skriver ikke kode, tester ikke programvare, ser ikke ut til å gjøre noe - hvorfor ikke sende deg til å gjøre noe? Tross alt er levering allerede om en måned!
Michael: Skriv litt kode!
Tim: Det virker for meg som om de ikke er bekymret for arbeid, men for manglende synlighet av fremgang. For å få det til å virke som om vi nærmer oss suksess, må de se oss trykke på knapper på tastaturet. Hele dagen fra morgen til kveld. Dette er problem nummer én.
Oleg: Misha, du tenker på noe.
Michael: Beklager, jeg gikk meg vill i tankene og fikk et tilbakeblikk. Alt dette minnet meg om et interessant rally som skjedde i går... Det var for mange rally i går... Og det hele høres veldig kjent ut!
Livet uten lønn
Tim: Forresten, det er slett ikke nødvendig å organisere "stevner" for kommunikasjon. Jeg mener, de mest nyttige diskusjonene mellom utviklere skjer når de bare snakker med hverandre. Du går inn om morgenen med en kopp kaffe, og det er fem personer samlet og rasende diskuterer noe teknisk. For meg, hvis jeg er leder for dette prosjektet, er det bedre å bare smile og gå et sted om virksomheten min, la dem diskutere det. De er allerede involvert så mye som mulig. Dette er et godt tegn.
Oleg: I boken din har du forresten en haug med notater om hva som er bra og hva som er dårlig. Bruker du noen av dem selv? Relativt sett har du nå et selskap, og et som er strukturert på en veldig uortodoks måte...
Tim: Uortodoks, men denne enheten passer oss perfekt. Vi har kjent hverandre lenge. Vi stoler på hverandre, vi stolte mye på hverandre før vi ble partnere. Og for eksempel har vi ingen lønn i det hele tatt. Vi jobber bare, og hvis jeg for eksempel tjente penger fra kundene mine, så gikk alle pengene til meg. Etter det betaler vi medlemskontingent til organisasjonen, og dette er nok til å støtte selskapet selv. Dessuten spesialiserer vi oss alle på forskjellige ting. Jeg jobber for eksempel med regnskapsførere, fyller ut selvangivelser, gjør alle mulige administrative ting for bedriften, og ingen betaler meg for det. James og Tom jobber på nettstedet vårt, og ingen betaler dem heller. Så lenge du betaler kontingent, vil ingen tenke på å fortelle deg hva du må gjøre. For eksempel jobber Tom nå mye mindre enn han en gang gjorde. Nå har han andre interesser; han gjør noen ting som ikke er for lauget. Men så lenge han betaler kontingent, vil ingen komme bort til ham og si: "Hei, Tom, gå på jobb!" Det er veldig enkelt å forholde seg til kolleger når det ikke er penger mellom dere. Og nå er forholdet vårt en av de grunnleggende ideene i forhold til ulike spesialiteter. Det fungerer og det fungerer veldig bra.
Beste råd
Michael: For å komme tilbake til "beste råd", er det noe du forteller kundene dine om og om igjen? Det er en idé om 80/20, og noen råd gjentas nok oftere.
Tim: Jeg trodde en gang at hvis du skrev en bok som Waltzing with Bears, ville det endre historiens gang og folk ville stoppe, men... Vel, se, selskaper later ofte som om alt er bra med dem. Så snart noe vondt skjer, er det et sjokk og en overraskelse for dem. "Se, vi testet systemet, og det består ingen systemtester, og dette er ytterligere tre måneder med uplanlagt arbeid, hvordan kunne dette skje? Hvem visste det? Hva kan gå galt? Seriøst, tror du på dette?
Jeg prøver å forklare at du ikke skal bli for sint over den nåværende situasjonen. Vi må snakke ut, virkelig forstå hva som kan ha gått galt, og hvordan vi kan forhindre at slike ting skjer i fremtiden. Hvis et problem dukker opp, hvordan skal vi bekjempe det, hvordan skal vi begrense det?
For meg ser alt dette skummelt ut. Folk takler komplekse, irriterende problemer og fortsetter å late som om de bare krysser fingrene og håper på det beste, vil det "beste" faktisk skje. Nei, det fungerer ikke slik.
Øv på risikostyring!
Michael: Etter din mening, hvor mange organisasjoner engasjerer seg i risikostyring?
Tim: Det som irriterer meg er at folk rett og slett skriver ned risikoer, ser på den resulterende listen og går på jobb. Faktisk er det å identifisere risikoer for dem risikostyring. Men for meg høres dette ut som en grunn til å spørre: ok, det er en liste, hva vil du endre? Du må endre standard handlingssekvenser med hensyn til disse risikoene. Hvis det er noen vanskeligste del av arbeidet, må du takle det, og først da gå videre til noe enklere. I de første spurtene, begynn å løse komplekse problemer. Dette ser allerede ut som risikostyring. Men vanligvis kan folk ikke si hva de endret etter å ha satt sammen en liste over risikoer.
Michael: Og likevel, hvor mange av disse selskapene er involvert i risikostyring, fem prosent?
Tim: Dessverre hater jeg å si dette, men dette er en veldig ubetydelig del. Men mer enn fem, fordi det er virkelig store prosjekter, og de kan rett og slett ikke eksistere hvis de ikke gjør i det minste noe. La oss bare si at jeg blir veldig overrasket om det er minst 25 %. Små prosjekter svarer vanligvis på slike spørsmål på denne måten: hvis problemet påvirker oss, så løser vi det. Da kommer de seg selv i problemer og engasjerer seg i problemhåndtering og krisehåndtering. Når du prøver å løse et problem og problemet ikke er løst, velkommen til krisehåndtering.
Ja, jeg hører ofte, "vi løser problemer etter hvert som de oppstår." Det vil vi sikkert? Vil vi virkelig bestemme oss?
Oleg: Du kan gjøre det naivt og ganske enkelt skrive viktige invarianter inn i prosjektcharteret, og hvis invariantene går i stykker, er det bare å starte prosjektet på nytt. Det viser seg veldig piembucky.
Michael: Ja, det skjedde med meg at når risikoer ble utløst, ble prosjektet rett og slett redefinert. Fint, bingo, problemet løst, ikke bekymre deg lenger!
Tim: La oss trykke på tilbakestillingsknappen! Nei, det fungerer ikke slik.
Keynote på DevOops 2019
Michael: Vi kommer til det siste spørsmålet i dette intervjuet. Du kommer til neste DevOops med en keynote, kan du løfte teppet for det du skal fortelle?
Tim: Akkurat nå skriver seks av dem en bok om arbeidskultur, organisasjoners uuttalte regler. Kultur bestemmes av organisasjonens kjerneverdier. Vanligvis legger ikke folk merke til dette, men etter å ha jobbet med rådgivning i mange år, er vi vant til å legge merke til det. Du går inn i et selskap, og bokstavelig talt i løpet av få minutter begynner du å føle hva som skjer. Vi kaller dette "smak". Noen ganger er denne duften veldig god, og noen ganger er det, vel, ups. Ting er veldig forskjellig for ulike organisasjoner.
Michael: Jeg har også jobbet med rådgivning i årevis og forstår godt hva du snakker om.
Tim: Faktisk er en av tingene verdt å snakke om på keynoten at ikke alt bestemmes av selskapet. Du og teamet ditt, som et fellesskap, har din egen lagkultur. Dette kan være hele selskapet, eller en egen avdeling, et eget team. Men før du sa, her er det vi tror, her er det som er viktig... Du kan ikke endre en kultur før verdiene og troen bak spesifikke handlinger er forstått. Atferd er lett å observere, men å søke etter tro er vanskelig. DevOps er bare et godt eksempel på hvordan ting blir mer og mer komplekse. Interaksjoner blir bare mer komplekse, de blir ikke renere eller klarere i det hele tatt, så du bør tenke på hva du tror på og hva alle rundt deg tier om.
Hvis du ønsker å oppnå raske resultater, her er et godt emne for deg: har du sett selskaper hvor ingen sier «jeg vet ikke»? Det er steder hvor du bokstavelig talt torturerer en person til han innrømmer at han ikke vet noe. Alle vet alt, alle er utrolige lærde. Du henvender deg til enhver person, og han må umiddelbart svare på spørsmålet. I stedet for å si «jeg vet ikke». Hurra, de ansatte en gjeng lærde! Og i noen kulturer er det generelt veldig farlig å si "jeg vet ikke" det kan oppfattes som et tegn på svakhet. Det er også organisasjoner der alle tvert imot kan si «jeg vet ikke». Der er det helt lovlig, og hvis noen begynner å tulle som svar på et spørsmål, er det helt normalt å svare: "Du vet ikke hva du snakker om, ikke sant?" og gjør det hele til en spøk.
Ideelt sett vil du gjerne ha en jobb hvor du kan være konstant glad. Det vil ikke være lett, ikke hver dag er solrik og behagelig, noen ganger må du jobbe hardt, men når du begynner å gjøre status, vil det vise seg: wow, dette er et virkelig fantastisk sted, jeg trives godt med å jobbe her, både følelsesmessig og intellektuelt. Og det er selskaper hvor du går som konsulent og umiddelbart innser at du ikke kunne tåle det i tre måneder og ville stikke av med skrekk. Det er dette jeg vil snakke om i rapporten.
Tim Lister kommer med en keynote til DevOops 2019-konferansen, som finner sted 29.-30. oktober 2019 i St. Petersburg. Du kan kjøpe billetter . Vi venter på deg hos DevOops!
Kilde: www.habr.com