Jobba smartare genom att återanvända information och dela den med andra. Säkert har din organisation en massa bra information, det är bara det att den är spridd på olika ställen, och kanske till och med är det enstaka personer som besitter den.
I denna artikel ger jag tips om hur du och din organisation kan jobba mot enhetlighet i processer, produktutveckling och designlösningar. En del av informationen är viktig för internt bruk i din organisation, medan andra tar sig uttryck i användarnas upplevelse av produkter och tjänster.
”Enforce consistensy in architecture and designed solutions”.
En väl fungerande kunskapsbank gör att människor bidrar med sin kunskap och dessutom delar med sig till andra. En kunskapsbank kan till exempel innehålla begreppslistor, informationsarkitektur och informationsmodeller, principer för lösningsarkitektur och systemlogik (till exempel regelverk för beräkningar), UX guidelines och designmönster, grafisk profil, dokument på genomförda användningstester etc etc.
Generiska krav passar utmärkt i en kunskapsbank. Läs gärna ett av mina tidigare blogginlägg:
> Återanvänd kraven
Det är smart att återanvända krav, och jag kan inte se någon motsats till det agila manifestet genom att dokumentera dem. Att arbeta enligt agila metoder innebär inte att teamen ska sluta dokumentera, det är bara en princip om vad som är viktigast.
> Läs det agila manifestet
Frontend style guides används inom systemutveckling för att återanvända designmönster och information i mjukvara. Detta kan låta ambitiöst, men vinsterna är många både för UX-team, utvecklare och andra intressenter.
Om du vill veta mer om värdet av frontend style guides och vad de bör innehålla, läs artikeln på Norman Nielsen Group:
> What is a frontend style guide
Exempel på hur en frontend style guide kan se ut finns här (detta exempel vänder sig både till den egna organisationen och till utvecklare som bygger webbplatser till kunder):
> Episerver frontend style guide
Det finns även organisationer som tagit fram style guides om hur dokumentation till olika användargrupper ska skrivas vad gäller ordval, format och språklig stil. Här är ett par exempel:
> Myndigheten för tillgängliga medier (Lättläst)
> Mailchimp style guide (voice and tone)
Tips på hur du skapar en kunskapsbank:
Ställ frågan ”Varför”
Det första många kommer att tänka på är valet av verktyg. Syfte och innehåll är viktigare.
Formulera vad som är målet med kunskapsbanken för dig och din organisation och hur ni når dit eftersom konceptet bygger på att användarna själva bidrar med innehållet. Börja prata med folk, och ta temperaturen på intresset av en kunskapsbank. När detta är klart så sätt igång i liten skala, fastna inte i analysfasen och perfektionssjukan.
Personligen har jag bra erfarenhet av att skapa kunskapsbanker på Wiki-sidor. Men det beror snarare på att sätta upp en strategi för att bygga upp kunskapsbanken än själva valet av verktyg.
Både Confluence och SharePoint har utmärkt stöd för Wiki-sidor. Dessutom finns alltid den senaste versionen av informationen publicerad. Det gäller att ha rätt ambitionsnivå i början som jag skrev om i en tidigare artikel:
Läs gärna ett av mina tidigare blogginlägg:
> Ställ rätt krav på verktyg för kravhantering – 4 tips
Skapa samarbete över avdelningsgränserna
För att få ut maximal nytta av kunskapsbanken på kort och lång sikt, är det viktigt att IT, förvaltning och verksamhet använder en och samma plats. Problemet idag är ju att regelverk, principer och generiska krav finns utspridda på olika ställen i organisationen. Bygg och dela med varandra!
Tänk innehåll före struktur
Bygg sidor i en platt struktur. Startsidan är väldigt viktig och fungerar ungefär som en portal till kunskapsbanken, sätt därför upp en ”innehållsförteckning” med korta introduktionstexter. Därför är det viktigt att startsidan är så pass flexibel att det blir möjligt att bygga ut den när antalet ämnesområden och sidor växer. Det viktigaste är länkningen mellan sidorna.
Menyer kan leda till att det blir rörigt och svårt att hitta information. Vänta med att bygga ut en meny till vänster till att börja med. Det kan vara viktigare att ha en knapp eller menyalternativ för att återvända till startsidan.
Om det redan finns relevant och aktuellt innehåll på intranätet kan det under en övergångstid vara bättre att länka till det materialet i kunskapsbanken istället för att ha duplicerat material i parallella miljöer. Självfallet bör helst allt relevant och aktuellt innehåll på intranätet och andra ställen flyttas över till kunskapsbanken.
Kommunicera
Löpande kommunikation är viktigt om arbetet som pågår att bygga upp kunskapsbanken och vad som behöver göras, exempelvis i veckobrev och olika möten. Lika viktigt är att kommunicera en vision om att vi alla delar med oss av kunskap och erfarenheter (skulle lika gärna kunna vara en princip på högsta nivån). Besluta vad informationsägare och ämnesansvarig ska göra, och hur alla kan vara med och bidra. Ge kunskapsbanken tid – attityder går ganska enkelt och snabbt att påverka, men värderingar och beteenden tar betydligt längre tid.
Tillsätt en arbetsgrupp
Denna arbetsgrupp behöver vara dedikerad till sin uppgift att identifiera och acceptera generiska krav (alternera efter 6 månader med ny konstellation personer). Ta gärna vara på entusiastiska personer som vill ha denna förändring att öppet dela information, kanske någon är särskilt lämpad att leda förändringen. Denna arbetsgrupp består lämpligen av personer som representanter från exempelvis följande områden:
• Informations- eller lösningsarkitekt
• Kravanalytiker
• Testledare
• Verksamhetsarkitekt
• Förvaltningsledare
• Objektägare
• Övrigt, representant från Compliance, juridisk enhet
Bygg och underhåll innehållet
Utse informationsägare med ansvar för att informationen inom varje område uppdateras och ämnesansvariga med ansvar för att informationen inom varje specialområde är korrekt. Diskutera hur innehållet ska kategoriseras, alltså hur de ska taggas för bra filtrering för att hitta information.
Använd samma språk
Skapa en begreppslista i kunskapsbanken som är en gemensam modell för användning av begrepp för såväl verksamheten som de generiska kraven. Så att alla talar samma språk och har en gemensam förståelse för hur begreppen ska användas. Det är väldigt viktigt och förhindrar många missförstånd.
Identifiera och prioritera ämnesområden
Prioritera arkitektur och verksamhetskrav om det tyder på att det är efterfrågade ämnesområden. Fortsätt göra behovsinventering, där kanske framgår att processer samt roller och behov, verksamhetskrav, produktdata med configuration management är efterfrågat. Med en platt struktur går det att utöka antalet sidor och ändå kunna ha en stabil struktur, vilket kan åstadkommas genom startsidan, kategorisering och länkar.
Sätt upp principer
Principer fungerar som ledstjärnor, prioritera vad som är viktigt för organisationen som helhet. Ett exempel på princip kan vara ”Vi ska inte bygga webbplatser eller IT-system, vi ska skapa digitala tjänster”.
Fortsätt bygga mer innehåll
Gruppen bör träffas åtminstone varje vecka i början för att arbetet ska gå framåt. Håll workshops istället för långdragna diskussionsmöten. Jobba iterativt och bygg upp innehållet lite i taget med ständiga förbättringar. Avveckla samtidigt duplicerat innehåll på andra ställen! Fortsätt arbetet att skapa en kultur där vi delar med oss och arbetar tillsammans! Besluta vad informationsägare och ämnesansvarig ska göra, och hur alla kan vara med och bidra. Iterera, iterera igen. Bygg och dela med varandra!
Låter det jobbigt? Nej, inte om ni börjar i liten skala och lyckas skapa en kultur att dela information med varandra. Och ha roligt på vägen!
Författare: Helén Alseby, agil produktägare samt krav- och verksamhetsanalytiker
Tyckte du om denna artikel? Dela gärna! > Läs fler artiklar
Vill du ställa en fråga eller tipsa om något du vill läsa om? > Välkommen att höra av dig