Offentlige konkurranser kan bli unødvendig kompliserte. Her er tingene du ikke trenger å ta med! Dette gjør jobben enklere for både utlyser og leverandør – og konkurransen mer profesjonell.
PS: Alle eksemplene er fra faktiske anbud.
“Grensesnittet skal være brukervennlig”
Dette er selvsagt svært viktig. Problemet er at alle leverandører vil påstå at systemet er brukervennlig, og det vil være vanskelig for utlyseren å gi en score uten å faktisk teste hvert system. Dersom dere ønsker å skille klinten fra hveten, kan man presisere med det man faktisk har i tankene, f.eks: “Admingrensesnittet skal kunne brukes på mobil”.
“Publiseringsløsningen skal støtte responsive design”
Dette er unødvendig å ta med av to grunner: Så fremt websiden skal designes, gir publiseringsløsningen ingen føringer for stilarket. For det andre er responsive design en selvfølgelighet i 2017. En bedre formulering er: Beskriv deres prosess for design og front-end implementering.
“Løsningen bør støtte god SEO”
Dette er en uheldig formulering, siden selv håpløse systemer kan gi god SEO dersom verdiene er hardkodet. Og enda viktigere: det er innholdsprosessen som vanligvis har størst innflytelse på resultatet. Dersom redigeringsmuligheter er viktig, fokuser på dette. En bedre formulering, er: Systemet bør støtte redigering av H1, title tag og meta description per side.
“Løsningen må ha en WYSIWYG”
Dersom utlysningen omfatter et CMS, vil det være umulig å finne en løsning uten. Kravet er derfor unødvendig.
“Støtte for krysspublisering”
Alle systemer kan tagge en artikkel. Hva annet har man egentlig i tankene?
“Det skal være mulig å bruke Google Analytics”
Igjen: Det er ingen løsninger som vil hindre deg i dette. Spør heller etter kompetanse på Analytics, kanskje?
“Innhold skal kunne skrives ut”
Alt på web kan skrives ut, spørsmålet er bare hvordan det skal se ut – og det bør besluttes i designprosjektet. Det er bedre å levere en mal for print-design dersom denne finnes, eller å be om design og implementering for gitte sidemaler.
“Vi bør kunne redigere CSS og kode i CMS-et”
Moderne webutvikling lagrer ikke kode i databasen, men benytter Git versjonskontroll. Et mer fornuftig krav, kan være: “Våre utviklere skal ha skrivetilgang til kodens Git repository”.
“Webredaktør skal ha stor frihet i hvordan hun ønsker å vise innhold på sidene”
Kravet mangler presisjon, og det blir derfor nesten umulig å vite når kravet er innfridd. Videre vet man lite om hva slags verdi dette vil gi – kanskje gjør det arbeidsflyten mer krevende, samtidig som prosjektet blir dyrere? Dropp kravet, eller vær tydelig.
“Løsningen skal støttes alle nettlesere”
Kravet er urimelig. Sjekk Google Analytics, og list opp nettleserversjoner som står for mer enn 0,5% av trafikken.
“Man skal kunne bruke FTP for opplasting”
FTP er en gammeldags protokoll med innebygd sikkerhetsproblemer. Dropp kravet, og be heller leverandøren beskrive andre løsninger.
“Filer skal kunne organiseres i en mappestruktur”
Moderne CMS-er har heldigvis kommet lenger enn at en fil må ligge i én mappe; det er ikke lenger slik man organiserer filer for web. Etterspør bare en fleksibel kategorisering.
“Man må kunne legge inn bilder i artikler” eller “Innhold skal kunne kategoriseres”
Slike krav er unødvendige; det finnes ingen webløsninger som ikke støtter dette. Spar plassen!
“Artikler skal kunne vises i listeform og i en grid”
Slike eksempler finnes det mange av, nemlig tekstlige beskrivelser av hvordan noe skal se ut. Slike valg gjøres bedre i et designprosjekt, og bør ikke låses i en teknisk spesifikasjon.
“Tilleggsfunksjonalitet”
Mange anbud inneholder omfattende krav som ikke teller inn i konkurransen. Dette er gjerne integrasjoner mot tredjepartssystemer, eller tanker om noe som kanskje kan gjøres i en fjern fremtid. Slike krav stjeler mye tid for leverandøren, og er også de som gir flest spørsmål til kunden. Fremfor å inkludere mulige fremtidsplaner i kravtabellen, kan dette heller opplyses om i en egen tekst. Da slipper man å bruke tid på tekster som bidrar lite til å avklare hvem som bør vinne oppdraget.
“Løsningen skal støtte Universell Utforming”
UU er viktig; dette er lovpålagt fra 2014. Nettopp derfor gir kravet lite verdi i i seg selv. Etterspør heller kompetanse! Be leverandøren beskrive hvordan de planlegger, designer og tester for Universell Utforming i sine prosjekter.
Hva skal man da spørre om?
Dette blir tema i et senere blogginnlegg – her har jeg enda sterkere meninger.
Leave your reply