Markedet for webplatforme er umodent. For dig som køber kan det derfor komme som en overraskelse, når funktioner, du tog for givet, ikke er med i det købte produkt, men skal specialudvikles. Det kan være gammelkendte standarder fra nettet, som ikke er understøttet, eller features, som slutbrugerne mest oplever som fejl. Inden du går i gang med valg af platform, er det derfor centralt, at du har afdækket selv ret basale behov – og konfronteret dem med standardprodukternes virkelighed.
For at navigere fri af de værste farer må du afklare to centrale spørgsmål:
1. Hvad forventer brugerne?
2. Hvordan skal systemet passe ind i eksisterende processer?
Første fare: Jeg får for lidt
Nettet er en del af folks dagligdag, og browser-baserede systemer er normen på arbejdspladser. Derfor kender dine kolleger alt til, hvad webmediet kan og forventer, at deres organisations systemer er på højde med, hvad de ellers har set.
Det er desværre langt fra altid tilfældet: Mange systemer undlader at understøtte basale kendte standarder. Et simpelt krav som det at lave bogmærker – altså links fra ét sted på en webside til et andet – er langt fra understøttet af alle. Redaktører må derfor ofte ty til at skrive XHTML kode – hvilket de færreste er fortrolige med.
Fra Microsoft Office-pakken ved folk, hvordan man vælger en fil ved at browse efter den. Konceptuelt er det samme operation som at lave et link fra en side til en anden på sin hjemmeside eller intranet: Redaktører bør kunne browse efter den side, de vil linke til. Imidlertid kræver velansete og udbredte systemer som Microsoft SharePoint, at de manuelt kopierer en sides adresse, når de vil linke til den.
Anden fare: Jeg får det forkerte
En anden risiko for at ende med et system, der ikke passer til ens krav, er, at man vælger den tekniske løsning uden at have afdækket organisationens processer og behov tilstrækkeligt.
Her kan rettigheder være et problemområde. En systemadministrator har omfattende rettigheder til at ændre i et system eller slette hele hjemmesider. Hvis administrator-rollen samtidig er den eneste rolle, der kan tildele adgang til et system med mange brugere, står man i et ubehageligt dilemma: Enten at gøre en højtlønnet administrator til flaskehals på en rutineopgave eller at bryde sikkerhedsforskrifter ved at dele administrator-rollen bredere. Et sted som finanssektoren, hvor fokus på sikkerhed er kritisk, vil man reelt blive tvunget til det første valg. BEA Weblogic Portals indbyggede CMS og Google Search Appliance er eksempler på systemer, hvor for få niveauer af rettigheder kan være et problem.
Tredje fare: Jeg får for meget
I IT-udvikling trives en myte om, at fleksibilitet og mange muligheder altid er af det gode. Men hvis brugerne bare vil lave en ny artikel, så forstyrrer det, hvis de hver gang skal vælge mellem otte filtypemuligheder med kryptiske navne. Ligeledes kan et hav af knapper til at formatere tekst i alskens farver og størrelser ende med at gøre hjemmesiden svær at læse og navigere på, hvis webredaktørerne gør brug af de uensartede muligheder.
Fjerde fare: Jeg får kun noget på papiret
En fjerde fare er, at mit system kun er en ramme – før det giver værdi, skal funktionerne kodes særskilt. Du tror, at du bare skal sætte cd’en i og installere programmet for at få adgang til alle de funktioner, salgsfolkene promoverede. I stedet ender du med en regning på hundredvis af udviklingstimer, før du får den ønskede værdi.
Hvad kan jeg gøre for at få det rigtige?
Du skal have godt styr på dine kollegers behov: Et godt udgangspunkt er at klarlægge, i hvilken grad der trækkes på standarder fra web, Office og Windows i det system, du har i kikkerten. Det vil spare træning og give mere tilfredse brugere.
Du skal vide, hvilke scenarier og processer I ønsker understøttet, men det betyder ikke, at du skal skrive tykke kravspecifikationer. I stedet kan du bruge disse retningslinjer:
- Produkttestning er uomgængelig
Inviter brugerne til at medbringe scenarier og procesdiagrammer til produktdemonstrationer, hvor der demonstreres hvordan og hvor godt funktioner udføres. - Vær kritisk i leverandør-mødet
Kan systemet udføre denne standardfunktion out-of-the-box? Hvordan? Kan mangler omgås? Kan der laves tilpasning, som vil være understøttet i opgraderinger i fremtiden? Sørg for, at beslutningstagerne er til stede, når de kritiske spørgsmål stilles. - Træk på andres erfaringer
Søg information fra kundereferencer, rapporter, nettet og dit netværk uden for din organisation - Regn aldrig med den næste version
Din indflydelse på den videre udvikling af dit valgte system er lille. Den næste version er sjældent forbedret mere end 10-20 %. Opgraderinger kommer næsten altid senere end planlagt, og leverandørerne satser ofte mere på ny funktionalitet end på at rette basale mangler i tidligere versioner.
Endelig kan du begrænse risikoen ved at starte i det små med simple krav først og afprøve et nyt system på et område, der ikke gør så ondt. Det kan også være en idé at bryde udrulningen af et nyt produkt op i mindre leverancer, der implementeres hvert kvarte eller halve år.
Held og lykke med dine projekter!
Lær mere:
- Artikel: En kort kravspecifikation
- Artikel: Et muligt alternativ til kravspecifikationer?
- Artikel: CMS Watch: A Scenario-based Approach to Evaluating CMS Vendors
- Research: Real Story Group > Research
- Læs andre artikler på J. Boye
Ansøg om medlemsskab af en erfa-gruppe, deltag i vores internationale webkonferencer, eller overvej at deltage i et kursus. Hvis du har spørgsmål, kommentarer eller bemærkninger vedr. artiklen, så hører vi meget gerne fra dig.
