{"id":3504,"date":"2019-11-18T00:00:00","date_gmt":"2019-11-18T00:00:00","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/problems-with-keeping-your-project-on-the-right-track\/"},"modified":"2026-04-28T14:03:40","modified_gmt":"2026-04-28T14:03:40","slug":"problemer-med-a-holde-prosjektet-pa-rett-spor","status":"publish","type":"post","link":"https:\/\/thecodest.co\/nb\/blog\/problems-with-keeping-your-project-on-the-right-track\/","title":{"rendered":"Programvareutvikling til rett tid: Strategier og innsikt"},"content":{"rendered":"

Hva er sakens kjerne?<\/strong><\/h2>\n

Her er noen vanlige \u00e5rsaker vi ofte h\u00f8rer:<\/p>\n

    \n
  1. Vi jobber med v\u00e5rt nye produkt\/oppstart, og time-to-market er avgj\u00f8rende for oss<\/a> og v\u00e5r(e) investor(er).<\/li>\n
  2. Vi har viktige utgivelser eller nye funksjoner p\u00e5 trappene, og vi har et stort behov for \u00e5 levere dem i tide.<\/li>\n
  3. Vi har planlagt utviklingspipeline frem til slutten av \u00e5ret og \u00f8nsker \u00e5 ha en komfortabel situasjon i 4. kvartal, slik at vi unng\u00e5r un\u00f8dvendig hastverk og stress.<\/li>\n<\/ol>\n

    Som du kan se, er det \u00e5 administrere prosjekt<\/a> er en hodepine for enhver teknisk leder. De sp\u00f8r seg ofte hvordan de skal organisere arbeidet til utviklingsteam<\/a> for \u00e5 unng\u00e5 forsinkelser og s\u00f8rge for at alle planlagte produkt<\/a> funksjoner utvikles jevnt og i tide. Det sier seg selv at et potensielt \"gap\" og stagnasjon i utviklingen kan f\u00e5 smertefulle konsekvenser. Altfor optimistiske tidsplaner, mangel p\u00e5 utviklere, d\u00e5rlig organisert arbeid osv. kan f\u00f8re til at prosjektet kommer p\u00e5 etterskudd i forhold til tidsfristen.<\/p>\n

    \"Programvareprosjekt\"<\/p>\n

    MOSKVA-metoden<\/strong><\/h2>\n

    La oss starte med en rask forklaring av hva MOSCOW-metoden egentlig er. Det er en spesiell prioriteringsteknikk som brukes i prosjektledelse<\/a> og programvareutvikling<\/a> \u00e5 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.<\/p>\n

    Jeg tror derfor at en god l\u00f8sning for alle teknologisjefer er \u00e5 sette seg inn i MOSCOW-metoden (med kategorier som \"m\u00e5\", \"b\u00f8r\", \"kan\" og \"vil ikke\"). Gjennomf\u00f8ringen av de to f\u00f8rste kategoriene - \"m\u00e5\" og \"kan\" - er vanligvis vanskelig. Det kan v\u00e6re umulig \u00e5 gjennomf\u00f8re s\u00e5 mange oppgaver - noen ganger med begrensede menneskelige ressurser, kommende tidsfrister eller andre hindringer.<\/p>\n

    I utgangspunktet har bedrifter ulike tiln\u00e6rminger til \u00e5 h\u00e5ndtere denne typen problemer. God risikostyring er n\u00f8kkelen til \u00e5 snu trusler til seire. La meg presentere et ferskt eksempel knyttet til temaet. For noen uker siden ble en prosjektleder fra SaaS<\/a> produktselskap kontaktet meg om muligheten for \u00e5 outsourcing<\/a> tre programvarer Ingeni\u00f8rer<\/a> for en fast periode fra begynnelsen av oktober til slutten av november. Det hender at selskaper i enkelte perioder trenger st\u00f8tte fra flere utviklere p\u00e5 grunn av antall oppgaver som skal utf\u00f8res og for \u00e5 holde prosjektet i \u00f8nsket utviklingstempo.<\/p>\n

    Den nevnte prosjektlederen kom opp med ideen om \u00e5 ansette en dedikert team<\/a> av backend-ingeni\u00f8rer, som kjenner v\u00e5re teknisk stabel<\/a> matcher kjerneproduktene deres. Vi startet prosjektet med en fleksibel og komfortabel pay-as-you-go-modell. Det krevde ikke mange lange m\u00f8ter, samtaler eller signering av en haug med kompliserte kontrakter. Vi fikk en klar id\u00e9 om hva foresp\u00f8rselen gikk ut p\u00e5, og siden vi visste at tiden var avgj\u00f8rende her, ordnet vi opplegget p\u00e5 en smidig m\u00e5te, slik at redningsteamet var klart til \u00e5 sette i gang.<\/p>\n

    Det er mange flere fordeler med \u00e5 sl\u00e5 seg sammen med en teknologipartner som er relevant for vekstplanene dine. Ekstern st\u00f8tte er f\u00f8rst og fremst kostnadseffektivt (det sparer deg for opptil 35% av budsjettet). Utviklere som slutter seg til din internt<\/a> teamet tilf\u00f8rer ofte ekstra kunnskap og et nytt perspektiv p\u00e5 det gjennomf\u00f8rte prosjektet. Takket v\u00e6re et slikt samarbeid eliminerer kunden risikoer og flaskehalser knyttet til tidsfrister, forsinkelser og en lang liste med oppgaver som ligger p\u00e5 vent. For \u00e5 komme tilbake til den nevnte MOSCOW-metoden: Er det verdt \u00e5 g\u00e5 p\u00e5 akkord med tempoet i leveringen av oppgaver i kategoriene \"m\u00e5\" og \"b\u00f8r\"?<\/p>\n

    \"Programvareutviklingsteam\"<\/p>\n

    Er det en l\u00f8sning for deg?<\/strong><\/h2>\n

    Dette er v\u00e5rt perspektiv p\u00e5 hvordan vi holder prosjektene p\u00e5 sporet. Jeg er nysgjerrig p\u00e5 om du har lignende erfaringer med oppsettet til ingeni\u00f8rteamet 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\u00e5 en god sommer, ikke bare n\u00e5r de er p\u00e5 ferie, men ogs\u00e5 mens de kj\u00f8rer jevnt og trutt? produktutvikling<\/a>? Gi meg beskjed i en privat melding her.<\/p>\n

    God planlegging!<\/p>\n

    Les mer om dette:<\/strong><\/p>\n