At holde projektet på rette spor er en fælles udfordring for mange teknologiske virksomheder, hvis primære fokus er rettidig og effektiv produktudvikling. Jeg læser dette mellem linjerne i regelmæssige samtaler med vores kunder og partnere. Jeg vil gerne dele en interessant historie med dig i håb om, at den også vil inspirere dig og hjælpe dig med at løse dine almindelige problemer i forbindelse med effektiv styring af softwareudviklingsprojekter.
Hvad er sagens kerne?
Her er nogle af de grunde, vi ofte hører:
- Vi arbejder på vores nye produkt/opstart, og time-to-market er afgørende for os og vores investor(er).
- Vi har vigtige udgivelser eller nye funktioner planlagt i pipelinen og har virkelig brug for at sende dem til tiden.
- Vi har planlagt udviklingspipelinen frem til slutningen af året og ønsker at have en behagelig situation i 4. kvartal, så vi undgår unødig travlhed og stress.
Som du kan se, er håndtering af projekt giver enhver teknisk chef hovedpine. De spørger ofte sig selv, hvordan de skal organisere udviklingsarbejdet. hold for at undgå forsinkelser og sikre, at alle de planlagte produkt funktioner udvikles gnidningsløst og rettidigt. Det er overflødigt at sige, at et potentielt "hul" og stagnation i udviklingen kan have smertefulde konsekvenser. Alt for optimistiske tidsplaner, mangel på udviklere, dårligt organiseret arbejde osv. kan føre til, at dit projekt kommer bagud i forhold til deadline.
MOSKVA-metoden
Lad os starte med en hurtig forklaring på, hvad MOSCOW-metoden helt præcist er. Det er en særlig prioriteringsteknik, der bruges i projektledelse og softwareudvikling at nå frem til en forståelse med interessenter (kunder eller medlemmer, der er involveret i et projekt) om den betydning, de tillægger leveringen af hvert krav.
Så jeg tror, at en god løsning for enhver teknisk leder er at genopfriske MOSCOW-metoden (med dens kategorier som 'skal', 'bør', 'kunne', 'vil ikke'). Implementeringen af de to første kategorier - 'skal' og 'kan' - er normalt vanskelig. Antallet af opgaver, der skal udføres - nogle gange med begrænsede menneskelige ressourcer, kommende deadlines eller andre forhindringer - er måske ikke gennemførligt.
Grundlæggende har virksomheder forskellige tilgange til at håndtere den slags problemer. God risikostyring er nøglen til at vende trusler til sejre. Lad mig præsentere et nyligt eksempel, der er relateret til emnet. For et par uger siden kontaktede en projektleder fra SaaS-produktvirksomheden mig om muligheden for at outsourcing tre softwareingeniører i en fast periode fra begyndelsen af oktober til slutningen af november. Det sker, at virksomheder i nogle perioder har brug for støtte fra flere udviklere på grund af antallet af opgaver, der skal udføres, og for at holde projektet i det ønskede udviklingstempo.
Den nævnte projektleder kom med ideen om at ansætte et dedikeret team af backend-ingeniører, da han vidste, at vores Teknisk stak matcher deres kerneprodukt. Vi startede projektet med en fleksibel og behagelig pay-as-you-go-model. Det krævede ikke mange lange møder, opkald eller underskrivelse af en bunke komplicerede kontrakter. Vi fik en klar idé om anmodningens art, og da vi vidste, at tiden var afgørende her, arrangerede vi opsætningen uden problemer, så redningsteamet var klar til at rulle.
Der er mange flere fordele ved at slå sig sammen med en teknisk partner, der er relevant for dine vækstplaner. Ekstern support er først og fremmest omkostningseffektiv (det sparer dig for op til 35% af dit budget). Udviklere, der slutter sig til din internt team bringer ofte ekstra viden og et nyt perspektiv ind i det gennemførte projekt. Takket være et sådant samarbejde eliminerer kunden risici og flaskehalse i forbindelse med deadlines, forsinkelser og en lang liste af afventende opgaver. For at vende tilbage til den omtalte MOSCOW-metode: Er tempoet i leveringen af opgaver i kategorierne 'skal' og 'bør' værd at gå på kompromis med?
Er det en løsning for dig?
Dette er vores perspektiv på, hvordan vi holder projekterne på sporet. Jeg er nysgerrig efter, om du har lignende erfaringer med dit ingeniørteams setup? Hvordan planlægger du arbejdsbyrden for vigtige funktioner i din pipeline i feriesæsonen? Hvilke andre metoder bruger og anbefaler du til andre tekniske chefer, så de kan få en god sommer, ikke kun når de er på ferie, men også mens de kører glat? produktudvikling? Lad mig vide det i en privat besked her.
God planlægning!
Læs mere om det: