Slik styrer du et bedriftsnettstedprosjekt (med Rich Butkevic fra Project Zendo)

Les transkripsjonen:

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Beklager eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Ben Aston

Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager. Velkommen til DPM-podkasten. Enten du er en erfaren prosjektleder, en digital produsent eller noe helt annet – kanskje du plutselig har fått ansvaret for å lede prosjekter – skal du vite at du i dag har tusenvis av andre på øret som er i samme situasjon og gjør sitt beste for å starte, planlegge og levere bedre prosjekter.

Vi i thedigitalprojectmanager.com er her for å hjelpe deg med å bli tryggere og dyktigere som prosjektleder, og vi er her for å koble deg sammen med andre som også leder og styrer prosjekter. Hvis du virkelig ønsker å ta prosjektlederferdighetene dine til neste nivå, kan du sjekke ut DPM School og melde deg på vårt proffmedlemskap for å få tilgang til alle de kuraterte ressursene våre.

Mens du lytter til programmet, må du til slutt gjerne abonnere og melde deg på e-postlisten vår på thedigitalprojectmanager.com, slik at du holder deg oppdatert på alt som skjer. Hvis du noen gang har gjennomført et prosjekt for et bedriftsnettsted, vet du godt at det er utrolig vanskelig å få det riktig. Det skyldes delvis at slike prosjekter ikke gjennomføres særlig ofte, men det er mer enn det: uklare mål, en vag brief, et virvar av interessenter og masse politikk.

Alt dette gjør det utrolig vanskelig å få et bedriftsnettsted ferdig i det hele tatt – langt mindre å få det riktig. Legg til noen tekniske utfordringer, og disse skinnende, nye nettstedprosjektene kan bli en fullstendig katastrofe. I dagens podkast skal vi derfor forklare hvordan du kan gjennomføre prosjekter for bedriftsnettsteder på riktig måte. Lytt videre for å få vite hvordan du kan planlegge, styre og kontrollere de kommende prosjektene dine for bedriftsnettsteder og få dem riktig i mål.

Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager, og velkommen til DPM-podkasten. Enten du er en erfaren prosjektleder, en digital produsent eller noe helt annet – kanskje du plutselig har fått ansvaret for å lede prosjekter – skal du vite at du i dag har tusenvis av andre på øret som er i samme situasjon og gjør sitt beste for å starte, planlegge og levere bedre prosjekter. Vi i thedigitalprojectmanager.com er her for å hjelpe deg med å bli tryggere og dyktigere som prosjektleder, og vi er her for å koble deg sammen med andre som også leder og styrer prosjekter.

Hvis du virkelig ønsker å ta prosjektlederferdighetene dine til neste nivå, kan du sjekke ut DPM School og melde deg på proffmedlemskapet vårt for å få tilgang til alle de kuraterte ressursene våre. Mens du lytter til programmet, må du til slutt gjerne abonnere og melde deg på e-postlisten vår på thedigitalprojectmanager.com, slik at du holder deg oppdatert på alt som skjer.

Denne podkasten presenteres av Clarizen, ledende innen programvare for virksomhetsomfattende prosjekt- og porteføljestyring. Besøk clarizen.com for å lære mer. I dag har jeg med meg Rich Butkevic-

Rich Butkevic

Perfekt.

Ben Aston

Sa jeg det riktig?

Rich Butkevic

Du sa det perfekt.

Ben Aston

Der ser du, jeg øvde. Rich er konsulent innen prosjektstyring, og han er forfatter av bloggen projectzendo.com. Ta gjerne en titt der. Han holder også kurs i prosjektstyring over hele Texas, og hvis du er interessert i det, kan du besøke artofpmo.com. Vi kommer tilbake til det om litt. Rich har faktisk en unik kombinasjon av ledererfaring innen prosjekt- og produktstyring, kvalitetssikring, forretningsanalyse, markedsføring og opplæring. Han bruker Agile og Scrum, og han har alle bokstavene og sertifiseringene man kan ønske seg: PMP, Certified Scrum Master, IBM Rational Unified Process, Amazon- og e-markedsføringssertifisering. Han har alt.

Hei, Rich, og takk for at du blir med oss i dag.

Rich Butkevic

Hei, Ben. Takk for invitasjonen. Det setter jeg pris på.

Ben Aston

Jeg har lyst til å begynne med å se nærmere på alle kvalifikasjonene og bokstavene du har etter navnet ditt. Noen mener at de ikke bryr seg om sertifiseringer, mens du tydeligvis har valgt motsatt retning og skaffet deg nesten alle som finnes. Skyldes det en særlig lidenskap for læring, eller hva fikk deg til å sertifisere deg innen alt mulig?

Rich Butkevic

Jeg vet ikke om det gjelder alt, men jeg har en lidenskap for læring. Det er rett og slett noe jeg liker å gjøre. Jeg mener at en sertifisering innen prosjektstyring – eller egentlig innen hvilket som helst fagområde – viser at man tar yrket alvorlig og holder seg oppdatert. Bortsett fra PMP-sertifiseringen har jeg stort sett skaffet meg de andre sertifiseringene etter behov i ulike prosjekter.

Hvis jeg for eksempel arbeider med et prosjekt som bruker Amazon Web Services, liker jeg å sette meg grundig inn i teknologien slik at jeg kan gjøre en bedre jobb som prosjektleder. Da oppdaget jeg at jeg likte det og ville lære mer. Når jeg først skal lære mer, er det fint å ha et konkret mål å strekke seg etter. Derfor gjør jeg det til et mål å ta en sertifisering, og det er omtrent slik de [uhørlig 00:05:30] oppstod.

Ben Aston

Fortell oss hvordan du begynte med prosjektstyring. Du er tydelig teknisk orientert. Jeg kjenner ikke mange prosjektledere som har en teknisk sertifisering som AWS-

Rich Butkevic

Ja.

Ben Aston

Hvordan startet du og kom inn i prosjektstyring?

Rich Butkevic

På college jobbet jeg som teknisk supportmedarbeider. Jeg svarte på telefonen akkurat da bredbåndet begynte å komme. Jeg fikk derfor en tidlig teknisk start i en ganske spennende periode. Rett etter at jeg var ferdig på college, ble jeg forretningsanalytiker i et stort telekommunikasjonsselskap i Chicago, der jeg bodde på den tiden. Derfra gikk jeg videre til kvalitetssikring, begynte å lede kvalitetssikringen og beveget meg så inn i prosjektstyring i det samme selskapet. Der tok jeg sertifiseringen min, og så utviklet tingene seg videre.

Ben Aston

Du gikk altså gjennom teknisk support og kvalitetssikring før du kom inn i prosjektstyring. Du lærte sikkert mye den første dagen som prosjektleder. Hva ville du sagt til ditt yngre jeg nå, med den kunnskapen du har i dag?

Rich Butkevic

Det viktigste er at det ikke handler om verktøyet. Mange prosjektledere blir svært opptatt av å kjenne alle nyansene og detaljene i prosjektstyringsverktøyet de bruker. Etter min mening er verktøyet bare en måte å effektivisere, automatisere og støtte en prosess du egentlig bør kunne gjennomføre med blyant og papir.

Hvis du ikke er komfortabel med å lede et prosjekt med bare en penn og en notatbok, betyr ikke det at du faktisk bør gjøre alt slik. Men det å være en god prosjektleder handler ikke om å kunne mest om Microsoft Project eller et annet prosjektstyringsverktøy. Det handler om mye mer enn det – om mykere ferdigheter og om å forstå hva du prøver å oppnå som prosjektleder, i stedet for å være ekspert på programvaren.

Ben Aston

Ja, absolutt. Men når vi først snakker om verktøy, for jeg liker verktøy-

Rich Butkevic

Ja, jeg også.

Ben Aston

Hva består prosjektlederverktøykassen din av, bortsett fra pennen og notatblokken du nevnte?

Rich Butkevic

Det som har gjort størst forskjell i verktøykassen min, bortsett fra selve prosjektstyringsverktøyet vi bruker, er en eller annen form for samarbeidsverktøy. Jeg liker Slack. Det er enkelt og lett for folk å bruke, og jeg synes det gjør en enorm forskjell sammenlignet med å forsøke å styre alt gjennom en mengde e-poster og Excel-dokumenter som ligger spredt rundt omkring på fellesområder ingen finner igjen.

Jeg liker Slack, men selve verktøyet – konseptet og ideen – er viktigere enn hvilket verktøy du velger.

Ben Aston

Bruker du noen integrasjoner med Slack som du synes er spesielt nyttige for å støtte samarbeid og gjøre det lettere å bruke de mykere ferdighetene?

Rich Butkevic

Ikke noe spesielt jeg kommer på, bortsett fra enkelte integrasjoner jeg noen ganger bruker som konsulent. Selskapene jeg jobber for, har vanligvis noen standarder vi må følge. Tidsstyringsprogramvaren som integreres med Slack, kan derfor variere. Det er bra å ha en integrasjon, men det som virkelig har vært nyttig i Slack, er å lære hurtigtastene. Det har gjort en enorm forskjell.

Ben Aston

Fortell oss om favoritthurtigtasten din.

Rich Butkevic

Oi. Nå setter du meg på prøve. Jeg vet ikke. Det virker som om jeg kjenner dem instinktivt – fingrene mine vet hva de skal gjøre-

Ben Aston

Det gjør du sikkert.

Rich Butkevic

Men hjernen min gjør det ikke.

Ben Aston

Du kan ikke sitere dem, men du kjenner håndbevegelsene.

Rich Butkevic

Ja. Det er litt som telefonnummeret mitt. Jeg har noen ganger problemer med å fortelle folk hva telefonnummeret mitt er, men jeg har ingen problemer med å taste det inn, fordi jeg trenger det.

Ben Aston

Ja, det er morsomt. Men for å gå tilbake til poenget ditt: Det handler ikke om verktøyene, selv om vi nå har begynt å snakke om verktøy. La oss gå tilbake til poenget ditt om at god prosjektstyring ikke handler om verktøyene. Fortell oss mer om hva du har oppdaget at kunsten ved prosjektstyring egentlig består av, og hvordan du bruker de myke ferdighetene til å levere bedre prosjekter.

Rich Butkevic

Kommunikasjon og lignende myke ferdigheter er selvfølgelig viktige. Men kanskje en bedre måte å si det på er at man må forstå på et konseptuelt nivå hva en prosjektleder skal gjøre, og hvordan et prosjekt ideelt sett skal gjennomføres. Da kan du konsentrere deg om det som er viktig, i stedet for ting som egentlig bare er bortkastet tid.

Gjennom et prosjekt finnes det noen store hovedområder du bør fokusere på. Under disse finnes det oppgaver du må eller bør utføre, men du må først identifisere hvilke krav du har. Du må sørge for at både virksomheten og det tekniske teamet – dersom det er et IT- eller nettstedprosjekt – har en felles forståelse av kravene. Du må sikre at testing gjennomføres og at feil håndteres på en eller annen måte. Det handler om å forstå de mer overordnede oppgavene, det som vanligvis ville blitt representert som sammendragsoppgaver i en prosjektplan, og å forstå det større målet og hvorfor du gjør disse tingene.

Jeg pleier å si at hvis du ikke kan skrive en tweet om hvorfor du fyller ut et dokument eller gjør det du gjør, bør du stoppe opp og bli tydelig på hvorfor du gjør det. Hvis du ikke vet hvorfor du gjør noe, kan du ikke gjøre det godt – og det kan hende du ikke trenger å gjøre det i det hele tatt.

Ben Aston

La oss gå inn på temaet styring av prosjekter for bedriftsnettsteder. Vi publiserte nylig en artikkel om hvordan slike prosjekter går galt – en huskeliste for prosjektledere. Ta en titt på den på thedigitalprojectmanager.com hvis du ikke har lest den ennå. Realiteten er at dette er vanskelig. Bedriftsnettstedprosjekter er virkelig krevende. Derfor engasjerer selskaper byråer og konsulenter for å få hjelp, enten det gjelder en større oppdatering, migrering til skyen, implementering av et nytt CMS eller integrasjon med digitale markedsføringsverktøy. Slike prosjekter gjennomføres ofte bare hvert tredje til femte år, og de involverte har derfor ikke nødvendigvis mye erfaring. Kanskje har de bare ledet et slikt prosjekt én eller to ganger i løpet av karrieren.

Det er utfordrende. Som jeg nevnte i begynnelsen, er det mange interessenter, uklare briefinger, politikk og tekniske utfordringer. Hvis du ikke har lest Richs artikkel, bør du gjøre det. Jeg vil snakke om prosessen og hvordan vi kan effektivisere den, med utgangspunkt i det Rich nettopp sa om å forstå hva som må skje for at prosjektet skal lykkes. Men først: Hvorfor er dette så vanskelig? Kan du dele et eksempel eller en skrekkhistorie om hvordan dette har gått galt for deg tidligere?

Rich Butkevic

Når det gjelder hvordan ting har gått galt, var en av de viktigste lærdommene jeg tok med meg tidlig i karrieren: Stol på folk, men kontroller. Det hendte ofte at prosjektressurser sa at de hadde fullført en oppgave, mens det de egentlig mente, var at de hadde planlagt å fullføre den, eller at den stod på gjøremålslisten. Så dukket andre ting opp, og oppgaven ble glemt eller feid under teppet. Noen av disse problemene blir dessverre ikke synlige før man går i produksjon.

Det var en av de største lærdommene jeg fikk tidlig. En annen var hvor viktig godt samarbeid er i store team, særlig i store prosjekter eller når ressursene sitter geografisk spredt. Jo større prosjektet er, desto mindre kan du stole på at én eller to personer skal gjøre en heroisk innsats og redde alt på slutten.

I et prosjekt for et bedriftsnettsted kan en konsulent som meg komme til et nytt selskap noen ganger i året og arbeide med slike prosjekter. Jeg har sannsynligvis arbeidet med et par dusin av dem. Men en system- eller nettverksadministrator i en virksomhet kan ha vært der i 15 år og kanskje bare gjennomført noe lignende én, eller høyst to ganger, i løpet av de ti eller femten årene de har vært ansatt.

Selv om det kan virke rutinemessig for mange, er det derfor slett ikke rutine for mange av ressursene i en virksomhet.

Ben Aston

Jeg kan dele en historie om noe som gikk galt. For noen år siden jobbet jeg med et prosjekt for et bedriftsnettsted, og utfordringen handlet egentlig om manglende samsvar i briefen. Det viste seg å være knyttet til interessenthåndtering. Dette skjer ofte i prosjekter for bedriftsnettsteder: Personen som har fått ansvaret for å lede prosjektet internt, har ikke nødvendigvis samlet inn alle innspillene fra teamet sitt.

De hadde skrevet en brief, men den var ikke godkjent – eller, hvis den var godkjent, var den ikke blitt ordentlig gjennomgått. Vi gikk derfor videre, utformet nettstedet og bygget det. Rett før lansering oppdaget vi at det fantes et ekstra godkjenningsnivå i prosjektets styringsstruktur, et nivå vi ikke hadde vært klar over gjennom hele prosjektet. Vi fikk beskjed om at grunnleggeren og presidenten måtte godkjenne nettstedet før lansering. Vi svarte: «Det nevnte dere ikke tidligere.» Det viste seg at grunnleggeren og presidenten var den egentlige sjefen.

Rich Butkevic

Det stemmer.

Ben Aston

Vedkommende hadde svært tydelige meninger om hva de ville og ikke ville ha, og dette var grunnleggende for hele prosjektet.

Rich Butkevic

Ja.

Ben Aston

Vi fikk naturligvis en vanskelig samtale. Vi måtte si: «Beklager, men dette stod ikke i briefen. Dere har godkjent alt gjennom hele prosjektet, og nå er grunnleggeren og presidenten misfornøyd. Dermed er alle andre også misfornøyde.» Vi måtte utstede en omfattende endringsforespørsel, og kunden ble selvsagt opprørt over å måtte betale mer. Det gjorde forholdet dårligere.

Rich Butkevic

Ja.

Ben Aston

Vi hadde kanskje også et ansvar, fordi vi ikke presset hardt nok på for å få tydeliggjort styringsstrukturen helt i begynnelsen. Vi burde ha tatt prosjektet saktere og sørget for godkjenning hele veien opp i organisasjonen.

Rich Butkevic

Det kan være svært vanskelig, særlig i store virksomheter. Du kan ha et dusin identifiserte interessenter, men alle har en sjef, og disse sjefene har gjerne også en sjef. Når en tilstrekkelig høytstående sjef ser en endring på nettstedet de ikke liker, kan de overstyre beslutninger som allerede er tatt. Det kan bli komplisert.

Ben Aston

En viktig lærdom for meg var å forklare konsekvensene. Nå sier jeg: «La oss kartlegge interessentene og lage en RACI-matrise for de ulike milepælene. Men hvis denne personen skal godkjenne, og vi senere oppdager at noen andre må ha siste ord, får det konsekvenser for kostnadene og tidsplanen. Si fra nå, ellers får vi konsekvenser senere.»

Ofte er det markedsavdelingen som får ansvaret, og så delegerer de oppgaven til en junior medarbeider. Den personen sier: «Jeg tar med sjefen min.» Da svarer jeg: «Vi bør nok ta med noen flere også.»

Rich Butkevic

Ja.

Ben Aston

Hvordan ser den overordnede prosessen ut? Hvordan går vi fra at en bedriftskunde sier «Jeg trenger et nytt bedriftsnettsted», til «Da var det ferdig»?

Rich Butkevic

Ja.

Ben Aston

Du snakket om hovedområder og sammendragsoppgaver i prosjektplanen. Hvordan ser dette ut for deg? Du er en tydelig tilhenger av Agile og har Scrum-sertifisering. Hvordan påvirker det måten du gjennomfører et prosjekt for et bedriftsnettsted på, når en mer trinnvis og portstyrt tilnærming kanskje passer bedre på grunn av godkjenningene?

Rich Butkevic

På høyeste nivå er det første jeg vil sikre at vi gjør, å identifisere de faktiske målene for prosjektet eller nettstedet. Noen ganger handler det om en fusjon eller et oppkjøp der to nettsteder skal slås sammen. Andre ganger er det en redesign, en rebranding eller implementering av et nytt innholds-styringssystem. Målene bestemmer mange av de påfølgende oppgavene i prosjektet.

Når målene er identifisert, går jeg videre til brukerhistorier. Dette er noe mange design- og nettstedprosjekter overser. De fleste virksomheter skal ikke betjene absolutt alle. De kan som regel identifisere noen ulike kundeprofiler – ulike typer mennesker som skal se nettstedet. Noen skal kjøpe noe, noen trenger informasjon, og eksisterende kunder ønsker kanskje å bestille på nytt.

Hver brukertype har ulike mål på nettstedet. De ser etter forskjellig informasjon, har ulik kunnskap og følger ulike veier gjennom nettstedet. Det endelige målet for brukeren og virksomheten varierer med kundeprofilen. Derfor må du identifisere disse profilene-

Ben Aston

Flott.

Rich Butkevic

Når du beskriver hvorfor de besøker nettstedet og hva de håper å gjøre, hjelper det med å styre neste del av prosjektet: utformingen av nettstedshierarkiet og strukturen. Du bør begrense antallet klikk det tar å komme til et sted. Det du leter etter, bør ikke ligge begravd 20 sider ned i nettstedet. Da finner brukeren det aldri, eller blir frustrert. Det er også dårlig av mange andre grunner, blant annet med tanke på SEO.

Når hierarkiet er på plass, ser vi på innholdet og hvordan det skal forvaltes. Et lite nettsted med færre enn 50 sider er lett å håndtere. Men et bedriftsnettsted på virksomhetsnivå kan ha tusenvis av sider. Da må man vite hvilket innhold som skal beholdes, oppdateres, slettes eller slås sammen. Det er en stor oppgave, og her kan verktøy være til stor hjelp. Du vil ikke ha to–tre tusen Word-dokumenter liggende i en tilfeldig mappe.

Ben Aston

Ja.

Rich Butkevic

Først etter dette begynner jeg å bekymre meg for de tekniske sidene ved prosjektet. De er forholdsvis statiske. Det finnes forskjeller mellom virksomheter når det gjelder infrastruktur og CMS, men du kan få alt det tekniske perfekt. Hvis målene ikke er gjennomtenkt, hvis du ikke dekker kundenes behov, hvis nettstedet ikke er brukervennlig og hvis riktig innhold ikke finnes, spiller ikke de tekniske delene noen rolle.

Ben Aston

For deg handler det altså om å definere briefen og målene, identifisere de viktigste personaene eller arketypene og lage informasjonsarkitekturen. Deretter kommer designfasen med wireframes og designelementer. Gjør du dette som parallelle arbeidsstrømmer? For personer som tenker at oppdagelse, planlegging og design tar mye tid før byggingen kan begynne: Hvilke grep kan man ta for å arbeide parallelt og samtidig gjøre jobben riktig?

Rich Butkevic

Jeg prøver å unngå for mange snarveier. Planleggingen har enorm betydning for hvor raskt prosjektet går senere. Hvis du ikke har tid til å gjøre det riktig, får du heller ikke tid til å gjøre det på nytt. Mye kan likevel gjøres parallelt.

Mens du arbeider med de overordnede målene, kjenner en eksisterende virksomhet vanligvis kundene sine. Du kan begynne med brukerhistoriene, notere tanker om nettstedstrukturen og bruke den eksisterende strukturen som utgangspunkt ved en redesign. Innholdsteamet kan samtidig gå gjennom innholdet og bestemme hva som skal slås sammen, fjernes eller oppdateres. Alt dette kan gjøres samtidig.

En iterativ og agil tilnærming er særlig nyttig for interessenthåndtering. Du bør så raskt som mulig komme frem til noe interessentene og beslutningstakeren kan se med egne øyne. Mange ledere ønsker ikke å delta i det daglige arbeidet, og det er ofte riktig. Men hvis du arrangerer et møte der de kan se fremdriften og nettstedet på en skjerm, kommer de gjerne. Da får du verdifulle tilbakemeldinger. Jo tidligere du får dem, desto bedre, fordi du ikke vil at en designbeslutning skal forplante seg gjennom hele nettstedet før du oppdager at en leder på C-nivå ikke ønsker den.

Ben Aston

Brukertesting kan også være svært nyttig. I et prosjekt for et bedriftsnettsted identifiserer vi personaene helt i begynnelsen. Hvem bygger vi dette for? I virksomheter blandes dette ofte sammen med ønsket om å tilfredsstille en leder eller styrke lederens ego. Det kan være et underforstått prosjektmål, men det må på en eller annen måte gjøres tydelig.

Når vi lager personaene, blir vi enige med kunden om hvorfor prosjektet gjennomføres. På de fleste bedriftsnettsteder finnes det noen som sier: «Det viktigste på hjemmesiden er å fortelle alle om det fantastiske administrerende direktøren vår nettopp gjorde.» Da kan vi spørre: «Hvorfor må alle vite det? Hvis dere er en bredbåndsleverandør, trenger brukerne kanskje noe annet.»

Det finnes uttalte og underforståtte mål. Personaene hjelper oss med å styre beslutningene om hvorfor vi plasserer innholdet der vi gjør. Deretter kan vi teste resultatet med personaene. Vi gir dem konkrete oppgaver, viser dem nettstedet, informasjonsarkitekturen og wireframene, og ser om de finner frem. Hvis de ser informasjon om direktøren, men ikke finner hvordan de konfigurerer bredbåndspakken, har vi et godt argument for å endre hjemmesiden.

Rich Butkevic

Det er et godt eksempel, og slikt skjer hele tiden. Ved brukertesting er det viktig at deltakerne faktisk representerer kundeprofilene du identifiserte tidligere. Hvis du selger boligforsikring, bør du ikke teste med personer som ikke eier bolig, eller med tenåringer. Deltakerne må være gode eksempler på de som faktisk skal bruke nettstedet.

Mange virksomheter bruker egne ansatte til brukertesting. Det er vanligvis en dårlig idé. Ansatte kjenner virksomheten, målene og bransjespråket. Du kan teste og tro at alt er enkelt, men når nettstedet lanseres, forstår ikke allmennheten hva et ord som «bredbånd» betyr. De klikker kanskje ikke på lenken, blir frustrert og går til en konkurrent som bruker «høyhastighetsinternett».

Ben Aston

Vi har snakket lenge om oppdagelse, planlegging og design. La oss snakke om byggingen. Du har mye erfaring med de tekniske sidene ved å styre et bedriftsnettsted. Designet må fungere i tråd med målene vi satte i begynnelsen. Hvis vi vil øke konverteringer eller nå KPI-ene våre, må designet være riktig. Men det er et gap mellom et godt design og et nettsted som faktisk fungerer som det skal.

Hva er dine viktigste råd for byggeprosessen? Hva bør en prosjektleder som leder et slikt prosjekt for første gang, tenke på når vedkommende skal styre et utviklerteam?

Rich Butkevic

Det viktigste er å huske at utviklerne ofte ikke har særlig erfaring på akkurat dette området, særlig ikke med migrering. De har kanskje erfaring med å drifte et nettsted etter lansering, men ikke nødvendigvis med de tekniske detaljene i en migrering. Gjennom erfaring har jeg sett noen områder som ofte blir oversett.

Det ene er HTTPS-videresending. Nesten alle nettsteder, spesielt bedriftsnettsteder, er sikre slik at trafikken krypteres. Du må sørge for at en forespørsel via HTTP, eller uten HTTPS, sendes videre til den sikre versjonen av siden. Hvis URL-en ikke omskrives riktig, kan søkemotorer oppfatte HTTP- og HTTPS-versjonen som to ulike nettsteder. Det kan føre til problemer med duplikatinnhold, og analyseverktøyene kan spore versjonene separat. Da blir det vanskelig å knytte konverteringer sammen.

Et annet problem oppstår når nettstedet skal lanseres og DNS må oppdateres. DNS oversetter et nettstednavn til en IP-adresse slik at nettstedet kan finnes på nettet. Personen som skal oppdatere DNS, har kanskje ikke tilgang til domeneregistraren. Det er ofte svært begrenset hvem som har tilgang til virksomhetens rotdomene, og det er bra. Men du må sikre at de riktige personene har tilgangen de trenger.

Prosjektteamet, særlig ledelsen, må også forstå at en DNS-endring bruker tid på å spre seg til servere over hele internett. Du vil unngå å sende ut en melding om at alt er klart, for så å få mange svar om at nettstedet ikke virker. Det kan hende det fungerer om 15 minutter, fordi endringen ennå ikke er spredd. Denne forståelsen reduserer unødvendig panikk på lanseringsdagen.

Ben Aston

Det er gode råd om lansering. Ofte er vi så oppslukt av utviklingen at vi først dagen før lansering begynner å tenke på DNS, innlogginger og tilganger. Da oppdager vi kanskje at ingen kjenner innloggingsopplysningene, eller at personen som gjør det, er på ferie.

La oss gå tilbake til utviklingsprosessen. Hvordan styrer du utviklere når prosjektlederen ikke er teknisk og ikke kan se hva de faktisk gjør? De skriver kode, du spør om oppgaven er ferdig, og de svarer ja – men mener egentlig «nesten». Hvordan håndterer du det?

Rich Butkevic

En iterativ tilnærming er svært nyttig. Da får du mulighet til å se noe som fungerer eller ikke fungerer i en demonstrasjon på skjermen. Det hjelper deg med å oppdage problemer tidlig og se om fremdriften er slik den skal være.

Jeg kan heller ikke understreke nok hvor viktig det er å unngå lange opphold mellom møter og oppdateringer. Jeg ønsker ikke møter bare for møtenes skyld, men et fem minutters daglig eller annenhver dag langt stående møte kan holde arbeidet på sporet. Dette er vanlig i Scrum, men kan brukes uansett utviklingsmetode. Jo oftere dere holder ting friskt i minnet, følger opp og løser problemer, desto større er sjansen for at prosjektet holder kursen.

Ben Aston

Fremdrift er viktig. Vi må fortsette å ha demonstrasjoner og bygge noe som kan vurderes. Ved slutten av uken kan utvikleren vise frem navigasjonsmenyen. Da oppdager du kanskje at den fungerer på datamaskinen, men ikke på telefonen. Det er mye bedre å oppdage slike problemer tidlig.

Regelmessige sprintdemonstrasjoner, fremvisning av arbeid underveis og daglige oppdateringer hjelper oss med å unngå tåken som oppstår når utviklere arbeider alene i seks uker og vi først da oppdager at resultatet ikke er riktig.

For de som lytter halvt i bilen: Vi har snakket om oppdagelse, planlegging, design, utvikling og lansering. Hva er ett enkelt råd til noen som skal lede eller allerede leder et prosjekt for et bedriftsnettsted? Hvordan sikrer vi at prosjektet lykkes og holder kontroll på budsjett og tidsplan?

Rich Butkevic

Det handler om en kombinasjon av det vi allerede har snakket om. Godt samarbeid er viktig, og et verktøy kan hjelpe med å legge til rette for det. Daglige stående møter er nyttige fordi de gjør det mulig å oppdage mange problemer tidlig. Jo kortere tilbakemeldingssløyfen er, desto bedre.

I en agil tilnærming brytes sløyfen ned i for eksempel toukersperioder der dere demonstrerer noe reelt. Deretter brytes den videre ned gjennom daglige møter. Med Slack eller et annet samarbeidsverktøy kan dere ta opp problemer med en gang, i stedet for at noen venter til neste dag eller neste sprint.

En annen ting vi ikke har snakket om, er å gjennomsøke nettstedet for ødelagte lenker før lansering. Det avdekker mange problemer som ofte blir oversett. Som prosjektleder pleier jeg uken før lansering å kjøre en gjennomgang av nettstedet. Da kan du oppdage feil i koden, organisatoriske problemer eller tekniske problemer. Det er en enkel måte å avdekke store feil på.

Ben Aston

Har du noen råd om hva man kan bruke til å gjennomsøke nettstedet?

Rich Butkevic

Ikke noe spesielt. De fungerer stort sett på samme måte. Jeg ville søkt på nettet etter en lenkesjekk eller et verktøy for kontroll av lenker.

Ben Aston

Noe som sjekker lenker.

Rich Butkevic

Det kommer an på om du bygger et helt nytt nettsted eller redesigner et eksisterende, og om verktøyet må kjøres internt eller utenfra. Det finnes noen nyanser, men det viktigste er å sørge for at du gjør det. Det gir stor verdi.

Ben Aston

Tusen takk for at du ble med oss, Rich. Det mest verdifulle vi har snakket om, er den tidlige delen av prosjektet: å få briefen riktig og definere mål og hensikt tydelig fra starten. Alt annet bygger på dette. Vi har ikke snakket så mye om fasen etter lansering, men det er viktig å evaluere resultatene. Hvis vi har fulgt målene gjennom hele prosjektet, er det lettere å se at nettstedet gir resultater, avkastning og verdi. Det er svært viktig å starte riktig.

Rich Butkevic

Takk, Ben. Det har vært flott å være her sammen med deg.

Ben Aston

Det har vært flott å ha deg med. Hva er dine råd, tips og triks for nettstedprosjekter? Hva har fungert, og hva har ikke fungert? Hvis du har historier om feil eller suksesser, kan du fortelle oss om dem i kommentarfeltet. Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med i fellesskapet vårt gjennom DPM-medlemskapet. Der finner du mange nyttige ressurser, blant annet prosjektplaner for store nettstedprosjekter med ulike metoder, sprinter eller en mer fossefallsbasert tilnærming.

Du får tilgang til Slack-teamet vårt, maler, kurs, kontortid, e-bøker og mer. Hvis du likte det du hørte i dag, kan du abonnere, bruke et par minutter på å gi oss en ærlig vurdering og takke for at du lyttet. Vi høres neste gang. Ta vare på deg selv.