Episode 3 - Den fejlfri illusion

I dette afsnit snakker vi om nul-fejls tolerancen indenfor IT udvikling, og hvorfor det er umuligt at leve op til.

Transcript

SPEAKER_01 0:00

Men har du tænkt over, hver for det så snakker med det?

SPEAKER_00 0:07

Ja, vi har snakket om sidste gange. Om vi skulle diskutere det her med fejlkultur. Altså det her med kultur, hvor man ikke må lave fejl kontra en kultur, hvor det er okay, at der sker fejl og ikke undgå fejl, men man skal sørge for at være forberedt på fejl. Og det tror jeg stadigvæk, når jeg kigger omkring, at der er stadig rigtig mange steder en nullfejlskultur eller nultolerancekultur over fejl.

SPEAKER_01 0:39

Jamen det virker ikke, som om der er noget, der forsvinder lige forlybet. Det virker, som om det stikker meget dybere. Det er også snakker om det i politik, og i folketinget og sådan noget, at det virker som om, at det er sådan en kultur, der hersker, man kan sige, der, hvor vi sidder i øjeblikket, men det er jo i princippet nogen, som i et andet omfang aftaler nogle opgaver fra noget, der er blevet vedtaget i folketinget. Så man kan sige, at hvis det den måde, de opererer på den, så trækker det jo hele vejen med ned i den løsningplementering. Fordi så står der en eller anden minister, der tager fat i en eller anden kontorchef eller noget siger, at jeg har lovet det her, og jeg bliver mål på det her. Og det her er sådan, vi gør her hos os. Så nu har jeg brug for, at jeg skal have vide, hvem der har lavet fejlen. Det kommer ikke som en overraskelse, at der er sådan en kultur, især i offentlige instanser, og ikke kun i folketinget. I hvert fald, hvis det er rigtigt, at det også er sådan en kultur er på borgen, hvis man kan sige det.

SPEAKER_00 2:05

Jeg tror, det der er interessant for mig, det er egentlig konsekvensen af den her nulfejskultur. For det jeg synes, at der så bliver konsekvensen, det, at man siger, at vi laver ikke fejl, vi må ikke lave fejl. Vi laver det fejl fritt. Så alt det, der har at gøre med overvågning, fejlhåtering, fejldokumentation error cods, alle de her ting, man normalt vil bygge omkring som turing eller monitorering eller lokning, det behøver man så ikke at lave. Det kan man så bare væk, fordi der sker ikke fejl. Vi laver fejl fare, for det er blevet bedt om at lever. Så derfor så kigger vi ikke rigtig inde i det. Jeg synes, der er sådan overnet til, at hvis man ikke kan lave fejl og alle fejl skri udbæret i produktionssætning. Så negliger man på en eller anden måde de omkringliggende værktøjer, som man normalt vil bygge. Lige såvel, hvis du bygger ind din hode med tricket statements. Hvis der noget kan gå Gale, så vil gerne have, at du opdager Gale, så kan håndere det på en pæn måde. Men det går jo også hele vejen ud til, at hvis der går noget forretningsmæssigt eller deploymentmæssigt eller lignende, hvilket der kommer til at ske på et tidspunkt, så skal du jo også have en håndtering af det, så du ikke bliver opmærksom på det, og tror du kan gøre noget ved det, og ander helst uden datab, eller uden når der sker fejl i forhold til den behandling, som applikationen skal foretage. Og det synes jeg, man ser meget igennem fingre med, når man har den her nullfejlskultur.

SPEAKER_01 3:38

Jeg har egentlig oplevet det som en konsekvens af nullfejlskultur. Altså, at mange af de her ting mangler. Og i hvert fald. Jeg forestiller mig, at nogle af de her ting mangler i højere grad af udenhed. Og ansvar sområdet for nogle forskellige ting, har været svær at placer. Og det færder mellem to stoler. Det vil sige, hvis det er dit ansvar, det ikke er mit ansvar. Så skal du ikke måle på det, og jeg skal ikke måle på det. Men så er der ikke nogen måler på det.

SPEAKER_00 4:22

Men det er så også ligeguld, for det virker.

SPEAKER_01 4:28

Men bare for lige prøve at forstå. Når det er, at du siger, at nulfiskultur, den gør sådan, at der ikke bliver mål på de her ting. Fordi sådan det har jeg faktisk ikke.

SPEAKER_00 4:46

Jeg har ikke tænkt over det, jeg har ikke oplevet det sådan. Det er noget så konkret som det, jeg oplever, at så diskuterer man om de her forskellige ting og så videre. Og så bliver fejlhåteringen, hvis der sker en fejl, det bliver kontaktudvikleren, der har lavet det. Det er jo for mig ikke fejlhåtering. Det er jo for mig en opførelse af, at man siger, at hvis der nu skulle blive noget, det gør der ikke. Men hvis der nu skulle blive noget. Så kan I lige tage fat i os. Men problemet er jo, at når du aflever et stykke stoffer til brugtræning, og så er det sådan set lige om, om det til intern brug eller ekstern brug, så skal udvikler jo gerne slippe det stykke stoffer, så er det jo lige pludselig ikke færdigt. Nej så er det jo et drift. Og så kan det godt være, at der er en support afdeling eller en driftafdeling eller lignende omkring organisationen eller virksomheden, der leverer den her applikation. Men det er jo i min optik et problem, hvis det udviklerne, der er driftansvarlige.

SPEAKER_01 5:51

Det er et problem, at udviklingen er driftansvarlige, hvis planen er, at det ikke er udviklerne, der skal drift det. Fordi det er sådan ste kunne egentlig godt tænke mig, eller jeg tror, at noget af den her umåndhed, der er i nogle af de her software ting, vi har været inde over. Kommer af, at man tror, at når udvikleren har set sin to testes på grønt så ligner af. Nu er jeg problem, ikke. Og så alle de problemer, der faktisk opstår mærker udvikleren ikke på sin egen krop. Og det går ikke ondt. Og derfor bliver der ikke taget hånd om det. Hvis det bare udvikleren i hvert fald til at starte med sig i de første 3-6 måneder eller år eller et eller andet. Software. Det skal gøre ondt. Pudviklingen. Så det er, at de kan se, at hvis ikke laver det her grund, så får jeg faktisk ikke min søvn af jeg mulighed for at have fred og ro i weekend, fordi det ringer fandme i timer og prøvede bilde mig ind fagfri software har gået ned igen. Lide der hvor der var allermest brug for det. Og hvorfor er den her loket så væk. Nu skal jeg bruge en ekstra time på at fejlsøge. Hvis jeg dog bare lige havde sørget for, at koden indeholde endne fejl besked i lokken. Så det var et minuts opgave at konstatere, hvad fejlen faktisk er, frem for at det bliver sådan en halv time, hvor man skal grænse lokks, og prøve at finde den helt rigtige, hvor man skal ned og se på en eller anden specifik parametre ud, for det kan man så går et andet system for at slå op, hvad det så var for en fejl, der var tale om. Det oplever jeg. På den måde oplever jeg, at det vil være meget sundt, hvis udvikleren var tæt på, men det er jo ikke på, hvis der planen er, at udviklingen ikke skal være en del af driften, så skal det jo ikke være det. Men så skal man finde en anden måde, hvorpå der er et encitement for udviklingen til at faktisk laver af stykke software. Hvor der er styre på de der fejl beskider. Så de er til at afgået uden. Man skal have etisk herogliflexikon. Eller man skal bruge trolig sådan noget detektiv arbejde med at prøve at finde ud af nogle ting, der passer sammen. Og hvorfor er det lige, når jeg får sådan en 500 internal server i dag, og jeg fik også en i går. Hvad det så, der gør, at jeg kan finde ud af, at det faktisk er to vidt forskellige ting, der er gået galt. Fique det er bare ikke noget, der bliver værnet om. Og det virker også, som om, at det er noget, som dem, der laver forretningskravstillelse, det er overhovedet ikke noget de sætter nogen værdi i. Når der er nogen, der har lavet en ordentlig fejl besked, det hjælper jo ikke i, at de i deres exceller kan krys af og sige, at nu den her FI4 1742, den er døme. Nu kan vi det her. Men det er. Så jeg ved ikke, om det var noget i sideborde. Men det er i hvert fald også en ting og overvejer det her med, hvornår skal udviklingen ikke være en del af den drift længere. Jeg tror i hvert fald ikke, det er den rigtige løsning af at tage dem ud for tidligt. Så får det ikke den erfaring.

SPEAKER_00 9:41

Det kan jeg, at jeg tror, det kommer ekstrem meget an på, som du svar ind på i starten af måden. At hvis du er en virksomhed eller et konsulenthus eller lignende, der leverer softwareløsninger, og der er vant til levere softwareløsninger. Så tror jeg, at man også godt ved, at det her skal enten ud at drift af dig selv, og det skal være billigere drift, eller det her er noget software, du skal overlevere til kunden, og så er du ude af det. Og i så falde, så tror jeg, at man er mere til bøje håber jeg, til ligesom tage højde for, at ting kan ske. For eksempel sådan noget med, hvad sker der, hvis nogen stopper applikationen ved i en kørsel, eller hvordan siker også, at vi ikke har data tab, eller hvordan sørger vi for, at vi ikke får lavet en operation halvt? Sådan helt almindelige spørgsmål, som man bør stille sig selv som udvikler. Og på det efterfølgende kommer sådan noget, okay. Hvordan sørger vi for at eksponere nogle snifter på den her service, hvis det er noget, som kunden skal selvdreft af lignende. Der fortæller, at den kører, og den fungerer, og den er oppe. Og samtidig, hvis der kan forekomme nogle fejl, der kræver en form for brugerhandling. Så skal det jo være dokumenteret specifikt, hvad for en fejl, der kan forekomme. Altså at dem man er opmærksom på, der kan så forekomme, fejl, man ikke er opmærksom på. Men det må at være opmærksom på. Og så skal der være en eller anden form for handling om, hvordan man kommer videre derfra. Og det er klart, at der er en stor forskel på at bygge noget agil software, som skal ud og leve mindre steder under udvikling. Der kan man jo samt et udviklingsteam tæt på. Der er en risiko for flere fejl, end der er med noget, der bliver leveret af fine pakker. Nu er det her færdigt. Men jeg synes stadig, det er.

SPEAKER_01 11:24

Teorien er der endre eller større risiko for en mindre risiko for fejl i noget, som er pæn pakke ind og leveret. Jeg kunne godt finde i tvivl om det er faktisk også af sådan.

SPEAKER_00 11:41

Det tror jeg ikke, det er. Men man kunne håbe, at det. Men jeg tror, det der er vigtigt for. Det der er vigtigt for mig, det er, at selvom der stiller et udviklingstiam tæt på, eller selvom det er gelt og lignende. Så synes jeg, det er problematisk. Det synes jeg, vi har oplevet mange steder, vi har været. At så får man ikke tænkt inde som ledig udviklingen, at det her på et tidspunkt skal drift. Det må det ikke sket drift i nu, selvom det måske ikke lever tæt på udviklingstiamet, eller tæt på udviklingsafdelingen, hvis man har sådan. Så må man jo antage på et eller andet tidspunkt, at det skal overgå til stabil drift, eller det skal overgå til drift efter fattig udvikling eller lignende. Og der synes jeg ofte, jeg oplever det, og det tror jeg personligt stammer fra sådan en nulfskultur. Jeg oplever, at alt det her, der har at gøre med overvågningen virker tingene, kører det har adgang til det, det skal. Og alt det, der har at gøre med, hvordan får vi det gan, hvis det er sket, det bliver sådan en eftertke. Når det føret ude og levet i noget tid. Eller også bliver det en efterpanke, der føren der tror, når problemet er opstået.

SPEAKER_01 12:58

Jeg oplever, at selv om en eller anden større konsulent virksomhed, selv skal drafte det. Så hvis dem, der ligesom sidder med det økonomiske overblik, og dem som i den her konsulent virksomhed, kan se, at vi kommer til at tjene finder bare på tal en halv million eller 200.000 kroner. Det har vi i ren profit gewinst et eller andet, hvis vi er færd i den her måde frem for om to måneder, så vil der være et internt pres på det her udviklingssteam, som ikke er kun selv, på at nu skal man altså lige se på rundet af. Man skal lige nu, og igen leve op til de her minimumskrav fra kunden det, der er skrevet ind i kontragen, så vi lige kan få sparket over på den anden side, så vi kan komme i gang med den her drift aftal. Så jeg tror, uanset om det er kun selv, eller om det. Eller hvem det er, der styder projektet, altså kunne jeg godt være bange for, at det der med noget ordentlig fejlhåtering, det bliver nedprioret. Og det kan også godt være det fordi, at jeg oplever, at det har mindre at gøre med den der nullfejlskultur. Men det kunne være, at i stedet for at jeg bliver ved med at sikre om det, så kan jeg måske prøve lige at reflektere over, hvordan jeg oplever den her nulfejskultur spillet ind i de projekter, som jeg har været involveret i. Og det er primært relateret til en meget lav risikovilighed. Og med lavisikovilighed, så kan man sige, at det lyder meget sjundt. Men hvis man ikke er villig til at risikere lidt så bliver man ved med at bare gøre ting, sådan som de gjorde i går. Fordi det kan man ikke blive klandet for. Det er jo sådan, vi har gjort i går i foregårs og de sidste mange år. Og man kan sige, at jeg tror, der, hvor jeg første gang oplevet det her, det var en tidligere chef, som forsøgte at sælge open source til både private og det offentlige. Og man kan sige, at det største problem, det var, at der var aldrig nogen, der var blevet fyret for, at jeg havde valgt Microsoft. Der var ikke nogen, der havde en risikovillighed til at faktisk prøve reelt at kigge på, om der var nogle stykker open source software, der faktisk til deres konkrete specifikke behov, der, hvor de var på det tidspunkt, at det kunne erstes af noget open source. Og det tror jeg godt læde min gamle hat på, at sådan nogle scenar har der været, hvor man med fordele kunne have brugt en Apache webserver i stedet for en Microsoft East. Eller man kunne have brugt Open Office, som det hæng, i stedet for Microsoft Office, fordi de kontorpakke behov, man havde, at det var en så lille del af den der Microsoft Word, at det kunne sagtens have fungeret. Og der er masser af open source software. Og det er jo ikke sådan, at fordi man bruger et stykke open source software, så kan man ikke bruge noget andet. Men jeg tænker, at det her med nulfejlskultur? For mig taler meget mere ind i den her risikovillighed og turve nogle nye græsgange af og lige så, okay, hvis vi prøver at tænke lidt ud af boksen, gøre ting anderledes, end vi plejer, kan vi så faktisk vinde noget. Og man kan sige, hvordan påvirker det såftwareudviklingen, jamen, det kan det kan være noget med at prøve et nyt programmeringsprog af. Nu er jo vi har joet noget closure og sådan noget, og det er der bare. Det er i hvert fald den oplevelse, jeg har, at der er ikke særlig mange store, der ønsker at rør det med en lille tang. Fordi man kan sige, at de har deres sharper, de har deres jav, og de har måske noget, hvad det er noget Python. Og det virker jo. Så der er ikke nogen, der er ikke nogen grund til at don't rock the boat. Og det er måske meget fint i 50% af tilfældene. Men altså der er. Hester ske noget nyt en gang i mellem, så bliver man også nødt til at prøve noget. Så jeg tror, det er der, hvor jeg oplever den her manglende risikovillighed. Det er i hvert fald et sted. Så er der måske noget mere over i noget proces. Altså man kan sige, at det er både godt at skille den seneste tid, og den seneste tid, der er nok nogle år efterhånden, har jeg kunet mindre og mindre, fordi jeg er blevet trukket ind tæt tættere på noget forretning. Og når man prøver at udfordre lidt, at den måde, vi gør tingene på, kunne vi ikke prøve at russe lidt op i det, prøve at komme af med det der. Er det virkelig så vigtigt. Kun man ikke, hvis man skal have det der væk, så sige til nogen, at så må I nøje med det der, eller ikke udlede det der, vi plejer at gøre, det kan jeg udlede af det der i stedet for. Og ja, det giver måske her noget mere arbejde her, men det er bare lige en til, at I har automatiseret det opmod det her nye, i stedet for blive ved med at holde fast i, at vi gør på den gamle måde. Men igen der oplever jeg også den her manglende risikovillighed til at faktisk gå ind og sige. Vil du hvad det gør vi skulle lige og godt se, at der måske er lidt mere arbejde i det med lad os lige prøve det af. Og så man siger, at det er så måske ikke så meget nødvendigvis softwarespecifikt, men det binder sådan i softwaren, fordi det kommer til at gøre, at man holder fast i nogle gamle måder at gøre tingene på, så man med fordelen måske kunne have forkastet og simplificeret.

SPEAKER_00 20:20

Og det tror jeg bestemt også af en stor del. Jeg tror for mig, det handler det lige så meget om det her med, at når man kommer ud af sted, eller man starter noget nyt eller videre. Så en af de første sted er min oplevelse, man sterder ind. Det er på standard og vjeronjering. Det kan man starter, hvis det har. Så er det næste, der kommer liggen i vejen, når man har fået funktionalitet. Det er, at så er der nogen, der måske begynder at sige. Det kunne være, hvis jeg have nogle test. Og det er også altid, der kommer sent i processen, men det er noget de fleste efter opmærksom på, at selvfølgelig skal være noget test, så vi skal have forskellige niveauer af test. Jeg føler bare stadig, at så stopper den der, fordi så er der deployment og sådan noget efterfølgende i forhold til CT. Men det her med, når det er pløjet, det her med at facilitere det, når det er det pløjet. Det føler jeg bare stadigvæk, at store dele af branchen og rigtig mange projekter ikke har grebet fat i ud på det værd, når man sidder og kigger på sine feature, og stiller de her spørgsmål at siger, okay, hvad er det forretningen har behov for? Hvad er det for nogle patterns, vi kan bruge? Hvad er det for nogle test, vi skal lave, for at være vi ser, at det her virker både vores bedcase, der er jo nogle vores corner cases. Og så burde det også være naturligt at sige, okay. Hvad er for nogle fejl, der kan forkomme, hvordan kan vi mitigere det? Det vi ikke kan mitigere, hvordan kan vi sørge for at lave nogle handlinger på det. Og der føler jeg bare rigtig ofte, at mange steder i stere mindre steder, der er det bare, at vi har det her problem, det kan vi løse sådan, og så stopper det. Og jeg tror, at noget af det, jeg måske prøve at lave et oprump om, det er det her med, og få lavet sådan en fuld cirkel, der ikke bare står og ved nu det live. Og der er det, at jeg føler lidt, at den her nulfejlskultur er sådan lidt, at hvis ikke tingene virker er fejl fri, så bliver det ikke det bløjet. Og i det kommer også helt naturligt, at så bliver det pløjet det sidste step. Det sidste logiske step, vi snakker om, fordi vi siger, at vi sørger for, at vi ikke ligger det i produktion, eller vi ikke lægger det live før at det er fejl frit, eller førercen eller fejlgængen er så langt ned, så det ikke er problem. Men i virkeligheden er der jo, man har jo den her meget klassiske det klassiske 8 tal, hvor man har de forskellige eller uendelighed, hvor vi har de forskellige dele udvikling, test, kvalitetssikring, deply og drift. Og det er ligesom, der er rigtig mange, der har glemt og drift. Og så går man jo så tilbage og endårer og refaktorer det også den. Alt efter deply mangler i det her udenligheds.

SPEAKER_01 23:07

Det er nogle andre problem.

SPEAKER_00 23:08

Det er jo et andet problem. Og det er måske der, hvor jeg tænker, at det bringer så til en helt anden del af diskussionen, som måske i virkeligheden også har navert af det her med, ja nu er det jo færdigt. Jeg så har sådan en eller anden, at når det er plet og det ud, så må det være det. Og så kan vi snakke nok så meget med genig udvikling. Min erfaring er, det er meget få steder, der forgår af lige udvikling.

SPEAKER_01 23:33

Ja, og jeg oplever, at softwaren, der bliver brugt. Det er sjældent færdig. Fordi at når det ligesom møder virkeligheden, så opdaver man alt den shortcomings. Og så skal det jo laves, og så møder det virkeligheden, og så opdaver man igen shortcomings, eller den kontekst, det bliver brugt i, har ændre sådan. Og det kan være alt fra noget lovgning, der ændrer sig til, at nu er han træk længere. Og det gør som regel, at der er nogen nye problematikker og nogle ting, der skal tages hånd op. Men kom til at tænke på. Det her med nulfultur i en anden ting, som jeg synes, der egentlig er relevant i den sammenhæng. Nu kan man sige, at nu har vi også været konsultenter i det offentlige. Og man kan sige, et andet sted, jeg har oplever den her nufejskultur, det er det her med, at alle scenarier skal være fx 100% automatiseret. Man taler om, at hvis man kigger på en eller anden pje af data, så 85% af det måske sådan. Men det for eksempel skyder sig på 85% af det sådan lige til, at så er der måske 10%, der er svære. Der er rigtig svære, og så er der de sidste 2 procent, som er bare virkelig hardcore. Og så skyder man en masse energi på at prøve at automatisere de sidste 2%, fordi systemet skal jo bare kun al selv, i stedet for at acceptere at sige, okay, de der to 6 procent. Det kan simpelthen ikke betale sig automatiseret. Det er meget bedre, at vi klerer det ad hoc sådan lidt hen ad vejen. Så prøver vi at tage de første hundred af de der meget sværere og se, hvordan det går at lave en det er måske næsten energik plan, for det ikke, men det virker som, at man prøver at planer. Man tror, at man kan overskue al den der kompleksitet. Og prøver at planlægge sig ud af det hele, fordi man har en anden forventning om det kan man. Og der oplever jeg bare virkligheden siger noget andet, at nej. Det kan du ikke. Du kommer til at lave fejl. Så du tror, du har gentænkt alle scenarne, så fordi det er så komplekt, så kommer det til at fejl. Det har været bedre, når hvis man starter med at acceptere at sige, at det her er så komplekst. Der kommer til at lave fejl, vi må tage det lidt gang.

SPEAKER_00 26:27

Det tror jeg også tager ind i den der med den her opfattelse, som jeg jo synes hænger sammen med nufskulturen om, at når det er kodet, så er det færdigt. Så er meget sådan i det om, at nu står der snuret et sted, og der behøver ikke nogen folk, der kigger på det, at der ikke nogen fint, det kører bare. Det her med, at når vi er færdigt med det software, så kan du håndtere alle former for use cases, som der måtte, og det står bare spændere, og det passer sig selv, fordi det lavet, som det lavet. Virligheden er jo bare, at der kommer nye cases til hele tiden, og der er ting, der går ned, og der er udfrakommende ting, du ikke ved, vil påvirke dig. Og derfor er du nødt til hele tiden at sige, okay, men hvordan håndterer vi de her ting, når vi først er i drift. For det er jo en anden ting af det her, hvor jeg bliver problemat. Hvis ikke du tænker de her ting inde i din udvikling, så står du med behovet i påskanten den dag, der går noget galt, og du har data, eller den dag, der sker andet, og du ikke ved, hvordan du kommer videre. For først tingene er i produktionen, og der er nogen, der afhængigt af det her støgt soffer, så er det rigtig translæt til bruge 8 dage på at finde ud af, hvordan du får det til at køre igen. Og ja, det kommer også til at ske. Jeg kan huske, at en af de steder, hvor vi har oplevet, hvor vi blev allermest præset ved at huske sådan tidlig, mens jeg var noget samme. Det var, hvor vi havde et rate på disk. Og så gik en diskus. Og så, at det er fint, vi får plæt en disk, den skal skiftes. Og så indden den nye disket så i diske nummer to her. I rate. Så ikke nok med, at vi havde datotab, og vi skulle til at genskabe data fra bækkop osv. Vi havde også et system, som folk var afhængig af der var nede. Og et system, vi ikke kunne være afhængig af internt, men der faktisk også var ekspert samarbejdspartner, der var afhængigt af. Og det er bare sådan noget. Det sker, og lige meget, hvor meget bækker og bækker, du har så Murfis lov, chancen for, at de der disk inden for et døgne hinanden, tror jeg, det var sådan fuldstænder lige, at vi havde bestældt des to. Og det kan være svært at tænke, men hvis nu man har tænkt sine backup løsninger og sine softwarsninger. Og fallover, eller tænke sin deployment, hvordan kan man hurtigt få et kopir af systemet op at køre. Jeg føler bare, at der er sådan en tendens til. Nu har vi gået det, nu er det færdig, nu er det live. Jeg synes, der er så mange ting, der bliver glemt. Også i store virksomheder eller i folk, der har gjort det her længe. Det er færende folk, hvor der er en masse spørgsmål, jeg føler personligt, der ikke bliver stillet, eller som jeg siger bliver en eftertanke.

SPEAKER_01 29:10

Jamen. Det er egentlig.

SPEAKER_00 29:16

Og jeg er ikke sikker på det, at jeg er ikke nemlig sikker på, det er noget, der kommer med erfaring, for det ikke er noget, man er bevidst om, eller det er ikke noget, man har stået i. Hvis man nu er for simpelt i en organisation, der er meget segmenteret. Og udvikling af som ikke sådan en driftfængde og ikke ved der er problemer, eller det kunne være en kundsøgsafdeling, der bruger en del af softwaren til at supportere kunder eller lignende, så tror jeg ikke på, at det er noget, man tillæger sig heller.

SPEAKER_01 29:40

Så skal man selv opse det. Og hvis du har en travl hver dag, hvor du bliver preset på alle mulige fronter. Så er det ikke selgt, at du så også lige synes, at du har overuskud til at opsøge, hvordan den software, du har med til at skrive, egentlig bliver brugt. Altså man kan sige, det burde jo være sådan, at de udviklere, der har skrevet noget software, var interesseret i, hvordan det blev brugt, og sat en af i, at brugerne synes, det var fedt at bruge og sådan noget. Men kan man sige, at hvis organisationen er opsplittet på sådan en måde, at folk er isoleret, og det vil sige, udvikleren af over et eller andet hjørne, hvor det er, at de måske aldrig møder dem, der sidder og bruger det. Jamen så skal den der udvikl være virkelig herd for at gå ned og opsøge en information selv. Det kommer nok sjældent til at ske. Og der kan man sige, det er det jo på en eller anden måde organisationens ansvar at sørge for, at den barriere er så lille som overhovedet muligt, eller at det er tænkt ind, at det er måden, man gør ting på, her, at vi skal have den feedback u for brugerne tilbage på en konstruktiv måde, hvor det ikke bare bliver sådan noget basking af, at det er bare noget lort, og det her er også noget lort. Hvorfor laver jeg sådan noget lort hele tiden? Men altså, kan man sige, jeg opløve, at det fungerede super godt. Det var virkelig sædv hos den kunden sammen, hvor det var, vi sad nærmest lige ved siden af de bruger, som brugte systemet. Og det er jo altså, det var dagligt, at man fik noget feedback. Og det kunne være i begge endder og skal det her med. Selvfølgelig var det super fedt, hvor nogen, der kom og sige, at det der nye der, det har hjulpet også så meget, at nu er det bare så meget nemmere. Og andre gange, så var det sådan noget. Det fungerer sgu bedre før.

SPEAKER_00 31:49

Men jeg kan også huske den reaktion, der kom, da du henvender dig ud af den her kunden efter været noget tid. Jeg kunne ikke godt tænke mig at få lov en dag og sidde op i kunservise og høre, når de tager telefoner, og hvordan de bruger systemet og se deres arbejdsgang, for så kan jeg bedre sætte mig ind i, om vi skal lave ændringer eller når der kommer nye ting. Og det var altså. Hvorfor er det? Og jeg kan huske et andet eksempel. Det var faktisk før den kunden. Det var før, at vi taget på projekter samme på den måde. Men der havde vi jo en brugergruppe, hvor de forskellige kunder havde mal til to medarbejdere, hvor vi holdt brugergruppen, hvor vi fik feedback fra de forskellige brugere om de feature, der var blevet leveret i den seneste vildige, så havde vi gerne tre måneder efter et brugergruppen. Og så var den ene gang, der synes jeg, jeg havde lavet en super fed feature. Og så sidder den der brugergruppe, og så sidder dem, der lige var heldigvis repræsentanter i brugergruppen, men lige præcis den feature. Og så sagde en super fed feature, der sparer sådan mas arbejde. Det var rigtig rigtig lækkert, hvis den lige lavet et andet sted, og hvis vi lige kunne bygge om på step 2 og step 3. Og så jeg sige, der tager jeg og tænkt, at det er da fuldt, stændig lige gyldig. Og der havde de her to bruger, det har så tættet og taget tid på. Hvor meget de lovede for at klik rundt og sådan ting, og meget de mene, de kunne spare. Og så lavede vi ændringer. De endte lige ved at spare halvenden times arbejdsgang om dagen, hvor vi lige flyttet rundt på nogle små ting. Så det, jeg synes, der var lige gyldigt. Det var faktisk rigtig vigtigt for dem. Og det har faktisk ret stor betyd for dem. Og der er jo ikke nogen, der ved, hvordan systemet fungerer bedst andet end dem, der skal bruge det. Og det er måske også problemer, at jeg synes ofte, og det er sådan set næsten lige om, om det er privat eller offentligt. Vi er blevet meget overdagen med, at dem, der sidder og kravstiller og dem, der sidder og skriver, de her forretningskrav, som skal implementeres. Det er ikke en gang folk, der har prøvet at sidde med det, eller der skal bruge det. På en eller anden måde har vi fået segmenteret brugerne, eller vi har fået lagt brugerne så langt væk fra hele processen. Det er mere sådan, et vi har behov for. Og så ser de ikke noget igen, før vi siger, her det. De bliver ikke rigtig inddraget, de bliver ikke hørt. Jeg synes ikke, at det her løbende feedback, som du snakker om, det kunne det godt være udviklingsfasen. Og jeg synes ofte også, at jeg oplever det jo også, hvad jeg hører fra nogle af vores kolleger i andre brancher osv. At det er jo heller ikke fordi, de bliver taget med på råd. Altså sådan noget som at have en medarbejderrepræsentant af ikke blandt sådan medarbejdsrepræsentant i forhold til trivl så vid. Men det med at have en medarbejderrepræsentant, der kan sidde med og sige, at vores arbejdsgang er faktisk sådan der sådan og sådan. Det synes jeg også er noget, der er forvundet i løbet af de sidste 10-12 år. Nu skal lige tænke på, hvor mange år siden her. Det er 16 år siden af jegst, der har kørt brug. Jeg har kørt vebinar, hvilket også har en går feedback. Men det sær af brugrupper, der ligger langt tilbage.

SPEAKER_01 35:05

Sådan lige for og prøve at komme tilbage til det her med nulfultur, fordi der er en ting, som jeg lige kommer til at tænke på, som jeg synes, der faktisk også taler ind i det. Det er det her med, at hvis man har opfattet af, at man må ikke lave fejl, og der kommer jo til at opstå et fejl på et eller andet tidspunkt. Så lige pludselig kommer det til at kommer sådan en kultur til at forstre sådan en blame game. Fordi kan sige, at vi må ikke lave fejl her, og vi kan som set fejl der, så nu skal jeg prøve at argumentere, hvorfor det ikke er mig, der har lavet fejl. Og så bliver der brugt utrolig meget tid på, at man skal ligesom have tøret den der fejl af fra sin eget bord, og skubber den over på nogle anders. Så man kan placeret ansvaret der, så man ligesom kan sige. Det er ikke her, vi laver fejl. Det er derovre. Og det er også et kæmpe problem. Det er så utrolig ikke konstruktivt for at løse problemet og finde en løsning på fejl, når man prøver at skubbe det rundt alle sted. Jeg tror, det værste eksempel har været, hvor der, hvor fejlen egentlig var, eller burde ligge, var så gode til at argumentere for, hvorfor det ikke var deres fejl, at løsningen blev skuppet hen i et fuldstændig fjoldet sted, så der sidder nogen over på den anden side af brug og siger, så må I løse det. Og det havde bare været 10 gange mere effektivt, hvis det var, man havde taget ind der, hvor problemet egentlig var opstået. Og så, det kan vi godt se. Løsningen ligger smart det. Men der kommer løsningen ikke til ikke, fordi samtalen gik på, hvem har lavet fejl, og den der lavet fejl. Det var det skruet op. Det er jo også forfærdeligt og at sædde og viden til.

SPEAKER_00 37:20

Det vil klæge rigtig mange at accepteret at sige, at det er hvad det er vores fejl. Også fordi, at min oplevelse er, at hvis man siger, ved du hvad, det er også, der har lavet en fejl. Det er selvfølgelig beklagligt. Vi har analyseret, den har haft de her de her konsekvenser. Nu har fået stoppet fejlen. Og så er vi i gang med at finde en kortsigt løsning og en langsigtet løsning. Altså med opserver, mitikere og fiks. Og der er du helt ret, at der er det mere sådan noget. Det kan det ikke være også. Det må være det med også. Og så kan man bruge tre-re på at diskutere, hvem der har lavet fejl i stedet for. Jeg vil jo vågne den påstand, at meget ofte har man ret god idé om, hvor fejlen er opstået.

SPEAKER_01 38:00

Og faktisk kan man sige. Så oplever jeg også, at de her fejl ofte er en kombination af mange ting. Så man kan godt sige. Hvis man bliver sådan meget fyrkendet, så kan man sige, at fejlen ligger i jeres timer. Men hvorfor fejl opstået. Det kan være alt mulige ting. Der kan have været noget sygdom. Der kan have været et meget hårdt pres fra ledelsen om, at der var nogen, der skulle lever. Og det vil sige, at der bliver der scår nogle hjørner, man har nogle deadlings. Og det kan være, at man kan være noget ansættelsessting med at der er kommet nogle nye ind. Og det er man måske blevet presset til at lave nogle rokader med personel eller af nogle andre årsager. Og alt muligt. Og i stedet for bare ligesom at sige, at de her fejl, der sker en gang imellem. Lad os lave noget post morgend og se, om I ikke kan lære af dem og reducerer chancen for, at det sker igen. Men ladder med det der fingerpingen. Det løser ikke problemet. Tværtimod det gør, at de løsninger, der kommer på banen, tager længere tid om at komme på banen, og ofte er af rænger kvalitet, fordi man forsøger at skå problemet. Alle forsøger at skå problemet væk, og så lander problemløsningen måske ikke det sted, hvor det vil have været bedst. Og nogle gange vil det også være fedt, hvis det var, at man kan sige, okay. Selv man ikke tænker, at det her også, der introduceret problemet, men at løsningen er nemst og bedst herover, hvis man så var villig til at tage den til sig. Men det er der jo ikke nogen, der har, hvis det er, at for det første bliver da set dårligt på dig, hvis der har lavet en fejl og fort andet. Så har du en deadline og nogen, der i hvert fald ikke ved tak dig, for at du forsøger at lægge løsningen det rigtige sted på en eller anden fejl. I stedet for, så siger det, at du har taget noget ekstra arbejde. Hvad med det der, du har lovet, at der skulle være færdig til i morgen, hvor det så færdig. Så nu skal du arbejde i weekend eller hvad? Der er ingen forståelse for, kan man sige den gode, langsiget løsning. Så det bliver hele tiden sådan noget med. Nu er vi over i det her med langsiget og kortsiget løsning. Ja.

SPEAKER_00 40:32

Det er tilbage problem, som vi har vendt hinanden i andet afsnit. Men jeg synes, jeg synes, det er meget interessant, for i det her er jo en del af den der fuldstændig syge fejlkultur. Hvor at man på en eller anden måde, altså det er jo sådan et eller andet med, at hvis vi har en kultur, der hedder, vi må ikke lave fejl, og vi laver ikke fejl. Når så der opstår fejl, så bliver det jo naturligt at prøve at få det væk fra en. Jeg synes, det hele hænger meget godt sammen i det her med, at hvis vi ikke må lave fejl, så bliver vi også bange for. Når der opstår en fejl, så vil vi heller ikke have det hængende på os. Og jeg har jo gjort, det kan jeg også tæt for. Og det har været godt af skidt, men jeg gjorde det for mange mange år siden, da vi rent faktisk havde så nogle menneskerordninger, hvor vi fik unge mennesker ind. Og sige, at det her med hjem påhør. Det er okay at lave fejl. Jeg vil bare gerne have, at hvis der sker en fejl så i dig, der ringer til kunden og siger, hvordan du skal høre. Jeg har kommet til at lave en fejl. Jeg har haft den betydning, vi kigger på det. Og det var godt på sin vis, fordi for lært dem det her med, at det de laver har en konsekvens. Det var rigtig skidt, fordi vi har oplevet nogle meget få eksempler, hvor det var med til at frembringe en nulfejlskultur, fordi de var bange for at stå skolet. Det var ikke det var meningen. Meningen var jo at sige, at det er okay, at skær fejl, der gør, men vi skal kunne stå ved, at vi har lavet en fejl, og vi skal turge kommunikere med kunden om, at vi har foret en fejl, så må jeg tage den derfra. Men den er den svær.

SPEAKER_01 42:03

Jeg tror, i det tilfælde har det så nok været bedre, at det var en erfaring personligt. Det er det. Der tog den samtale med kunden. Det skal være en kun, man kender, hvis man sender sådan en ung uderfaren til at tage den samtale, det kan sgu nemt går galt. På mange måder, både i kunde forholdet, men også for den udfarende, fordi det er så grænse overskridende. Og der tror jeg også, det ville have været bedre, hvis det var den af senjeren havde sagt for det her. Jeg snakker med kunden, og når man så taler med kunden, siger at vi har lavet en fejl. Og det er ikke ham, han har lavet en fejl. Det er jo lavet en fejl. Det er sådan her det har konsekvens. Det er sådan, at vi løser det. Lad os komme vidre.

SPEAKER_00 42:57

Og det er jo helt jægt. Jeg tror også, at det der var vigtigt for mig i hele den proces, vi kørte den gange, og som jeg stadig kører til deles, det er det her med at prøve at frembre en kultur, der siger, at vi skal selvfølgelig minimere fejl. Men vi skal også acceptere, at fejl kan forkomme, og vi ikke kan udgå fejl. Og det er vigtigt er sådan set ikke, om der sker en fejl. Det vigtig, hvordan vi håndterer fejl. Altså at hvis man er ret til sagen for, at man har lavet en fejl og går i baglås. Det er sådan set noget værks, hvis man der måde siger, vi går vores bedst, det var sådan set ikke så godt. Men nu får vi stoppet fejlen, nu får vi analyseret fejlen og nu får vi lavet en løsning på fejl. Hvis du kan holde holde hovedet klokt i de fejlspersoner, så står du altså langt langt bedre, end hvis der hele tiden er den her frygt for fejl.

SPEAKER_01 43:46

Men altså. Hvordan undgår, at man kommer over i den modsatte grøft, og hvor man sådan bliver ligaglad. Fordi det er jo heller ikke mening. Man skal have respekt for at fejlende altså for fejl og have respekt for, at de kan opstå, så man ikke bare sådan, JA, der kommer fejl i gang imellem. Det pløjer hver fredag, og så går vi hjem ikke.

SPEAKER_00 44:13

Men det var lige præcis det, jeg håber. Det var lige præcis, jeg har håbet ved, at dem, især de unge, for jeg synes, de er farligt, det ved det godt, men især de unge nyuddannet, eller folk, der måske er inde og snuds til at været. Hvis de før sættet og skulle forklare sig over en kunden, eller hvis de før hørt fra kunden, hvad de har haft af betydning, så er sådan set lige meget, om de har lidt et økonomisk tab, eller de har været rammet på andre måder, eller om det er nogle medarbejdere, ikke kunne passe deres stilling. Min erfaring er, at første gange de bliver stillet over for konsekvensen af deres handlinger, så kan jeg se en klar forbedring i deres tilgang til den kvalitet, de leverer. Og det er det, der var helt en at køre det principe. Og det tror jeg stadig på det principe.

SPEAKER_01 44:56

Jeg tror, det er rigtig rigtig vigtigt af, at udvikleren er tæt på den forretning, som de sidder og løser et problem for, og forstår konsekvenserne ved både de fejl, der bliver introduet i koden, men jeg tror jeg egentlig også med til, at det er til at skabe en generelt bedre forståelse af, hvordan softwaren bliver til noget, der bliver brugt i en eller anden organisation, og hver for nogle forretningsmæssige konsekvenser alt muligt har. Ik kun fejl, men faktisk også, som vi var inde på før, eller du nævner før, det her med, hvis interfacet er sådan ud, så sparer de faktisk halving timer om dagen. Det er jo ikke en fejl, men det er igen, den der forståelse af, hvordan softwaren den bliver brugt i en virksomhed. Eller fejl i softwaren, hvilke nogle konsekvenser har den for virksomheden. Bestninger om, hvordan softwaren fungerer, og hvordan har det her konsekvenser på virksomheden. Der tror jeg, den der med fejl, som kan være med til at sætte softwaren i en real kontekst. Fordi det er nemt at forstå. Ofte. Så man kan se, okay, jeg havde glemt at tjekke for, at de der dårlige data ikke måtte ind, og nu ser databasen her ud. Så kan man se konsekvensen. Og så tror jeg, derfra begynder man i højere grad og identificer alle mulige konsekvenser. Ikke kun influenteret fejl, men alle mulige konsekvenser ved bestlængingen man tager i kogen, hvordan udter det så over i organisationen.

SPEAKER_00 46:42

Jeg synes også, og det tror jeg er rettigt, jeg synes også, at det har oplevet med mange større projekter. Eller mange projekter, der bliver købt som projekt på baggrund af noget færdisk material. Den distance, der er der, og det har jeg oplevet nogle gange efterhånden. Det betyder også, at dem, der sidder og udvikler det, og dem, der sidder tester eller sådan noget, det har aldrig med bruger. Det er aldrig med en repræsentant for kunden. Det ved ikke gregen. De ved bare, at de laver den her boks, der gør det. Og min opfattelse er, at de første par gange, at der så sker en fejl, det kan være ret grove fejl, men når de så bliver præsenteret for konsekvensen, eller der har været en fejl eller lignende, så kan der godt være, og nu skal man så på sige, at der ikke var sådan holdning af sådan, og det var ikke så godt. Det var det ikke. Jeg synes, at jeg oplever, at de første par gange tingene sker, og indtil man får forklaret konsekvenser af sådan noget, så er der en meget lag i fær holdning til, at der har været fejl i noget, som måske bliver brugt af 4-50 mennesker på daglig basis. Og det ligger så langt væk fra dem. Det er jo bare noget kuret, det kan jo ret. Det tager lige 10 minutter ret. Ja, det tager 10 minutter og ret. Men lige nu, der sidder der altså nogen, der er ramt af den her fejl har vi allerede foret det her.

SPEAKER_01 47:58

Man kan sige, at det tager 10 minutter for der ret, så tager det en halv timer komme igen deployment pipeline, så tager det et par timer, at der nogle tester, der skal være, at vi ser, at det er okay, og vi tager godt lægge det i produktion.

SPEAKER_00 48:12

Så skal vi have deployment vind.

SPEAKER_01 48:14

Så skal vi have deployment vindu, og det bliver i morgen. Så nu har der siddet en større organisation en helt dag, og ikke kunne arbejde. Hvem, der betaler deres løn den dag, hvor de sidder træet og tomer. Så ja, altså. Så er vi tilbage til det der med, vi skal ikke over i den anden grønt. Det skal være der, hvor man tager så ved, at der opstår en fejl, og man tager det seriøst, og man finder en god løsning. Men det skal ikke være derover, hvor man bliver, det er bare en fejl. Så det skal være.

SPEAKER_00 48:50

Jeg tror, det der er vigtigt, det er i stedet for, at den her sådan helt grundlæsen med at sige at vi laver det så godt, at der ikke sker fejl, og der ikke er fejl. Og hvis der er nogen fejl, så det er ikke klar. Det, at vi i stedet for skal hen og sige, at vi gør alt, hvad vi overhovedet kan, for at der ikke opstår fejl. Men vi skal også være realistisk med, at på et tidspunkt sker fejl, så vi skal sørge for at have implementeret ting, der med tilerer fejl, eller gøre det muligt for os at håndter fejl. Og problemet er, at jeg føler lidt, at det er lige så dem, som der der med at sige, at det er bare en fejl, så er det ikke vigtig her. Det er lige så dem, der har den der med at sige. Det kommer faktisk ud af klarer. Der sker ikke fejl. I virkeligheden skal du lægge et sted, hvor du gør det bedst, lige som hvis du havde en noldfultur. Men du er realist i omkring på et tidspunkt op så går det fejl.

SPEAKER_01 49:40

Jeg har lige aftalt om robuste systemer.

SPEAKER_00 49:44

Ikke i nogle af de tidligere afsnitt på den måde, vi har aftalet.

SPEAKER_01 49:47

Men det kunne måske. Det taler meget godt ind i det her med.

SPEAKER_00 49:52

Det kan være godt ind til næste gang.

SPEAKER_01 49:55

Lad os prøve at måske lige bruge det som springbar til næste gang. Medtolerante systemer.

SPEAKER_00 50:04

Og robuste systemer.

SPEAKER_01 50:05

Robuste systemer og fejltolerante. Det er super vigtigt, at det ikke er fejlfri systemer med fejltolerante systemer.

SPEAKER_00 50:12

Det synes jeg er en klar. Men det er sådan set alt for data af det her. Det kommer i hvert fald godt rundt. Det tror jeg, hvor meget vi kommer rundt her om det emne, det er det så tænker, at vi kommer rundt.