Du vil stadig oppleve at så mange som 50% av utviklingsprosjektene for tilpasset programvare mislykkes. Dette eldgamle problemet er et mareritt for mange CTOer og tekniske ledere. På den annen side betyr forhåndsvarsel at du kan forberede deg selv og teamet ditt og minimere risikoen for å mislykkes.
I teknologibransjen vil du gjentatte ganger oppleve at så mange som 50-70% av *tilpasset programvareutviklingsprosjekter sluttfeil. Dette eldgamle problemet er et mareritt for mange CTO-er og tekniske ledere. På den annen side betyr forhåndsvarsel at du kan forberede deg selv og dine team og minimere risikoen for feil. Dette er en utfordring som alle utviklerteam står overfor, produkt designere og du - som leder - bør møtes.*
Jeg er ikke i tvil om at tilpasset programvare prosjekter er krevende, og du må ta vare på selv de minste detaljene for å lykkes. For å være ærlig, etter å ha sett på statistikken om dette emnet, er jeg forbløffet over omfanget av problemet. Selv innså jeg hvor viktig det var da jeg leste historiene om selskaper som hadde mislyktes i samarbeidet med teknologipartnere, eller som hadde mistet en prosjekt på grunn av en betydelig budsjett- eller fristoverskridelse.
Jeg begynte å lure på hvorfor det var slik. Jeg har flere års erfaring med tilpassede programvareutviklingsprosjekterDerfor var jeg spesielt interessert i dette temaet. Jeg bestemte meg for at jeg, basert på min egen erfaring, skulle identifisere alle de største truslene knyttet til *tilpasset programvareutviklingsom jeg nå skal dele med dere.*
Min personlige liste over de største utfordringene ved utvikling av tilpasset programvare
-
Språkbarriere. Dette er et av de vanligste problemene når folk leter etter en teknisk partner. Jeg er imidlertid ikke i tvil om at denne faktoren enkelt kan løses. Du trenger nemlig bare å velge en partner for programvareutvikling som kan garantere problemfri kommunikasjon. Flytende engelsk er obligatorisk. Det er et internasjonalt språk, og du kan ikke kommunisere ordentlig uten det. Tenk deg en situasjon der du ønsker å snakke med en utvikler om et problem eller en feil. Hvis det viser seg at den eneste personen som kan snakke engelsk, er en prosjektleder som ikke er en teknisk person, er det et problem. Du må vite at kommunikasjon med utviklere - for å være effektiv - må være veldig presis, noe som krever kunnskap om det engelske språket. Husk denne enkle regelen.
-
Dårlig kommunikasjon. Kommunikasjonsaspektet er til en viss grad knyttet til språkbarrieren. I tillegg til språket må du være overbevist om at det daglige samarbeidet er velorganisert. Etter min mening blir dette aspektet ofte oversett. Kompetansen til utviklingsteamet er kanskje en viktig del av jobben deres, men det er også kommunikasjonen med kunden. Dessuten - og det vet jeg av egen erfaring - hvis den gjensidige kommunikasjonsprosessen er godt styrt, går hele prosjektet mye mer effektivt, og du unngår unødvendige problemer, for eksempel forsinkelser.
-
Bryter tidsfrister. Dette er en svært vanlig situasjon, som du kanskje har opplevd selv. Det er svært vanskelig å anslå tidsrammer for programvareutviklingsprosjekter. Ofte er de innledende antakelsene helt feil. Manglende evne til å overholde tidsfrister kan påvirkes av mange faktorer, inkludert de jeg beskriver i denne artikkelen. Jeg tror at riktig metode for prosjektledelse spiller en stor rolle her. Anbefalinger? Definitivt Scrum.
-
Utilstrekkelig kunnskap. Programvareutviklingsprosjekter krever vanligvis bred kunnskap om teknologi. Dette er en stor utfordring med tanke på at teknologien er i stadig utvikling, og utviklerne må være oppdatert på alle nyheter. På dette punktet er det viktig at ditt eget team er oppdatert på teknologinyheter. Dette er ikke så opplagt som det kan virke, spesielt ikke når programvareutviklingsprosjektet er implementert internt av en liten gruppe utviklere. Det kan oppstå situasjoner der teamets kompetanse viser seg å være utilstrekkelig, noe som raskt kan føre til problemer og dermed til at prosjektet mislykkes.
-
En usammenhengende visjon. Forestill deg en situasjon der du innleder et samarbeid med en teknologipartner - for eksempel en programvarehus og snakker om dine behov. Du beskriver produktet du ønsker å lage i detalj. I begynnelsen ser alt ut til å gå på skinner. Etter hvert viser det seg imidlertid at din visjon er helt forskjellig fra partnerens. Dermed oppstår det et problem fordi arbeidet til teamet av utviklere og produktdesignere ikke lever opp til forventningene dine.
Jeg tror dette er et ganske vanlig problem. Noen ganger er det vanskelig å kombinere kundens visjon med "harde" løsninger som brukes av utviklere. I denne situasjonen er det definitivt nyttig med teknisk teamerfaring og myke ferdigheter. Det er viktig at den tekniske partneren din oppfyller forventningene dine, men som kunde må du være klar over at en bestemt løsning som programvareselskapet foreslår, faktisk kan vise seg å være mer effektiv. Husk dette.
-
Endringer i løpet av prosjektet. Når det gjelder IT-prosjekter, er scope creep (fra eierens side) og gold planting (fra PM, Scrum Master eller utviklere) de vanligste truslene. Ukontrollerte endringer i prosjektet, tilføyelse av ny funksjonalitet eller innføring av endringer faller utvilsomt inn under trusler som påvirker både effektiviteten og hastigheten i prosjektene. Den riktige måten å styre prosjektet på er å sørge for at den første nøkkelfasen er 100% nøyaktig, ettersom dette vil påvirke prosjektets senere suksess.
-
Utilstrekkelige midler til prosjektutvikling. Finansiering er i bunn og grunn en av de viktigste faktorene for at prosjektet ditt skal lykkes. Det er åpenbart. Men jeg vil gjerne rette oppmerksomheten mot et litt annet aspekt. Det er viktig at du har et garantert budsjett på lang sikt, og ikke bare for den utviklingsperioden som ble lagt til grunn helt i begynnelsen. Hvorfor er det så viktig? Grunnen er enkel. Det er svært ofte slik at utviklingstiden forlenges med opptil 20-30%. Dette må du ta hensyn til, slik at prosjektet ditt er økonomisk sikkert. På den måten minimerer du risikoen for at prosjektet fortsatt befinner seg i utviklingsfasen når budsjettunderskuddet begynner å vise seg. Dette er direkte relatert til en feil estimert prosjektvarighet.
-
Udefinerte trusler og svakheter. Før du starter prosjektet, vet du sannsynligvis at hele prosessen kanskje ikke er enkel. Du er sikkert enig med meg i at alle prosjekter er en utfordring. Derfor mener jeg at du bør analysere potensielle trusler og svakheter som kan påvirke sluttresultatet, før du setter i gang. Det er viktig å håndtere slike trusler på riktig måte helt fra begynnelsen.
Sammendrag
Jeg vil ikke foreslå hvilke av truslene som er nevnt ovenfor som er de vanligste. Jeg tror ikke det finnes noen regel for dette - alt avhenger av prosjektets detaljer. Men hvis du står overfor utfordringen med å gjennomføre ditt eget prosjekt, bør du huske på det jeg har skrevet her. Jeg tror at det å ta hensyn til problemene jeg beskriver kan være en veiledning for deg, som indikerer hva du ikke skal gjøre og hvordan du skal håndtere en trussel. Alt dette for ikke å bli et offer for brutal statistikk, men heller fullføre prosjektet.
Og det er det jeg ønsker for deg. Hvis du har spørsmål knyttet til utvikling av tilpasset programvarevennligst kontakt meg. Jeg vil gjerne svare på dem alle.
Les mer om dette:
Hvorfor er det verdt å ha et vekstteam med ansvar for forretningsutvikling? Casestudie av Codest
Hvordan finne et marked som passer for produktet ditt?