Kriterier for å lykkes med utviklingsprosjekter i 2022

‍
Hvordan planlegger du egentlig et vellykket utviklingsprosjekt i moderne tid? Hvordan kan du levere utvikling av høyere kvalitet, raskere? Basert på vår erfaring i 2022 har vi laget en guide til hva du bør tenke på for et vellykket forløp.

‍‍‍

‍

Suksesskriteriene for å lykkes med utviklingsprosjekter er målbare faktorer. Ved å følge retningslinjer vil interessenter ha muligheten til å evaluere prosjektet, og avgjøre om ønskede resultater ble oppnådd.

Generelt er prosessen rundt programvareutvikling kompleks, men uavhengig av hvor enkelt eller komplekst prosjektet er, kreves det en effektiv prosjektplan. For å utvikle et vellykket utviklingsprosjekt er det avgjørende å ha en klar visjon og forståelse av hva man ønsker å oppnå. Uansett om du bruker en tradisjonell 'waterfall'-metodikk eller en mer moderne 'agile'-metodikk vil det være utfordrende å nå målet, og dersom ikke alle i prosjektet deler en klar visjon fra starten av så kommer man fort på avveie.

‍

Vellykkede utviklingsprosjekt - den gamle ‘waterfall’-metodikken

‍

‍

Enkelt fortalt er waterfall-metodikken en lineær og sekvensiell tilnærming til prosjektledelse, som pre-definerer mål for hvert trinn i prosjektets utviklingssyklus. Denne modellen er oppkalt etter måten hver fase av prosjektet flyter inn i den neste som et fossefall.

Det vil være forretningsutviklere og prosjektledere som klamrer seg til tidligere vellykede prosjektgjennomføringer, og fremdeles sverger til vannfallsmetodikken. Disse vil i tradisjon tro starte med det kommersielle (budsjett, kostnad, forhåndsplanlegging, forhåndsdokumentasjon/design, forhåndsdefinert tidslinje, omfang, osv), og jobbe seg nedover prioriteringslisten ved hjelp av overlevering etter endte faser - ‘du begynner etter jeg er ferdig’.
Denne tradisjonelle metoden er svært avhengig av instruksjoner og kontroll. Denne metoden har vært en effektiv måte å gjennomføre prosjekter på gjennom hele den industrielle revolusjon, og helt frem til internettets ankomst. Etter internettets ankomst er mer moderne og flytende tilnærminger til prosjektgjennomføring blitt introdusert.
‍
I dagens fartsfylte verden er det en utfordring å tilpasse den tradisjonelle metodikkens tilnærming. Innen du har fullført den første oppgaven din, f.eks dokumentasjon, har markedet endret seg, eller konkurrentene dine har gitt ut sin versjon. Dette gjør at du må endre designet ditt, som igjen betyr at du går tilbake til dokumentasjonen og deretter mest sannsynlig endre eksisterende kode.

Det er ikke noe feil med vannfallsmetodikken i seg selv,  det er fortsatt tid og sted for denne gjennomføringsmåten i, f.eks oppdragskritiske systemer der liv gjerne står på spill (flyavionikk, bilkontrolldatamaskiner, medisinske systemer, trafikklys m.m.). Disse systemene kan ikke svikte, ikke en eneste gang, men de er ekstremt kostbare, og det med rette.
‍

Nøkkelfaktorer for å sikre suksess i utviklingsprosjekter

‍

Samle kravspesifikasjon

“Less is more” når det kommer til krav for smidige (agile) prosjekter. Innsamling av krav er hjørnesteinen i ethvert utviklingsprosjekt. Utvikling som ikke tilfredsstiller kundens krav, regulatoriske krav, øker verdien av løsningen eller samsvarer med deres forretingsprossessflyt er resultat av dårlig kravhåndtering. Det er omfattende lister og forklaringer av individuelle programhandlinger.

Kravene er delt inn i to brede kategorier; funksjonelle og ikke-funksjonelle. Funksjonelle er krav som rapportering, interaksjon med brukere, pålogging m.m. Ikke-funksjonelle er krav som sikkerhet, databaseskjema og lagringskrav. Dette bør gjøres i samråd med forbruker. Det er derfor utvikling ofte starter med forretningsflyter hvor hvert enkelt steg i flytene spesifiseres og registreres.

‍

Planlegging

Smidige prosjekter begynner med forhåndsplanlegging. Et prosjekt gjennomført med smidig metodikk starter med en prosjektvisjon og et produktveikart som forteller hvilke funksjoner som ønskes inn og hvor viktige disse er. Hver funksjon beskrives i detalj ift. hva brukeren kan foreta seg i løsningen (innlogging gjennom sosiale medier, betaling med Vipps/Visa, ta bilde, skanne QR kode osv.). Forhåndsplanleggingen tar også høyde for forretningsmål og strategi. På dette stadiet diskuterer vi ikke implementasjon pr. platform eller design. Implementasjonsforslag kommer fra eksperter på f.eks. mobilutvikling og design i fellesskap. Et typisk endringsønske er “en ny knapp som sender en rapport på epost”. Ved å grave i det egentlige behovet så kan kanskje dette løses ved enkle integrasjoner mot andre løsninger i stedet for å lage løsninger som krever manuelle prosesser. 
‍

Planlegg releaser og iterasjoner. Utviklerne kan velge å frigi hver iterasjon til kunden, eller gruppere flere iterasjoner i én og samme release. Så snart alle oppgaver tilhørende en funksjonalitet er spesifisert, designet og gjennomgått med utviklingsteamet, så kan man starte å planlegge releaser basert på tidsestimater.
‍

• Dette sikrer at hver iterasjon kan fullføres innenfor tidsrammen som er spesifisert i produktbacklogen
• Hver utgivelse tilfører løsningen noe som alene har verdi for kunden
• Datoene for utgivelsesmilepælene og det endelige produktet kan bestemmes ved hjelp av denne utgivelsesplanen.
• Den totale prosjektkostnaden bestemmes av antall iterasjoner og arbeidstimene til teamet. Utgifter til overhead og materiell kommer i tillegg.
  ‍
  

Smidig prosjektplanlegging hjelper å prioritere de nært forestående iterasjonene. Prosjektteamet møtes jevnlig for å planlegge de neste iterasjonene. Uklarheter og mangler blir belyst og spørsmål fra alle deltakere skal kunne besvares. Teamet blir oppdatert på produkt-backlogen og prosjektets videre prioriteringer i starten av møtet. Utviklingsteamet velger oppgaver fra backlog som hører til én og samme iterasjon og kan leveres selvstendig samt tilføre løsningen verdi..Teamet estimerer oppgavene i fellesskap og bestemmer så hvilke roller ulike team-medlemmer skal ha på de ulike oppgavene.

‍

Kommunikasjon

I starten av et prosjekt er effektiv kommunikasjon spesielt viktig.
Kunde bør tydelig kommunisere sine produktkrav og visjoner. Det bør sikres at alle kundens ønsker samsvarer med overordnede mål og KPIer. Ved å ha gode spesifikasjoner og komplett overordnet design, som samsvarer med kundens ønsker,  sikrer en at utviklingsteamet bygger akkurat det man ønsker.

Definér tydelig arbeidsomfang slik at alle har god forståelse av kompleksitet for det som skal utvikles. Tydelig kommunikasjon fra start øker sannsynligheten for et vellykket prosjekt. 

En klar og konsistent avtale bidrar til å unngå forvirring og reduserer forsinkelser og feil i prosjektet. Kommunikasjon er viktig i alle faser av prosjektet, og det bør være en dedikert kommunikasjonskanal for å bedre kommunisere og forstå oppdateringer, bekymringer og suksesskriterier.

‍

Teamet

Teamstørrelse er en avgjørende faktor i et teams produktivitet. Teamstørrelsen vil bli bestemt av metoden som brukes, prosjektets kompleksitet, budsjett, ressurser og tidsfrister.

Roller og oppgaver: Tydelig definering av individuelle roller, grupperoller og ansvar gir effektiv vekst og øker teamets åpenhet. Det hjelper til å vite hvem man skal kontakte i ulike scenario, og at kunden vet hvem som skal kontaktes dersom det er flere kontaktpunkter i prosjektets livsfase. Målet for utviklingsprosessen vil også sterkt påvirke sammensetningen av teamet ditt. 

Ansett de rette menneskene: Til slutt vil kvaliteten på utviklingsteamet du bygger avgjøre prosjektets suksess. Å velge de riktige teammedlemmene øker sjansene dine for å bringe din visjon til virkelighet.For å bygge et godt team av talentfulle utviklere er en klar og velstrukturert rekrutteringsstrategi avgjørende. Når du intervjuer søkere bør du være like oppmerksom på deres personlighetsegenskaper og evne til å passe inn i bedriftens kultur som deres evne til å gjennomføre en tiltenkt oppgave. Under følger noen anbefalte egenskaper du bør se etter når du ansetter utviklingsressurser:

• Smarte hoder med riktig holdning: Ingenting er bedre enn å jobbe med personer som hele tiden er glad for å samarbeide og produsere fremragende arbeid. En god holdning på jobben øker produktivitet, letter mellommenneskelige relasjoner og reduserer unødvendige tvister. At kandidaten kan tenke nytt og tar initiativ på jobben bør også være et kritisk vurderingskriterium for å avgjøre om den enkelte er den riktige eller ikke.
• Samarbeid: God kommunikasjon påvirker effektiviteten av utviklingen,  og samarbeidet mellom teammedlemmer. For å dele erfaringer og lytte til kollegers innspill trenger man gode kommunikasjonsevner og sterke teknologiske evner. 
• Tilpasningsevne og læringsiver: Flinke utviklere er ofte genuint interessert i faget, og kontinuerlig på utkikk etter nye teknologier og muligheter for å utvide sin ekspertise og kompetanse. Tilpasningsdyktighet til bedriftskultur og arbeidsmiljø er også viktige egenskaper.
  ‍

‍

Utvikling av prosedyrer og hvordan følge dem:

Design & Prototyping 

Produktkravene som et team har ved starten av designprosessen kan endres under produktutviklingen. Bruk kostnadseffektive metoder for å få designidéer foran kundene tidlig i designprosessen. Gjenta raske design- og testsykluser for å definere brukerbehov, prioritere user-stories og la brukerne teste de innovative ideene dine. Å ha kortere tidsrammer før en utgivelse bidrar også til å holde teamene fokusert under den smidige prosessen.
‍
Her er syv grunnleggende prinsipper for å lykkes med å ta i bruk smidig produktdesignmetodikk:
‍

• Tilgjengelige ledere - Ledere som verdsetter arbeidet rundt brukeropplevelse har en tendens til å gjøre følgende:
  ‍
  -  inkludere ux-designere i tidlig prosjektplanlegging, og lytte til designutøverne.
  -  Redusere uventede forespørsler; mangelen på planlagt backlog påvirker sprintplanlegging, og til syvende og sist lagets ytelse. Med Agile har ledelse en tendens til å ikke forstyrre planlagte aktiviteter (etter beste evne).
  - Ta høyde for og gi tid til brukerundersøkelser og testing. Involverte ledere mener at gode brukerundersøkelser fører til bedre produkt med tid og ressurser.
  ‍
  
• Teamet må være multifunksjonelt - Designere jobber sammen med andre teammedlemmer (utviklere, markedsførere, m.fl.) Dette fremmer teamarbeid og eierskap til prosjektet.
• En godt administrert produkt backlog og prosjektplanlegging er avgjørende - En produkt backlog viser funksjoner et team håper å inkludere i et sluttprodukt. Smidige produktdesignere må nøye prioritere backlogen. Alle oppgaver bør få en verdi eller score av brukerne deres. Individuelle oppgaver kan dra nytte av å bruke verktøy som brukerpersonas og empatikart. Når produktdesignere tydelig definerer målgruppens behov og ønsker, blir det mye lettere å identifisere funksjoner som gir dem verdi. 
• Det er presise estimater for når neste utgivelse vi skjer -  Det er avgjørende å estimere både tiden som kreves for å designe funksjoner (designteamets innsats) og tiden som kreves for å kode disse funksjonene (innsatsen til utviklingsteamet).
• Det er presise estimater for når neste utgivelse vi skjer -  Det er avgjørende å estimere både tiden som kreves for å designe funksjoner (designteamets innsats) og tiden som kreves for å kode disse funksjonene (innsatsen til utviklingsteamet).
• Designprosessen støttes av research og testing - Noe som betyr at designteamet kan bruke så lite tid som mulig på brukerundersøkelser og testing, samtidig som de kan dra stor nytte av arbeidet lagt ned på forhånd. Brukerintervjuet og feltundersøkelser er til stor hjelp her.
• Design og utvikling er iterative prosesser - Inkrementelle prosesser. Med andre ord bør store produktreleaser (milepæler) deles inn i mindre, mer håndterbare deler. Iterativt validerte produkter er designet for å møte behovene til brukere og virksomheter.
• Konstant kommunikasjon er nøkkelen

‍

Utvikling & koding

Den foregående fasens design fungerer som systemets blåkopi, og leverer mye av informasjonen som kreves av utvikleren. Utvikleren vil oversette design til kode. Feilsøking er med i prosessen med å finne og rette kodefeil. De fleste programmeringsspråk støtter i dag kompilering av en “debug”-versjon. Utviklerne benytter debug-versjonene til å gjennomgå koden, opprette bruddpunkter, inspisere variabelverdier og får feilsøkingsinformasjon om koden.

Selv om programvareutvikleren er “designeren”, er det viktig å ha et så presist design som mulig for å unngå små feil som igjen kan føre til store feil. Under kodefasen er det viktig at man er åpen for å møte kunden dersom det er nødvendig med avklaring eller foredling av et krav. Etter at koden er stabil kompileres den og brukes til systemtesting.

‍

Måling av suksess og sporing av fremgang

Beregninger bør i hovedsak sees på som et verktøy for å teste hypoteser som både støtter et spesifikt mål, og gir svar som hjelper til med å fremme forbedringer. Husk at det ikke er verdt å måle om du ikke kan gjøre noe med dataene.

Prosjektanalyse, også kjent som utviklingsanalyse, er kritiske verktøy for å identifisere og fjerne potensielle eller eksisterende veisperringer i løpet av utviklingens livssyklus. Du kan ikke administrere prosjektet effektivt uten disse målingene, de hjelper deg å samle inn og anvende verdifulle data. Du må definere programvareberegninger for å måle og overvåke ytelse. Disse beregningene bør etableres ved starten av prosjektets utvikling for å sikre en jevn og konsistent arbeidsflyt.Suksess kan måles på en rekke måter: samsvar med prosjektmål, overholdelse av innledende krav, eller verdien som skapes av sluttproduktet for din bedrift og dens kunder. Utfordringen er at “verdi” eller “kvalitet” kan måles på en rekke måter, inkludert brukervennlighet, pålitelighet, strukturell integritet og så videre. Måling av fremgang i et IT-prosjekt er avgjørende for både kunde og utviklingsteamet. Av åpenbare grunner ønsker kunde å vite hvordan ting går, men det hjelper også utviklere med å fokusere og prioritere. Dette øker teaminvolvering og ansvar for sluttresultatet.
‍

Testing & kvalitetskontroll

Kvalitetssikring (QA) er en metode for å overvåke utviklingsprosessene i gjennomføringen. Eksempler på modeller for testing er ISO 9000, eller Capability Maturity Model Integration (CMMI). I noen tilfeller brukes selve programvaren til å fikse feil.

‍

Deployment til produksjon 

En distribusjonsplan forutser handlinger etter levering. Denne distribusjonsplanen hjelper deg med å bedre forstå hvordan gjennomføringen vil utfolde seg i sanntid og hvordan man både kan forutse og håndtere potensielle konflikter. Under følger et par ting du bør vurdere før du starter med distribusjonsplanen. Disse vil hjelpe deg med å planlegge og gjennomføre prosjektet mer effektivt.

Begynn med sluttbrukeren - Når du distribuerer programvare må brukervennligheten vurderes, og du bør gjøre dette før du lanserer til offentligheten. Å få tilbakemeldinger fra brukere som ikke har vært involvert i utviklingsprosessen hjelper til med å finne feil før de forårsaker misfornøyde kunder. Det er også verdt å merke seg at det bare er utvalgte personer som får være med i denne gruppen av sluttbrukere. Vi ønsker ikke å distribuere tjenesten til for mange nettopp fordi det genererer mer støy enn nødvendig. Å kommunisere med sluttbruker betyr å kommunisere før lansering. Minn dem på at dette er et nytt produkt som kanskje må fikses. Oppmuntre dem til å være tålmodige når den nye tjenesten lanseres, og inviter dem til å gi deg verdifulle tilbakemeldinger.
Ha din versjon i bakhodet - Du vil sannsynligvis gå gjennom flere versjoner av produktet ditt etter produktlanseringen. Versjonskontroll i prosjekssyklusstyring sørger for dette. Både eksterne dokumenter (f.eks oppdatering av programvareveiledningen) og interne dokumenter (f.eks logg over kodeendringer for neste versjon) kan inkluderes her.
Er endringer verdt det? - “Ikke fiks det som ikke er ødelagt”, eller “ikke fiks det som fungerer”. Å lage nye produkter, eller endre eksisterende kan være en stor oppgave med utilsiktede konsekvenser som skaper nye feil for kundene dine. En bør i planlegging av programvaredistribusjon vurdere om en oppdatering er verdt bryet eller ikke. Fokusér på å gjøre riktige prioriteringer som tar produktet fremover, og som gir sluttkunden verdi. Jobb med å holde kompleksiteten nede.

‍

Vedlikehold og support

Så du har lansert ditt produkt. Drifts- og vedlikeholdsrutinene starter. Feilrettinger, brukerassistanse og funksjonalitetsforespørsler er eksempler på støttetjenester, mens patcher og dataoppdatering er eksempler på vedlikehold. Det er viktig å skille disse. Bestem, gjerne sammen med kunden, kundens behov for vedlikehold og støtte. Mange typer vedlikehold og support er tilgjengelig avhengig av selve produktet, og kundens behov. Å forhindre vedlikeholds- og supportproblemer er avgjørende for å holde alle parter fornøyde og treffe på forventninger i henhold til det som er på forhånd avtalt.
‍

Kriterier for å bygge vellykkede utviklingsprosjekt i 2022 - Vår utprøvde Agile-metodikk 

Vi har spurt Mark, vår eksisterende Lead Scrum Master i Seven Peak Software om hva han tenker er de mest kritiske punktene for å gjennomføre et vellykket utviklingsprosjekt.
‍
I smidig utviklingsmetodikk er man ikke like opptatt av tidslinjer, kostnader, planlegging, analyser og forhåndsskrevne krav, sier han. Smidig utvikling er opptatt av å levere størst mulig verdi til sluttbrukeren, til enhver tid. For en “Agilist” vil de 10 viktiste kriteriene for et vellykket prosjekt være følgende:
‍

• Åpenhet: Alle (inkludert kunden) må til enhver tid være klar over hva alle andre gjør. Dette er vanligvis skjult for kunden i en vannfalls-metodikk.
• ‍Inspeksjon: I slutten av hver sprint undersøker vi hvordan vi fullførte oppgaven, og ser etter måter å forbedre prosessen på. Vi definerer beregninger for å kvantifisere effektivitet.
• Tilpasning: Etter hver inspeksjon teamer vi nye prosesser (eller variasjoner av bruken deres). Hvis de fungerer beholder vi dem, hvis ikke de gjør det, skroter vi dem og prøver noe annet neste sprint.
• Agile kunde: Man er avhengig av at også kunde forstår Agile-metodikk, og helst ønsker eller allerede benytter denne arbeidsmetodikken selv. Dersom dette ikke er tilfelle vil prosjektet ofte kun kjøre i en kort periode, og deretter mislykkes - eller en blir presset til å kjøre en vannfalls-metodikk fra starten, og i verste fall er markedet endret eller konkurrentene bedre når prosjektløpet er ferdigstilt. I Agile-metodikk sikter man ikke mot perfeksjon ut av startblokken, men heller mot å være gode nok, så raskt som mulig.
• Agile selskap: Videre må selskapet forstå og støtte Agile-metodikk. I utgangspunktet vil et nytt selskap mest sannsynlig være for lite til å velge ut sine kunder, og vil i stedet fokusere på vannfalls-prosjekter for å skape volum. Senere i livssyklusen bør man derimot tilpasse seg for å så mye som mulig arbeide med agile-metodikk i kundeengasjement. Den kommersielle siden av selskapet bør finne kunder og prosjekter der en kan benytte agile-metodikk, samtidig som at vannfalls-prosjekter reserveres kun for oppdragskritiske systemer.
• Tillit: Vi stoler på at alle involverte er profesjonelle aktører som vil utføre oppgaven de er trent til så effektivt som mulig. Når en ber om et estimat fra en utvikler, stoler både kunde og en selv på den verdien som tilbys. Under en vannfalls-metodikk, hvis en utvikler indikerer at noe vil ta to måneder å gjennomføre, er det dessverre vanlig at en prosjektleder eller kommersiell rolle enten øker eller reduserer tidsestimatet, avhengig av hvilken kommersiell posisjon man står i.
• Kvalitet: Vi vil aldri gå på akkord med kvalitet for funksjonalitets skyld. Aldri. Fordi programvare per definisjon har potensialet til å være buggy, ønsker vi ikke å ta snarveier.
• ‍Kompetent produkteier: Produkteier er den mest sentrale rollen i et Scrum-prosjekt (les om hva forskjellen på en produkteier og prosjektleder er her).
  Denne stillingen er relativt ny (ca 20 år gammel), og erfaring tilsier at det har vært mangel på kompetente produkteiere. Mange selskaper utformer ganske enkelt produkteiers ansvar overfor prosjektleder, noe som er feil. Tradisjonelle prosjektledere har noen ganger vist seg å være en dårlig produkteier, ofte fordi den tradisjonelle prosjektleder er opplært under vannfalls-metodikk og ledelse, og det er en utfordring å kvitte seg med gamle vaner og tidligere suksessfull erfaring med prosjektgjennomføring. 
• Scrum utviklere: Utviklere med Scrum-erfaring er vanskelig(ere) å finne, og når de først er funnet er vanskelig å beholde på grunn av deres høye etterspørsel.
• Kontinuerlig integrasjon og utvikling: I Scrum er vi anti-handoff og tar til ordet for økt parallelisering.
  ‍

Organisasjoner må jobbe raskere, og levere mer verdi i 2022. Agile produktutvikling lover å akselerere produktlevering, og kontinuerlig føre til forbedring av kundetilfredshet.

Vurderer du å implementere Agile-metodikk i din organisasjon?
Hvis du er usikker på om du skal ta i bruk Agile eller ikke bør du ta en titt på denne statistikken; 
‍20+ astonishing agile adoption statistics for 2022
‍

Konklusjon

Hovedforskjellen på de mest benyttede metodikkene vannfall, spiral(hybrid tilnærming), og smidig er at et vannfallsprosjekter benytter en fast, lineær plan. Alt er forhåndsplanlagt, og kundene samhandler kun ved prosjektets start og slutt. Ved å benytte spiral-metodikk så kombineres sekvensielle og prototypemodeller. For store prosjekter med pågående forbedringer fungerer denne metodikken godt. En iterasjon (spiral) inneholder spesifikke aktiviteter som resulterer i et lite utviklingsprosjekt. Med smidig utvikling legges imidlertid nye prioriteringer og krav til prosjektet etter kontinuerlige sprinter og tilbakemeldinger fra kunde.

Om du har erfaring med smidig utvikling, eller om du så er ny til metoden å gjennomføre prosjekt på, bistår vi deg gjerne i gjennomføringen av ditt neste utviklingsløp. I Apphuset designer, utvikler og administrerer vi prosjekter ved å benytte design-thinking og smidige metodikker- som bidrar til å lage produkter og tjenester som brukerne vil elske.
‍

Kontakt oss