Slik administrerer du et programvareprosjekt: En komplett veiledning
Å administrere et programvareprosjekt betyr å holde omfang, mennesker, tidsplaner og leveranser samkjørte, ofte samtidig som alt rundt deg er i endring. Etter min erfaring mislykkes de fleste prosjekter ikke fordi teamet ikke kan kode. De mislykkes fordi kravene endres gradvis, avhengigheter blir oversett, og interessenter ikke får vite om det før det er for sent.
Denne veiledningen tar deg gjennom alle fasene i leveransen av et programvareprosjekt: fra å definere omfang og velge en metodikk til å håndtere risiko, følge fremdriften og lansere med trygghet. Den riktige programvaren for prosjektstyring utgjør en reell forskjell her. Når du er ferdig med denne artikkelen, sitter du igjen med et praktisk veikart du kan ta i bruk umiddelbart.
Hva programvareprosjektstyring egentlig innebærer
Programvareprosjektstyring handler om å holde omfang, mennesker, tidsplaner og kvalitet samkjørte fra det første oppstartsmøtet til den endelige produksjonssettingen. Det som gjør programvareprosjekter spesielt krevende, er ikke selve koden, men alle delene som er i bevegelse. Krav endres midt i en sprint. Avhengigheter blir synlige sent. Interessenter har ikke samme oppfatning av prioriteringene. Teamene er spredt over tidssoner og fagområder.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Alle programvareprosjekter går gjennom fem livssyklusfaser, uavhengig av metodikk:
- Oppstart: Definer problemet, identifiser interessenter og oppnå enighet om hvorvidt prosjektet er verdt å gjennomføre.
- Planlegging: Avgrens arbeidet, estimer innsatsen, fordel roller og fastsett milepæler.
- Gjennomføring: Bygg løsningen. Det er her det meste av den daglige prosjektstyringen foregår.
- Overvåking: Følg fremdriften opp mot planen og håndter avvik før de får vokse seg større.
- Leveranse: Sett løsningen i produksjon, overlever den og stabiliser den.
Effektiv styring av prosjektarbeidsflyten hjelper team med å forstå hvordan arbeidet beveger seg fra planlegging gjennom utvikling, testing, godkjenning og levering.
Hva som gjør programvare annerledes enn andre prosjekter
Programvareprosjekter har noen egenskaper som generelle råd om prosjektstyring ikke tar høyde for. For det første er produktet usynlig helt til det ikke er det lenger. Med andre ord kan du ikke gå rundt i lokalene og se at 60 % av en funksjon er ferdig. For det andre begrenser tekniske beslutninger som tas tidlig, valgmulighetene senere på måter som ikke alltid er åpenbare for ikke-teknikere. For det tredje er teamet som utfører arbeidet, ofte også teamet som estimerer det, noe som skaper skjevhet.
En prosjektleder som forstår dette, arbeider på en annen måte. Du følger ikke bare opp oppgaver. I stedet avdekker du hindringer, forklarer tekniske avveininger for interessenter og legger til rette for at utviklerne skal kunne gjøre sitt beste arbeid.
Velg riktig metodikk for prosjektet ditt
Metodikken din former alt: hvordan arbeidet avgrenses, hvordan team samarbeider og hvordan dere reagerer på endringer. Det finnes ikke ett universelt riktig valg, men det finnes et riktig valg for din situasjon.
Typen smidig implementering du velger … avhenger av kompleksiteten i avhengighetene og gjensidige avhengighetene i produktet og organisasjonen din, samt størrelsen på teamene dine.
Bruk denne tabellen for å finne tilnærmingen som passer situasjonen din:
| Metodikk | Best egnet for | Vær oppmerksom på |
|---|---|---|
| Scrum | Tverrfaglige team som utvikler trinnvis med hyppige lanseringer | Seremonier kan bli en belastning i svært små team |
| Kanban | Løpende arbeid uten faste sprinter (support, drift, vedlikehold) | Manglende rytme hvis begrensninger på pågående arbeid ikke håndheves |
| Vannfall | Prosjekter med fast omfang og stabile krav (samsvar, infrastruktur) | Feiljusterte krav oppdages sent |
| SAFe / Scaled Agile | Store organisasjoner som koordinerer flere smidige team | Kompleksitet og mye prosessarbeid |
| Hybrid | Prosjekter med en fast leveringsdato, men et omfang i utvikling | Forvirring hvis teamets spilleregler ikke er tydelig definert |
Smidige prosjekter har en tendens til å gi bedre resultater enn fossefallsprosjekter, men metoden er ikke hele forklaringen. PMIs nyere forskning antyder at suksess i mindre grad avhenger av å velge én metodikk enn av hvor godt teamene tilpasser den til arbeidet sitt.
Bruk smidige seremonier uten smidige prinsipper, så blir daglige statusmøter til statusmøter og sprinter til små fossefallsprosjekter.
Jeg vil også advare mot å bytte metodikk underveis i prosjektet, med mindre noe faktisk er ødelagt. Forstyrrelsen lønner seg sjelden.
Sett sammen det riktige teamet og tydeliggjør ansvarsområdene
Forskning har lenge knyttet dårlige krav til kostbart omarbeid i prosjekter. Men etter min erfaring kan uklart ansvar være like frustrerende. Når ingen vet hvem som tar den endelige beslutningen, venter alle – eller, enda verre, tar alle beslutninger hver for seg.
Start med å kartlegge rollene prosjektet faktisk trenger:
- Prosjektleder (PM): Har ansvar for leveransen – tidsplaner, risikoer, kommunikasjon og samordning med interessenter.
- Utviklingsleder (EM) eller teknisk leder: Har ansvar for teknisk kvalitet og gjennomføringen av utviklingsarbeidet.
- Produktleder: Har ansvar for «hva» og «hvorfor» – krav, prioritering og brukerresultater.
- Utviklere: Har ansvar for implementeringen innenfor det avtalte omfanget.
- QA-ingeniører: Har ansvar for teststrategi og kvalitetsporter.
- Designere: Har ansvar for brukeropplevelse og visuelt resultat, og bør helst involveres før utviklingen starter.
- Interessenter: Har ansvar for forretningsresultatet og tar de endelige beslutningene om viktige avveininger.
Bruk et ansvarsrammeverk fra dag én
Et RACI- eller DACI-rammeverk tydeliggjør ansvaret før det oppstår hull. RACI (ansvarlig, beslutningsansvarlig, konsultert, informert) fungerer godt for gjennomføring av oppgaver. DACI (driver, godkjenner, bidragsytere, informert) er bedre for beslutninger. Jeg vil foreslå å bruke begge i større prosjekter: RACI for arbeidet og DACI for beslutningene som kan føre prosjektet ut på feil spor hvis de tas feil.
Dokumenter dette i prosjektbeskrivelsen og del den ved prosjektoppstarten. Når folk vet hvordan beslutninger tas, slutter de å vente på tillatelse til å gå videre.
Finn det riktige PM-verktøyet for programvareprosjektet ditt
Før du velger en plattform, bør du vurdere de ulike måtene du kan bruke prosjektstyringsprogramvare på, og hvilke funksjoner teamet faktisk trenger – fra oppgavetildeling og planlegging til rapportering og samarbeid.
10 Utvalgte toppverktøy for prosjektstyring
For å gjennomføre prosjektet på riktig måte må man ofte finne de riktige verktøyene for oppgaven. Her er mine beste anbefalinger av verktøy for programvarebasert prosjektstyring.
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
Selv med det riktige teamet og den riktige plattformen kan det være vanskelig å få alle til å bruke den konsekvent. Ved å forstå hvorfor prosjektstyringsprogramvare er vanskelig å bruke på en god måte, kan du forutse problemer med innføringen før de påvirker leveransen.
Definer omfang, krav og suksesskriterier
Omfanget er grunnlaget hele prosjektet hviler på. Hvis du tar feil her, får det konsekvenser for alt som følger. Når estimeringen for eksempel er feil, blir interessentene uenige, og teamet leverer feil løsning.
Stuart Taylor, grunnlegger av Influential PMO og forfatter av Å bli prosjektleder, forteller en historie som fungerer godt som et praktisk eksempel her. Et prosjekt for å lage et SMS-svar på kundeklager fikk aldri kravene dokumentert eller godkjent. Under den avsluttende testingen stilte så et medlem av styringsgruppen et spørsmål som førte hele prosjektet ut på villspor.
De hadde kommet så langt at det nesten var ferdig, og de holdt på med den avsluttende testingen da noen i styringsgruppen nevnte: «Og hva skjer når kunden svarer på det?»
Han fortsetter:
Og ingen hadde sagt det høyt før de siste to ukene av prosjektet.
Begynn med de grunnleggende prinsippene for prosjektledelse som styrer hvordan du definerer omfang, fordeler ansvar, håndterer risiko og måler suksess.
Begynn deretter med intervjuer av interessenter. Spør hvordan suksess ser ut, hva som ikke omfattes av prosjektet, og hvilke beslutninger som allerede er tatt. Skriv så et kravdokument som dekker:
- Forretningskrav: Hvilket problem løser vi, og for hvem?
- Funksjonelle krav: Hva må systemet gjøre?
- Ikke-funksjonelle krav: Begrensninger knyttet til ytelse, sikkerhet, tilgjengelighet og skalerbarhet.
- Utenfor omfanget: Hva skal ikke bygges i denne utgivelsen.
Definer målbare suksesskriterier
«En bedre betalingsopplevelse» er ikke et suksesskriterium. «Reduser avbrutte handlekurver med 15 % innen 60 dager etter lansering» er det. Definer KPI-ene dine før noen skriver en eneste kodelinje. Dette er viktigere enn de fleste team innser, og det tvinger dessuten frem tydelighet rundt hva dere faktisk jobber mot.
Forhindre ukontrollert utvidelse av omfanget tidlig
Ukontrollert utvidelse av omfanget, endrede krav og ressursbegrensninger er vanlige prosjektledelsesutfordringer som er enklere å håndtere når du identifiserer varselsignalene tidlig.
En ukontrollert utvidelse av omfanget kommer sjelden som et dramatisk krav. Den kommer som et lite tillegg i en Slack-tråd, en kommentar om «når vi først er i gang» på en oppgave, eller en antakelse fra en interessent som aldri ble utfordret.
Taylor snakker om hvor viktig det er å utfordre antakelser på dette stadiet.
Tenk på gangene da du, mot bedre vitende, ble stresset gjennom prosessen og presset forbi av sterke stemmer og innflytelsesrike personer i organisasjonen som du egentlig ikke følte deg i stand til å si nei til.
Utfordre det likevel.
Etabler en enkel vane for endringskontroll fra starten: Alle nye forespørsler vurderes opp mot gjeldende omfang, tidsplan og ressurser før de legges inn i oppgavelisten. Jeg går gjennom dette i detalj i delen om endringshåndtering nedenfor.
Planlegg arbeidet: estimering, milepæler og budsjett
Planlegging gir prosjektet ditt et skjelett. Uten den er gjennomføringen bare organisert kaos.
Del arbeidet opp i milepæler og sprinter
Begynn på makronivå. Identifiser de viktigste milepælene – betydningsfulle tidspunkter der noe beviselig er ferdig. Del deretter hver milepæl opp i biter på én sprint som teamet kan gjennomføre på én til to uker. Dette gir deg en naturlig tilbakemeldingssløyfe uten at du må vente til slutten for å oppdage at dere ligger etter.
Estimer ærlig
Ingen estimeringsmetode er perfekt, men noen fungerer bedre enn andre for programvare. Her er det jeg har sett fungere:
- Historiepoeng med planleggingspoker: Godt egnet for relativ størrelsesvurdering i smidige team, men bare nyttig hvis teamet kalibrerer konsekvent.
- T-skjortestørrelser: Raskt for tidlige samtaler med interessenter om omfanget.
- Trepunktestimering: Estimer beste, verste og mest sannsynlige scenario, og beregn deretter gjennomsnittet. Mer ærlig enn gjetninger basert på ett enkelt punkt.
- Prognoser basert på sammenlignbare prosjekter: Sammenlign estimatet ditt med hvor lang tid tilsvarende arbeid faktisk tok tidligere. Team undervurderer konsekvent fordi de tar utgangspunkt i ideelle forhold.
Ta høyde for hele bildet i budsjettet
Budsjetter for programvareprosjekter må vanligvis ta høyde for:
- Personalets tid (utviklere, QA, design, PM, EM)
- Verktøy, lisenser og infrastruktur
- Tredjepartsintegrasjoner eller API-er
- Testmiljøer
- Buffer for det uforutsette (jeg anbefaler minst 15–20 %)
Legg inn litt ekstra tid i tidsplanen før du presenterer den for interessentene. Det er mye enklere å levere før fristen enn å reforhandle en overskredet frist.
Gjennomfør en god oppstart og etabler samarbeidsrammene
Et oppstartsmøte er egentlig tidspunktet der dere bygger en felles forståelse og blir enige om hvordan teamet skal samarbeide, ikke bare en formalitet. En svak oppstart betyr at dere vil bruke de neste seks sprintene på å besvare spørsmål på nytt som burde ha vært avklart den første dagen.
Dette bør dere ta opp i oppstartsmøtet
Gå gjennom dette i deres første møte med hele teamet:
- Prosjektets formål og mål: Hvorfor finnes dette, og hvordan ser suksess ut?
- Roller og eierskap: Hvem er hvem, og hvem bestemmer hva?
- Omfang og hva som ikke er omfattet: Hva er inkludert, hva er ikke inkludert, og hvordan skal endringer i omfang håndteres?
- Milepæler og viktige datoer: En overordnet tidsplan som alle kan forholde seg til.
- Samarbeidsavtaler: Møtefrekvens, forventninger til svartid og eskaleringsveier.
Bli enige om verktøyene og hvilke kilder som er autoritative
Dere trenger ett sted der prosjektet bor. Jeg foreslår en prosjekthub i Notion, Confluence eller et lignende verktøy. Et sted som inneholder prosjektbeskrivelsen, veikartet, åpne beslutninger og møtenotater. Legg deretter til verktøyene dere bruker i gjennomføringen:
- Jira eller Linear for oppfølging av oppgaver og sprintstyring.
- Slack eller Teams for asynkron kommunikasjon (med en tydelig kanalstruktur).
- Figma for overlevering av design.
- GitHub eller GitLab for kode og gjennomgang av forespørsler om kodeendringer.
Verktøyet er ikke like viktig som enigheten. Dokumenter normene deres, og sørg for at teamet følger dem.
Kommuniser tidlig, ofte og med riktig målgruppe
Kommunikasjon er der de fleste prosjekter i stillhet går galt. Det er ikke slik at teamene ikke snakker sammen, men de snakker med feil personer, med feil hyppighet og med feil detaljnivå.
Dokumenter hva som fungerte, hvor teamet støtte på forsinkelser, og hvilke beste praksiser for digital prosjektledelse det er verdt å ta med videre til neste prosjekt.
Tilpass budskapet til målgruppen
Utviklere trenger kontekst og tydelighet om hva som skal bygges videre. Ledere trenger å vite om prosjektet følger planen, og om det finnes beslutninger de må ta. Interessenter på mellomnivå trenger nok detaljer til å gi nyttige innspill uten å gå seg vill i implementeringsdetaljer.
Jeg foreslår en kommunikasjonsrytme som ser omtrent slik ut:
- Daglige standup-møter: 15 minutter, med asynkron kommunikasjon først hvis teamet er distribuert. Gå gjennom hva som er gjort, hva som kommer, og hva som er blokkert.
- Ukentlig statusoppdatering: Et skriftlig sammendrag som sendes til interessentene, med fremdrift, risikoer og nødvendige beslutninger.
- Demoer annenhver uke: Vis fungerende programvare til interessentene. Dette er den raskeste måten å avdekke manglende samsvar på.
- Månedlig sammendrag for ledelsen: Én side, tre deler: Hvor vi er, hvor vi skal, og hva vi trenger.
Dette bør du unngå
Ikke la standup-møter bli statusmøter der alle rapporterer til prosjektlederen. Ikke send e-poster som krever et møte for å bli forstått. Og ikke vent med dårlige nyheter til den formelle oppfølgingen – ta opp problemer så snart de er tydelige, ikke når de allerede har gjort skade.
Ta beslutninger raskt og transparent
Langsomme beslutninger er blant de stilleste prosjektødeleggerne. Når teamet ikke vet hvem som kan godkjenne en beslutning, stopper arbeidet opp, det bygges inn omveier, og beslutningen tas som standard i stedet for etter en bevisst vurdering.
Bruk et beslutningsrammeverk
For eierskap på oppgavenivå fungerer RACI godt. For viktige prosjektbeslutninger som arkitekturvalg, reduksjon av omfang og forlengelse av tidsplanen foretrekker jeg DACI:
- Pådriver: Personen som driver beslutningen fremover.
- Godkjenner: Personen som har siste ord.
- Bidragsytere: Personer hvis innspill er nødvendig.
- Orienterte: Personer som trenger å kjenne utfallet.
Utpek en DACI for hver større beslutningstype før gjennomføringen starter. Du vil ikke måtte finne ut hvem som skal godkjenne en reduksjon av omfanget kl. 16.00 en fredag.
Før en beslutningslogg
En beslutningslogg er et enkelt dokument som registrerer hva som ble besluttet, hvem som besluttet det, og hvorfor. Dette høres byråkratisk ut, men det lønner seg i det øyeblikket en interessent stiller spørsmål ved en beslutning som ble tatt for tre sprinter siden. Dokumenter beslutninger i prosjektets samlingssted, og lenk dem til de relevante oppgavene eller milepælene.
Vit når du skal eskalere, og når du skal beslutte lokalt. Hvis en beslutning påvirker omfang, budsjett eller en avhengighet utenfor teamet ditt, skal du eskalere. Hvis den gjelder arbeidet i din egen arbeidsstrøm, tar du beslutningen og går videre.
Håndter risiko, avhengigheter og koordinering på tvers av team
Risikohåndtering handler ikke om å opprette et register og glemme det. Det handler om å identifisere hva som kan gå galt, beslutte hva du skal gjøre med det, og se etter signaler tidlig nok til å kunne handle.
Opprett et risikoregister som faktisk blir brukt
Start risikoregisteret under planleggingen, ikke etter at problemene har oppstått. Registrer følgende for hver risiko:
- Hva risikoen er
- Hvor sannsynlig den er (lav, middels, høy)
- Hva konsekvensen vil være hvis den oppstår
- Hva du skal gjøre for å redusere den
- Hvem som har ansvaret for risikoreduseringen
Gå gjennom det i de ukentlige oppfølgingsmøtene. Et risikoregister som bare åpnes når noe eksploderer, er et etterlevelsesdokument, ikke et styringsverktøy.
Kartlegg avhengighetene dine
Avhengigheter er der prosjekter blir flokete. Identifiser følgende før gjennomføringen starter:
- Interne avhengigheter: Arbeid som ett teammedlem eller én arbeidsstrøm må fullføre før en annen kan starte.
- Eksterne avhengigheter: Team eller leverandører utenfor prosjektet som du er avhengig av.
- Systemavhengigheter: Tredjeparts-API-er, infrastruktur eller data som løsningen din er avhengig av.
Legg inn tidsbuffere rundt eksterne avhengigheter. Etter min erfaring er disse den vanligste kilden til uplanlagte forsinkelser, fordi du ikke kontrollerer prioriteringene til det andre teamet.
Bygg relasjoner før du trenger dem
Hvis prosjektet ditt berører et annet teams kodebase eller systemer, bør du presentere deg før du trenger noe fra dem. En kort asynkron melding i starten av et prosjekt fører deg mye lenger enn en hastemelding i siste liten mot slutten.
Følg fremdriften og rapporter status ærlig
Fremdriftsoppfølging fungerer bare hvis dataene er ærlige og synlige. Et dashbord som alltid viser grønt, er verre enn ikke å ha noe dashbord i det hele tatt. Det forteller interessentene at alt er i orden, mens teamet i stillhet sakker akterut.
Velg måltall som gjenspeiler virkeligheten
Bruk disse måltallene for å få et tydelig bilde av prosjektets helsetilstand:
- Planlagt kontra faktisk hastighet: Fullfører dere arbeidet dere forpliktet dere til i hver sprint?
- Fullføringsgrad for milepæler: Blir de viktigste leveransene ferdige i tide?
- Antall åpne blokkeringer: Hvor mange aktive blokkeringer har teamet, og hvor gamle er de?
- Feilrate: Hvor mange feil oppdages i kvalitetssikringen sammenlignet med i produksjon?
- Interessenttilfredshet: En enkel temperaturmåling etter demonstrasjoner eller viktige milepæler.
Rapporter dårlige nyheter raskt
Når prosjektet er forsinket, må du si fra. Gi interessentene et tydelig bilde: hva som ble forsinket, hvorfor det ble forsinket, og hvilke alternativer som finnes. Ingen liker å høre dårlige nyheter. Men de misliker overraskelser enda mer.
En god statusoppdatering har tre deler: her står vi nå, dette har endret seg siden forrige oppdatering, og dette trenger vi fra deg. Hold den kortfattet, og knytt den til milepælene interessentene allerede kjenner.
Bygg inn testing, kvalitet og håndtering av teknisk gjeld
Kvalitet er ikke en fase på slutten av et prosjekt, men en praksis gjennom hele prosessen. Team som behandler testing som en siste port, leverer saktere og med flere feil enn team som bygger kvalitet inn i hver sprint.
Definer «ferdig» før du starter
Før den første sprinten begynner, må dere bli enige om hva «ferdig» faktisk betyr. En solid definisjon av ferdig omfatter vanligvis:
- Koden er gjennomgått og slått sammen
- Enhetstester er skrevet og består
- Integrasjonstester er bestått i et testmiljø
- Akseptansekriteriene er verifisert av QA
- Ytelsesmålene er nådd
- Dokumentasjonen er oppdatert
Uten dette betyr «ferdig» det utvikleren mente at det betydde.
Test i alle faser
Test tidlig, test ofte, og bruk uavhengige testere når du kan. QA-ingeniører oppdager andre ting enn utviklere fordi de nærmer seg produktet utenfra. Automatisert testing håndterer regresjoner. Manuell testing avdekker brukeropplevelsesproblemer som automatisering ikke finner.
Sett av kapasitet til teknisk gjeld
Den gjennomsnittlige organisasjonen sløser bort 23–42 % av utviklingstiden på grunn av teknisk gjeld (og den akkumuleres for hver sprint du ignorerer den).
Jeg vil foreslå å reservere 15–20 % av sprintkapasiteten til å redusere gjelden. Det betyr at dere planlegger refaktoreringsarbeid eksplisitt, i stedet for bare å håpe at det skjer. Følg opp gjeldspunkter i backloggen på samme måte som dere følger opp funksjoner. Når interessenter protesterer mot «vedlikeholdsarbeid», bør du sette det inn i en sammenheng med leveringshastighet: Uadressert gjeld gjør alle fremtidige sprinter langsommere.
Håndter endringsforespørsler og skiftende prioriteringer
Endring er garantert i alle programvareprosjekter. Målet er ikke å forhindre den, men å håndtere den uten at den ødelegger tidsplanen eller svekker teamets fokus.
Bruk en enkel endringskontrollprosess
Alle endringsforespørsler bør gjennomgå en rask vurdering før de legges inn i backloggen:
- Definer endringen: Hva er det konkret som etterspørres?
- Vurder konsekvensene: Hvordan påvirker den omfang, tidsplan og ressurser?
- Identifiser avveiningen: Hva blir nedprioritert eller forsinket hvis dette legges til?
- Få godkjenning fra riktig interessent: Bruk DACI her.
- Kommuniser utfallet: Fortell teamet og interessentene hva som ble besluttet, og hvorfor.
Dette trenger ikke å være et formelt skjema for endringsforespørsler. En Slack-tråd med en oppføring i beslutningsloggen er ofte nok.
Beskytt teamet mot kontekstbytte
Hyppige endringer i prioriteringer har en reell kostnad – ikke bare i form av tapt arbeid, men også tapt fokus. Når ledelsen endrer kurs midt i sprinten, bør standardreaksjonen ikke være å ta den nye prioriteten oppå eksisterende forpliktelser. Synliggjør avveiningen tydelig: «Vi kan starte på X nå, men Y blir forsinket til neste sprint. Skal vi fortsette?» Det er ikke motstand – det er åpenhet.
Ved reelt presserende endringer bør du vurdere å forhandle om omfanget midt i sprinten i stedet for å forlate alt pågående arbeid. Beskytt i det minste noe av teamets kapasitet slik at dere kan fullføre det som allerede er under arbeid.
Planlegg utrulling, lansering og overvåking etter lansering
Leveransen er ikke så mye målstreken som øyeblikket da risikoen blir reell. En lanseringsplan som avsluttes med «slå sammen til hovedgrenen», overser den mest avgjørende delen av leveransen.
Planlegg en trinnvis lansering
For alt som har betydelig innvirkning på brukerne, vil jeg foreslå en trinnvis utrulling fremfor en alt-på-en-gang-lansering. Funksjonsflagg lar deg eksponere en ny funksjon for en liten prosentandel av brukerne først, slik at du får reelle signaler før full utrulling. Hvis noe går galt ved 5 % utrulling, har du begrenset skadeomfanget.
Lag en plan for tilbakerulling før du distribuerer. Vit nøyaktig hva «angre» innebærer, enten det er å slå av et funksjonsflagg, rulle tilbake en database eller følge en bane for utrulling av en hurtigreparasjon. Team som ikke planlegger tilbakerulling, får det travelt når de trenger den.
Overvåk etter lanseringen
Definer overvåkingsperioden etter lansering før du setter løsningen i produksjon. Følg med på:
- Topper i feilfrekvensen: Uvanlig økning i unntak eller mislykkede forespørsler.
- Ytelsesforringelser: Endringer i svartid eller gjennomstrømming.
- Endringer i brukeratferd: Lavere engasjement eller konvertering i berørte flyter.
- Antall supportsaker: Økning i relaterte klager.
Sett opp varsler i overvåkingsverktøyene dine – Amazon CloudWatch, Datadog eller tilsvarende – før lansering, ikke etterpå.
Avslutt med en retrospektiv gjennomgang
Når støvet har lagt seg, gjennomfører du en retrospektiv gjennomgang med hele teamet. Gå gjennom hva som gikk bra, hva som ikke gikk bra, og hva dere ville gjort annerledes. Dokumenter resultatene, og ta dem frem i starten av det neste prosjektet. Teamene som forbedrer seg raskest, er de som behandler hvert prosjekt som en læringssyklus, ikke bare som en leveranse.
Ta deg tid til å anerkjenne det teamet har levert. Det betyr mer enn de fleste ledere tror.
Du er klar til å lede ditt neste programvareprosjekt
Når du har fått prosessen på plass, kan riktig prosjektstyringsprogramvare utgjøre forskjellen mellom en plan som ligger i et dokument, og en plan hele teamet faktisk arbeider ut fra – bruk denne veiledningen for å finne et verktøy som passer teamets størrelse, arbeidsflyt og integrasjoner før neste prosjekt starter.
