Å holde prosjektet på rett spor er en vanlig utfordring for mange teknologibedrifter som først og fremst er opptatt av rask og effektiv produktutvikling. Jeg leser dette mellom linjene i regelmessige samtaler med kundene og partnerne våre. Jeg vil gjerne dele en interessant historie med deg i håp om at den kan inspirere deg og hjelpe deg med å løse de vanligste problemene knyttet til effektiv styring av programvareutviklingsprosjekter.
Hva er sakens kjerne?
Her er noen vanlige årsaker vi ofte hører:
- Vi jobber med vårt nye produkt/oppstartsbedrift, og tiden til markedet er avgjørende for oss og investorene våre.
- Vi har viktige utgivelser eller nye funksjoner på trappene, og vi har et stort behov for å levere dem i tide.
- Vi har planlagt utviklingspipeline frem til slutten av året og ønsker å ha en komfortabel situasjon i 4. kvartal, slik at vi unngår unødvendig hastverk og stress.
Som du kan se, er det å administrere prosjekt er en hodepine for enhver teknisk leder. De spør seg ofte hvordan de skal organisere utviklingsarbeidet team for å unngå forsinkelser og sørge for at alle planlagte produkt funksjoner utvikles jevnt og i tide. Det sier seg selv at et potensielt "gap" og stagnasjon i utviklingen kan få smertefulle konsekvenser. Altfor optimistiske tidsplaner, mangel på utviklere, dårlig organisert arbeid osv. kan føre til at prosjektet kommer på etterskudd i forhold til tidsfristen.
MOSKVA-metoden
La oss starte med en rask forklaring av hva MOSCOW-metoden egentlig er. Det er en spesiell prioriteringsteknikk som brukes i prosjektledelse og programvareutvikling å komme til enighet med interessenter (kunder eller medlemmer som er engasjert i et prosjekt) om hvor viktig de mener det er at hvert krav oppfylles.
Jeg tror derfor at en god løsning for alle teknologisjefer er å sette seg inn i MOSCOW-metoden (med kategorier som "må", "bør", "kan" og "vil ikke"). Gjennomføringen av de to første kategoriene - "må" og "kan" - er vanligvis vanskelig. Det kan være umulig å gjennomføre så mange oppgaver - noen ganger med begrensede menneskelige ressurser, kommende tidsfrister eller andre hindringer.
I utgangspunktet har bedrifter ulike tilnærminger til å håndtere denne typen problemer. God risikostyring er nøkkelen til å snu trusler til seire. La meg presentere et nylig eksempel knyttet til temaet. For noen uker siden ble jeg kontaktet av en prosjektleder fra et SaaS-produktselskap om muligheten for å outsourcing tre programvareingeniører i en fast periode fra begynnelsen av oktober til slutten av november. Det hender at selskaper i enkelte perioder trenger støtte fra flere utviklere på grunn av antallet oppgaver som skal utføres og for å holde prosjektet i ønsket utviklingstempo.
Den nevnte prosjektlederen kom opp med ideen om å ansette et dedikert team av backend-ingeniører, vel vitende om at vår teknisk stabel matcher kjerneproduktene deres. Vi startet prosjektet med en fleksibel og komfortabel pay-as-you-go-modell. Det krevde ikke mange lange møter, samtaler eller signering av en haug med kompliserte kontrakter. Vi fikk en klar idé om hva forespørselen gikk ut på, og siden vi visste at tiden var avgjørende her, ordnet vi opplegget på en smidig måte, slik at redningsteamet var klart til å sette i gang.
Det er mange flere fordeler med å slå seg sammen med en teknologipartner som er relevant for vekstplanene dine. Ekstern støtte er først og fremst kostnadseffektivt (det sparer deg for opptil 35% av budsjettet). Utviklere som slutter seg til din internt teamet tilfører ofte ekstra kunnskap og et nytt perspektiv på det gjennomførte prosjektet. Takket være et slikt samarbeid eliminerer kunden risikoer og flaskehalser knyttet til tidsfrister, forsinkelser og en lang liste med oppgaver som ligger på vent. For å komme tilbake til den nevnte MOSCOW-metoden: Er det verdt å gå på akkord med tempoet i leveringen av oppgaver i kategoriene "må" og "bør"?
Er det en løsning for deg?
Dette er vårt perspektiv på hvordan vi holder prosjektene på sporet. Jeg er nysgjerrig på om du har lignende erfaringer med oppsettet til ingeniørteamet ditt? Hvordan planlegger dere arbeidsmengden for viktige funksjoner i pipelinen i ferietiden? Hvilke andre metoder bruker du og anbefaler andre tekniske ledere, slik at de kan få en god sommer, ikke bare når de er på ferie, men også mens de kjører jevnt og trutt? produktutvikling? Gi meg beskjed i en privat melding her.
God planlegging!
Les mer om dette: