Want create site? Find Free WordPress Themes and plugins.

7 gyldne råd, når du skal udvikle et nyt website til din virksomhed

Af Adam Osbirk Moe, Capgemini Sogeti

Skal din virksomhed have et nyt website? Så er indholdet naturligvis det vigtigste. Men som it-konsulent ved jeg, at teknologien enten kan forstærke jeres indhold – eller det modsatte. Derfor har du her 7 konkrete råd, som kan hjælpe jer sikkert igennem processen og sikre et resultat i topkvalitet. Jeg har skrevet rådene for at spare jer for de ærgrelser, forsinkelser og unødvendigt kostbare fejltagelser, som ind imellem rammer website-projekter.

Ved at læse hundreder af kravspecifikationer og deltage i udvikling af løsninger gennem 18 år har jeg gjort observationer, som er relevante for alle virksomheder, der køber it-løsninger. Her har du mine bedste råd om at udvikle et nyt website. God fornøjelse.

1)    Hvad er jeres vision med sitet?

Skal man virkelig udvikle en decideret vision for et website, vil du måske spørge? Det er svært at svare entydigt på, fordi der både er fordele og potentielle ulemper.

  • Hvad tæller FOR, at I skriver en vision?

Det er vigtigt at være enige om, hvad endemålet er, fordi mange valg afhænger af det store perspektiv. Det ses desværre ofte, at virksomheder eller organisationer får udviklet et nyt website uden at være afklaret internt. Det gør det svært for folk internt at lave et godt udbud, og det gør det tilsvarende svært for potentielle eksterne samarbejdspartnere at dimensionere tilbuddet rigtigt. Og her taler jeg ikke om penge men om valg af arkitektur, fremtidssikring, udvikling af funktioner etc.

Så hvad er en god vision? Vision kommer som bekendt af ”video”, som betyder ”jeg ser”. Det er en god regel at gøre visionen konkret og synlig, så det står klart for enhver, hvad man skal gå efter. Det kan naturligvis være vanskeligt at gøre noget abstrakt synlig. Men så kan man med fordel bruge SMART-modellen og gøre visionen:

– Specifik

– Målbar

– Accepteret

– Realistisk

– Tidsbegrænset

Bare for eksemplets skyld kunne en vision være: ”Alle digitale kundehenvendelser skal være besvaret af den rigtige medarbejder inden for 24 timer, og information om, hvorvidt vi har en vare på lager skal være opdaterede inden for 5 minutter”.

  • Hvad tæller så IMOD en vision?

Du skal især være opmærksom på to faktorer. Den ene faktor er, at visioner, der har indflydelse på organisationers måde at arbejde på, ofte kræver forandringsledelse og organisatoriske tilpasninger og kan ende med at blive ret omfattende.

Hvis man f.eks. har en vision om at udvikle en portal, der løser alle problemer for alle kunder og forbrugere i det hele taget, kan det synes mere interessant at tænke store tanker end at udvikle den funktion, som gør, at en kunde på 5 minutter kan bestille et produkt via højst 3 skærmbilleder.

Så skal I udvikle en vision? Måske. Men du skal være afklaret om, hvad det primære formål med den nye website er. Og hold øje med, at I ikke mister fokus på at få udviklet den funktionalitet og de forretningsgange, der opfylder konkrete behov og løser konkrete problemer – dem der får business casen til at hænge sammen.

2)    Identificer jeres tekniske (non-funktionelle) krav

Krav kan med fordel deles op i funktionelle og non-funktionelle krav. De funktionelle krav handler om, hvad brugeren skal kunne gøre, og hvordan. Mens de non-funktionelle er krav til systemerne, der leverer brugeroplevelsen. Det er vigtigt, at man internt identificerer de non-funktionelle krav fra start, fordi det næsten er umuligt at sammenligne tilbud uden et overblik på dette område.

Non-funktionelle krav kan f.eks. være:

  • .NET baseret teknologi
  • Skal kunne køre på seneste versioner af browsere som Chrome, Firefox og Safari
  • Løsningen skal have høj sikkerhed (f.eks. alle formularer sikret mod cross site scripting)
  • Redaktøren skal kunne publicere en artikel på 5 minutter
  • Man skal kunne finde ethvert produkt med højst x antal klik
  • Redaktøren skal kunne previewe indhold og se, hvordan det fremtræder på forskellige skærmopløsninger og devices
  • Krav til svartider og performance

Dette er tekniske mindstekrav, der sikrer, at jeres løsning er korrekt dimensioneret. Så den kan håndtere det antal brugere, I forventer, og så løsningen er udført teknisk korrekt i forhold til at kunne skalere, når I får succes med jeres website.

3)    Identificer jeres funktionelle krav – med user stories

Når det gælder om, hvad websitet skal kunne, vil jeg anbefale, at du som hovedværktøj bruger user stories. I stedet for en detaljeret beskrivelse af nøjagtige funktioner, som du ønsker leveret. Og det er der flere grunde til:

  • Beskriver du funktionerne i stedet for arbejdsgange, risikerer du at gå glip af smartere måder at gøre ting på. Her vil en leverandør, der besvarer dit tilbudsmateriale kunne beskrive, hvordan arbejdsgangen løses med deres løsning, i stedet for at bestræbe sig på at opfylde dit krav, sådan som du entydigt har beskrevet det.
  • User stories beskriver forretningsprocesser fra første kontakt til gennemført handling. Ved at bruge dem undgår du at stille krav om, at standardløsninger skal indrette sig efter eksisterende ad hoc arbejdsgange i stedet for at udnytte mere moderne workflows på systemet. Der vil ofte være tale om konfiguration fremfor skræddersyet udvikling.
  • Med user story udnytter du leverandørens ekspertise. Forestil dig, at du skal bygge en bro. Men i stedet for at definere broens størrelse, definerer du, at 10.000 biler skal kunne passere på 40 minutter. På den måde åbner du op for, at en potentiel leverandør fortæller, at han kan nedsænke en tunnel, som kun vil koste en brøkdel af en bro … Så har du brugt en user story til at udnytte leverandørens fulde ekspertise.
  • User stories er interessante og lette at forholde sig til for organisationen. Mens beskrivelser af funktioner hurtigt bliver kedelige, er det mere nærværende, når du arbejder med user stories. Lad os sige, at du beskriver, hvordan en bruger skal kunne downloade en rapport og fra alle sider i rapporten klikke direkte ind på en relevant side i jeres produkt-katalog på nettet. Det kan alle forholde sig til. Og leverandøren kan byde ind med sit forslag om, hvordan det teknisk bliver gjort bedst og mest elegant.

4)    Vælg på baggrund af dine tekniske og forretningsmæssige krav

Udbudsmateriale til potentielle leverandører skal naturligvis også indeholde din virksomheds overordnede målsætninger og planer. Det kan f.eks. være, at I ønsker en større personalisering end i dag, eller at I senere gerne vil kunne tilkøbe e-handels funktionalitet, som I ikke er klar til nu. Selv om det ikke er en del af første scope, ved leverandøren dermed, at det sandsynligvis kommer senere, så de kan tænke det ind i arkitekturen.

Sammen med de non-funktionelle krav kan I nu opstille en matrice med tekniske krav og de overordnede målsætninger til den nye løsning. Den gør det muligt for jer at vælge system på baggrund af organisatoriske og forretningsmæssige målsætninger.

 

5)    Udbuddet: Send din tilvalgsmatrice til højst 4 software leverandører

Indrømmet: Det kan friste at invitere potentielle leverandører, som har udviklet et website for en bekendt. Og man kan selvfølgelig ikke afvise, at det kunne være den rigtige leverandør. Men jeg vil til enhver tid anbefale, at man udvælger sin leverandør struktureret og i to trin:

Vælg systemet først

Vælg Umbraco, Episerver, Sitecore eller hvilket system, som passer bedst til din organisations krav. De fire systemleverandører, som du ønsker at sammenligne ved hjælp af din tilvalgsmatrice, bør være de fire på markedet, der er understøttet af flest softwareleverandører. På den måde undgår du at blive bundet til et system, der er ved at blive udfaset, og du er ikke bundet til en bestemt implementeringspartner. Du kan skifte ud, hvis der opstår problemer. Med tildelingsmatricen kan du ud fra jeres digitale strategi vælge det system, der passer bedst til din organisation og jeres digitale road-map.

Bed de fire leverandører svare på, om de kan levere på de tildelingskriterier, du har listet med standard-løsninger og -moduler. Med den vægtede score kan du skære feltet ned til to systemer, som du gerne vil se præsenteret. Præsentationen bør softwareleverandøren stå for, da det er deres software og ikke implementeringspartnerens evne til at levere, du skal vurdere. Når du derefter har besluttet dig for det system, du gerne vil have din nye løsning baseret på, er det tid til at finde den rigtige implementeringspartner.

Vælg din implementeringspartner til sidst

Når du har indkredset det system, du ønsker, kan du finde en implementeringsparter, der både har erfaring med systemet, og som kan forstå og leve op til jeres krav og ønsker. I denne fase ville jeg personligt fokusere på, hvor stor erfaring implementeringspartneren har med systemet, hvor mange certificerede udviklere der er ansat, og selvfølgelig hvor tilfredse deres kunder er.

6)    Udnyt præsentationsmødet til at få en god dialog

Jeg oplever ind imellem, at man er for tilbageholdende under præsentationsmøderne med implementeringspartnere. Måske fordi man bestræber sig på at behandle alle potentielle leverandører lige. Hvilket ender med, at man ikke tør sige ret meget på de enkelte møder.

Min påstand er, at jo mere diskussion og jo flere spørgsmål/svar man kan få frem under en præsentation, jo bedre beslutningsgrundlag får man. For det viser sig næsten altid, at:

  • Uanset om en implementeringspartner er motiveret af at tjene penge, skal man ikke undervurdere værdien af at skabe en god stemning og motivere partneren ud over det økonomiske incitament. Lige som en god træner eller sportsdirektør hele tiden skal motivere selv ekstremt vellønnede fodboldspillere. Sørg for at gøre det vigtigt, sjovt og spændende at udvikle netop jeres løsning. Penge er heldigvis ikke alt.
  • Implementeringspartneren ved meget mere, end du får ud af en énvejs-samtale. Og måske meget mere, end de selv er bevidst om. Så skab en dialog i møderne. Det aktiverer deres viden, og det er faktisk det mest retfærdige, du kan gøre over for potentielle partnere. Det giver dem optimal mulighed for at vise, at de kan løse opgaven bedst. Husk, at løsningen ikke bliver bedre end samarbejdet, og gode samarbejder bygger på dialog.

Så væk med berøringsangsten. Spring ud i det og vær ikke bange for at vise det, hvis din viden om teknologi har mangler. Jo bedre en potentiel samarbejdspartner forstår din indsigt, dine visioner og din kommunikation, jo bedre og mere brugbar rådgivning får du.

7)    Tag på referencebesøg – du lærer meget af det

Er du i tvivl om, hvem du skal vælge, vil jeg anbefale dig at besøge implementeringspartnerens kunder. Alt for få gør det.

Men det er vigtigt, at du bruger dine referencebesøg rigtigt. For som nogen engang har sagt, kan en dårlig implementeringspartner lave et kaos ud af en god platform, og en dygtig partner kan få en dårlig platform til at virke rimelig fornuftigt.

Så lad ikke referencebesøget drive dig fra en platform til en anden. Brug referencebesøget til at vurdere implementeringspartnerens evne til at forstå og imødekomme kundernes behov og evnen til at levere i dagligdagen. Og spørg hellere en gang for meget end en gang for lidt. Min erfaring er, at virksomheder er bemærkelsesværdige hjælpsomme.

Jeg håber du har kunne bruge disse 7 råd. Webprojekter er ikke svære, men de kræver en struktureret proces, hvor både du og leverandøren har fælles målsætninger og arbejder godt sammen.

 

Did you find apk for android? You can find new Free Android Games and apps.