I dagens Computer Sweden meddelas att ”Riksbyggens CIO släpper taget”. Förhoppningsvis faller han inte handlöst – vad han gör är att minska sin egen budget med 98%; pengar som istälet förs över till verksamheten, utan att vara öronmärkta för IT. Meningen är att man genom detta ska göra det möjligt för verksamheterna att själva driva processen kring sina behov och de möjligen IT-baserade stödsystem de kan vilja ha.
Hallelulja!
…men nej? Vadnudå?
Ingen nämnd, ingen uthängd, men genom åren som konsult, drygt 20, har jag jobbat med ett brett spektrum av företag och verksamheter och då kunnat se effekten av ett stort antal sätt att organisera sin IT-verksamhet och sin affärsutveckling. Och min spontana reaktion är att även om intentionerna är värda att applådera är den praktiska effekten av vad Riksbyggen nu tänker göra att varje enskilt stuprör skapar sina egna IT-system och tjänster.
Affären och verksamheten i stort (och användare, både internt och externt) skulle vinna på att systemen delade information. Men eftersom varje låda äger sin egen unika aspekt av den gemensamma informationsmängden även rent ekonomiskt och i sin unika roll kanske inte får ut så mycket av samordning så blir det ingen samordning. För det kostar pengar.
Varje chef värnar om sina siffror. Helheten blir ett ansvar för VD eller GD och om de inte skapar incitamentmodeller och tydlig ekonomisk styrning som premierar samordning så blir det inte heller något med saken.
För även om alla inblandade förstår problematiken så är det inte på helheten utan på det egna resultatet man mäts.
Jag har sett det igen och igen och igen; hur intressenternas behov och förväntningar ligger på en nivå som de faktiska styrmedlen och systemägarstrukturerna inte klarar av att möta, och det är aldrig styrmedlen eller systemägandet som får stryka på foten – det får verksamhetens affär eller verksamhet göra istället.
Självklart hoppas jag att jag har fel. Jag håller tummarna för att man på Riksbyggen faktiskt ändrat inte bara i budgetfördelningen.
Hoppas hoppas…
Fantastiska utvecklare!
Vi arbetar i ett företag som har helhetsåtaganden. Ibland blir det bökigt men oftast är det trevligt. Bökigt närvi slåss om samma budget men trevligt när alla drar år samma håll – den mest användbara lösningen med givna förutsättningar.
Det sitter ett gäng utvecklare som möts minst en gång i månaden för att lära sig saker, teammöten helt enkelt. Vilken glädje när de ringer upp och vill veta vad vi som arbetar med User Experience inom vårt företag gör.
” Vi vill tänka lite mer som ni gör….” är deras önskan. ” Kan ni inte komma och berätta hur vi ska tänka. ”
Lycka är att samarbeta med folk som vill vidga sitt yrkeskunnande! Klart att vi åkte dit och berättade.
Ett användarperspektiv i balans med kundnytta och duktiga utvecklare. Kan man ha en bättre början på ett systemutvecklingprojekt?
I dagens Computer Sweden finns en artikel benämnd Olika projekt – olika utmaningar. För webbprojekt tar man upp att ny teknik komplicerar saken. Ursäkta? Ny teknik?!?! På vilken planet då? Jag gjorde mitt första webbprojekt våren 1995, om jag inte minns fel. Då hade några kollegor redan gjort andra webbar, under hösten 1994. Och när ett vinstdrivande, börsnoterat, konsultföretag gör såna uppdrag, då är det inte direkt på skoj.
Sedan 28 dagar är vi inne i 2009. 2009-1995=14 år. Jag ska villigt erkänna att det hänt en del sedan dess, men inte så mycket som man kan tro. Nångång 1998/99 började man medvetet skilja innehåll från formatering och det enda som EGENTLIGEN hänt sen dess är att datorerna blivit fler och att nätverken blivit snabbare. Ajax och alla andra bokstavskombinationer i all ära, särskilt svårartat är det inte.
Artikeln är genomgående ytlig. Under rubriken ”Få med användare” sägs ”Men gör klart från början att det är fullkomligt nödvändigt att få deras engagemang – annars är projektet i det närmaste dödfött.” Nu är det ju så att det inte är ”användarna” själva som avgör nivån på sitt engagemang, utan cheferna som prioriterar deras arbetsuppgifter. Användarengagemang är således inte en individfråga utan en ledningsfråga.
Notera att jag inte klassificerar användningstester som ”användarengagemang’; det verkar inte heller vara vad artikeln avser – min tolkning är att det handlar om att ta användarna till hjälp vid definiering och avgränsning av krav- och målbild.
Min personliga erfarenhet är att det största problemet i dessa sammanhang är att projekten drivs som IT-projekt, inte som verksamhetsprojekt, och drivs de som verksamhetsprojekt är inte upplösningen god nog för att kunna fungera som underlag i ett implementationsprojekt. Båda scenariona medför oplanerat – OBUDGETERAT! – merarbete och ökad risk för att slutprodukten inte motsvarar förväntan.
Ett annat vanligt problem är att beställaren detaljstyrt kraven i upphandlingen av ett implementationsprojekt men har missat flera avgörande delar, varför ytterligare (återigen obudgeterat) kravarbete måste till.
Att skylla på ny teknik eller på för dåligt användarengagemang är undanflykter; dimridåer utlagda för att dölja de verkliga problemen, och bidrar till att minska sannolikheten att projekten ska kunna genomföras på ett bra sätt.
Det är märkligt hur ofta fokus ligger på presentation istället för på insamling och inlämning av data. Många långa meningar har talats och skrivits om vikten av transparens, om att tillhandahålla den information som ”användaren” verkligen behöver, om kanaler för kommunikation.
Vad få talar om är hur informationen ska hamna där.
Normalanvändaren på företag A eller myndighet B eller vårdinrättning C har helt andra saker att fokusera på än att lära sig hur CMS:et funkar i MOSS eller EPi eller WebSphere eller allt vad de heter.
Ja, de går på kurs. Nej, de minns inte riktigt hur man skulle göra, sen när det väl är dags att skriva något. Nej, systemen är inte intuitiva. Särskilt inte för sällananvändare.
Resultatet blir låg kvalitet i informationen, vilket i sin tur resulterar i lågt användande.
Tyvärr har leverantörerna av sagda system ingen som helst insikt i att det huvudsakligen är backend som deras system fallerar. Istället pratar de om integration med funktionalitet X och Y, eller om möjligheterna att anpassa presentationsmallarna.
Lägg lite krut på att göra de gränssnitt som ska användas för informationslämning mer intuitiva, och inse att egennyttan regerar – ingen vill bara ge och ge, man vill ha något tillbaka också. Varför ska jag göra denna ansträngning om jag inte får något tillbaka också?
Dags för tillverkarna av standardsystemen att börja bry sig om användbarheten. På riktigt.
(Ett annat problem är att beställare, leverantörer, etc. fortfarande, år 2007, tror att ”intranät” är synonymt med ”personaltidning på nätet’. Pinsamt. Men det är en fråga för ett annat inlägg.)
Då och då träffar man på konsulter (och beställare) som tvärsäkert hävdar att personlig erfarenhet av de lösningar man ska implementera inte är en nödvändig faktor om man vill leverera kvalitativa IT-lösningar. Som argument hävdar de att om erfarenhet vore en förutsättning skulle ingen utveckling ske, och vid första anblicken är det ett argument som är svårt att överbevisa. Men är det verkligen ett motsatsförhållande?
Är det inte snarare så att det är ur erfarenheten som idéer om behov och lösningar kläcks? ”Tänk om…”
Kanske att ren metodkunskap räcker för att kartlägga och prioritera behov och krav, men när det kommer till att faktiskt möta dessa behov med funktionalitet och processtöd kan personlig erfarenhet vara en avgörande faktor för om lösningen faktiskt kommer fungera även i praktiken.
Så kan exempelvis den oerfarne välja att satsa på commmunities eller chattforum, när den erfarne har misslyckats några gånger och därför kan ha en aning om vad som krävs för att sådana fora ska fungera.
Och hur bygger man bäst ett intranät vars syfte är att ena företagets skilda kulturer samt att synliggöra ledningen? Vilka ”funktioner” ska man satsa på?
För kanske är det inte ens funktionaliteten som är det viktiga, utan utförandet – exempelvis gränssnittets känsla av transparens i informationsflödet – som är det avgörande?
Även i nästa steg – den konkreta impelmentationen, när intranätet sätts ihop eller byggs – är erfarenhet en förutsättning. Erfarna systemutvecklare slipper göra banala misstag som i ett senare skede resulterar i vad man kan tycka är onödiga supportkostnader och system som fungerar på märkliga sätt.
För det är just det erfarenhet är – att ha lärt sig något av sina misstag, och använda den kunskapen för att lösa problemet på ett bättre och mer effektivt sätt nästa gång. Och det är också det som är en del av det som kallas utveckling.
Plötsligt är inte argumentet om att även den i det praktiktiska utförandet oerfarne är lämpad att föreslå lösningar så självklart, utan kan snarare ses som en rationalisering från den som aldrig behövt realisera ett koncept och som aldrig behövt lära av sina misstag.
Och plötsligt går det att förstå varför så många teoretiskt smarta lösningar inte fungerade i praktiken…
Disclaimer: Observera att ovanstående inte argumenterar för att man alltid ska använda supererfarna konsulter. På något sätt måste man ju lära sig! Däremot ska man vara medveten om att det finns folk där ute som låter kunniga och bra men som bara säljer gammal ost och inte orkar eller vågar lära. Och det är dem man måste kunna identifiera och nobba.
Andra bloggar om: verksamhetsnytta, användbarhet, erfarenhet, implementering
Pella Bergquist
Ylva Betinakis
Maria
Christer Rindebäck
