Software Premortem - hvordan reddes patienten, efter at de døde?

Sådan løses problemer, før de sker?

Hvad er ideen bag et premortem?

Tanken bag premortem er at finde problemer, før de opstår.

Hvad angår softwareudvikling, uanset om du har en formel lancering af en stor udgivelse eller en uformel en af ​​en lille funktion, er der et tidspunkt, hvor du kan stoppe og forestille dig, hvad der ville ske, hvis.

Premortem-konceptet tilskynder teamet til at antage, at patienten er død, eller i softwareverdenen - projektet er mislykket. Projektet kan mislykkes, efter at det er frigivet af flere årsager.

Måske var kodekvaliteten lav.

Nogle nøglefunktioner blev måske ikke implementeret, hvilket medførte, at markedsoptagelsen var langsom.

Måske var markedsoptagelsen hurtigere, end vi havde forventet, og antallet af mennesker, der bruger det, var så stort, at det forårsagede skalaproblemer for infrastrukturtjenesten, der kører projektet.

Måske ville der være mange kunder, der ringer til supportcentret for at stille spørgsmål til den nye skinnende funktionalitet, men supportdivisionen er ikke bemandet til at svare dem, eller måske ved de ikke, at vi har leveret et nyt projekt.

Måske vil projektet introducere beskyttelse af personlige oplysninger, og vores juridiske afdeling er ikke engang i løkken, eller måske vil en hvid hacker finde sikkerhedsindtrængningsfejl.

Måske vil nogen tweet en negativ feedback om funktionen, og den ville blive viral.

Måske ved vi ikke, om projektet er en succes eller en fiasko.

Der er mange grunde til, at et projekt kan mislykkes.

Normalt, når vi starter et nyt projekt og begynder at implementere det, er vores sind indstillet til en bestemt tilstand.

Vi er målrettet mod at udfylde alle kravene til funktionen til tiden og imødekomme nogle kvalitetsbjælker. I en mere moden organisation har vi måske også sat os nogle succesmålinger.

Det er faktisk godt.

Hvis vi har en plan og krav, og kvalitetsbjælke og målinger, der skal måles, er vi gode.

Men det sker. Det er en kendsgerning.

Bugs afsløres, efter at projekter er blevet frigivet.

Omstændighederne kendes ikke i bedste fald eller ændres i værste fald.

Projekter mislykkes.

Lort sker.

Men, og dette er hovedideen bag premortem, hvad-hvis vi kan bringe os selv i en sindstilstand, hvor vi mener, at projektet faktisk er mislykket, efter at vi har frigivet det.

Kan vi være i den sindstilstand, at lort faktisk skete?

Hvis vi kan, hvis vi er under den antagelse, at alt helvede brød løs, så er vi nødt til at forstå hvorfor? Hvorfor er der sket? Hvad har vi gjort forkert? Hvad skulle vi have gjort anderledes?

I henhold til forskningen (en god henvisning til den findes i HBR post fra september 2007), og ifølge min erfaring såvel fra det forgangne ​​år, ville vi være i stand til at forhindre mindst nogle af de mest kritiske problemer, der muligvis mislykkes et projekt. Fantastisk!

Er premortem det samme som trusselmodellering?

Selvom der er nogle ligheder, er det ikke det samme.

Trusselmodellering er normalt et foruddefineret sæt spørgsmål, som du skal besvare for at sikre dig, at du har dækket dit grundlag. Dette er en lignende del.

Forskellen er, at du i preortem ikke svarer på templerede spørgsmål. Tværtimod. Du prøver at komme i humør, af en fiasko. Patienten er død. Projektet mislykkedes. Verden kollapser, hvad fanden har vi gjort forkert? Dette er mere en fantasibor end en forhør.

Hvordan gør man premortem ret? Gamification, Gamification og Gamification

At komme i den krævede sindstilstand for en premortem er svært. Meget hård.

Hvorfor? Først og fremmest skal du hoppe ind i fremtiden, og hvis du ikke har bilen ....

“Grå kupé på vejen” af Franck V. på Unsplash

For det andet døde patienten ikke. Projektet mislykkedes. Forudsat at det er mislykket, kræver en vis kreativ fantasi!

For det tredje er folk skeptiske. Softwareudviklere er kyniske.

De ville ikke købe ind i alt forudgående ting.

I deres sind er de ting, som de kunne have tænkt på, blevet tænkt på, og ting, der ikke har… ja, ingen fantasiøvelser ville hjælpe.

Dette er stedet, hvor gamification og atmosfære kommer til at spille.

Opret en kalendermødeinvitation: Projekt “someProjName” - premortem ”.

Inviter hele holdet.

Udviklere, QA, produktledere, ux designere.

Hvis du kan, bør du invitere et par flere mennesker, der ikke er så fortrolige med dette projekt.

Måske nogle mennesker fra et andet team, eller folk fra kundesupportgruppen. Det betyder ikke rigtig noget. Den gode ting ved at bringe folk, der ikke er et delhold, er, at de er den tætteste ting, du har til en rigtig kunde.

Før selve mødet, send til alle inviterede et par ord på premortem, eller endnu bedre, send dem denne artikel (-:

På selve mødet får du skeptiske blik.

Nu skal du indstille scenen.

Vær dramatisk. Vis dem billeder.

“Ødelagt hvidt flyselskab på jorden om dagen” af Hao Zhang på Unsplash

Fortæl dem en historie.

Giv så mange detaljer, du kan på scenen.

Vælg en bestemt dato i fremtiden. For eksempel 3 og en halv måned efter lanceringen.

Find den nøjagtige dato. Lad os antage, at dette er den 14. marts, 2019.

Find ud af nogle interessante ikke-relaterede detaljer om den dag, der ville sætte folk i humør.

For eksempel er den 14. marts pi dag. Fortæl teamet om det.

Fortæl dem, at du den 14. marts, nøjagtigt kl. 17:12, 3 minutter, før du har indsat din bærbare computer i din rygsæk, og klar til at lukke dagen, fik du en e-mail fra virksomhedens administrerende direktør med følgende emne: URGENT! projekt “someprojname” - rettes X med det samme.

Vores job er at finde X.

Nu begynder de at komme i humør.

Forklar dem, at du deler dem i to grupper for at krydre tingene lidt.

Rød og blues.

Før mødet skal du forberede notater på forhånd med følgende titler:

  • Sikkerhedsofficer
  • Businesschef
  • Chef for kvalitet
  • Juridisk officer
  • Chef for Marketing

Opret et sæt blå noter og et sæt røde noter.

Hvis du ikke har nok mennesker, skal du bare strejfe gennem nogle af titlerne (det er ikke kritisk).

Giv nu en hat med noterne indeni, og lad hver en vælge en tilfældig note. Dette vil opdele rummet i 2 grupper (rød & blå), hver person med en bestemt titel.

På det tidspunkt ville du være i stand til at føle spændingen i luften, da folk fornemmer, at en konkurrence kommer.

De har ret.

Forklar dem spillereglerne.

  • Hver gruppe går til et dedikeret mødelokale.
  • Hver gruppe har 45 minutter til at komme med de mest alvorlige problemer, der fik projektet til at mislykkes.
  • Hver person i gruppen kan bidrage med et spørgsmål inden for hvilket som helst domæne, men skal huske, at de specifikt har ansvaret for et bestemt. Dette skaber for enkeltpersoner en følelse af ejerskab. Ingen marketingchef ville gerne have, at under deres skift, nogle forpassede marketingmaterialer / kampagner forårsagede manglende opmærksomhed omkring en ny funktionalitet.
  • Efter 45 minutter deltager holdene igen og går over problemerne.
  • Holdet med de mest alvorlige problemer (du kan rangere det efter deres sværhedsgrad eller ej) vinder is, en cupcake eller prale rettigheder.
  • Du kan krydre ovenstående med dine egne kreative ideer - jeg elsker at høre om dem!

Det er det. Du er færdig. Min anbefaling er ikke at fortsætte, men at stoppe mødet. Målet med mødet blev nået. Målet var kreativt at tænke over, hvad der fik projektet til at mislykkes. Det er det.

Offline skal du gå over listen over poster, som holdet har fundet, og gennemstribede ting, der er duplikeret eller ikke relevant (da de blev testet og valideret, eller med 0 sandsynlighed, eller allerede er håndteret).

En vigtig ansvarsfraskrivelse her er, at du ikke er tvunget til at løse eller håndtere alle de problemer, der blev bragt op under premortem-sessionen. Det er op til teamet at beslutte ROI (Return of Investment) for hver af opgaverne. Hvis investeringsafkastet er lavt, skal du lukke dem som "vil ikke løse".

For de spørgsmål, der er relevante, skal teamet tildele ejere for at det skal kunne håndteres i de næste par dage, før projektet går i gang.

Du har lige gemt et projekt.